Sprites!

[princec]

Nah, dirty rects almost completely useless for me - we have a lot of movement and a lot of overdraw.

The speedup difference between 50 and 150 draw calls was actually fairly negligible - maybe a 10% boost. However... I finally put VBOs into the sprite engine. Woah! What a difference. 60fps nearly all the time, just like that. Because of how VBOs work I couldn't interleave writes and draws on a state-change basis any more; it's back to writing all the sprites in one go and then rendering everything in one go. But even so - much faster.

One thing in particular may be helping here, which is that I use GL_STREAM_DRAW_ARB and GL_WRITE_ONLY_ARB and map the VBO. This means the data that I write to the buffers is written straight to the card, probably even bypassing AGP RAM, and especially importantly, it completely bypasses any RAM caches on the way.

So: VBOs FTW! I can still implement band sorting but I'll have to write my own much faster interval tree class.

And then I'll have a look at optimising the sprite atlases depending on adjacent sprite image usage and feeding back a data file into the sprite packer.

After that it'll very likely be back to being fill-rate limited like it was 7 years ago when I first wrote the damned thing! But this time I can fill 30x as many pixels

Cas

[Nate]

JWS or it is all a lie.

[princec]

  Patience patience!

Cas

Games published by our own members! Check 'em out!

[Eli Delventhal]

That's awesome! I'll have to look into VBOs in the future.

[princec]

Do it now! Any other method is totally obsolete by the looks of things.

Cas

[kappa]

Do it now! Any other method is totally obsolete by the looks of things.

Cas

do you plan to keep that as default? or have some non vbo fallback too?

[Eli Delventhal]

Do it now! Any other method is totally obsolete by the looks of things.

Cas

I'm supposed to be releasing on Monday! Changing the whole drawing system is probably not worth it at this point.  Maybe for updates, though. The game stays around 30 FPS but I've already got a few optimizations in mind that I think could definitely get it to around 60.

[princec]

We will not support cards without fully functional VBO. No fallback will be provided.

Anything less than 60fps is rubbish So you go ahead and release, in shame!

Cas

[Eli Delventhal]

Anything less than 60fps is rubbish So you go ahead and release, in shame!

It's for the iPhone. You try getting 60 FPS when you have no dedicated graphics card and OpenGL 1.1.

On the 3GS it never goes below 60 FPS.

[princec]

Does the iPhone have VBOs?

Cas

Games published by our own members! Check 'em out!

[Eli Delventhal]

Does the iPhone have VBOs?

Cas

Well I looked into it, and apparently it does via an OpenGL ES extension. So if I had the time to drop in some optimizations the game could really benefit from a few. I've used FBOs in a couple places, but no VBOs.

[princec]

The current state of play with the server VM on the 1.6GHz Turion64x2 and Nvidia 6150 Go:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55

