Well we had a merged voxel and polygon 3D engine, that worked for a while at least, OK to demo, but not to play.
Then it happened :(.
The virtual Hard Disk I was using to use the Jag Tools on a Modern PC OS - VANISHED?!.
To this day I still don't know how that happened, one day the file was there, the next it was gone. For a while I wondered if my virus software had quarantined it or something but it didn't. We've since had further problems - but a fairly strict backup-regime has been implemented so there should be no more frights like this.
Now I did have back-ups (after I'd lost 2 Real HDs on my Falcon in 1 day - I DID do back-ups) , but I'd got complacent, and not done them as often as I should, so we had CD backups for quite some time before and the redo files locally, I thought it would be OK.
I was mistaken, retrieving the data from the redo files proved very tricky. I ended up extracting all the ascii data I could and putting them into big files and slowly whittling them down to the most up to date version I could reconstruct.
It almost worked. We had almost complete files, the only parts that didn't seem to work anymore were the interrupts (when a component in the computer, for example a timer, can cause the current program flow to be interrupted and jump to another piece of code to deal with the situation before returning to the normal flow). Now Atari had suggested in one of their developer docs that the way to keep the Blitter (the processor in the Jaguar used to copy textures or draw shaded polugons) busy was to form a stack of commands, and just load them into the Blitter each time it finishes itscurrent operation, so thats what I tried.
- Writing the Blitter data to a stack
- enabling the Blitter Interrupt so that as soon as it finished its last operation it interrupted the processor in which the data was being prepared. In this case it was one of the fast RISC chips, the Graphics Processor Unit (GPU), which then picked up the next values stuck 'em in the Blitter and went back to its work.
Now this is great if all you have is large gouraud (a method for providing smoothly shaded polygons) or unshaded textured polygons, but if you have small polygons, the overhead makes it a false economy.
Oh and sometimes JUST sometimes it can mess up a load/store command (to read or write values to/from meory).
And guess what? If it messes up the wrong store, everything can freeze. So I did a quick re-write of the interrupt part of the engine and gained a not inconsiderable amount of performance (perhaps 30% more polys/sec with small polys).
At last... some GOOD news.
It still wasn't fully stable in other respects but the freezing problem was GONE ... so off I toddled to JagFest 06 in Warrington. Where it promptly refused to load from CD and so everybody there at Warrington, sorry but you saw the '05 version again.
What would you have seen? - well it would have looked a little like this.
Did it just get dark?
The Head Up Display (HUD - the buttons, life bars, map, etc) is merely a placeholder and has already been replaced, but it might provide a hint at the kind of experience (obviously reduced in scale) that we'd like to achieve.