[Jblade]

does it sound like the vanilla game by default, or do you have to turn an option on in the menu, because if so that's dumb.

[Jimmy]

Blzut3, on 24 February 2020 - 10:36 PM, said:

The output heard by the audio engineer will also depend on the sound card used, what amplifiers, what speakers, human factors (i.e. do they have any hearing loss).

Holy shit this post is fucking stupid and worthless.

[Danukem]

Blzut3, on 22 February 2020 - 06:59 PM, said:

The option to use low quality resampling is there for those who want it.

That's good. And while I largely agree with TerminX's post (and upvoted it), EDuke32 folks should to be careful when it comes to criticizing Raze for decisions that make it less faithful to DOS Duke. The fact is that Eduke32 has a mixed record when it comes to fidelity, especially recently. Sometimes the lack of fidelity is defended on the grounds that it helps make for a better platform to make "cool mods". I actually think that's good, in principle -- I only object when it breaks the fuck out of longstanding behavior that's integral to the original game.

[Phredreeke]

Blzut3, on 24 February 2020 - 10:36 PM, said:

As for being the same code, it's worth noting that in the Duke 3D setup you can turn the mixing down to 8kHz which from a quick test and to my ears seems to reduce (or at least change) some of the noise. (And this would probably depend on what sound hardware the user is using and how it handles lower sample rates.)

Yes. Because if you run Duke3D at 8khz the samples at 8khz aren't resampled by the game. The audio would still be resampled by your OS to whatever your sound card outputs.

Trooper Dan, on 25 February 2020 - 01:14 AM, said:

That's good. And while I largely agree with TerminX's post (and upvoted it), EDuke32 folks should to be careful when it comes to criticizing Raze for decisions that make it less faithful to DOS Duke. The fact is that Eduke32 has a mixed record when it comes to fidelity, especially recently. Sometimes the lack of fidelity is defended on the grounds that it helps make for a better platform to make "cool mods". I actually think that's good, in principle -- I only object when it breaks the fuck out of longstanding behavior that's integral to the original game.

I think the case could be made for user defined sounds to use modern resampling (kinda like how NBlood emulates the Polymost clipping behaviour for user defined voxels)

[TerminX]

Blzut3, on 24 February 2020 - 10:36 PM, said:

The output heard by the audio engineer will also depend on the sound card used, what amplifiers, what speakers, human factors (i.e. do they have any hearing loss). Everything in the chain changes how sound is heard and people have different preferences. You'll probably say none of that counts for various valid technical reasons, but at least the sound card's filters/behavior does matter to people since there are endless debates on what OPL emulator sounds right despite many of them supposedly being bit accurate.

That stuff counts, but it only comes into play after the audio engine has done its work. The sound card, amplifier, speakers, etc don't matter much as far as correctness goes if the audio output is already different beforehand, because even if everything in the chain is 100% identical after that point it still won't sound like it did when they made it.

Blzut3, on 24 February 2020 - 10:36 PM, said:

So is 16-bit 22kHz the only truly correct sound when vanilla had multiple modes?

No, of course not... but it's more correct than just reproducing something resembling the lowest quality offered by the original. To me, it's somewhat equivalent to defaulting to 320x200 and giving users an option to change the screen resolution that only controls the size of the surface the output is rendered to, with the actual option to change the rendering resolution itself buried in a menu somewhere. It's just incredibly inconsistent with the game's original output.

Trooper Dan, on 25 February 2020 - 01:14 AM, said:

EDuke32 folks should to be careful when it comes to criticizing Raze for decisions that make it less faithful to DOS Duke. The fact is that Eduke32 has a mixed record when it comes to fidelity, especially recently. Sometimes the lack of fidelity is defended on the grounds that it helps make for a better platform to make "cool mods". I actually think that's good, in principle -- I only object when it breaks the fuck out of longstanding behavior that's integral to the original game.

C'mon man... it's disingenuous to compare major intentional differences in output with unintended breakage that was later fixed and you know it.

[Danukem]

TerminX, on 25 February 2020 - 01:54 PM, said:

C'mon man... it's disingenuous to compare major intentional differences in output with unintended breakage that was later fixed and you know it.

