Despite working for a 3D graphics IP company I've never actually tried coding any 3D stuff from the ground-up on an 8/16-bit machine and I figure I might want to give that a try someday.The problem is that there's all sorts of places an algorithm can go wrong. Is my maths shoddy to start with? Have a made a mistake converting it to fixed-point? Or have I just misunderstood some instruction?
Although I grew up prodding around with an action replay (and to be fair using windbg on kernal mode drivers for windows isn't that much better) it's a bugger of a way of working, especially when the error might involving trashing memory so you've not got any way to investigate.
To help me solve the problem of at least getting the algorithm right I've knocked up a framework. All it does is allow you to set up a palette (using Amiga colour values), give you 1-5 bitplanes (plane 0 providing the LSB) and allow you to read and write from them with bounds checking. Once your function (which should draw a single frame) returns it dumps the plane contents to binary files and spits out a .bmp with the output.
So what does this mean? It means you can breakpoint, single-step and printf the smeg out of your code when you are developing it and write it all as C with floating point maths, just like a PC routine but with a wierd graphics configuration. Once I'm happy with that I can convert the algorithm to use fixed-point 16-bit maths and keep an eye on it as I go. When that's working fine I can subdivide the steps taken until it becomes pseudo-68k and all with pretty much the same level of comfort as debugging a windows application.
By that point the remaining thing to do would be to convert it to 68k assembler (which should be a line-by-line translation if I've kept to the plan) and hope I don't introduce any bugs along the way.
No comments:
Post a Comment