/vr/ - Retro Games

[Anonymous No.7906603]

Software rendering > 3d hardware accelerated rendering

[Anonymous No.7906608]

>>7906603
Yeah man I love Doom on the Saturn too

[Anonymous No.7906694]

>>7906603
Man, 3D accelerators were a massive scam pushed by Carmack and 3dfx

[Anonymous No.7906709]

>>7906603
I agree, but you should consider what a privileged position you have to be able to have that preference. CPUs are now fast enough to run old games like Quake, including very complex community maps, at 100+ FPS or whatever it is. And all those tricks like texture filtering are things you take for granted as an option rather than something that was hard to achieve.

[Anonymous No.7906732]

Did anyone ever render that in 4k or 8k? I really would like to know if that would recude the general noise.

[Anonymous No.7906746]

>>7906732
Even back in the day at 768p software render, Quake looks absolutely fine and not really that much different than GLQuake.

[Anonymous No.7906754]

Only zoomers think texture filtering wasn't a big deal.
There is a case to be made that Quake was made without it in mind, but generally, you want it, and software precludes that.

Either way, the real issue was the horrible latency. Software was far more responsive at 20 FPS. Voodoo 1 was a wash. Voodoo 2 was the real Quake card.

[Anonymous No.7906971]

>>7906754
>Either way, the real issue was the horrible latency. Software was far more responsive at 20 FPS.
Proof? Software rendering at 20 FPS is going to have more latency than hardware at 30 FPS, just pure math.

[Anonymous No.7906990]

>>7906971
if the game can't handle consistent 30FPS it's going to feel clunkier and latency will be inconsistent

[Anonymous No.7907012]

>>7906709
Based post

[Anonymous No.7907191]

>>7906694
Schizo post.

>>7906754
>but generally, you want it
No, I don't, it looks like hot garbage.
https://www.quaddicted.com/engines/software_vs_glquake
You can decide for yourself, but I think it kills the gritty aesthetic of the game.

[Anonymous No.7907362]

>>7906603
I think the best looking 3d accelerated games started as software rendered. Later on developers used texture filtering as an excuse to stretch low rez textures over big areas.

[Anonymous No.7907409]

>>7906754
>software precludes that
not really. at least, not completely.

[Anonymous No.7907423]

>>7906603
>>7906694
So this is the new discord shitpost of the week?

[Anonymous No.7907569]

>>7906603
and?

[Anonymous No.7907647]

>>7906603
Software rendering was the only mode that enabled those crazy water distortion effects right?

[Anonymous No.7907949]

>>7906603
r_drawflat 1 > wall textures

[Anonymous No.7907957]

>>7907949
S0VL

[Anonymous No.7907979]

>>7906603
> quake
> 1996

> Kings Field
> 1994

why was quake considered cutting edge, again?? can americans just not admit that Japan was kicking their ass?

[Anonymous No.7907983]

>>7907979
Pathetic

[Anonymous No.7908003]

>>7907983
By June 1996 From Software already released Kings Field III... They finished their third textured fully 3D game a month before Id released Quake.

[Anonymous No.7908010]

>>7908003
Whoahow look up the Virtua Fighter 3 release date.

[Anonymous No.7908016]

>>7908010
so whats the big deal about quake

just looked good?

[Anonymous No.7908054]

>>7906694
yeah, a scam to make your games look and perform better

[Anonymous No.7908083]

>>7906971
>Just pure math
Baka. Read this. https://danluu.com/latency-mitigation/
>>7907191
As I said, Quake is an exception, even ignoring all the flaws of GLQuake.
>>7907409
That doesn't even work on certain transparencies. You'll notice that the skybox mountains still look completely unfiltered.

[Anonymous No.7908119]

>>7908016
>fully 3D, complete with real room over room, bridges, water, walls and floors at any angle you could imagine, even enemies and projectiles were 3D
>it was all software 3D, too and could have as complex level architecture as it did for the time due to very smart culling/optimizing (Binary Space Partitioning, also used in Doom)
>the game was fast; the player is fast, the monsters are fast, the projectiles are fast, the traps are fast, the fighting was fast, and the online multiplayer was fast (ridiculously fast, even)
>had enjoyable level design, maps looked cool, were fun to explore, had great atmosphere, lots of secrets to discover, and had clever combat encounters
>monsters all had their own behavior, there's basic grunt gunmen in the intro levels for each episode, but then you'll get monsters which all have distinct behaviors and qualities, requiring their own tactics, different kinds of monsters are combined against the player to force him to think and act faster
>gritty medieval gothic aesthetics, crosses fast action and gunfighting with dark fantasy horror visuals, has great sound design and music to go with that, the guns boom like thunder and the monsters roar like angry oxens