What I was trying to do there was point out that in both cases (mainline EDuke32 and the Raze fork) sometimes decisions are made with the aim of giving the best overall results for content on the platform, even if that means a lack of fidelity to the DOS game. The breakages aren't intentional, but for some of them we had to point them out with increasing volume for a very long time before it seemed like fixing them became a priority. That's relevant insofar it speaks to what VP regards as important to the EDuke32 platform. In the post from Mblackwell that I linked, he was responding to me and others who were complaining about breakages and us claiming that EDuke32 is supposed to be faithful to the original gameplay. His reponse was that no, the main purpose of EDuke32 was to be a good platform for making content, and that you guys do try to be faithful but not at all costs. In principle, there's nothing wrong with that. But I also think that using modern audio resampling as the default is defensible for exactly the same reason. If the goal is to make a fork that works well for the most content possible, then it makes perfect sense.

tldr; I agree with your priorities and I don't mean to seem disingenuous -- I was trying to say that the audio resampling method that Raze uses by default could be defended on the same ground that certain EDuke32 divergences (e.g. different clipping) could be defended

[TerminX]

Trooper Dan, on 25 February 2020 - 02:24 PM, said:

The breakages aren't intentional, but for some of them we had to point them out with increasing volume for a very long time before it seemed like fixing them became a priority.

You'll have to forgive me for not being super apologetic about my lifelong chronic depression issues getting in the way of fixing some particularly unfortunate bugs for several months. I'm not really very happy about it either, but all I can do now is fix the remaining issues and tell people to chill... so, chill!

Quote

tldr; I agree with your priorities and I don't mean to seem disingenuous -- I was trying to say that the audio resampling method that Raze uses by default could be defended on the same ground that certain EDuke32 divergences (e.g. different clipping) could be defended

"Different due to bugs or oversights" and "different by design" hardly seem comparable. Maybe you could explain how wanting to fix glaring issues where the player could easily warp through solid walls and die etc is at all similar to changing the audio resampling based on personal preference, because I don't get it. If you are somehow under the impression that I intended to just leave aspects of the game broken forever after the clipping changes and then suddenly changed my mind, you have the wrong impression entirely.

[Blzut3]

TerminX, on 25 February 2020 - 01:54 PM, said:

don't matter much as far as correctness goes if the audio output is already different beforehand

Then perhaps the debate doesn't matter much since Raze's audio output will never be "correct" since it uses OpenAL for "improved" 3D sound? Although the irony that Raze improves the 3D sound and then eliminates the frequencies that are easy to aurally locate is not lost on me. As funny as that is, I still personally think it's the right way to interpret the data.

TerminX, on 25 February 2020 - 01:54 PM, said:

No, of course not... but it's more correct than just reproducing something resembling the lowest quality offered by the original.

Given there are very few sounds in the game that are 22kHz I think there's room for argument that 22kHz is not actually the highest quality setting in the game. Maybe hard to argue for 8 given the number of 11kHz sounds, but I think it could be done. Wouldn't be the only time that games have had "highest quality" settings that actually made things worse. To give one example: Hexen had redbook audio but very few people bother with it telling me they're "poor renderings." But given they were rendered by the developer surely it's the intended sound right?

Out of pure curiosity though: Given the assumption that the 22kHz 16-bit setting is the "correct" one, how does eduke32 handle the default setting of 48kHz? Does it render 22kHz and then do a high quality resample or does it just add even more noise? If the latter, do you still consider that "correct?"

[Danukem]

TerminX, on 25 February 2020 - 03:40 PM, said:

You'll have to forgive me for not being super apologetic about my lifelong chronic depression issues getting in the way of fixing some particularly unfortunate bugs for several months. I'm not really very happy about it either, but all I can do now is fix the remaining issues and tell people to chill... so, chill!

I'm chill...but I interpreted the lack of response to the bug reports at that time as VP not being concerned about the bugs. I've lived with chronically depressed people and I've seen firsthand that it's an extremely serious, sometimes crippling, condition. Not communicating during a low point could be a wise decision... Maybe you should have someone else at VP as a designated community responder during times when it gets especially rough.

TerminX, on 25 February 2020 - 03:40 PM, said:

"Different due to bugs or oversights" and "different by design" hardly seem comparable.

I accept that distinction, but when it comes to EDuke32 the truth is pretty messy. Sometimes behavior diverges from DOS Duke because of design choices motivated by making it a better platform. This includes not just bugs and oversights but also subtle and not so subtle differences. Consider: Polymost has long been the main renderer in EDuke32, even though only recently does its output resemble the software renderer. The visual differences aren't exactly by design but they are hardly accidental either.

[Jimmy]

I dunno dude. I like that TX is kind of an asshole sometimes. We get along off and on, and butt heads off and on. But at least I know he's not lying or bullshitting. I can't think of any time he hasn't delivered, just maybe not on time-frames people want. Oh well, it's FREE.

[VGA]

