Dev Diary: Performance, Take III

As an aside, it's cold enough to freeze the balls off a brass monkey right now*. Schools are closing, they city isn't recommending being outside and a concentration of mist, fog and steam creeps over the lake. Thankfully, no zombies. This would be a really bad time for zombies.

So after thinking that my making Dreadnought render in such a way that it didn't have to redraw an entire table at once that I had more or less licked my major performance problems. Take II on rendering was to determine precisely where things had been and were going and adjust specific tiles. I even tried to make a multidimensional array to hold the DOM elements to speed up lookups. My Mac still wasn't happy, so I replaced the entire table based map with HTML divs instead.

As another aside, there's a movement within web developers that tables are obsolete and divs are the way for virtually everything. My problem with that is - tables were designed to hold information side by side and above and below ... divs were not. Clever CSS tricks work around this problem but often cause brand new ones.

Also, when I replaced a huge table with a series of absolutely positioned divs ... I got no benefit. None. Nada. Nothing. Probably because for modern computers, a table which isn't nested simply isn't much of a problem.

No, the problem is just size in general. It seems to be the number of elements, not the type, and sectioning portions of the elements off seems to have minimal effect. I'm not sure if it's DOM manipulation in general. A single move can cause several elements to flip class and content. With a very small map (say 300 tiles), this is really fast. With a large map (say 3,000 tiles) this goes down to a crawl.

Well, on my Mac at least. But what's the point of making a web based game if at least a lower common denominator can't work with it? I don't want to publish processor requirements for a turn based game.

So I have three options:

1) Maintain only a series of small maps. In other words, your "dungeon" would consist of 300 tile blocks. This feels suboptimal to me - burden to map creation, restrictive to gameplay.

2) Abandon discrete tiles. Instead of using elements for every tile, use elements to define overall room specifications and then rework the event structure to match. This is a pretty major overhaul considering the amount of code that currently exists that examines an activated tile. Course, to keep that code - #1 is about the only appropriate approach.

3) Ditch the DOM and use a canvas tag. This has a couple of attractive elements. Canvas tag offers many more rendering options (non-uniform lines, circles, etc). It's actually about the only thing (other than flash) which resembles what I'm trying to do (graphically represent data). However, it's also the most severe departure and would definately limit development to FireFox ... not just now but probably permanently without another rendering (and event) re-write.

Hm. Sigh. This is definately the biggest snap I've hit so far - a potential fourth quarter "backbreaker" turnover if you will. Actually, it's not that severe - I just wanted to make a Super Bowl reference. It's been my experience that when you see a browser slug in the way my BonEcho (an optimized version of FireFox for PowerPC) is slugging right now - it's trying to tell you that you're abusing the system. It's better to have this early warning now than down the road.

* "brass monkeys" refer to the brass holdings for cannonballs on a sailing ship.


tagged: game, gaming