Jump to content
  • Advertisement
  • entries
  • comments
  • views

Variable height sectors

Sign in to follow this  


I switched from 16/8 division to 24/16 division, and wall heights are now calculated rather than being dragged off a lookup table.

There's also backface culling (the cylinder around the central cube is marked as double-sided, hence no culling there) but there is still no clipping or occlusion.

@philipptr: I'm guessing your technique is to calculate the angle of the point, add an offset to it, then convert back into a new coordinate? I just adapted some 3D point rotation code I had, simplifying (mathematically) it and removing any references to z.

I will probably not use textured walls - not so much for performance issues, but for aesthetic reasons. Scaling a texture down on a wall displayed on a 96x64 monochrome display (without antialiasing) looks pretty ugly. Simple lines look a lot cleaner.

Oh, and hello aCiD2 [wink]
Sign in to follow this  


Recommended Comments

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.

Share this comment

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

Good luck!

Share this comment

Link to comment
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

Share this comment

Link to comment
@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.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!