Comparing Quake to King's Field feels really misguided, since they aren't the same kind of game, and are on pretty different technical levels. Looking at pic related, Quake is chock full of detail like this in all of its maps.

[Anonymous No.7908179]

>>7908083
>That doesn't even work on certain transparencies
you say "doesn't even", but clearly it's an edge case that may well be a single flag flip away.
the point is that, in principle, you can do any algorithm on the CPU. you're not babysitting the API, and the API is not babysitting you.
the only real 'limit' for filtering is 8-bit palette. I don't actually know if there's any other reason for it than memory - and if that's the case you could drop the texture resolution by half (feasible for Unreal), go full 24-bit, and still remain 25% in the green.

[Anonymous No.7908207]

>>7908119
>>fully 3D, complete with real room over room, bridges, water, walls and floors at any angle you could imagine, even enemies and projectiles were 3D
Wow so Descent two years late then

[Anonymous No.7908209]

>>7908179
The issue is that alpha-tested transparencies cannot be dithered like that, or the edges would look absolutely horrendous. You need a linearly interpolated alpha mask of some sort, and then you might as well just be using acceleration.

[Anonymous No.7908240]

>>7908209
I'm arguing possibility, not practicality or aesthetics. I'm a nearest guy myself.
https://mankrip.tumblr.com/post/631533857388314624

[Anonymous No.7908338]

>>7906746
> 'back in the day' @768p SR
Assuming 'back in the day' means when the game was released, what kind of CPU did you own to run quake in 768p in software mode?

[Anonymous No.7908343]

>>7908083
>Baka. Read this.
We're not talking about perceived latency OR buffered frames.
My analogy with software 20 FPS vs hardware 30 FPS already includes the latency between GPU buffered frames.

We're talking simply pure math from mouse click to gun firing on screen, comparing software to GPU with everything else being the same between the two tests.

[Anonymous No.7908345]

>>7907409
this doesnt look like quake

[Anonymous No.7908350]

>>7907979
>>7908003
You realize we already had games like Descent and Terminator by then? Made in the west, true 3D engines way before Quake.
Quake is influential because it was one of the first games to get 3D acceleration patched in right after it's release, hence why it's considering cutting edge PC software. Plus it incorporated a lot of clever software engineering to deliver good performance even when software rendered compared to other software rendered 3D games of the time.

It wasn't until the PS2 though that PCs overtook (at console launch times) the performance lead of GPUs. There's no shame in saying that a PS1 game had better graphical hardware at the time.

[Anonymous No.7908353]

>>7908345
Neither does Quake at 1024x768 in software rendering mode.

>>7908338
Real time? A magical one, even a 1GHz Athlon form 5 years later will give you a less FPS than you have fingers.

[Anonymous No.7908357]

>>7908350
>one of the first games to get 3D acceleration
in other words, the whole premise of this thread is invalidated

[Anonymous No.7908446]

>>7908240
Yikes, exactly what I imagined.

[Anonymous No.7908473]

>>7908343
>Perceived latency
What? Are you referring to the part about late-frame extrapolation? Similar ideas are also applicable to non-VR games, but that's not relevant for Quake.
>We're talking simply pure math from mouse click to gun firing on screen
Yes, exactly what most of the article is addressing. Taking the GPU out of the equation reduces this lag significantly.
With worst-case load and input timing scenarios, it goes something like this.
>50ms input buffering > 50ms rendering > present on screen = 100ms
VS
>33ms input buffering > 33ms frame setup > 33ms rendering > present on screen = 100ms

So that's very roughly equivalent, assuming you are just dual-buffering with no synchronization. There are some caveats. API setup rarely takes that much time, but on the other hand, GPU commands are slow to respond, so I'd say it evens out. In practice, acceleration is far more prone to experiencing bubbles and excessive buffering (especially with an uncapped framerate), so I would still place my bets on 20 FPS software being a bit more responsive, going by the pure math.

