Making Graphics Like it's 1993

I feel like the idea of fixed-point is under-utilized and very under appreciated. There are loads of applications where this is a better choice, let alone more performant.

The Build engine didn't use BSP, it treated connections between sectors as portals and rasterized the walls as (90 degree rotated) trapezoids while performing clipping against those portals. This allowed it to have dynamic wall geometry (e.g. moving trains, rotating light fixtures, etc) as well as "room-over-room" setups as long as you couldn't see both rooms at the same time (in both Blood and Shadow Warrior they found a workaround for it allowing to create more "3D" spaces by making identically shaped sectors with the floor of one sector acting as a portal to the ceiling of the other sector - supposedly this wasn't "natively" supported by the engine, but it was flexible enough for the game studios who used it -without even having access to the source- to do it themselves).

The first level of Duke Nukem 3D does use a few Build tricks - e.g. another one is that sprites can be "axis aligned" instead of following the camera and they can also have collision - this can be used to create rudimentary 3D geometry by treating each sprite as an axis aligned quad and in the first level it is used to make a bridge between two buildings (right before the level exit button).

Blake Stone Rise of the Triad used later versions of the Wolf3D engine and had textured floors/ceilings

> Doom and IIRC Duke Nukem as well used a BSP engine which was much more flexible

Duke Nukem (Build engine) did not use BSP

https://www.jonof.id.au/forum/topic-137.html#msg1548

With the data structure being more efficient, and doing less overall work, I think this part of the Doom/Duke engine might even be faster than than Wolf3D

For floors, unfortunately there's no such luxury, and if I remember correctly DOOM subdivided floors into patches, and only did proper perspective at the corners, and interpolated inbetween.

So while it didn't have custom processors for sprites and background layers it meant there wasn't a rigid fixed function nature to what the PC could do.

By the mid-late 90's with dedicated 3D processor this wasn't an issue any more but there was a brief time in the early 90's where there was this wonderland of unique visual rendering.

Though your extender could make things a little more annoying on that front :-P

(DJGPP and Free Pascal -which use the same "go32" extender by DJ Delorie- do not do a full linear mapping so you need to do a bit more juggling to get stuff on screen there)

But maybe a software renderer and SDL_Texture could preserve it?

    int s = y*screenRect.w;
    
    for (int x = 0; x < screenRect.w; x++) {
       pixels[s + x] = argb(255, frame>>3, y+frame, x+frame);
    }

It's not that rare, is it? Off-hand, and very mainstream; Perfect Dark, Mirrors Edge, Dishonored (don't remember if it's the first or second one), Metroid and more are all kind of "shooters" with female protagonist, although maybe Mirror's Edge is more just "first-person" than "shooter" to be 100% accurate.

Not to mention the large selection of "RPG + FPS" where you can be either man or woman.

---------

Seems the author also realize the thing with the pattern and likely gender of the cat:

> After all, I do need to give the protagonist his fair share. [image] (Yes, I know it's a female, but call it convention rooted in dialect.)

No, this isn't a Perfect Dark game

[0] https://store.steampowered.com/app/1592280/Selaco/

[1] https://store.steampowered.com/app/1693280/Supplice/

[2] https://store.steampowered.com/app/1378290/The_Citadel/

[3] https://store.steampowered.com/app/3371240/Beyond_Citadel/

[4] https://store.steampowered.com/app/2443360/Zortch/

[5] https://store.steampowered.com/app/3807500/Zortch_2/

[6] https://store.steampowered.com/app/1051690/Nightmare_Reaper/

[7] https://store.steampowered.com/app/1785940/COVEN/

[8] https://store.steampowered.com/app/1406780/Viscerafest/

[9] https://store.steampowered.com/app/1072150/Hedon_Bloodrite/

I have no idea the names of nearly anyone but a CEO or lead Director in the games industry of the past 15 years.

http://www.effectgames.com/demos/canvascycle/

We did use magenta and colors near it for reserved pixels that would never be seen onscreen, but in our case it was for color animation. The Mac couldn't do full-screen palette animation in a way sanctioned by the OS, because Apple arbitrarily inserted an internal wait for the vsync monitor refresh interval in all of its palette functions, with no way to disable it or directly access the low memory variables that controlled the color lookup table (CLUT) like on the PC. So an empty main loop with palette animation ran at 60 fps, but doing any draw calls at all caused a timing miss which dropped it to 30 fps, while the CPU sat at about 50% idle. Our games redrew the whole screen anyway, so we opted to translate pixel colors on the fly via our own lookup table instead.

Apple also didn't provide OS calls for page flipping (to draw the next frame of animation while the current one is shown to double the frame rate), probably by design to maintain the Mac's image as a "professional" desktop computer, because such tricks were well-understood in the gaming industry. Or video resolutions below 640x480 (sometimes 512x384 on certain models).

Apple also tended to ship machines with half-width busses (supposedly to reduce cost) like the Mac LC, which reduced memory bandwidth so much that full-screen scrolling was difficult to achieve.

Those decisions prevented the Mac from becoming a performant gaming system, even though the RISC-like 68k chip with its numerous registers, predictable instruction set format and unsegmented memory were far superior to PC architecture at the time IMHO.

Later PowerPC chips like the 603e had a cache misalignment issue where double-width 8 byte memory copies that weren't 8 byte aligned ran at about half speed (probably using 2 copies internally) so I think we had to drop down to single-width 4 byte copies or use a cache hint function to disable caching while copying image buffers, which ran slightly slower.

Notable snafus included years-long delay of support for newer OpenGL versions, so we were stuck with fixed-pipeline 1.x calls long after the PC was exploring shaders. Then iOS only supported OpenGL ES, with no real reason not to offer an ES compatibility layer on desktop, necessitating support of 2 codepaths. Instead of remedying that stuff, they introduced Metal, which nobody asked for.

Not to mention deprecating wide swaths of the OS, forcing rewrites from MacOS 8 to 9 (Carbon), then from 9 to X (Cocoa), then from MacOS to iOS (Objective-C and Swift). Don't forget the 68k to PowerPC to Intel to ARM chip migrations, which forced developers to be aware of endianness issues, which greatly increased the complexity of reading/writing binary files.

Combining all of those permutations, MacOS software would often only survive perhaps 3 years before needing a rewrite. I probably have 10 times as many applications (mostly old games) on my Mac with a no-smoking sign through them as runnable applications.

I'm reminded of the expression "lemons for the price of peaches". The outer elegance of the Mac obfuscated the underlying byzantine layers. Denial became woven into the Mac experience, so much so that developers took a certain level of trauma to keep up appearances. I know I did. That's why I got out of the biz in the early 2010s after so many of our games that we put so much work into turned out to be commercial failures. We might have made 10 times more money targetting the PC, and conceivably 100 times more if we had cross-platform resources like Unity and Steam.

I bring this stuff up because rose colored glasses often obscure what really happened. Especially now with political insiders and the media producing so much revisionist history. Stuff we remember as cutting-edge manifested because the state of the art at the time was so abysmal.

I look around today and I see a whole lot of assumptions being made that this is all there is. That the current path of tech is the one true way. When nothing could be further from the truth. We're ruled by powerful duopoly forces presenting the illusion of choice, when all eggs are in the GPU basket. But do they use GPUs on Star Trek? Probably not.

I'd be curious to know in more detail what exactly is going on there. I guess the box sharpening is where most of the beef is.

It's the result of the Blender compositor postprocessing, just keep in mind it falls apart once you go low enough in resolution (it's an image space thing after all), so I'm not sure if that helps your case.

EDIT: Also, your project is very cool!

> If this sounds unreasonable to you, that is because it is.

Those listed, are tame. I don't understand this kind of faux modesty.

> My goal was to build a complete, shippable first-person shooter using techniques that were common in the early 90s

Goes on to explain how they used 3D blender...which wasn't available until 1998.

A vanity cat project being tailored and submitted for nostalgia clickbait. I don't think there's anything useful to take away from this other than some color shade selection ideas.

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.