upvote
How so? Doing this with modern OpenGL would be much simpler than the software rasterizer solution.

I think I'm gonna have to do it anyway, because some players claim they get nausea when playing at such low resolution (320x240), and the only way to give them higher resolutions that perform reasonably is to have it hardware accelerated.

Renderer is abstracted away already, but the real difference would probably be occlusion culling... With raycasting, I get it for free, but if I'd go down the hardware accelerated path I'd have to pick something more clever.

Raycasting and software rendering in general tends to scale poorly with resolution, even with vectorization and all the bells and whistles of modern CPUs.

reply
Unless you plan on rendering the level on some very retro hardware (think S3 Virge, maybe Voodoo 1) you can render the entire level in OpenGL with just zbuffer and alpha tested sprites and it'll run perfectly fine - if anything with such low polycount, chances are you're going to make the renderer slower by trying to do occlusion culling on any GPU released in the 21st century :-P. If you pack the geometry in a few vertex buffers (for each unique texture) even per-frame, you'll get four digit FPS in any relatively modern GPU.

As an example this[0] video shows the benchmark from Post Apocalyptic Petra running on my previous GPU (RX 5700 XT) which all it does is build a per-frame (client-side) vertex-buffer in OpenGL 1.1 (the engine was made for actual retro PCs running DOS and Win9x so it does some rudimentary occlusion culling but that mainly affects 90s hardware, not anything released since 2000 or so). If anything, the rendering has so little overhead that half of the framerate is "eaten" by the FPS counter overlay :-P.

[0] https://www.youtube.com/watch?v=64ysz5rXkzw

reply
That's really cool.

Thinking about modern games, a single character model probably has more vertices than my entire level (and yours probably), so it's definitely reasonable to expect occlusion culling for such simple geometry might actually reduce performance rather than increase it.

reply
Yeah, even this model[0] i made a few years ago for a game i wanted to make for the OG xbox (which has a GeForce3-like GPU) has ~2230 triangles and the entire first level of Post Apocalyptic Petra is ~5800 triangles, so you could say that even a turn of the century 3D character has more or less the same polycount as an entire 90s level (the game i wanted to make would have many characters on screen so i kept the polycount low but i've heard games having 5-6K character or more - e.g. Kingdom Under Fire had ~10K triangles for the main character and a game like Dead or Alive where there are few characters on screen had 15-20K triangles).

Meanwhile more current games have much higher polycounts, easily going above 100K triangles - e.g. Dante from DMC5, a ~7 year old game, apparently has ~190K triangles and that had to run on the more anemic PS4/XBone hardware :-P (though i'm not sure if it used the full 190K model there or some cut down version).

[0] http://runtimeterror.com/pages/iv/images/1073c7062db40837240...

reply
I rendered some Source engine levels on a shitty laptop in 2012ish and they still rendered at perfectly acceptable FPS (30+) just by rendering all the geometry in the level in one shot.
reply
The synthesis technique would be to build the DOOM-style BSP tree and then construct a bunch of meshes for use depending on which portal space you're currently in, but .. as you say, you don't need to do that because it's at most a few hundred polygons.
reply
Sure, but it becomes a question of how far you can push things. Maybe you raytrace the whole thing. Maybe there's some fractal geometry going on. Maybe you use a fisheye lens projection. Maybe your levels are dynamically tesselated. Maybe you have to do a few fancy tricks to achieve equivalent texturing etc.

But ignoring the GPU you have on your system is boring

reply
Writing a retro-inspired game using retro approaches despite all the modern options is precisely what makes this interesting.
reply