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?