[Anonymous No.7908597]

>>7908357
Quake was launched before concumer 3D accelerators were widespread. Quake was developed and launched with only software rendering, the post you replied to literally mentions "right after it's release", which you conveniently left out. 3D acceleration for Quake was a patch and not part of the launched game.

[Anonymous No.7908630]

>>7908473
Add half to one frame delay to the 50ms of software rendering, since it uses a single frame buffer too, to keep vsync. Also don't forget that frame presentation time on the screen must be accounted in too when we are talking about responsiveness in general, when we are looking at frame after frame.

As I said myself, I wasn't even talking about general responsiveness, just argued about the fact that in any case 30 FPS 3D API vs 20 FPS software, the 30 FPS is going to win, even if you add the additional processing latency.

[Anonymous No.7908780]

>>7908630
>To keep Vsync
Not sure why you would bring that up. Not only does Winquake default to not using V-sync, I explicitly refrained from considering it since it has a tendency to add several frames of latency in accelerated applications. I clearly remember having to turn it off on a Voodoo 2 to make Unreal Tournament acceptably responsive.
Since the screen presentation time depends on other factors and is constant between software and hardware anyway, it wasn't worth considering. Same goes for mouse polling rate, etc.

>As I said myself, I wasn't even talking about general responsiveness, just argued about the fact that in any case 30 FPS 3D API vs 20 FPS software, the 30 FPS is going to win, even if you add the additional processing latency.

So it's just smoother? That, ironically, is what I would ascribe the word "perceived" to.

[Anonymous No.7908789]

>>7908597
so what you're telling me is, there's nothing notable about quake

[Anonymous No.7909253]

>>7908780
Not anon but I think they mean that software rendering in Quake has one frame of buffer, which is true for original DOS Quake

[Anonymous No.7909265]

>>7908789
Except it being a showcase of great software development and hardware utilization of the time and also a kickass first person shooter from id? Sure
I have no idea what you're even on about anymore, seems to be just butthurt again Quake or failure to realize the things behind it

[Anonymous No.7909272]

>>7908789
so what you're telling me is you're gay and you like fart noises

[Anonymous No.7909293]

>>7908789
I don't know. Is a game that single handedly made 3D accelerators popular not notable? Quake was *the* game people bought 3D accelerators for and why it got a patch for 3D acceleration right away.

[Anonymous No.7909430]

>>7909253
What do you mean by one frame of buffer? How it deals with the video depends on the setting. Some of the VESA modes allow for triple-buffering, even.

[Anonymous No.7909491]

>>7908207
Except it was fun.

[Anonymous No.7909494]

>>7908789
>>7907979
>>7908003
>>7908207
hipsters get the rope

[Anonymous No.7909524]

>>7909430
Didn't say otherwise, just saying by default

[Anonymous No.7909565]

>>7909524
That still doesn't make sense. It's still technically double-buffered, even if the render target resides on local memory. You'd never want a single buffer for anything 3D. You actually can do that in OpenGL, and it reduces lag at the cost of nasty artifacts.

[Anonymous No.7909582]

>>7909565
Having a single frame in the buffer at all times is double buffering, anon

[Anonymous No.7909598]

>>7909582
Don't bother with that guy, he's been trying to smartass the whole thread already without actually knowing how it works (or having very basic understanding, basically Kruger).

[Anonymous No.7909612]

>>7909582
I think we are speaking past each other, you'll have to elaborate.
It would not be double-buffering if you were, say, blitting to the front buffer directly.

[Anonymous No.7909617]

>>7909598
>people shitposting for attention on 4chan
wow

[Anonymous No.7909624]

>>7909598
Yes, God forgive me for citing the man behind the engine itself and not just speaking out of my ass.

[Anonymous No.7909648]

>>7906694
>3D accelerators were a massive scam pushed by Carmack and 3dfx
I know, imagine if no one bought 3d accelerators and we were all still using software rendering today haha

fucking moron

[Anonymous No.7909653]

>>7909648
You mean kind of like what happened to network controllers and sound cards and we're still fine?

[Anonymous No.7909656]

I don't know about Quake, but, from my experience, Half-Life looks a lot better in software mode at 640x480 than in OpenGL at 1600x1200.

