Right.. Except I use XOR-filling rather than traditional polygon scan conversion. And that changes a lot of things.jargon wrote:remember, for drawing a triangle, always split a render into the upper and lower portion at the corner vertically between the other two, then render those two triangles top half first, also check whether the corners are clockwise or counter-clockwise in order to deduce faster if that surface is even a visible side, i usually use clockwise for polygons on the inner surface of a polyhedron.

As in drawing the polygons in back-to-front order? As I've stated earlier XOR-filling can't handle overlapping polygons, it's the main drawback of the method. I would have to do actual clipping to display overlapping or concave objects, and I have no idea how to do that with reasonable performance (well, aside from precalculating everything).beyond that i use simple z-order split of existing polyhedrons in event two overlap.

Sorry, but I don't understand what you're trying to tell me.creating a multiplication matrix for the 3 axis using sums of binary-split increments of rotation from within a look-up table instead of raw cos/sin works much more effectively.

I'm using precalculated (co)sine tables, and the trigonometric product rules to avoid multiplications, if that's what you mean. At any rate the whole thing is running in less than 500 cycles for 16-bit precision so it's not really a bottleneck anymore.

Right, no.. Just plain flat-shaded polygons for me. I don't even want to think about how slow texture mapping would get..beyond that, if you decide to implement textures, i highly advise to not take perspective into account for textures and simply render them as if they were an orthogonal re-orientation of each triangle, as the NES would suck CPU cycles like crazy taking that into account.

Again, I don't quite follow you. However I am using logarithm and exponential tables for the perspective division.my advice for perspective is to use exponential projection as i described here:

http://nesdev.com/bbs/viewtopic.php?p=32745#32745

i only left out of that description that is best to simplify the look-up table so that only each depth plane is used in which the scalar comes to a full integer when translated.