Bare-Bones Intro to Textures & Programmable Pipeline

Shared Code
#1

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.

The original minimal examples will be hosted on the Wiki. Small guides or tutorials may be included there, as well:

–

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
[]A simple ShaderProgram utility class to load and bind shaders (inspired by ra4king’s code)
[]A simple abstraction of “vertex data” – aka for Vertex Arrays, Vertex Buffer Objects, etc. (So far only vertex arrays has been implemented.)
[]Utilities for creating an orthographic 2D projection matrix (origin top-left)
[]A simple SpriteBatch, demonstrating how to put it all together to draw potentially thousands of sprites efficiently

–

Source: https://github.com/mattdesl/lwjgl-basics (BSD license)

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. :slight_smile: Let me know if there are features/extensions you’d like added…

P.S. Yes, you can probably tell the package structure was inspired by LibGDX…

#2

Good luck!

#3

Very good library.

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.

Good work and thank you davedes! :slight_smile:

#4

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… :yawn:

#5

Here is a feature request, it may sound somehow abstruse, but yeah:

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.

#6

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.

#7

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…

#8

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.

#9

yeah, right… premature optimization :wink:

#10

Come on guys shaders are really really easy to use :slight_smile:
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.

here the requested shader, which results in white triangles


void main()
{
   gl_FragColor = vec4(1.);
}
#11

Medal because of this awesome quote :wink:

#12

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. :slight_smile:

#13

I’ve changed the spritebatch to include a View matrix. This works perfectly, and was tested in the VertexArrayExample.java class.

Propably you don’t want it, but if you do, how do I “submit” my change?

EDIT: Also, the View matrix is optional, so the user doesn’t have to fiddle around with it.

#14

You can send pull requests which I will then accept or reject. :slight_smile:

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.

#15

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.

#16

Okey… Propably I need a second git course… or a better, a complete one…

Sending you a PM.

#17

Nevermind, got it working:

I would have never thought I’d manage to do that alone :stuck_out_tongue:

#18

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. :slight_smile: I’ll accept it for now and tweak the SpriteBatch a bit more over the weekend.

#19

Oh wonderful :slight_smile:
Good suggestions, btw… I think I’ll try this idea out myself too.

#20

I have to say, not many projects I see on Github can boast that their latest changes were made 32 minutes ago.

Cheers, and good job! :smiley: