This week the work was very little, but was (that is my immediate goal, to actually work a little each week and don’t fall behind ‘dorfing).
Aftershave was moved to OpenTK, and sadly I discovered that it doesn’t have any direct means to get text input (it just recieve individual keystrokes), so the console now died. One of the advantages is text rendering, as it supports rendering from real fonts, that I missed from working with other libraries.
Also, I found the original design document for Aftershave, when it was a college project, dated March ‘06. I want to write a new one, reusing the good ideas form it. Hereby I declare this week the Write the Document week, and promise to have it here next time I post.
I tweaked the site a little, and changed the avatar system to use gravatar, so most of you people will now have silly faces next to your comments.
PS: Dear Grue, please stop failing, or die slowly.
Wow, half a year without updates… That was lazy.
Not much to say, this week I resumed work on Maped Prime (400 revisions! happy revisionversary!), and started designing Aftershave (as my last post said, as a *very* simple game).
Also, this new version of Windows Live Writer finally does what I expect from it, and lets me tweak the post HTML. Now I need to redesign this ugly site a bit.
Verge Goodness
The work on Maped Prime has been smooth, cleaning up code, redesigning the program to allow changes.
A lot of the global state code has already been removed, and that with other and most new coding is a lot smoother now. For fun I wrote a XML exporter, and worked great.
I fixed a very small rendering bug that had bothered me since the beginning. The map was offset always by one (zoomed in) pixel top-left. Reading GDI+ documentations, turned out that using PixelOffsetMode.None make the first pixel to be centered in (0 ,0), so it spans from (-0.5, -0.5) to (-0.5, -0.5). Using PixelOffsetMode.Half makes pixels act as expected. Now *that* is good design.
NOTICE: Don’t bother to try Prime now, tools are disabled.
The Legend
After working this last semester at a uni project with OpenTK I was wondering if moving Aftershave to it. Makes using modern OpenGL actually fast and easy. And it also has a good font rendering system. I will look into it.
About the game itself, it should have four basic dungeons with four unique enemies and one boss, one final dungeon, and a simple overworld. And two NPCs. And that’s it. Pretty simple and writable in a small timeframe (or so I hope)
Well, see you next week!
Some of you are probably wondering where I went. I’m still alive, I think, but december was busy on the real world.
I did advance a little on Maped (just here on my local copy), fixing the tile import system, to be able to import images as maps (even multilayer ones), and preventing tile duplicates.
On Aftershave, I just did a lot of thinking again. As I said earlier I was getting nowhere, so as a new year resolution, I’m going to complete Aftershave as it was originally intender, two and a half years ago, as a small (four dungeon and almost no story) Zelda clone.
And also! I completely failed trying to M something. This is as far as I got (two working menu screens)
About the title: I’ll be gone for January doing an intership on a hydroelectric power plant far from home, and with no computer near me. I’ll resume work (this time for real) on Feb.
Seeya, guys.
I’ll be out all January doing an internship, and probably won’t have access to a computer, so I shall work hard during December and February. As this time I’m really getting into Maped, this is an official calling to all the Verge community: please ask for features, report bugs and give ideas of future development. So, people, any ideas?
Brush your teeth after every meal
Did I heard someone saying “brushes”?
Alas, behold! A simple brush system is now implemented.
Maped Prime: A little brush screenshot
Well, to be sincere, not fully implemented, you can’t undo it. But the idea is there. Variable size, square and round brushes (any other shape, a horsey maybe?)
The battle of the codes
So, this two week (three counting the previous update) of fighting against maped3 had been weird. I don’t know if it grew over the time from a nice little program to a mess of epic proportions (no offense to anyone who worked on it, it did it’s work nicely).
A big problem that has been standing against me is passing data around. This was the messiest part of the original, in my opinion. Sometimes the data is passed around in a big class, sometimes as parameters between classes, sometimes, the fields of the called class are updates, sometimes it uses globals, sometimes it passes data around and uses globals instead and sometimes the passed data are the globals.
A pretty dirty example is the current method for implementing undo and redo, the MapEventInfo class sent by the mapviewer contains a SetTile method that adds a set tile operation to the map OperationManager.
So I decided that a good idea (and to prepare for MDI) was to make classes that contain the information needed for operating: MapContext, contains all the data necesary to edit maps (Map, selected layer, selected tiles for painting, the map OperationManager), EditorContext, the common application data… I should add TilesetContext and EntityContext, at least, and make a proper editor for those.
Preparing the way to the future
I was reading last week’s update by Overkill, and started to think about which could be the best way of implementing multiple zone, obstruction and entity layers. The idea that came to my mind was “layer groups”. There is two kind of layers: graphic and logical. The entity layer is both of this, and the zone and obstruction layers don’t have much sense without an entity layer. This “logical groups” should exist anywhere in the layer list. And there should be named retrace hooks, also.
I liked the idea of waypoints (I imagine a pin in the map :3) also, they could be very useful for some things.
This pressed the panic button on an issue that has been bothering me: backwards compatibility. A simple way of knowing supported features for a format, would be to have a feature flags enum, as a property on each format encoder… But this poses a problem: what to do if the map you are trying to save doesn’t support a feature? for some things if fairly simple (like alpha blending, or waypoints, as they could be made into zones or entities), but for others, like the multiple logical layers thingy, is could be messy. Any opinions?
This week has been very demanding from a real life point, so the update is short.
I continued working with the plugins in MapedPrime
Now the file mananging (both map and tileset) uses plugins. For now, just Verge3, I need to finish fixing Verge2 file loading and connecting the codec plugin system, so the program uses it.
The internal representation for the file formats are horribly mangled and hacky (there are some nasty hacks in-model to support Verge2 loading), so I’ve been cleaning them a bit. More work should go to the codec and less to the model.
And I added a basic plugin window. For now it lists the internal plugins. There it is:
Maped Prime alpha version: Plugin window
The little problem now is that Mono 2.0 has Windows.Forms (or System.Drawing, I don’t know) completely destroyed, at least in Windows on my computer. This week I’ll test it in the oficial Mono-Suse LiveCD, to see if it works.