Slow, but steady.

Moving on

It Is Still Going Strong

I admit that progress is slow. Which is ironic since most of the code is written it just needs to be [re:]implemented. However, there are methods and practices that do need just a little bit of optimisation, a touch of refactoring.

One example of this is when I noticed that moving the cursor inside the tilemap viewport lined the entire widget up for redraw. Which for a 16x16 (approx.) square is a lot of power, so I got rid of that and I removed drawing the cursor.

Another argument for early optimisation is the way scaling images are handled. B!astEd is image intensive. Every tile at its smallest is around 64 bytes in an indexed form and four times that (256b) when drawn. Scaling this involves creating a new array of colours for every size. And, with the potential to be painted in four different palettes. It can get costly as images are recreated with every call to zoom, both in and out. To counter this I've tried a few methods:

Every method involves a tileset. A tileset is an image of any size that's clipped into 8x8 tiles.  The tilemap varies however.

Decisions, decisions

Method:

1. A tilemap is a single image and tiledata is used to create a buffer that is drawn to screen. When painting an entire tile the tile must be generated according to the maps properties then scaled and copied over. But, it doesn't have to be regenerated on draw.
2. A tilemap is a collection of tiles that are generated just in time.  Works fine. Slows down massively when scaling is too high.
3. As above but the tiles image is pre-generated and held in a buffer. Good, but without a system to manage images memory can potentially get off the roof.

I'm currently using M3. M3 means the buffer should already exist and won't have to be regenerated at every draw call, but more memory will be used. To mitigate that I'm using a similar approach to the Shared Image built into FLTK with a class derived from the main FLTK image. Sometimes you've got to use what you've got. There's another advantage and that is for a map that has many of the same tiles overall memory use will be down, which is a win. 

At the moment

I feel that editing a tileset, and the associated image, with ease is paramount to what I hope to achieve with B!astEd.  I've been overthinking for the past couple of weeks, however. With the tileset editor becoming more like a paint program.