That's pretty cool. Have you noticed much if any performance reduction in calculating the wall height instead of using a lookup table? Just seems like you'd want to minimize calculations as much as possible, or maybe i'm just underestimating the Z80 processor.

Now, you need a fill routine (not very difficult since your walls are vertical) and a z-buffer (ouch) [grin]

Good luck!

Why hello ben ^_^ Does the Z80 support colours?

nice gif :) will you fill the rectangles and order them before you draw them or will you use a zbuffer?
if you have fixed height walls you would only need to have a one dimensional array as buffer which stores the drawn height per pixelrow but that wouldnt work for things like the cube :/

yes you're right that was my thought when I wrote that code. I never thought it could be that easy ;) (and fast :) )

@acid2: I really dont know much about this stuff, but istn that more a question if the display/display controller can handle colour data? I though the z80 would only give the pixel data to the display controller which only would cause a huge slow down since its so much more data.

btw wasnt that a z80 in the gameboy color? I think it was one twice that fast as the original gameboy z80 so it could handle the gameboy games without problems. so that shows that it doesnt really mean a huge slowdown :D

@caffeineaddict: Yes, there is indeed a performance hit. The problem is more lack of division/multiplication routines on the Z80 CPU itself, so you have to implement them yourselves with a long list of shifts/additions, one per bit. Seeing as I've left all these loops unrolled (for speed reasons) the code is now pretty massive (5KB!)

@Emmanuel Deloget: Using a z-buffer is probably too slow (and adds a rather large memory overhead) so I'll probably end up sorting the walls from front-to-back order (BSP?) then using some cunning trick recording the min/max heights of the walls as they are drawn on a per-column basis. Whether this will work well enough or not, I'm not entirely sure, so it's wireframe for the moment.

@acid2: as philipptr mentioned, it's not a CPU-dependant issue. The Sega Master System (and therefore Game Gear) both had colour displays (6-bit on the Master System, 12-bit on the Game Gear), but that's because the VDP (video display processor) supported colour graphics. All I get is a 96x64 monochrome LCD with a fairly primitive controller. Because of the latency of the LCD, you can create greyscale graphics by flickering the pixels on and off, but seeing as you need to be constantly outputting data to the LCD you waste a lot of CPU time doing this.

@philipptr: Occlusion is giving me one of my two big headaches at the moment (the other being clipping walls to the view, though that is an easier problem). The Nintendo Game Boys didn't have "proper" Z80s in them, they had a clone manufactured by Sharp in them, removing a few features and changing a few opcodes.