UPDATE:The code is undergoing changes. It's now becoming more of a utility library (the likes of SlickUtil, but cleaner and more modernized) rather than a bare-bones set of minimal code examples. Eventually I hope to turn it into a third party utility library for LWJGL 3.0.

There are plenty of tutorials and guides on the web, but not a lot of "complete source examples" that demonstrate the bare essentials of a modern GL app in Java (i.e. no fixed function). This isn't meant to be a tutorial/guide (at least not yet), but rather a source code reference for those trying to build their own 2D shader-based engines. It covers only the basics to get you started:

Basic LWJGL display creation

A simple Texture utility class to decode PNG files and load them into OpenGL textures

It's an early work in progress -- I hope to add more documentation and more examples, e.g. geometry shaders.

For now it uses VertexArrays (which are sometimes faster than VBOs). At some point I hope to add VBOs.

I didn't use GL3+ code or context since I'm running a 2.1 machine (as are many other Mac users). So while it may not truly be "modern GL," it does not use any fixed-function pipeline like glVertex2f or glTranslatef, and the concepts are more or less the same. Since we are using GLSL 120, attribute locations need to be passed to ShaderProgram, rather than defined in GLSL.

Cheers. Let me know if there are features/extensions you'd like added...

[size=5pt]P.S. Yes, you can probably tell the package structure was inspired by LibGDX...[/size]

Just some utilities.I don't like to stick to engines like Slick2D or libGDX, I like to pick the utilities I want to have. That's why I created a Utils project, and didn't gave a complete engine for Noise and other stuff to people.

That's just what I needed, and it works fast, is just the "bare bones" I needed and solved a problem I had for months.

Thanks. I may turn it into a "mini utils" package including TextureRegion, BitmapFont, and Color.. i.e. to completely replace SlickUtil as the "standard LWJGL starter kit." Although maybe that would be too much bloat...

I'd like to have a non-textured "mode" in the SpriteBatch, which should be somehow not so easy... propably... Because if you would want to do it "right" you'd need to switch to a shader, which doesn't does a texture lookup...

And secondly, which is very easy (and I have already implemented it) I would like to be able to tint different edges.

I'd like to have a non-textured "mode" in the SpriteBatch, which should be somehow not so easy... propably... Because if you would want to do it "right" you'd need to switch to a shader, which doesn't does a texture lookup...

And secondly, which is very easy (and I have already implemented it) I would like to be able to tint different edges.

I'd like to have a non-textured "mode" in the SpriteBatch, which should be somehow not so easy... propably... Because if you would want to do it "right" you'd need to switch to a shader, which doesn't does a texture lookup...

And secondly, which is very easy (and I have already implemented it) I would like to be able to tint different edges.

Just add a white texture and sample it. It'll just be multiplied with the color, which is just 1*color = color. The edge tint would be more difficult to implement I think.

I'd like to have a non-textured "mode" in the SpriteBatch, which should be somehow not so easy... propably... Because if you would want to do it "right" you'd need to switch to a shader, which doesn't does a texture lookup...

And secondly, which is very easy (and I have already implemented it) I would like to be able to tint different edges.

Just add a white texture and sample it. It'll just be multiplied with the color, which is just 1*color = color. The edge tint would be more difficult to implement I think.

Edge tint is easy, as you only need to change the attribute for each vertex.

But yeah, that's what I was talking about, when I said with "if you want to do it "right""...Texturelookups are costly...

Not if you're sampling the same place over and over again. There's a texture cache on the GPU making the texture read no more expensive than accessing the color variable. And let's face it, you're going to be CPU limited anyway, so what you win in CPU performance by batching is a lot more valuable than what you lose in GPU performance.

Not if you're sampling the same place over and over again. There's a texture cache on the GPU making the texture read no more expensive than accessing the color variable. And let's face it, you're going to be CPU limited anyway, so what you win in CPU performance by batching is a lot more valuable than what you lose in GPU performance.

Come on guys shaders are really really easy to use I know they are some sort of black box in the beginning, one always hear about the magically stuff they do, but have no clue how. Just read some mini tutorials and you are writing your first shader within a hour.Take a look at some beginner webgl tutorials, because webgl forces you to use shaders.

For plain or "non-textured" rectangles you should use a texture region (aka "sprite" in your "sprite sheet") that is a 1x1 white pixel. That way your rectangles can be pushed into the same batch as the rest of your sprites, without needing to compile a new shader or create a new OpenGL texture.

As the project grows, I will probably include a means of setting and getting projection and view matrices for the sprite batch. And, perhaps, some utility methods like translate/scale/rotate to easily affect the view matrix.

One issue is that it requires flushing the batch and sending a 4x4 matrix to the shader. This is why for individual sprite rotation it's often better to perform the rotation on the CPU, and send the transformed positions to GL. Ideally you should maximize batching and minimize glUniform calls.

One issue is that it requires flushing the batch and sending a 4x4 matrix to the shader. This is why for individual sprite rotation it's often better to perform the rotation on the CPU, and send the transformed positions to GL. Ideally you should maximize batching and minimize glUniform calls.

You're right, but I'm talking about a view Matrix. Which defines how the user looks at the world. Something like a game-viewport, a camera, which you can rotate and move and things like that.

And the camera (or actually view-) matrix is only set once, since you don't want to render some objects with different views.

One issue is that it requires flushing the batch and sending a 4x4 matrix to the shader. This is why for individual sprite rotation it's often better to perform the rotation on the CPU, and send the transformed positions to GL. Ideally you should maximize batching and minimize glUniform calls.

You're right, but I'm talking about a view Matrix. Which defines how the user looks at the world. Something like a game-viewport, a camera, which you can rotate and move and things like that.

And the camera (or actually view-) matrix is only set once, since you don't want to render some objects with different views.

IMO a better approach would be to combine the view and projection matrices on the CPU, thus only requiring us to store/send a single 4x4 matrix. The uniform would be called "projTrans" or "projView" or something.

I don't see an advantage of having an extra uniform and multiplying the matrices for every vertex, unless that is specifically required (in which case you should be extending SpriteBatch with custom features).

Thanks for the pull request, though. I'll accept it for now and tweak the SpriteBatch a bit more over the weekend.

One issue is that it requires flushing the batch and sending a 4x4 matrix to the shader. This is why for individual sprite rotation it's often better to perform the rotation on the CPU, and send the transformed positions to GL. Ideally you should maximize batching and minimize glUniform calls.

You're right, but I'm talking about a view Matrix. Which defines how the user looks at the world. Something like a game-viewport, a camera, which you can rotate and move and things like that.

And the camera (or actually view-) matrix is only set once, since you don't want to render some objects with different views.

IMO a better approach would be to combine the view and projection matrices on the CPU, thus only requiring us to store/send a single 4x4 matrix. The uniform would be called "projTrans" or "projView" or something.

I don't see an advantage of having an extra uniform and multiplying the matrices for every vertex, unless that is specifically required (in which case you should be extending SpriteBatch with custom features).

Thanks for the pull request, though. I'll accept it for now and tweak the SpriteBatch a bit more over the weekend.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org