Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Graphics Like it's 1993

staniks.github.io

Post reply on HN
Print view View original

161–169 of 169 posts

Re: Making Graphics Like it's 1993

#161

Post by ant6n »

bananaboy wrote: post #152
ant6n wrote: post #148

Earlier quoted context omitted.

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…

Thank you for all the interesting references. I had almost forgotten about the BSP-SNES port.

I think they main concern when doing sectors + portals for a wolf3d-type 3d engine is how much word is done when 'stepping into' portals. basically it requires changing the clipping range [x0, x] of the portal, and quickly finding the next visible wall segment. the clipping could actually be done in 'angle space', not even using vectors. That is, wall edges/"vertices" should be represented as [angle,distance]. I have also been thinking about how much of that math pipeline could be done using specialized 8-bit values and LUTs.

I have been thinking about trying to get something running on very slow hardware, although at some point the problem is more drawing on the screen quickly, not the renderer.

Re: Making Graphics Like it's 1993

#162

Post by badsectoracula »

1313ed01 wrote: post #155
badsectoracula wrote: post #34

Earlier quoted context omitted.

> 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 o…

[dead]

Re: Making Graphics Like it's 1993

#163

Post by Const-me »

pragma_x wrote: post #88
Teslazar wrote: post #81

Great article. I particularly enjoyed the approach to creating gibs. Although it was a tech demo, I created something like this around the mid 90s. One thing I did that I don't see mentioned in this article was I used 8x8 (or 16x16) light maps on the textures, which allowed me to easily have things like flickering torches and rockets that lit up the hallways as they shot down them. Lightmaps can also be used to "bake…

> I used fixed point math which optimized well. 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.

> let alone more performant

Not anymore. On modern hardware, the only operation where integers win is single cycle add/sub. For the rest of operations (multiplication, division, square roots, etc.) floating point is faster, sometimes by a lot.

Re: Making Graphics Like it's 1993

#164

Post by 2000UltraDeluxe »

Supermancho wrote: post #78
mg794613 wrote: post #55

There is nothing wrong with using AI. What I don't like is to see claims like "no AI slop" And yet it's riddled with emdashes and language "by hand" Seeing the skills of the writer, he definitely should be able to, but then I don't understand the claim.

From the article they list a bunch of arbitrary constraints... > 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 t…

Plenty of 3D tools available for consumer hardware in the 90's; the CGI for the first seasons of Babylon 5 was rendered on Amigas.

Re: Making Graphics Like it's 1993

#165

Post by Jare »

torginus wrote: post #149
tadfisher wrote: post #109

Earlier quoted context omitted.

The code exists! https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.... And it looks to me like we are mapping each row with a constant y, calculating the "distance" (thus scale factor) only once using just the vertical slope for the row.

Yeah sorry, you are right - I got it mixed up.

For the record, there were constant-Z full 3D engines in the late 90s, which would find the correct axes on screen to render perspective-correct textured triangles using oblique spans of pixels. They were incredibly complicated and prone to holes at the slightest numerical accuracy, but they were a sight to behold. Constant-Z meant not just saving on perspective divides, but also easy Z-buffer and depth-based fog.

Re: Making Graphics Like it's 1993

#166

Post by rasz »

Const-me wrote: post #163
pragma_x wrote: post #88

Earlier quoted context omitted.

> I used fixed point math which optimized well. 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.

> let alone more performant Not anymore. On modern hardware, the only operation where integers win is single cycle add/sub. For the rest of operations (multiplication, division, square roots, etc.) floating point is faster, sometimes by a lot.

If you care about performance you use logs and then multiplications turn into integer additions.

Re: Making Graphics Like it's 1993

#167

Post by Const-me »

rasz wrote: post #166
Const-me wrote: post #163

Earlier quoted context omitted.

> let alone more performant Not anymore. On modern hardware, the only operation where integers win is single cycle add/sub. For the rest of operations (multiplication, division, square roots, etc.) floating point is faster, sometimes by a lot.

If you care about performance you use logs and then multiplications turn into integer additions.

On modern processors, floating point addition often has equal performance to floating point multiplication. For example, on AMD Zen4 it’s 3 cycles latency and 0.5 cycles throughput.

I’m not sure that trick going to work in the context of computer graphics. To transform vectors or multiply matrices you need a mix of multiplications and additions, or an equivalent sequence of FMAs.

Re: Making Graphics Like it's 1993

#168

Post by dan-g »

Supermancho wrote: post #78
mg794613 wrote: post #55

There is nothing wrong with using AI. What I don't like is to see claims like "no AI slop" And yet it's riddled with emdashes and language "by hand" Seeing the skills of the writer, he definitely should be able to, but then I don't understand the claim.

From the article they list a bunch of arbitrary constraints... > 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 t…

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

You conveniently left out the second part of that sentence:

> … modern compiler and a platform abstraction layer.

The author very explicitly laid out their constraints in a bulleted list right below; I think calling this nostalgia clickbait is infelicitous at best.

Re: Making Graphics Like it's 1993

#169

Post by yunnpp »

TazeTSchnitzel wrote: post #153
yunnpp wrote: post #93

Earlier quoted context omitted.

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.

I think it's because it's what every tutorial does, and people just copy-paste that template without giving it too much thought. Just need to dig through the API a little.
Post reply on HN