Live data from Hacker News

Making Graphics Like it's 1993

staniks.github.io

151–160 of 169 posts

Re: Making Graphics Like it's 1993

#151
post #2

This is taking a lot of inspiration from Doom, but the actual raycasting engine is more like Doom's predecessors, the most well-known of which is probably Wolfenstein 3D: perpendicular walls, constant floor and ceiling height. Wolf3D didn't have textured floors and ceilings because of performance reasons, but several other similar games had them. Doom and IIRC Duke Nukem as well used a BSP engine which was much more…

I think the argument could be made both that both engines are raycasters, though they don't cast rays over pixels, but horizontal 2D spans (where each ray is going to end in the same sector).

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

Re: Making Graphics Like it's 1993

#152
post #148

Earlier quoted context omitted.

A grid of squares makes sense for the target hardware at the time though (286 or better CPU)

It really doesn't. I would argue that convex sectors with portals could be quicker than casting rays across a grid for every pixel column, except for some degenerate cases. This is because for any pixel column in-between the boundaries of wall segments, there's virtually no work to be done (O(1)), compared to the work of casting a ray along the grid O(n). Btw, 286 played wolfenstein rather poorly. The 386 is rather m…

Yes, I played it at the time on both a 286 and a 386. You might be right, although you're describing an algorithm more like what Duke3d used rather than raycasting in that case. I was talking purely about raycasting. So it sounds like a misunderstanding on my part.

It's true that Carmack has said several times, including in the readme to the source release of Wolf3d [0], that a BSP-based renderer might be faster than raycasting. He used a BSP tree based renderer for the SNES port of Wolf3d because the CPU was even slower, so I suppose that answers it! There's also a note in the GEBB page 164 from Carmack where he says it was slower than "looping through a few long wall segments". [1]

Early alpha versions of DOOM used a sector-based rendering technique, maybe like what you're describing, which ultimately was too slow [2]][3]. Then Carmack switched to BSP trees after doing the Wolf3d SNES port.

I think it would be pretty interesting to implement the same game with both a raycasting approach and a BSP or Build-style portal/sector approach and compare performance on a 386. DOOM ran terribly on a 386 but it did a lot more than Wolf3d, so it's not a great comparison. Catacomb 3D didn't use raycasting (it used a wall span rendering techniqe) and ran better than Wolf3d on similar hardware, but it had a bunch of glitches. But Carmack says they were due to lack of experience rather than the technique itself.

Anyway thanks for challenging my assumptions. This'll go on my todo list!

[0] https://github.com/id-Software/wolf3d [1] https://fabiensanglard.net/b/gebbwolf3d.pdf [2] https://youtu.be/NnkCujnYNSo?t=1592 [3] https://doomwiki.org/wiki/Doom_rendering_engine

Re: Making Graphics Like it's 1993

#153
post #93

If you want to play with software rendering, here's probably the shortest code that will get an ARGB8888 2D array from main memory to the screen efficiently for all platforms using SDL2 in C https://gist.github.com/CoryBloyd/6725bb78323bb1157ff8d4175d... you'll need to do the translation from a 320x200x8-bit palletized framebuffer to ARGB yourself ;) If you want to get inspired by what can be done with palletized fra…

At least with SDL3, you don't even need the renderer or the texture anymore. SDL_GetWindowSurface to get the surface and SDL_UpdateWindowSurface to present. That's the more software-graphics you can get from my understanding of the library. SDL still does the double-buffering for you.

SDL has always made it easy to directly present a software buffer of pixels to the screen. I'm not sure why someone would want to use the renderer/texture thing for this use case.

Re: Making Graphics Like it's 1993

#154
This author doesn't publish code, makes yet another Doom like Game, calls it not an AI slop. To the author's credit, seems to have made this 7 years ago, https://www.youtube.com/watch?v=YQ7aApNDPQc and then gave up working on it till recently.

It doesn't look like slop at all, and it looks like it actually is. Could have been used to generate art assets, or finish something author did not have the energy to do before. Nobody cares if that was the case. Why the hate towards AI even?

Re: Making Graphics Like it's 1993

#155
post #31

Graphics programming in the early to mid 1990s was pretty fun: write pixel data into the memory-mapped video RAM and it appears on the screen! A pointer to 0xA0000 was all you needed - no API or anything. The reason for the non-square-pixel 320×200 VGA mode they mention was that the video buffer took 64000 bytes, which fit into a 16-bit segment, making addressing it easy in 16-bit code/CPUs.

> A pointer to 0xA0000 was all you needed 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)

There is 16-bit DOS support in Free Pascal these days (yes, added long after 32-bit DOS support). That makes it easier to get a pointer to video memory. Makes other things less easy.

Also some (more) free (open source) 16-bit C-compilers now, like the ia16 gcc port and Microsoft's C compiler included in the MS-DOS repo on GitHub.

Not that 32-bit extenders do not come with some advantages, but I enjoy the simplicity of 16-bit.

Re: Making Graphics Like it's 1993

#156
post #10

I just noticed that this might be one of the rare shooters with a female protagonist: the cat has a calico pattern, and those are almost always female ( https://en.wikipedia.org/wiki/Calico_cat ).

> rare shooters with a female protagonist 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 ei…

And Ion Fury, from 2018, made with the Build engine: https://www.gog.com/en/game/ion_fury

Re: Making Graphics Like it's 1993

#157

We randomly chose magenta as our transparent pixel for shareware games too! I consider 1993 the last "good" year of the pre-internet age. The web didn't go mainstream until around 95, and 94 felt like a liminal year (dunno why). In 93 one could still wrap a plaid shirt around one's waist without fear of ridicule. Grunge and alternative music hadn't quite landed in rural America yet, although we didn't know what we we…

Sorry, false memory - I remembered the full story in all of its gory details after sleeping on it.

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.

Re: Making Graphics Like it's 1993

#158
post #117

Earlier quoted context omitted.

> Duke Nukem as well used a BSP engine 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 (i…

The funny thing is that looking backwards, I would never use a grid of squares for a raycaster like wolfenstein3d did. If I were to do a raycaster today, I would use convex sectors with portals, basically like duke nukem, but constant wall heights. You can do drawing very simply by just doing a linear pass across the sector, recursively stepping into other sectors. Then you can at least do arbitrary level geometries.

[deleted]

Re: Making Graphics Like it's 1993

#159

As a fellow 3d-engine-with-foolishly-unreasonable-constraints developer, I love the detail in the explanations here and seeing the process you went through.

If you want to follow this to its unnecessary limits on the PC, the CGA 3D engine in the 8086 version of Elite is probably maximally constrained :)
Post reply on HN