Jblade, on 24 February 2020 - 10:44 PM, said:

does it sound like the vanilla game by default, or do you have to turn an option on in the menu, because if so that's dumb.

Have you tested the port for yourself?

[Radar]

Blzut3, on 25 February 2020 - 04:16 PM, said:

Given there are very few sounds in the game that are 22kHz I think there's room for argument that 22kHz is not actually the highest quality setting in the game. Maybe hard to argue for 8 given the number of 11kHz sounds, but I think it could be done. Wouldn't be the only time that games have had "highest quality" settings that actually made things worse. To give one example: Hexen had redbook audio but very few people bother with it telling me they're "poor renderings." But given they were rendered by the developer surely it's the intended sound right?

Out of pure curiosity though: Given the assumption that the 22kHz 16-bit setting is the "correct" one, how does eduke32 handle the default setting of 48kHz? Does it render 22kHz and then do a high quality resample or does it just add even more noise? If the latter, do you still consider that "correct?"

I think everyone here is open to different rendering options being available. The contention arises when source port developers insist on keeping these features on by default.

[Phredreeke]

i would think the artifacting from 8khz -> 11khz would be worse than 8khz -> 22khz or 11khz -> 22khz.

Also I'd argue the proper way wouldn't be to cubic or spline resample everything, rather do the ASS resampling then offer optional low pass filters

[Jblade]

VGA, on 27 February 2020 - 06:46 AM, said:

Have you tested the port for yourself?

No and I'm not going to until there's something worth my time.

[Blzut3]

Phredreeke, on 27 February 2020 - 07:59 AM, said:

i would think the artifacting from 8khz -> 11khz would be worse than 8khz -> 22khz or 11khz -> 22khz.

Would be interesting to know from someone who knows specifics. Looking at spectrograms of nearest upsampled 8->11 and 8->22 would seem to indicate a similar noise pattern within the 4-5.5kHz range (where the 11kHz sample obviously cuts off). It does look a little denser, but emphasis on little. Can't say if there's enough of a difference to be audible other than the 22k upsample having the additional noise above 5.5kHz.

Phredreeke, on 27 February 2020 - 07:59 AM, said:

Also I'd argue the proper way wouldn't be to cubic or spline resample everything, rather do the ASS resampling then offer optional low pass filters

If ASS is doing nearest resampling like I've been assuming then if you do an optional low pass on a sound by sound basis then you're doing effectively what Raze does when set to sinc resampling just under a different name. Unless you mean specifically a low pass at a fixed frequency (i.e. 11kHz) which would be what my last post said (nearest to 22kHz and then sinc to 44/48).

[Fox]

Jimmy, on 25 February 2020 - 05:11 PM, said:

I dunno dude. I like that TX is kind of an asshole sometimes. We get along off and on, and butt heads off and on. But at least I know he's not lying or bullshitting. I can't think of any time he hasn't delivered, just maybe not on time-frames people want. Oh well, it's FREE.

If someone is never an asshole, then it means they are wearing a mask all the time.

And in my personal experience, they are often compensating for something else.

[Jimmy]

Fucking 10/10 observation fam

[Master O]

Fox, on 29 February 2020 - 11:24 AM, said:

If someone is never an asshole, then it means they are wearing a mask all the time.

And in my personal experience, they are often compensating for something else.

I assume you're referring to "Nice Guy Syndrome"?

[Fox]

Master O, on 29 February 2020 - 05:23 PM, said:

I assume you're referring to "Nice Guy Syndrome"?

No, in general. About people who are way too nice.

[Danukem]

I wouldn't assume that a person is like that just because they try to be nice on the internet, though. They could be very genuine in private life but put on a mask when in a public space where there is the potential for lots of backlash and misunderstandings.

[markanini]

Phredreeke, on 27 February 2020 - 07:59 AM, said:

Also I'd argue the proper way wouldn't be to cubic or spline resample everything, rather do the ASS resampling then offer optional low pass filters

That would sound closest to cubic, even with a cutoff near Nyquist. Most would find that sounding too muffled.

[Phredreeke]

IMO the frequency of the lowpass filter should be user adjustable with a rolloff, not a brick wall filter like sinc.

For reference, here's a post where the user measured the frequency response of their SB Pro 2 card https://www.vogons.o...=815309#p815309

[icecoldduke]

I posted this over on the DoomWorld forums, but Graf seemed to ignore the comment, so I'm going to post it here so it gets more visibility. Graf your threading idea is frankly just terrible , (for reasons stated below), same with your idea to stick with OpenGL.

