Android78

Hi Guys. I just came across this thread and it sparked my interest since I made a similar engine for the lynx back in my uni days (some 15 or so years ago). It wasn't nearly as polished (or finished) as luchsenstein, but the basics were there. I also used the horizontal format, but realized while I was looking at the graphics engine that it could have been much faster vertically, but would be terrible to play that way. The reason is the way suzy works with sprites, rendering them in rows, not columns. When combining the tilt and stretch parameters (tilt is how much right or left you want the next line to start being drawn from the previous and stretch is how much to scale the next line from the previous), this makes creating perspective vertically relatively simple and horizontal quite difficult (or will at least use more mikey time). The easiest way would be to setup each wall as a sprite with correct v size (which would actually be horizontal), starting h size, tilt and stretch values and draw using painters algorithm. This would cause some overdraw, but would free up mickey. The problem with this method as opposed to ray casting is that the horizontal scaling wont be accurate, but this should be pretty minimal (there is some mention in the documentation that the vertical stretching can be changed per line, but this isn't in the sprite control block, so no sure how that is supposed to work). The way it works is, if you have the sprite data as follows: 99119911 22992299 99339933 44994499 99559955 66996699 99779977 88998899 ... and a tilt of -1 (0xFEFF) and stretch of 2 (0x0200) then it would be rendered as (use your imagination... the '.'s are undrawn on screen pixels): ........99119911........ .......2299922299....... ......999333999333...... .....44499994444999..... ....9999555599995555.... ...666699999666669999... ..99999777779999977777.. .8888899999988888899999. You can see how this would be good for creating a perspective view. I think this is why John Carmack suggested his engine would have held the system vertically. It's a shame that the system didn't have a way to swap the rendering to column, rather than row as we would have then had possibility of some really cool games. There is probably a way to combine ray casting and the suzy scaling. I think my engine I had every wall divided up into columns and had SCB for each ray that would point to the sprite data with whichever wall column it hit and set the scale correctly for the distance. I knew it wasn't the most efficient at the time, but I had 6 months to get it done as well as all my other uni assignments. Anyway... glad to see that there are still people out there like me who are curious about this ancient hardware. With all the advancements, I still don't get as excited by the latest iphone/PSV/3DS as I did when I soldered 8 uv erasable flash chips to a board and soldered that to the connector from a cartridge to get my first program running on the lynx... those were the days!