[Phredreeke]

But 1/60 is more than 2/144? 🤔

[icecoldduke]

Phredreeke, on 05 March 2020 - 07:17 AM, said:

But 1/60 is more than 2/144? 🤔

Not sure what your argument is?

[LeoD]

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

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

icecoldduke, on 05 March 2020 - 06:27 AM, said:

The problem actually gets worse with higher frame rate[...]

Phredreeke, on 05 March 2020 - 07:17 AM, said:

But 1/60 is more than 2/144? 🤔

icecoldduke, on 05 March 2020 - 08:14 AM, said:

Not sure what your argument is?

If the lag is counted in (number of frames)*(time per frame), it is lower at higher frequencies, isn't it?

[Doom64hunter]

[Phredreeke]

1 frame of lag at 60 FPS is 17ms
2 frames of lag at 144 FPS is 14ms

That's what I was getting at

[icecoldduke]

LeoD, on 05 March 2020 - 08:32 AM, said:

If the lag is counted in (number of frames)*(time per frame), it is lower at higher frequencies, isn't it?

I see what your saying but that’s not quite my argument.

Grafs system lowers frame time which is good, but at a huge cost. So say if I push up on the controller, the result of that action won’t show up until two frames later. So for two frames the game will render him standing still, because the game is still rendering two frames prior.

Is that a better explanation?

Phredreeke, on 05 March 2020 - 08:51 AM, said:

1 frame of lag at 60 FPS is 17ms
2 frames of lag at 144 FPS is 14ms

That's what I was getting at

I get that but I’m sure how that benefits your case. 8ms is better then 14ms. When your playing at faster refresh, the amount of perceived lag becomes more of an issue.

[icecoldduke]

Also your math doesn't take into account the variable input rate of USB keyboard/Mouse devices, which makes your math not as clear cut. If you press a button, and you miss this frames simulation, you could actually be delayed 3 frames(under Graf's purposed pipeline), before you see the result of your input on screen.

[icecoldduke]

Also your math is wrong.

If your refresh rate is 60fps aka 16ms your input delay is 32 to 48ms under Grafs purposal.

At 144fps aka 8ms your at 16 to 24ms of delay, because it’s delay frames x adversge frame time. Even though the delay is less, the perceived delay is higher because your running at a faster refresh rate.

As stated above, my timings are a range because you need to factor in the variable delay in USB input devices.

[Danukem]

Well if you want to make a new renderer for EDuke32 to replace Polymer, you can spectacularly prove him wrong.

[Phredreeke]

icecoldduke, on 05 March 2020 - 09:53 AM, said:

Also your math is wrong.

If your refresh rate is 60fps aka 16ms your input delay is 32 to 48ms under Grafs purposal.

At 144fps aka 8ms your at 16 to 24ms of delay, because it’s delay frames x adversge frame time. Even though the delay is less, the perceived delay is higher because your running at a faster refresh rate.

As stated above, my timings are a range because you need to factor in the variable delay in USB input devices.

I'm not comparing Graf's proposal at 144fps to Graf's proposal at 60fps.

The comparison was between Graf's proposal at 144fps vs running the engine without it at 60fps.

If you get 144fps regardless there is no point to it.

[icecoldduke]

Phredreeke, on 05 March 2020 - 11:20 AM, said:

I'm not comparing Graf's proposal at 144fps to Graf's proposal at 60fps.

The comparison was between Graf's proposal at 144fps vs running the engine without it at 60fps.

If you get 144fps regardless there is no point to it.

Then your missing my argument which is comparing Grafs purposal at 60 vs 144 because if he designs his engine the way he’s purposing, gamers across the performance spectrum are going to have a bad experience.

I agree with you Grafs idea is pointless .

[Hendricks266]

It is not pointless. Where is the evidence behind your assertion that for every stage of multithreaded pipelining added, one frame of input lag is also added? In a naive implementation I can see that being the case, but overall it is not true. If done right it could improve frame pacing by not delaying all frame rendering while the game update is being calculated. Things like clipping calculations and CON execution can vary widely in how much time they take, while the rendering side of the code is more consistent, at least frame to frame in the same world location. The "only" thing you would have to do is triple-buffer the structures that the game provides to the engine for rendering. Any case where this results in more input lag than a single-threaded approach means your game is sending out frames late anyway in the latter case.