[Anonymous No.7909661]

>>7909653
>And we're still fine
Lol, no. The de facto 7.1 standard has ruined gaming audio forever.

https://youtu.be/bFXijU3tAZY

[Anonymous No.7909664]

>>7909661
3D sound is better than ever though, all the spatial stuff is in engine now. The problem is that hardware accelerated sound is gone after Vista, which sucks ass.

Technically not gone, but not used on PC anymore, still used on consoles where audio processing gets offloaded to shader based DSPs processing audio to offload CPU usage, since the CPUs are weaker to begin with.

[Anonymous No.7909667]

>>7909664
>gone after Vista
after Vista came out*

[Anonymous No.7909668]

>>7909664
>all the spatial stuff is in engine now

You mean in one of the many middleware libraries that are slow to integrate with anything? Windows 10 has a new dedicated API, yet barely any game makes use of it. And even then, Dolby Atmos and DTS both sound questionably colorful.

[Anonymous No.7909694]

>>7909668
No, I mean the positional engine, sure some are middleware and some are integrated, it's unrelated to the Windows output APIs though (but I don't think you mean those, since you mention the spatial APIs), which are only there for audio device and audio stream/mixing management, there's no 3D or spatial going on there.

Things like Atmos and DTS require the software to support it, there's generic methods of just using the 7.1 data coming from the engine to mix it into a spatial stereo signal. But none of that is actually processed on the sound card, it's all done on the CPU, unlike in the past where we actually had the sound card process several Wave or mp3 streams at once and mix them together.

[Anonymous No.7909703]

>>7909694
>there's no 3D or spatial going on there.
I'm talking about the API that interfaces with Atmos and DTS.
https://docs.microsoft.com/en-us/windows/win32/coreaudio/spatial-sound

It's used by the new Modern Warfare.

[Anonymous No.7909726]

>>7909703
Yeah got it, I meant things like WASAPI under "Windows output APIs" but I already thought you meant the spatial ones like Atmos, Sonic, DTS, etc.

[Anonymous No.7909742]

>>7908207
Descent doesn't have nearly as good level design or gameplay.

[Anonymous No.7909751]

>>7909653
some users demand more than just "fine"

[Anonymous No.7909778]

>>7909751
Unless it's the enterprise market, nobody really cares about those users since they are the minority.

[Anonymous No.7909920]

>>7906603
Imagine thinking Software rendering was better when all you had a 166mhz AMD. LMAO STFU with your unlimited cycles. Hardware Rendering was King.

[Anonymous No.7910040]

>>7909920
This, most of the zoomers on this board werent' even born when PCs had both a generic 2d card and dedicated 3d accelerator installed at the same time until cards came along that did both 2d and 3d hardware acceleration

[Anonymous No.7910107]

>>7910040
>This, most of the zoomers on this board werent' even born when 0.5% of PCs had both a generic 2d card and dedicated 3d accelerator installed at the same time until cards came along that did both 2d and 3d hardware acceleration
FTFY

[Anonymous No.7910264]

>>7910107
>0.5%
source

[Anonymous No.7910275]

Man, Quake 1’s atmosphere is like no other.

[Anonymous No.7910292]

>>7910264
That is a pretty dumb statement, true.
Reality was probably more like 0.1% at those times.

[Anonymous No.7910486]

>>7910292
I'm willing to meet your 0.5% claim half way at 0.25% and but must include15 minutes of handholding with mutual-touching

[Anonymous No.7910513]

>>7910486
but anon, I'm a girl

[Anonymous No.7910520]

>>7909751
fuck them

[Anonymous No.7910618]

>>7910513
so am I :3

[Anonymous No.7910704]

>>7908016
>>7908119
>>7908350
>>7908789
Wasn't the big thing about Quake the lighting system.
Like it was much better then other 3d games, something something Daikatana

[Anonymous No.7911220]

>>7910704
This advanced lighting system sure was underutilized.
Quake 3 even dropped dynamic lights entirely and just paints a blob around you whenever you fire.

[Anonymous No.7911240]

>>7907409
>that software texture filtering
S O U L

[Anonymous No.7911546]

>>7911220
>Quake 3 even dropped dynamic lights entirely
I'm just going to ask for source for this claim so you can find out the opposite yourself.

[Anonymous No.7911551]

