Adventures in pyglet: Quads

Got called off from the pizza mines tonight.  Should be worth some more time on the engine.

Switching the engine from rendering triangles to quads.  The way the new tile engine works is, it sets up a 2D array of vertex lists, all the same size, that represent the tilemap.  Deleting and creating new lists as needed, every frame, was too slow, so it leaves the lists in place and changes the vertex data when necessary, which seems to be fast enough, and flexible too; Z-order can be changed, I believe, by specifying a Z coordinate, which is important to the direction the art is taking.

The best way to do this would be to have one copy of each tile in the graphics card and just render each at need in the appropriate place, but difficulties in doing this seem to be a drawback to pyglet.

It's a somewhat confusing new way to do graphics for me, but I seem to be getting used to it.

Continuing with pyglet

After a lot of web searching and lying trying to beat the concepts into my head, I've finally gotten the basic tile engine working AND at a good enough performance.  Only thing is, now the HUD isn't appearing.  GAH!

EDIT: But wait!  I fixed it.  Maybe I can finally move on to non-mind-draining work, at last.

pyglet discovery

The current scheme is, a primitive shape (a triangle list) for each tile on screen.

My first attempt deleted the previous primitive and created a new one each frame.  Very poor performance.

Second attempt kept the tiles in place, but changed the vertices.  If the new tile has a different number of vertices from the first though, a resize operation has to be done.

It turns out that resize() is very expensive.  If I don't do it, and just make sure all the tiles have the same number of vertices, screen updates are much faster.

I'll have to design tiles around this, but the speed difference is encouraging.  I'm still looking into ways to improve performance.

What I was doing wrong

So, it seems in OpenGL there are modes the system can be in, with names like GL_PROJECTION and GL_MODELVIEW.  And each one is a "stack" of matrix transforms, through which the various objects you then create are converted on its way, each frame, into being displayed.

If you change the camera, you really want it to be in GL_PROJECTION mode.  What is more, if you don't call gl_LoadIdentity() before you actually change the camera, then it seems your camera's position is modified relative to its previous position instead of from the arbitrary origin of the coordinate system.

It seems like a simple mistake to make, and to fix, but my Google searches were not an appropriately-shaped key to unlock that knowledge.  Most of the tutorials I had seen had covered using OpenGL for 2D, but not for scrolling around, at least not in the way I was wanting to use it.  Because I didn't perform this necessary step I was getting strange behavior, like the camera skittering off when I tried to move it.

I had been partly misled by a tutorial that said you could set the projection system to gl_Ortho once, at setup, and leave it alone.  The thing is, the code ended setting the mode to MODELVIEW.  If you then change the camera after that, well, you get weird behavior.  Instead, I needed to change back to PROJECTION, reload the Identity matrix, and move the camera from there -- changing it back to MODELVIEW afterward.

Wheee.

Still working on OpenGL/pyglet

I had jerry-rigged tutorial code in place that *almost* did what I wanted.  But it was more fragile than I expected, and when I changed it to do the rest, it broke.

I've been having the disconcerting experience where, when in my web searching I find out something I've been doing wrong, I go in and fix it, and it causes a blank screen, or my coordinate space not being what I expected it to be.  So I go back in and do more searching, find out a little bit more about how OpenGL handles the matrix math to convert vertices into screen coordinates, fix what was wrong, but break something else along the way.

I hope the NSA enjoys seeing my Google search records as being every possible combination of "pyglet", "OpenGL", "orthographic", "glLoadIdentity", "pixel", "GL_PROJECTION", and "gluLookAt".

pyglet

After a lot of frustrating hacking, made not less so by the fact that Pygame and Pyglet have completely different display paradigms, I've managed to get Pyglet displaying rects from the game's simulation code.  I just wanted to make a post to celebrate that quiet victory.

Progress!

What has been going on lately?  This--

Because there was do much cruft in the code from early bad assumptions and later-added misfeatures, I started it over. That turns out to have been the right choice-- progress had been rapid again, the new cellular engine is *much* faster, and my second take at a random world builder produces much more interesting output.

I've been trying to merge a previous tile engine I had gotten working in pyglet with this, which has been going slower, mostly because piglet doors things so differently from Pygame.  Anyway, more soon....