steff September 07, 2001, 08:58 AM 

I just took a peek at your sourcecode.. At first i thought it would be written using fixespoint math, but i see you use floats, and i suppose theyīre not superbly emulated.. Thatīs one way to dodge speed. =)
You can get this runnig quite fast, atleast with spheres, Iīm not gonna say realtime cause I have no idea how fast the gba is...
For each row in the image, do a quick'n'dirty sphereplane test for all spheres in the scene, and keep track of all the spheres intersecting the xzplane that the row makes up, then do the same for all columns in the image, but xyplane offcrz. This way you know exactly which spheres are covering every single pixel. Once you know this, the sphere intersection is way more simpler than it is now... ( I like the squared radius calc for every intersection test btw..=) )
A good way to speed up firsthit rays is to either keep a precalculated array of normalized directionvectors, and just transform them with the cameramatrix. Or, you can build the directionvector from the matrix itself, and interpolate it over the screen... Iīve got some really nice results with realtime raytracing if your interested.. (although pc =))
And also, not retracing pixels gave me a 1520% increase, so itīs well worth implementing...
