I feel honored that you casted a glance at my code.
If I had known that such a thing could happen, I would have cleaned it a little bit
Yes you understood right. Get out of academic 3D to street math 3D that might suit better to 8 bits 1Mhz processor.ThomH wrote: ↑Thu Dec 26, 2019 10:32 pm It looks like your fast project ejects the classic linear algebra solution of dividing by z in favour of a trigonometric solution, using atan to determine the angles between a point and the horizontal and vertical planes, then using those angles to look up the 2d point through which the relevant ray runs? Have I understood that correctly? If so, very devious!
That's a very good advice. I plan to use the projection in several pass. A first pass to determine which Object are in the field of vision.ThomH wrote: ↑Thu Dec 26, 2019 10:32 pm If you can come up with that, I'm sure you're ahead of me on almost everything else, but on the off-chance: definitely using a binary search for display-area edge clipping. I do them in 3d, before projection, to offer guarantees about range at the next stage but I've also read persuasive arguments that if your objects are generally 'small' then it's more efficient to clip after projection.
And then, in an other pass, only project points and faces that belongs to visibles objects.
I also think of using distance to deal with Level Of Detail. For far objects, use a kind of vectorial drawing of a sprite .. and only use points and faces projection for close objects.
Well there are many ideas to explore . It is hard to determine which one is the most ressources-saving . That's why it's very interesting to take advantage of your experience.
Your post make me think of the topic of polygon clipping which is very interesting. I'm working on a own-made algo because sutherland hodgman algorithm looks far too heavy for a 6502.
DBUG has done something like that here:ThomH wrote: ↑Thu Dec 26, 2019 10:32 pm I keep meaning to stop being lazy and write a quick tunnel game based on fixed height walls, 2d map geometry, a 1d 1/z buffer and partial redraws — in the special case of fixed-height walls the 1/z buffer is nothing more than a "put this column into this slot only if it is bigger than the one that's already here", and you end up with a 240-entry table of height + pattern per screen column. So if you still have the previous table sitting around, it's pretty trivial to draw only the differences — completely redraw any column with a different pattern, just adjust the height of the others up or down a bit.
viewtopic.php?f=20&t=1813&hilit=walls.zip#p16985
Sorry you can't beat me on the field of lazyness .. homebrew is the proof