logoalt Hacker News

ryandrake • today at 3:15 PM • 3 replies • view on HN

He likes the look of nearest neighbor texture sampling, not software rendering.

You can do nearest neighbor in hardware rendering and you can do bilinear in software rendering. Rendering mode and texture sampling are two totally different things.


Replies

torginus • today at 6:21 PM

I think there's more to it. In Quake, the software renderer decides the color of each pixel, based on running some code on the CPU, which can do anything. GPU rasterization is far more standardized, with standards defining how each triangle ought to be sampled at each pixel coordinate (and the fact that you're sampling triangles in the first place).

The whole process is standardized with GPU rendering, leading to ways of rendering and content authoring that's quite different from how things used to be, and while definitely possible, modern 'retro' games often render like GPU accelerated games and just disable texture filtering, which doesn't quite give you the look.

He mentions Build games, which are not strictly polygonal.

While general purpose computation exists on GPUs, and the standard rasterization pipeline can be implemented in software, graphics cards have pushed people towards a 'look and feel' which comes partly from standardized data structures, content authoring and rendering approaches, that have made games feel samey.

Whereas with software rendering, essentially you have an array of pixels which you can set to a certain color, and the rest is up to you, which made devs come up with unique ways of rendering and authoring content.

The intricate level designs that were made possible with BSP based tools and are basically 'free' to render in software, had hell of a time making the transition to GPUs, as they rely on traversing the tree while drawing pixels, whereas for the GPU, you need to submit a list of triangles (unless you go GPGPU)

➕ show 1 reply
agumonkey • today at 5:46 PM

Technically you're right, a gpu is just a bunch of ALU and FPU in a way, we just defer computation to a massive array of them so the cpu can do other things, what you do on these gpu cores is up to you.

That said, historically, software rendering meant non-accelerated passes that could be carried out by a cpu at decent enough FPS.

ps: some could also say that a FPU is not software rendering since early x86 didn't have it in the cpu.

fmbb • today at 4:33 PM

The author likes the look of the tradeoff made due to the limitations CPU power imposed on the rendering model for real time 3D games 30 years ago.

Yeah you can hack configurations or create your own game to mimic this look.

If you read the post you will see it’s not only about the texture sampling, but also the color depth.

OP picked a good headline. You are fighting for semantics nobody cares about, and picking a more complicated synecdoche.