@bloodline
It varied :-) It was mostly a learning exercise and if I was to do it again, I'd avoid many pitfalls of last time....(famous last words - I'd just find new pits to fall into :lol: ).
First up, it was running on 68040 and was using OS standard stuff + cxg +warp3d (v3 funcs only).
A lot of overhead was from having to call the warp3d v3 functions for so many small sets of polygons. v4 is far better for this (one call can render as much as you can give it).
It ran at ~15fps when you were at the default zoom level. As you zoom out or go for a shallow view (anything basically increasing the number of cells to vis test and render) it got slower. To help things along, many detail objects and stuff 'faded out' and stopped being rendered all together beyond a certian long distance zoom level.
Similarly it got faster as you zoomed in, so I added extra passes for detail textures and stuff to take advantage.
One thing it used was a transformation cache. Given the nature of the engine I anticipated that the view wouldnt change much, most of the time youd be clicking on stuff and doing stuff locally then scrolling over somewhere else and fiddling about there.
Hence, only when the view changed was all the visible stuff recalculated, then reused until another change occured (for the static world/objects only, of course). So when you werent moving around it was very steady - the water ripplinng was hypnotisingly smooth ;-)
Anyhow, it ran on my first experimental portability layer project, but that in itself was canned (as it was frankly rather poo). My new portability layer doesnt have enough functionality yet and I am too busy to work on it for now, but its much cleaner, better designed - and most importantly faster :-)
Rather than upwards port that old engine, I'd write something new instead :-)
