questions on opengl, lwjgl(slick util)

six months of developing a 2d game/engine using lwjgl and slick util has led me pondering the following questions. I’m greatful for whatever answers you might have.

  1. Just how expensive is the texture.bind() operation? Is it worth learning about, enable and use the openGL z-buffer to make sure that each texture is only bound once? Remember, 2d game…

2 in slick util, when creating a new texture, the actual texture will still be loaded in the CPU’s/VPU’s physical memory after the actual texure class has been garbage collected?

  1. texture.release() in slick util, what does it do? Should it be used when you’ve compleately finished using a texture? Will it release the resources?

  2. Display.releaseContext(), what does this do? Does it release all textures?

  3. What about sounds? slick-util makes use of openAl if I’ve understood things correctly. If I create a new slick-util sound and then java garbage-collects that instance, I presume that the sound will still be occupying memory somewhere and slow things down. Can I make sure that a sound is properly released?

  4. when creating a texture in slick util, is it stored on the Vcards physical memory? If so, Approximatly, how much space does a png occupy? 32-bit/pixel? How do I know when I’m stressing my graphics card?

  5. is there a conventional way to store sprites in a java-game. In my case I have sprite-sheets, 128x128px - 2048x2048px. Some spriteSheets are “symmetrical”, which means that all sprites are 16x16 or 32x32… etc. For these I don’t need to specify any bounds. I simply have a class that takes a X and Y coordinate and renders that particular sprite. This is very effective. However, most spriteSheets are “dynamic”, which means that a sprite can have any size and be located anywhere. That means that for each sprite I need four unique coordinates, X1, X2, Y1, Y2.

First I used enums for this. like this:

pillar(1,4,67,48). The enum had the method render, which rendered the sprite. I moved away from this since enums are static and while each enum probably doesn’t take that much space and cost to create, I want to make my game as dynamic as possible and make sure that each state it’s in only uses the resources it really needs.

My current solution is to devide each spritesheet into an induvidual class. These classes have methods that returns a particular sprite, e.g:

public SPRITE getPillar(){return new SPRITE(1,45,1,67);}
public SPRITE getFountain(){return new SPRITE(2,45,3,56);}

this works pretty slick for for me, but is it a good practise?

  1. Depends on impl a bit and what generation you are working with and stuff. In general not the most expensive method but not to be abused either. If you can easily cut down on texture binds then great, if not then lets remember about how sick and evil premature optimization is.

  2. No.

  3. Don’t know the actual implementation in Slick (the method doc should really say) but I would guess yes - it releases the OpenGL texture object.

  4. Releases all textures, buffers, shaders etc. and the whole OpenGL context.

  5. Premature optimization again but if Slick has some kind of “Source” class, then I would expect that also has a “release()” method.

  6. A PNG is a compressed image file format. When you load a texture, it is stored in a non compressed format so it can be accessed quickly. How much space it takes up depends on the format you store it in. A typical RGBA format is 4 floats per pixel so will take up (roughly) 4 * 4 = 16 bytes per pixel. You will know when you’re video card is stressed when the program starts lagging. Premature optimization.

  7. I know of no conventional way. Your enum method sounded good. But do what is easier and what works. Premature optimization.