No screen shots today. Too bad.

Design Doc

My good friend, the doctor known as Brian, might help out with some art. I've know him for years and years so it's OK if I screw him over. It was at this point that I discovered that Brian could not, in fact, read my mind. For him to know what kind of art to make for the game I'd have to write down some kind of ... thorough description, "documentation", if you will, of the setting and gameplay. Madness.

So here's the current design manifesto. Read at your own peril, it's very much in progress.

Refactoring the GUI

I was iterating over all the buttons in a panel and checking if a mouseclick hit any of them in two different places. How ridiculously typical.

I've heavily revised all the workings of the GUI, Panel, and Panel Element classes. They're still a bit broken and I'm getting tired, so no screen shot of my new and improved ultra-slim GUI, but they're so beautiful and robust that I could make an interface out of a text file filled with noise. No, actually I seriously couldn't, but they're a lot better than they were.

Doing this brings up many new ideas that I should have in my GUI -- like what I'm thinking of calling a dynamicString class to put in place of regular strings in text elements or buttons that will update itself based on a call to some object somewhere else, for example a dynamicString could attach itself to a mouse position, then the mouse position would be displayed in real-time. Or something. The problem inherent in objects communicating with random other objects brings me to my next point...

Inter-object Communication

After discussing how Java's Swing handles buttons with Laura, I'm thinking of re-doing my relay class and adding a couple utility classes that can be used to set up connections between objects. Currently when a trigger is passed through the Relay it looks up the target by matching a string to a key in the Relay's dict. I thought, why does this need to be done every time? After the first successful 'connection' is made between trigger and target through the Relay, they could form a direct reference! (Of course some buttons will only ever be called once, like the 'quit' button, but for everything else I think this makes sense.)

The best part is, I don't have to intialize everything in a certain order like I think Java does. I just have to make sure that objects remove themselves from the Relay when they are deleted, which means I have to find out how the hell to add to built-in class functions -- I saw David O. do something in one of our Python/OpenGL projects where he had texture objects delete themselves from the OpenGL texture cache when they were themselves deleted; I just gotta do something like that.

Rendering

I've been having second thoughts to my rendering process.

I know that I've been hyping dirty rects for the past week and I do have my Video class set up to use them, I just have to figure out how to get everything that is rendered to pass their dirty rects back up to Video -- and how to do this only when necessary. It's a matter of planning, really.

And then I was thinking of how I render tiles: I currently render all the 'layers' in a tile from references to generic images as I iterate through, so like: blit Tile1 terrain, Tile1 terrainfringequads, Tile1 terraineffects, Tile1 isofeatures, Tile1 otherFX, shift over 128 pixels, blit Tile2 terrain, etc.

Could I not render every tiles bottom layer over the whole gamescreen, then every tiles next layer over the gamescreen, and so forth? Would this be much more costly? (A bit, probably.) Would I gain some kind of flexibility I wouldn't have otherwise? ... I recall an option in Civ where you'd tell it to show only underlying terrain. This may allow images to be drawn past the bounds of their tile without having (more) weird overlap artifacts.

And even further, I was talking to Laura about how I handle tiles, and she was saying why not render each tiles own little surface and store it in the tile (and only do this for currently visible tiles, of course), then call those on demand. This way I wouldn't have to re-render the whole stack of images every time -- I'd only have to re-render a stack of images in a tile where something changed. This would take more memory or something but may cut down on processing time -- I just have no idea if it'd be worth it.
I suppose I could implement all the different rendering methods and see empirically which has the best framerate, but that'd be a lot of work.

Does anyone know what's the best way to do this?