On-the-fly rendering > framebuffer rendering

[Anonymous No.7911583]

>>7907979
It's speedy. King's Field is great but it runs like a fucking dog. Carmack wants that meth head gameplay

[Anonymous No.7911598]

Your mom renders my cock every night.

[Anonymous No.7911659]

>>7911598
Don't even need a 3D accelerator to get playable frame rates rendering that.

[Anonymous No.7911751]

>>7911546
Source: The game
Just go to any dark room and try to illuminate it with the gauntlet. It does squat. It can only make bright rooms brighter.

There are virtually no dark rooms in the vanilla maps, so this was never a huge issue.

[Anonymous No.7911753]

>>7911751
What do you have the "Lighting" option set to in the video options?

[Anonymous No.7911757]

>>7911753
It's not set to vertex, anon.

[Anonymous No.7911772]

>>7911551
Based and race conditionpilled.

[Anonymous No.7911898]

>>7911751
it's there. fix your monitor and/or eyes

[Anonymous No.7911908]

>>7911898
Exactly and that's actual dynamic lighting, since even though it's not as noticable in Quake 3, many games that used the engine you can see it a lot in.
This isn't "just draws a static blob under the projectile" like anon claimed.

[Anonymous No.7911967]

>>7911898
Anon...

[Anonymous No.7912006]

>>7911967
Meanwhile, here is what actual dynamic lighting looks like.

[Anonymous No.7912013]

>>7911967
idk what that's supposed to prove. the wall clearly lights up slightly from the gauntlet.
as for the "tall" lights, Doom 3 does the same for all of its light sources, and it has precisely zero non-dynamic lighting.
>inb4 bizarro semantics

[Anonymous No.7912015]

>>7911967
>>7912006
Both have dynamic lights, original Quake 3 does just not overdo it as much.

>quickly turning the camera after you notice you were recording the gauntlet lighting up enviroment
priceless

[Anonymous No.7912026]

>>7912013
>>7912015
Are you deliberately being obtuse? I am alternating between the dark spot to show that it does not light the wall within the corridor up. It's only when I go outside that the blob becomes visible.
>>7912013
>as for the "tall" lights, Doom 3 does the same for all of its light sources, and it has precisely zero non-dynamic lighting.

>as for the "tall" lights, Doom 3 does the same for all of its light sources, and it has precisely zero non-dynamic lighting.
Don't know what you are talking about. I just booted up Doom 3, and the BFG lights up the environment spherically. You must be thinking of some artist-placed lights that are intentionally made tall.

[Anonymous No.7912068]

>>7912026
>it does not light the wall within the corridor up
it does. again, fix your gamma/monitor/eyes/brain

as for Doom 3, I'm talking out of my ass somewhat, I've only tried mapping for idtech4-based Dark Mod, and lights use radial falloff "horizontally" and linear falloff "vertically". though maybe I'm misremembering things, really can't be bothered to check.

[Anonymous No.7912078]

>>7912068
Wow, completely illuminating!

>>7911898
I just noticed that you're recording with fucking gl_overbrightbits on. Everything, including the HUD is dark. Turn it fucking off or go windowed.

[Anonymous No.7912094]

>>7912078
a screenshot isn't the best way to prove or disprove dynamic anything.
still, it looks like they may have fucked up and multiplied instead of adding the contribution.
it's still dynamic lighting.

>you're recording with fucking gl_overbrightbits on
I didn't really set it up, it's a clean install with mostly just the resolution changed. I think I noticed gamma brightening my other monitor and turned it down a bit. really, that just proves my point, the rocket light would have been even more visible with a clean config.

[Anonymous No.7912108]

>>7906709
this
comparing late 90s PC software and hardware to now is dumb as shit

[Anonymous No.7912110]

>>7912094
>a screenshot isn't the best way to prove or disprove dynamic anything.
That's why I made a WebM, which that picture is literally a screenshot of. Jesus Christ.
>it's still dynamic lighting.
You can call it fake dynamic light if you really want, but I like calling it what it is, a blob. Hard to treat it as light when it can't do the one thing it's supposed to, light up the darkness.
This was all done to save performance, because the Q2 lights were performance killers.

>I didn't really set it up
It's default for full-screen. It's normal for Quake 3 to turn up the gamma, but this won't affect recordings.
Also, correction, it's r_, not gl_

