Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Hey Jim - nice to see you around here! Thanks for taking the time.

My first attempt was a Raycasting engine, and while the speed was actually quite nice, I felt it would constrain the kind of environment I wanted to create. To be honest, never considered sprinkling some raycasting into later implementation.

That video you saw was from the SDL version, with me performing a flip on the video surface on every pixel, to help me debug stuff. I actually draw to offscreen buffer first and only then send everything to VRAM. To be fair, there was a fair amount of sloppy level design in there was well.

For my next project (The Mistral Report), while I did employ this same visibility algorithm, other options are still on the table. One thing I want to try is having a 1D Z-Buffer (Doom did that, AFAIK) for every column on the screen and perform the drawing front to back. Or simply go for portals-on-volumetric-sectors for good?

Finally, there is the undeniable bloat legacy from this engine being an port from a Android game I wrote while learning C++14. No wonder the binary end up with 800KB, while the rewritten engine for The Mistral Report is almost pure C99 and only has 150KB or so. Writing code for 486s was eye-opening.

(+1)

If you thought 486s were eye-opening, try the 8088 ;-)  "I can only access 64K at a time?  All the registers are 16 bits wide?  What the hell is this crap?"

While we used Z-buffering in the demoscene for a few objects, I don't think it would offer an appreciable speedup for the kind of overdraw you're doing -- you still have overdraw, but this time in the zbuffer.  It would save a little time during rendering as you'd only be looking up texels once per onscreen pixel, but that's not much of a speedup...  

You might be onto something regarding a portal system.  Check Fabien's analysis of the Build engine, it might give you some ideas: http://fabiensanglard.net/duke3d/build_engine_internals.php