Compiled + native   Method                          19.0%  8234  +     0    com.shavenpuppy.jglib.sprites.DefaultSpriteRenderer.writeSpriteToBufferF   9.4%  4089  +     0    worm.QuadTree.doCheckCollisions2   4.2%  1819  +     0    worm.QuadTree.checkCollisions   4.0%  1750  +     0    com.shavenpuppy.jglib.algorithms.RadixSort.sort   3.4%  1477  +     0    worm.features.LayersFeature.updateColors   3.0%  1316  +     0    worm.MapRenderer$RenderedTile.setTiles   2.9%  1267  +     0    com.shavenpuppy.jglib.sprites.DefaultSpriteRenderer.sort   2.8%  1216  +     0    com.shavenpuppy.jglib.sprites.DefaultSpriteRenderer.build   2.5%  1084  +     0    net.puppygames.applet.Screen$1.tick   2.1%   899  +     0    com.shavenpuppy.jglib.sprites.StaticSpriteEngine$1.processRendering   1.8%   797  +     0    net.puppygames.applet.Screen.tick   1.8%   787  +     8    worm.path.AStar.goalNotFound   1.1%   488  +     0    worm.entities.GidrahGameMapTopology.getNeighbours   1.0%   433  +     0    worm.MapRenderer.render   1.0%   422  +     0    worm.entities.Building.getCurrentAppearance   0.9%   385  +     0    worm.MapRenderer$RenderedTile.setLocation   0.7%   287  +     0    worm.MapRenderer.postRender   0.6%   258  +     1    worm.WormGameState.checkMouse   0.6%   249  +     0    worm.QuadTree.doCheckCollisions   0.6%   246  +     0    worm.path.AStar.nextStep   0.5%   222  +     0    worm.Entity.isTouching   0.5%   212  +     2    worm.QuadTree.checkLeafCollisions   0.4%   195  +     0    worm.WormGameState.tickEntities   0.3%   149  +     0    worm.Entity.update   0.3%   143  +     0    net.puppygames.applet.effects.Particle.tick  69.8% 30225  +    44    Total compiled (including elided)          Stub + native   Method                           6.6%     0  +  2860    org.lwjgl.opengl.ARBBufferObject.nglMapBufferARB   3.8%     0  +  1669    org.lwjgl.opengl.GL11.nglColor4ub   3.7%     0  +  1610    org.lwjgl.opengl.WindowsContextImplementation.nSwapBuffers   1.7%     0  +   746    org.lwjgl.opengl.ARBBufferObject.nglUnmapBufferARB   1.1%     0  +   477    org.lwjgl.opengl.GL11.nglTexCoord2f   1.1%     0  +   459    org.lwjgl.opengl.GL11.nglVertex2i   0.8%     0  +   328    org.lwjgl.openal.AL10.nalGetSourcei   0.7%     0  +   297    org.lwjgl.WindowsSysImplementation.nGetTime   0.7%    52  +   245    net.java.games.input.IDirectInputDevice.nGetDeviceData   0.7%     0  +   286    org.lwjgl.opengl.ARBBufferObject.nglBindBufferARB   0.5%     0  +   221    net.java.games.input.IDirectInputDevice.nGetDeviceState   0.5%     8  +   190    org.lwjgl.opengl.WindowsDisplay.nUpdate   0.4%     0  +   182    org.lwjgl.opengl.GL11.nglEnable   0.4%     0  +   155    org.lwjgl.openal.AL10.nalSourcef   0.3%     0  +   124    java.lang.System.arraycopy   0.3%     0  +   112    org.lwjgl.opengl.GL11.nglBindTexture   0.2%     0  +    83    org.lwjgl.opengl.GL11.nglTexEnvi   0.2%     0  +    82    org.lwjgl.opengl.GL11.nglDrawArrays   0.2%     0  +    78    org.lwjgl.opengl.GL11.nglEnableClientState   0.2%     0  +    74    java.lang.Object.hashCode   0.1%     0  +    60    org.lwjgl.opengl.GL11.nglDisableClientState   0.1%     0  +    58    org.lwjgl.opengl.GL11.nglDisable   0.1%     0  +    42    java.lang.Thread.sleep   0.1%     0  +    40    org.lwjgl.opengl.GL11.nglBlendFunc   0.1%     0  +    40    net.java.games.input.IDirectInputDevice.nPoll  25.4%    60  + 10950    Total stub (including elided)

That's after 563.75 secs (49696 total ticks). Frame rate dropped to about 45fps with over 2,300 sprites and well over 120 gidrahs. Still not good enough!

There is a reasonable amount of waste going into immediate mode rendering which I will slowly remove over time and replace with triple buffered VBO code.

Collision detection seems to be taking too long - I may try switching to cell-based collisions instead of the quadtree, though this might well not really have that much of an effect. The real problem here is that so many gidrahs are packed tightly together attacking some walls in this test - perhaps I should implement a bit of that behaviour to keep them apart.

As we can see though by far the biggest single waste is writeSpriteToBuffer still, which honestly should be far faster than Java allows it to be.

Cas

[Krux]

hi

I am using direct mode for particle sprite rendering. I got a huge speedup with avoiding many glBegin glEnd calls.
so changing this

1   2   3   4   5

for all particles p:   glBegin(GL_QUADS)   glVertex(...)   glEnd endfor

to

1   2   3   4   5

glBegin(GL_QUADS) for all particles p:   glVertex(...) endfor glEnd

made a huge difference.
Now rendering 30 000 particles is no Problem anymore.

[princec]

Only a loony would do it the first way though

Cas

[Krux]

it first i wanted to do it the oop stype with particle.draw. It ended in the first version and with very poor performance. Now I am happy with performant direct mode.

[Riven]

it first i wanted to do it the oop stype with particle.draw. It ended in the first version and with very poor performance. Now I am happy with performant direct mode.

For better performance, try vertex arrays and vertex buffer objects.

Ofcourse, it won't matter if the bottleneck is with fillrate, but it's worth a try.