GL_DEPTH_BUFFER

Turns out, if you want to use the Z coordinate to provide layering in OpenGL, you do have to explicitly use a depth buffer, it's not automatic, at least not in orthographic mode.  Just mentioning.

Fairly productive today

I switched the game's internal vertex format from two to three coordinates for vertexes.  The result is, I should be able to use the Z coordinate in the orthographic perspective to do tile priorities, which will allow for overlarge, overlapping tiles that don't cut each other off if they're on different planes.

"Solid" tiles, like rock, growing plants, and so on will use slightly-too-big tiles.  Fluids will too, but with a lower priority.  This should help to obscure (very slightly) the discrete, grid-based nature of the simulation.

Important note, that I've mentioned before but want to reiterate: the game is no longer going to be a platformer, but more of a real-time turn-based thing.
Reasons:
1. Platforming engines are difficult enough to implement without handling ejects and things like that in a dynamic cellular world.
2. That kind of action-based play I think will obscure the more thoughtful nature of the game.
3. I don't really want it to be, I want to try something new here.
4. I know roguelike implementation fairly well, and this helps to keep the game more easily achievable.
5. The baggage of having platforming was one of the things that bogged down the project before.  Let's keep it more achievable now, and not shoot for outer space in a solo project, the upper ionosphere is enough.

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".