Graf:
"For writing such a renderer I would use the same approach as in GZDoom, i.e. let the main thread perform the culling, then pass the elements to be rendered to a second thread to create render data from it, and then (what I'm still working on in GZDoom with slow progress) use a third thread to pass that processed data to the hardware and create a command buffer from it."

Me:
"Your main thread should be for the game bits. You have a render thread that builds up the command buffers, but your going to need to leave the culling in the render thread. The way your describing your pipeline your going to have 2 frames of latency, rather then just a single frame of latency. In a FPS game when the player hits a button they expect immediate results. One frame of latency people can deal with, two frames not so much.

Build is deceptively complex for GPUs. Your at the foundation stage at the moment. Lots of people have written graphics bits for Build, and trust me when I say it's such a kick in the ass when you realize you hit a ceiling with the graphics API.

The gains you get from Vulkan/Direct3d 12 come from less driver overhead in the pipeline, trust me when I say you need it on more complex user maps. User maps are the issue here not the retail maps. Remember I was targeting 60 to 144 fps, if your targeting 30fps you'll be fine in OpenGL. "

[Phredreeke]

He's not using Direct3D because that is Windows exclusive.

He plans to make a Vulkan backend but he started with OpenGL because that is common to all GPUs

[icecoldduke]

Phredreeke, on 04 March 2020 - 04:46 PM, said:

He's not using Direct3D because that is Windows exclusive.

He plans to make a Vulkan backend but he started with OpenGL because that is common to all GPUs

Regardless of what graphics API he's using, the biggest critique I have of his work or future work is his threading idea. It's just terrible(see the post above). His idea will introduce two frames of latency. So you press a key, and nothing happens until two frames down the line. It's ridiculous for a FPS game to have that. Technically you shouldn't even have one frame of latency, which is the biggest critique of my PolymerNG work. If I did it over, I wouldn't do it that way again.

[Danukem]

How much time had elapsed between when Graf outlined his plan, and when you posted your critique? It's possible that he has a different plan already but didn't want to get into it with you.

[Doom64hunter]

icecoldduke, on 04 March 2020 - 04:48 PM, said:

Regardless of what graphics API he's using, the biggest critique I have of his work or future work is his threading idea. It's just terrible(see the post above). His idea will introduce two frames of latency. So you press a key, and nothing happens until two frames down the line. It's ridiculous for a FPS game to have that. Technically you shouldn't even have one frame of latency, which is the biggest critique of my PolymerNG work. If I did it over, I wouldn't do it that way again.

So in PolymerNG, is this delay in any way noticeable to the user? Doesn't the game logic itself update at a much slower rate than at which the renderer refreshes the screen?

[icecoldduke]

I posted this critique about a week ago when I heard of his project. Someone on my discord channel pinged me about it. I was kinda disappointed to see Raze is simply a code refactor(in its current state), he’s still using OpenGL, and the was really disappointed about his future threading ideas.

To get any next gen build past the refactor stage, you have to switch to either Direct3D 12 or Vulkan.Youll have to have virtual texturing(which he disagrees with). You can’t have culling done on the hardware, which he also disagrees with.

With build and more complex user maps, you have to have two threads, one for the game bits and one for the renderer. This basically creates one frame of lag between you pressing a button and what you see on screen. Because the renderer is pushing through the games previous frame data.

This is less then ideal for multiplayer especially. You not only have lag between packets sent between players, but now you have introduced another bit of lag. Again for complex user maps you really don’t have a choice.

What Graf wants to do is make that problem worse by moving the culling to its own thread, this adds another frame of lag because the render thread can’t complete its work until the culling thread has figured out what’s visible.

The most ideal scenario is the game and render work on are on the main thread, and you kick of jobs to other threads. This only works if you have enough of the renderer and game code that can run in parallel, and are not dependent on other bits of work, but in build I can’t see a way to do that. This means you’d have no input lag.

Because of all of that, I can’t see Raze making much progress. Which is a shame really.

[Phredreeke]

Wouldn't the latency impact be mitigated at higher framerates?

[icecoldduke]

Phredreeke, on 05 March 2020 - 06:15 AM, said:

Wouldn't the latency impact be mitigated at higher framerates?

The problem actually gets worse with higher frame rate, especially with 144hz monitors. On a 144hz monitor it feels really weird if you’re input doesn’t match what your seeing on screen. Think about VR. What happens if a player moves there head and doesn’t see it in HMD till a few frames later? You get sick. While you won’t get sick on a flat 144hz screen, you do notice it, and it’s really annoying, ask any esports player.