[Phredreeke]

Yeah, I don't get either where the extra lag frame comes from (do threads have to wait for VSync to synchronise? ) I'm just saying that even then, if it means reaching whatever your refresh rate is then it's probably a worthwhile tradeoff.

[icecoldduke]

Phredreeke, on 05 March 2020 - 12:59 PM, said:

Yeah, I don't get either where the extra lag frame comes from (do threads have to wait for VSync to synchronise? ) I'm just saying that even then, if it means reaching whatever your refresh rate is then it's probably a worthwhile tradeoff.

It’s really not worth it, and I’ll explain we’re the extra lag comes from.

If you have your game and render jobs on the main thread, then you dont have any input lag(except for the usb delay).

If you move the render work to another thread you get one frame of delay. This is because your game thread does it’s work, passes it over to the render thread, then the game thread prepares its work for the next frame, while the render thread is preparing the last frame. The end result is the frame you see on screen, is last frames simulation.

Now Graf wants to add a extra layer of complexity into this, were you move the occlusion detection stuff to yet another thread, this means you either have to stall the render thread(which defeats the purpose of moving it to another thread in the first place) or you have to setup yet another queuing mechanism, which gives you the extra frame of delay. The net result is, the stuff you see on screen is actually from two frames ago.

The best way to do multi threading in games is to design your engine to do work in parallel, and have the core game and core render bits in the main thread, but it kicks off work to other threads. But with the build engine, I haven’t found a way to do that.

[Radar]

With Rednukem now an option for those who want vanilla accuracy, the EDuke32 project should strive to remove all the crazy spaghetti code from the original source.

[enderandrew]

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.

You could always attempt a new version of PolymerNG.

And FWIW, he has a Vulcan renderer in GZDoom. He is aware of the benefits of Vulkan and I'd be surprised if he didn't eventually have Vulkan rendering in Raze.

[Ursa Major]

With all this crazy talk about the downsides of multithreading, has anyone here even bothered to look at Graf Zahl's other project, GZDoom, to see how it implements multithreading? That should give a good hint what he's really planning. I see a lot of conjecture here but zero facts. What I can definitely say is that GZDoom does not lag, despite using multithreadiing in its renderer

My worries here lie elsewhere. Raze - being true to its name - ripped out a good part of code some mods may rely upon. It surely works great for the original games and old mods but with anything more recent the experience was less thrilling. I wonder if this can be resolved. Two mods I had major problems with were Duke TM and Nuclear Showdown.

[icecoldduke]

enderandrew, on 05 March 2020 - 02:32 PM, said:

You could always attempt a new version of PolymerNG.

And FWIW, he has a Vulcan renderer in GZDoom. He is aware of the benefits of Vulkan and I'd be surprised if he didn't eventually have Vulkan rendering in Raze.

Maybe at some point I’ll port some of my icedtech work over to Build. I’ve got a version of Doom 3 with virtual texturing, megatexture DirectX 12 raytraced lightmapper, PBR and a bunch of other stuff, and now I’m moving my Quake 3 AI recast Navmesh work over to IcedTech and making a arena shooter. Maybe when that’s done I’ll move that stuff over to build.

Anyway I digress. I hope his project succeeds, but atleast with the technical choices he told me about a week ago, I think this will go through a few rewrites before this becomes anything worthwhile. And it’s a shame really, he could just make the correct tech choices from the start.

[icecoldduke]

Hendricks266, on 05 March 2020 - 12:24 PM, said:

It is not pointless. Where is the evidence behind your assertion that for every stage of multithreaded pipelining added, one frame of input lag is also added? In a naive implementation I can see that being the case, but overall it is not true. If done right it could improve frame pacing by not delaying all frame rendering while the game update is being calculated. Things like clipping calculations and CON execution can vary widely in how much time they take, while the rendering side of the code is more consistent, at least frame to frame in the same world location. The "only" thing you would have to do is triple-buffer the structures that the game provides to the engine for rendering. Any case where this results in more input lag than a single-threaded approach means your game is sending out frames late anyway in the latter case.

I didn’t say mutlthreading was pointless, I said how he’s doing it is wrong, his method will lead to a pointless and unplayable result.

Ideally you would have a core game and rendering driver in your main thread. You want your work wide and long, basically saturating all cores and having your engine designed so work can be parallel as much as possible.

