Got caught in the optimisation trap

Posted by
February 22nd, 2014 6:16 pm

I know it’s bad to prematurely or pre-emptively optimise, buuut I was concerned about CPU usage, and it all seemed to stem from drawing routines…

So after a bit of reading around and testing and worrying, I rewrote all the drawing to use a spritebatched tileset image, and it’s now much much more comfortable. hooray!

If I’d been using images in the first place for tiles, I’d probably have done this from the get go, but because this is all solid colours, I thought creating images for them was madness. Turns out I was wrong; at least the images are being created once at runtime each, and only ever sat in memory. Making 32×32 flat coloured squares in Photoshop would have felt really botchy…

obligatory screenshot of progress:

Rooms are now randomly coloured, which I think is nice. Breaks up the monotony. Map view works, for each player. I think it’s rather nice, even if it is just scaling the live render.

Heading to bed now, tomorrow will see fast implementation of mechanics and UI (hopefully). At least I have a plan for those and they shouldn’t be too complex – I knew graphics-y stuff and the procedural thing would be the hard work on this, but I’m pleased with the results!

2 Responses to “Got caught in the optimisation trap”

  1. rigg.travis says:

    This looks so pretty.

    • beforan says:

      haha thanks! I’m no artist (though I’m pretty pleased with that shibe face!) so it really is just letting the graphics framework draw a lot of coloured rectangles in a carefully arranged order 😛 but I think it looks kinda cool 😀

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]