turns out my rasterizer failed horribly because of a 'convenience' call i wrote, which was meant as a go between between floating point z values and 20.12 fixed point values i was using in the z buffer. i thought it would be a good idea to clip the resulting value to a range that could be represented by a pixel in the z buffer. this call was used in my draw triangle function to pass the z depth to the integer based scan line function. needless to say the value was being shifted out of the neccisary range.
anyway rasterizer is still kind of messy but at least im on the right track. im blaming floating point precision here. the arm fpu isnt as predictable or precise as the one on a pc. i figure some fixed point math otta fix that up.
z buffer looks kinda wonky. its a straight 32 bit dump. didnt want to learn a format for 32 bit grayscale, so i just casted rgba to Uint32 and wrote it to a 32 bit targa. i want to say the far away stuff is red, close in stuff was in the alpha channel (i just added it on top of the rest in photoshop). idk, i wish i could analyse it better without shifting off 24 bits of accuracy.
i need a model that isnt all white to put the z buffer throught its paces. this pyro model was selected because i was to lazy to texture it and so instead colorized it. i saved it as obj with materials to export the material groups. then added parsing for the materials tags. this should allow me to build a crude material library and assign each one a different color. then have the renderer automatically change the colors as the object is being rendered.