For example: The core game driver would kick off n number of jobs to deal with con script execution. Then you would have physics jobs that could all be executed in parrael. But the main thread is stalled or doing work for the game driver, and then when everything completes, the render core driver start and it kicks off parallel work. Then the frame is done. The concept is the game and render drivers fully saturate all cores on the CPU, but the drivers run sequentially on the main thread.

Ideally in the renderer you would have work that could be done in parralel. but in build everting has to be down in sequential order, your forced to do multi threading the wrong old fashioned way.

The wrong old fashioned way, you have a game thread and a render thread. He also wants to add a third layer for occlusion. This is were you get something I think will be unplayable. This method is wrong for the reasons I stated above. Users will have a better, smoother experience using the method i described above.

[Player Lin]

Ursa Major, on 05 March 2020 - 02:46 PM, said:

My worries here lie elsewhere. Raze - being true to its name - ripped out a good part of code some mods may rely upon. It surely works great for the original games and old mods but with anything more recent the experience was less thrilling. I wonder if this can be resolved. Two mods I had major problems with were Duke TM and Nuclear Showdown.

I still would say : Too early to worry about these things. They even haven't get every classic games totally working and still in Alpha phase...

And you still have EDuke32 and other ports, Raze is just other port.

EDIT : Also, Graf runs into some problems with DNTM and Ion Fury(also some mods like AMC TC changes some internal keybind functions) and he's try to investigate how to resolve them.

[Phredreeke]

IMO he should put EDuke32 support on hold, it's a moving target. Similarly I can't say I'm a big fan of him declaring Shadow Warrior 'supported'

[icecoldduke]

This comment by him pissed me off. He shitted all over the original duke programming team. Has he ever shipped a game?

[Ursa Major]

icecoldduke, on 06 March 2020 - 11:55 AM, said:

Has he ever shipped a game?

Apparently he started years before Doom and Duke Nukem were released.
What a lucky coincidence that he just posted this today!

https://www.doomworl...um/post/2091443
A picture with proof can be found here: https://www.abandonw...ogical&gid=1245

So the question goes back: Have YOU ever released a game?

And this should also be required reading for you: https://forum.zdoom....p?f=347&t=67741

[icecoldduke]

Ursa Major, on 06 March 2020 - 01:07 PM, said:

So the question goes back: Have YOU ever released a game?

Ive shipped quite a few different games in the past 12 years .

I hope I’m wrong about him and Raze that’s we’re I’m going to leave it.

[DisgustedGrunt]

FPS in e1l1:

Eduke32 450+ (Polymost)
Raze 150, barely (Opengl, no fps cap)

[Fox]

icecoldduke, on 06 March 2020 - 11:55 AM, said:

This comment by him pissed me off. He shitted all over the original duke programming team. Has he ever shipped a game?

While he may sound condescending, he does have a point. Using gamecode from Ken "demo" is very amateurish.

[Phredreeke]

Lazy Dog, on 06 March 2020 - 03:11 PM, said:

FPS in e1l1:

Eduke32 450+ (Polymost)
Raze 150, barely (Opengl, no fps cap)

I get around 450-600 in Raze with FPS unlocked, while testing in EDuke32 I got 2500-3300 FPS (which is higher than I remember getting before... was there any recent optimisations?)

[icecoldduke]

Fox, on 06 March 2020 - 03:26 PM, said:

While he may sound condescending, he does have a point. Using gamecode from Ken "demo" is very amateurish.

How so? I’ve worked on quite a few engines in the industry at this point. If the engine developer supplies me code I’ll take it and use it.

The code in ken demo may or may not have had bugs, but it was a good sample project to get you up and running. Why rewrite something if your paying someone else to give you something of quality? If there’s was bugs in the code those, to your point, should have been flushed out during development. But to say it was amateurish to use that code is frankly insulting to the devs that worked on Duke3D.

[Danukem]

How much more motivation to make an EDuke32 renderer do you need?

[Jimmy]

>implying using BUILD/Ken's Labyrinth was a stupid idea
>required very little dev-time after 3D Realms scooped it up
>all costs furthering development recouped by licensing the engine to others
>three of the greatest FPS games ever made were on the BUILD engine + a handful of decent ones

Wow what a big fucking mistake. These clowns have their heads very far up their asses.