[Anonymous No.7912125]

>>7911967
It's embarrassing that people still tried to argue otherwise after this.

[Anonymous No.7912128]

>>7912110
>fake dynamic light
it changes the lighting, dynamically. it's a dynamic light.
>That's why I made a WebM
your webm showed that there are, indeed, dynamic lights in Quake 3.
and I could argue that it's the mapper's fuckup rather than the engine's. if the engine doesn't support some features in pitch-black areas, the map should not include those.

[Anonymous No.7912148]

>>7912128
>it changes the lighting
It literally doesn't. This is more akin to painting the wall with a brighter color. It looks brighter because the surface changed, not because the irradiance changed.

>and I could argue that it's the mapper's fuckup rather than the engine's.
You really mean that, don't you? This is a capitulation to the fact that dynamic illumination is not a thing. It sure takes some mental gymnastics to shift the blame to the mapper for missing a tiny spot, when the whole issue stems from a feature regression in the engine. It took effort to find a suitable vanilla map to demonstrate this.

[Anonymous No.7912150]

>>7912078
>I just noticed that you're recording with fucking gl_overbrightbits on.
That's default, maybe your installation or config files are fucked.

[Anonymous No.7912153]

>>7912148
>It took effort to find a suitable vanilla map to demonstrate this.
just means it's an oversight

[Anonymous No.7912164]

>>7912150
See
>>7912110

>>7912153
Says who? What if the map was made during a stage of development that still had functional lights? I could be wrong, but some beta builds of Quake 3 probably had it.

[Anonymous No.7912170]

>>7912148
>the surface changed, not because the irradiance changed
also the implication here seems to be that it's more performant to change the surface texture instead of the lightmap - when lightmaps are a hundred times smaller in size.
I'm not claiming to be an expert on its source code, but that doesn't seem right.

also also: what's this? https://github.com/id-Software/Quake-III-Arena/blob/master/code/renderer/tr_light.c

[Anonymous No.7912189]

>>7912170
IIt's not changing any texture, it just draws a transparent texture in a different pass.

[Anonymous No.7912191]

>>7906603
Where did the pixelated software rendering meme come from? These days all those "retro throwback" FPS games that try to imitate Quake in software rendering mode, unironically mostly hyped by zoomers who never ever played Quake back in the day since they were still shitting in their diapers.
Anyone can explain this meme to me?

[Anonymous No.7912197]

>>7912170
>also also: what's this?
Oh no no no

[Anonymous No.7912202]

>>7912197
>>7912170
That's the vertex lighting used for characters/items only.

[Anonymous No.7912205]

>>7912189
it can't "just draw" it, it has to be blended at some point. why would blending with texture pixels be faster than blending with lightmap pixels?

[Anonymous No.7912212]

>>7912202
"bmodel" in the code means the world and any of the moving doors/platforms etc

[Anonymous No.7912217]

>>7912202
no, that's the part for models, there's a section about dynamic lights in general

[Anonymous No.7912220]

>>7912205
I thought it was a given that drawing transparency is blending.
>why would blending with texture pixels be faster than blending with lightmap pixels?
It's already doing both.
Blending isn't the problem, updating the lightmap is.

[Anonymous No.7912235]

>>7912220
yeah I still don't get it
let's assume it's somehow cheaper to first draw this "blob" and then multiply by lightmap, leaving zero in the lightmap as zero on screen. well, why not switch them around then? I'm not seeing the optimization, seems like the same number of same operations.
again, obviously, not an expert.

[Anonymous No.7912240]

>>7912217
The screenshot shows a portion of R_SetupEntityLighting, which is called by R_AddMD3Surfaces, MD3 being models.

None of the Bmodels seem to be affected by normal vertex lighting. Doors and platforms still only light up if they are already illuminated. I know that the game uses uses a static vector for specular highlighting on everything, so maybe that could be what's happening.

[Anonymous No.7912256]

>>7912235
Again, the performance hog was not down to blending, but updating the lightmaps. In Q2, they were drawn by the CPU and uploaded dynamically.

Switching the blending order would probably be feasible, but I can imagine that it's problematic with Quake 3's shader system. It relies heavily on a specific order of blending for its effects. I'd love to see one try, though.

[Anonymous No.7912367]