Slick Forums

@Davedes
In your test case you call flush() on the batch... I copied the SpriteBatch but there is no flush-method

Ah okay for styled text I use a list of commands (like waveing a set of letters) Did not thought on other options xD

Nice, does this mean I can translate inside a bind/unbind? If so I love you

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

Ah, whoops. Made some local changes I forgot about. Here's the new version:
http://pastebin.com/HTCRgLkn


Since startUse/endUse uses glBegin/glEnd you can't use glRotate/glTranslate/etc. inside it.
The new drawEmbedded method transforms the vertices (same way ImageTransform did, basically) so that you can rotate images within startUse/endUse.

Started the test, with 2000 balls nothing else changed, but when using drawEmbedded (push Space once) I get more fps

So this means no translation huh? Dammit. Rotation is not the big deal but it would be awesome if I ould be able to translate inside a start/end by manipulating the vertex data. That's what I do when making a wave animation for a set of letters. I translate the current letter and translate back after drawing it.

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

What is the FPS difference? GPU/system specs?

I'm not sure why it's slower on your machine. In the end both are doing one draw call per frame, but drawEmbedded needs a lot of calls to glVertex, whereas the sprite batch does all of that in one go.

Might be that:

• Your driver optimizes for GL_QUAD, whereas the default sprite batch mode is GL_TRIANGLES (setUseTriangles changes this)
• The batch size given to glDrawArrays is too large, slowing things down
• The need to draw color info is slowing down SpriteBatch (drawEmbedded ignores it unless specified)

For typical use SpriteBatch will probably be faster than many calls to drawEmbedded as it will have fewer texture binds, render calls, etc. And for most machines it should perform far better, again I'm not sure why this isn't the case for you.

As for translation, this is definitely possible. I required it in my own game so I added a "translate" method to SpriteBatch:
http://pastebin.com/yV0NUrq7 (Ignore the VBO stuff as it isn't ready yet.)

Should work as expected.. Example:


Todos:

• Optional point sprite mode for faster rendering
• VBO + shader + instancing for newer GL versions
• Transform matrix to rotate/scale the batch (in addition to translate)
• Replace SpriteFont with Slick's AngelCodeFont

I will give you a detailed view today I I have the time. If not, sunday But I can tell you the deifference in fps it's 200 FPS. Normally it does something like 500 - 530 but with drawEmbedded it does 700-760.

Running on a Laptop with iCore 5 and NVidia GT 330MN (newiest Driver). System is Windows 7 64-bit.

Indeed, setting setUseTriangles to falsse increase the batch's speed to about 600-680

I will test the new batch later as said.

Edit:
maybe it's just the amount of code too. While drawEmbedded uses like... 20 lines of code the batch takes a lot more Should be a problem imho but it might slow down a lot of stuff.
Nice that you make translation possible, maybe you want to show that to badLogicGames since their batch does not support such stuff.

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

Let me just pop in real quick and take my hat of for this SpriteBatch stuff. Even without atlases or any other optimizations, just swapping image.draw to batch draw increased speed by orders of magnitude. HURRAY!