The simple (although not altogether graceful) solution, is to have a temporary array the same size as the existing map which is used to preview the line while it is being drawn - once the mouse button is released, the temporary line is plotted to the map proper. Nailed this code in a matter of minutes, and the routine worked beautifully.
The code won't go to waste, either, as most of the other drawing tools will also utilise this temporary buffer. With this in mind, I quickly knocked up the code for plotting rectangles on the screen.
After this came the job of tackling the Fill option; I spent some time reading up on various fill techniques, and most obvious answer seemed to be, work out how it is done, choose the best method, then see if someone else has written the code already. :)
As luck would have it, I managed to track down some fill code which was both accurate and fast (as opposed to recursive and clever, but dreadfully slow), and after a few minutes tinkering and debugging, the fill routines were in and working.
After getting some much-needed sleep, I decided to spruce up the editor a little by adding a nice pulsing cursor that isn't as heavy on the eyes as the old random one. I also corrected a few little flickers here and there (just because it's an Editor doesn't mean it has to be flaky).
* * *
I'm starting to get a clearer idea of the remaining functions and features I want the editor to include, so here's a brief rundown of the major tasks on the horizon in no particular order (which also doubles as my to-do list):
1. Brushes: it would be extremely nice to be able to grab chunks of on-screen data and paste them around as required. I might impose a limit on the size of brushes, but certainly, the user will be able to build up a library of common brushes (and save these out with the current maps / tilesets as part of a project file). Some Editors allow the user to grab a brush from multiple layers - I'll be neglecting to implement this level of complexity (it's hard to work in three dimensions when one of those dimensions is obscured by the other two!).
2. Multiple Maps: The editor deals exclusively with one map at present - this will be expanded to 8, accessible via the number keys.
3. Multiple Map Layers: For those wishing to create multi-layer, parallax backdrops, the editor will allow the user to have up to 4 layers for each map (foreground, background, static backdrop, and "copperlist" sky).
4. Multiple Tilesets: Currently there is only one tileset in memory but ideally, the user should be able to pick from a library of available tilesets when creating a map (and even change them on-the-fly - if they've organised their tiles in an orderly fashion, with wall tiles and suchlike in the same locations, there's no reason why this wouldn't be a useful feature).
5. Grab Tiles: Most decent editors allow the user to load in a bitmap and grab a tileset from the image. I'm toying with the idea of using a cursor to grab tiles from anywhere on the image (i.e. not using just a rigid grid of 16x16 or suchlike).
6. Tile Load & Save: Currently the user can only load and save maps, this needs to be expanded to encompass tiles, too.
7. Grid Display: Simple feature to display an overlaid grid in order to make map construction easier (this will be intelligent enough to automatically detect the current tilesize and draw itself accordingly).
8. File Headers: The various files will need proper header information, ultimately so that they will interface with the game seamlessly - there's no point writing specific code to set up each map when the game can read the header information and do it all automatically.
9. Tile Collision Data: I'd like to add a separate array which holds the collision data for each tile (i.e. solid wall, walk through, death, drain energy, solid to enemy but not player, enemy only, player only, etc.). This allows the user - if desired - to check collisions using just one map, as opposed to having a separate collision map. Speaking of which...
10. Collision Maps: Sometimes known as an Edge of Road map, this is a physically different map to the one which the player sees, but is used to dictate the collision detection. This is more flexible than defining collision data for each tile: for instance, you may want to have a swamp that the player can walk across safely, and one which drains their energy. By defining the safe and dangerous areas on the collision map, you can use the same tiles for both swamps without resorting to having duplicate tiles with different (i.e. safe / dangerous) attributes.
11. Collision Map Generator: As an extension of points 9 and 10, the user will be able to set up collision data for each tile, and then the editor will generate the collision map based on this data - this allows the user to very quickly set up collision maps, then go in and tweak by hand (rather than create an entire collision map from scratch).
12. Effects Map: Useful for triggering bonuses, enemies, and - as its name suggests - other effects, this will be an overlaid map tied to the main playfield like the collision map.
13. Tile Flipping: Gone are the days when artists have to produce flipped versions of their tiles - any editor worth its salt nowadays has a flip tile flag which tells the game engine to flip the tile as it is being drawn. Absolutely no idea how I'll be implementing this, but it's on my list.
* * *
Work continued into the wee small hours; after updating this blog, I set about tackling a few more drawing tools, including the Box Fill command (which draws solid rectangles instead of hollow ones), and the Box Fill Continuous command (which fills the rectangle with a continuous chunk of tiles - useful if you have large or complex graphics in your tileset). I also implemented multiple tilesets, added the Grid function, and fixed a couple of small bugs that had slipped through the net.
Despite this rapid progress, things have to proceed a little more carefully and methodically from now on; all of my drawing routines currently reference just a single map, so to avoid changing more routines than necessary, once I've implemented the Brush options I'll set about implementing multiple maps and tweak things accordingly. I also have to keep tabs on my routine order, as some routines affect a variable which may not get updated for another frame, causing glitches and flickers. Careful planning is the key - wish me luck!
