[mjr4077au]

Can anyone interested please try this patched build on 8813 using r_vsync 1? Seems fairly good to me.

Attached File(s)

•  eduke32.7z (1.79MB)
  Number of downloads: 600

[Mr. Death]

Mitch Richters, on 07 April 2020 - 07:35 PM, said:

Can anyone interested please try this patched build on 8813 using r_vsync 1? Seems fairly good to me.

I'd love to give it a try, but I'm on a 32-bit system so it wouldn't start up for me.

What changes did you make?

[Mark]

Are you saying the 32 bit version of 8813 won't run on your computer?

[LeoD]

Mark, on 08 April 2020 - 05:58 AM, said:

Are you saying the 32 bit version of 8813 won't run on your computer?

I assume the provided version is 64 bit. However, it won't run for me either. Bails out after showing an empty startup window for a few seconds. A debug exe could help. Maybe the build has local CPU optimizations compiled in.

[mjr4077au]

Sorry guys, yes I think it was locally optimised and x64.

Attached are un-optimised versions, one for each arch. I couldn't make my 32-bit toolchain compile the assembly so its built with NOASM=1.

Attached File(s)

•  eduke32_8813_BothPlatforms.7z (3.17MB)
  Number of downloads: 564

[Mr. Death]

Mitch Richters, on 08 April 2020 - 11:57 AM, said:

Sorry guys, yes I think it was locally optimised and x64.

Attached are un-optimised versions, one for each arch. I couldn't make my 32-bit toolchain compile the assembly so its built with NOASM=1.

Ok, I've tried out your patched build and it seems like the stuttering is finally fixed (or at least massively improved)!

Awesome work!

[mjr4077au]

Mr. Death, on 08 April 2020 - 06:46 PM, said:

Ok, I've tried out your patched build and it seems like the stuttering is finally fixed (or at least massively improved)!

Awesome work!

Awesome, that's great to hear!.

Basically, what changed in 8031 was the removal of glFinish() following SDL_GL_SwapWindow() in sdlayer.cpp. You can test this yourself by getting a release as new as r8603 and from the console, set r_swapcomplete to 1 which will restore the pre-8031 behaviour.

Adding this back for r_vsync 1 is ultimately what's restoring the playability with proper vsync, however from my reading, having to call glFinish() to not have the problems we're having with polymost is just a mask for the real issue, and this is corroborated in my mind since proper vsync with Polymer has no problems.

Other than that, I made some changes to Duke 3D's main game loop to further reduce input lag and compensate for the glFinish(). It should feel slightly better than stock, but those on better screens than me (i.e. not 60Hz) will probably not notice the difference.

[h3llf1re]

I wanted to weigh in here - I've experienced this problem with eduke32 for some time (probably since I started using it to be honest), and also Ion Fury more recently. I have a Gsync screen, and the problem occurs with Gsync enabled or disabled. What seems to happen is the game will experience a minor stutter, but after that the frametimes will be all over the place until the level gets reloaded. I've tried a whole bunch of things to try and fix it - things like tweaking the r_swapcomplete setting (and I'll edit this post once I've had chance to try everything mentioned in the first post), but the only thing I've found so far that helps reliably is by setting the in-game FPS offset to -1fps.

I've tried the latest synthesis build and the issue does still occur. Sometimes it takes longer to appear, but it always does eventually.

Another interesting observation is that playing at higher resolutions (e.g. 4K) makes the issue occur much more regularly. Being around multiple enemies seems to make it worse as well.

Answers to the questions (I will update this post once I've had chance to try everything):

Are there any power management or throttling settings active that could interfere with the program's performance? - No, I use the Ultimate Power setting in Windows 10
Are your CPU or GPU downclocking? Are their temperatures higher than they should be? - No, temperatures are under control and there's no throttling
Are you running on battery or plugged in? - Desktop/plugged in
Are there any background programs, tasks, or services taking resources away from the game? - Possibly a few, although I do try to minimise this
Does disabling overlays such as Steam and Discord help any? - Not that I have noticed.

Diagnostic Questions

What FPS limiter settings are you using? - in-game limiter. I've tried 60fps (with and without offsets), and off. An offset of -1 does seem to help a great deal.
If using NVIDIA, does enabling Threaded Optimization in the driver control panel help any? - No, it didn't seem to make any difference
Does turning off both Sound and Music help any? - No, it didn't seem to make any difference
Open the console ([~] in EDuke32/NBlood/etc, [Shift]+[~] in Ion Fury) and try the following cvars: sys_timer, win_systemtimermode, win_priorityclass. Typing them in by themselves will show the options that are available. Follow them with a number to change their settings. Run the "restartvid" command after changing any of these options to make sure they apply. Do you notice any difference? - I'll update this post when I've tried all of these
[Optional, Advanced] Some CPUs from 2017 onward may have a performance issue with their implementation of the High Performance Event Timer. Try switching Windows' QueryPerformanceCounter from HPET to TSC using the instructions at this link to see if there is any benefit. - Didn't seem to help

If you wish to use VSync:

Is there any difference between turning VSync on in-game, and turning it off in-game and enabling it in your graphics driver's control panel instead? - Doesn't seem to be - the stuttering occurs whichever way it is set
Does the FPS Offset option in Options > Display Setup > Video Mode help any? Start with -1 and +1. - Setting this to -1 does help, although you acquire a permanent minor stutter from doing this (helped somewhat by Gsync)
Is your system capable of GSync or FreeSync? Is it enabled? The preferred way to enable GSync is to enable VSync system wide in the NVIDIA Control Panel (set to On, not to Fast Sync), disable any VSync options in the game, and tweak the FPS Offset option to your satisfaction. Some older GSync monitors may benefit from an FPS Offset around -3. - I've tried with Gsync on and off, it doesn't seem to help with this issue (but it does make having a negative FPS offset more bearable)
Does enabling Triple Buffering help at all? If so, does input lag increase? - I did notice a small improvement by enabling Triple Buffering, but the issue still occurs.
Open the console (explained above) and try different values for the r_vsync cvar. (Before r8612: r_swapinterval, r_swapcomplete) Run the "restartvid" command after changing it. - I tried all different settings for this in Ion Fury (glFlush/glFinish etc) and nothing seemed to work.

[Mr. Death]

h3llf1re, on 10 April 2020 - 02:44 PM, said:

I wanted to weigh in here - I've experienced this problem with eduke32 for some time (probably since I started using it to be honest), and also Ion Fury more recently. I have a Gsync screen, and the problem occurs with Gsync enabled or disabled. What seems to happen is the game will experience a minor stutter, but after that the frametimes will be all over the place until the level gets reloaded. I've tried a whole bunch of things to try and fix it - things like tweaking the r_swapcomplete setting (and I'll edit this post once I've had chance to try everything mentioned in the first post), but the only thing I've found so far that helps reliably is by setting the in-game FPS offset to -1fps.

I've tried the latest synthesis build and the issue does still occur. Sometimes it takes longer to appear, but it always does eventually.

Another interesting observation is that playing at higher resolutions (e.g. 4K) makes the issue occur much more regularly. Being around multiple enemies seems to make it worse as well.

Answers to the questions (I will update this post once I've had chance to try everything):

Are there any power management or throttling settings active that could interfere with the program's performance? - No, I use the Ultimate Power setting in Windows 10
Are your CPU or GPU downclocking? Are their temperatures higher than they should be? - No, temperatures are under control and there's no throttling
Are you running on battery or plugged in? - Desktop/plugged in
Are there any background programs, tasks, or services taking resources away from the game? - Possibly a few, although I do try to minimise this
Does disabling overlays such as Steam and Discord help any? - Not that I have noticed.

Diagnostic Questions

What FPS limiter settings are you using? - in-game limiter. I've tried 60fps (with and without offsets), and off. An offset of -1 does seem to help a great deal.
If using NVIDIA, does enabling Threaded Optimization in the driver control panel help any? - No, it didn't seem to make any difference
Does turning off both Sound and Music help any? - No, it didn't seem to make any difference
Open the console ([~] in EDuke32/NBlood/etc, [Shift]+[~] in Ion Fury) and try the following cvars: sys_timer, win_systemtimermode, win_priorityclass. Typing them in by themselves will show the options that are available. Follow them with a number to change their settings. Run the "restartvid" command after changing any of these options to make sure they apply. Do you notice any difference? - I'll update this post when I've tried all of these
[Optional, Advanced] Some CPUs from 2017 onward may have a performance issue with their implementation of the High Performance Event Timer. Try switching Windows' QueryPerformanceCounter from HPET to TSC using the instructions at this link to see if there is any benefit. - Didn't seem to help

If you wish to use VSync:

Is there any difference between turning VSync on in-game, and turning it off in-game and enabling it in your graphics driver's control panel instead? - Doesn't seem to be - the stuttering occurs whichever way it is set
Does the FPS Offset option in Options > Display Setup > Video Mode help any? Start with -1 and +1. - Setting this to -1 does help, although you acquire a permanent minor stutter from doing this (helped somewhat by Gsync)
Is your system capable of GSync or FreeSync? Is it enabled? The preferred way to enable GSync is to enable VSync system wide in the NVIDIA Control Panel (set to On, not to Fast Sync), disable any VSync options in the game, and tweak the FPS Offset option to your satisfaction. Some older GSync monitors may benefit from an FPS Offset around -3. - I've tried with Gsync on and off, it doesn't seem to help with this issue (but it does make having a negative FPS offset more bearable)
Does enabling Triple Buffering help at all? If so, does input lag increase? - I did notice a small improvement by enabling Triple Buffering, but the issue still occurs.
Open the console (explained above) and try different values for the r_vsync cvar. (Before r8612: r_swapinterval, r_swapcomplete) Run the "restartvid" command after changing it. - I tried all different settings for this in Ion Fury (glFlush/glFinish etc) and nothing seemed to work.

Have you tried the patched build of 8813 that Mitch Richters uploaded? That seems to have fixed the ongoing vsync stuttering issue that I've been experiencing w/ eduke32.

[h3llf1re]

Mr. Death, on 11 April 2020 - 03:43 PM, said:

Have you tried the patched build of 8813 that Mitch Richters uploaded? That seems to have fixed the ongoing vsync stuttering issue that I've been experiencing w/ eduke32.

Hey, thanks for this! I've given it a quick test and so far it looks promising. Is the source code for this branch available anywhere?

[mjr4077au]

Yup

The changes here are a bit different to what I provided above. With this source should you compile, enable r_glfinish from the console to activate. This is for r_vsync -1, 0 and 1 modes.

If you like the changes, please comment on the merge request and upvote it.

[h3llf1re]

Mitch Richters, on 13 April 2020 - 07:09 AM, said:

Yup

The changes here are a bit different to what I provided above. With this source should you compile, enable r_glfinish from the console to activate. This is for r_vsync -1, 0 and 1 modes.

If you like the changes, please comment on the merge request and upvote it.

Thanks a lot! Will do

[TerminX]

OK, I merged it. I don't necessarily understand why it helps anyone, but we'll see...

[mjr4077au]

Ta, and apologies that I didn't name some things how you wanted, I just followed the convention for r_vsync which drops the r_. Feel free to push back on me for stuff like that to save you the trouble

[TerminX]

Mitch Richters, on 13 April 2020 - 02:51 PM, said:

Ta, and apologies that I didn't name some things how you wanted, I just followed the convention for r_vsync which drops the r_. Feel free to push back on me for stuff like that to save you the trouble

It wasn't a big deal... we don't quite have official style guidelines, and GitLab let me make the changes right in the UI without much fuss.

[Mr. Death]

Starting with r11321 of NBlood, I'm experiencing a strange stuttering issue when playing w/ vsync enabled. This isn't the same vsync stuttering problem we've been discussing, but something slightly different. I even get permanent drops into the 50 FPS range when standing on top of the mausoleum in the first level staring towards the funeral home. Not exactly sure what's going on, but the previous build (r11320) does not have this issue.

[Mr. Death]

Mr. Death, on 25 April 2020 - 04:34 PM, said:

Starting with r11321 of NBlood, I'm experiencing a strange stuttering issue when playing w/ vsync enabled. This isn't the same vsync stuttering problem we've been discussing, but something slightly different. I even get permanent drops into the 50 FPS range when standing on top of the mausoleum in the first level staring towards the funeral home. Not exactly sure what's going on, but the previous build (r11320) does not have this issue.

Ok, scratch all that...

The stuttering starts in r11374, and it specifically happens when using the new command r_glfinish. Sorry for the mix up :/

For some reason my performance takes a huge hit when using this new command w/ NBlood, and the overall movement & mouse aiming feels super "jittery". If I disable r_glfinish and use the Frame Rate Limiter instead it returns to normal.

I do also detect the same thing in eduke32 now that I really pay attention, but it's much less noticeable than in NBlood.

[mjr4077au]

There's no real surprise that performance takes a hit. Calling glFinish() forces the CPU to wait for the GPU to finish up. You normally don't want to do it and that's why the command is entirely optional by having it behind a CVAR.

Given that you're on lower end hardware, have you considered using Linux? You'd probably get a bit more life out of the PC and for whatever reason, the game just works better under Linux.

[Mr. Death]

Mitch Richters, on 26 April 2020 - 12:29 PM, said:

There's no real surprise that performance takes a hit. Calling glFinish() forces the CPU to wait for the GPU to finish up. You normally don't want to do it and that's why the command is entirely optional by having it behind a CVAR.

Given that you're on lower end hardware, have you considered using Linux? You'd probably get a bit more life out of the PC and for whatever reason, the game just works better under Linux.

Alright, that makes sense. Thanks!

I'm not really super tech savvy, and I've never used any other operating system outside of windows, so I wouldn't even know where to start with Linux. I do plan on getting a new desktop PC eventually, but for now I'm just riding my current setup until the wheels fall off XD

[mjr4077au]

Mr. Death, on 26 April 2020 - 12:57 PM, said:

Alright, that makes sense. Thanks!

I'm not really super tech savvy, and I've never used any other operating system outside of windows, so I wouldn't even know where to start with Linux. I do plan on getting a new desktop PC eventually, but for now I'm just riding my current setup until the wheels fall off XD

Haha fair enough, and yeah I can appreciate that a new operating system can be daunting. I reckon once you get your new PC, experiment on the old PC with a friendly Linux distro like Linux Mint or something. It'll be educational and you might find it enjoyable

If you can run Polymer without any of the lights and shadows and stuff that makes it slow, that might be a viable option as I've found the stuttering issues don't occur with that renderer.

[mjr4077au]

Mr. Death, on 26 April 2020 - 12:17 PM, said:

Ok, scratch all that...

The stuttering starts in r11374, and it specifically happens when using the new command r_glfinish. Sorry for the mix up :/

For some reason my performance takes a huge hit when using this new command w/ NBlood, and the overall movement & mouse aiming feels super "jittery". If I disable r_glfinish and use the Frame Rate Limiter instead it returns to normal.

I do also detect the same thing in eduke32 now that I really pay attention, but it's much less noticeable than in NBlood.

Jittery issues you've reported with r_glfinish 1 have been identified for EDuke32 and a merge request has been submitted to fix the problem.

[mjr4077au]

@Mr. Death, a proposed fix for Blook similar to what I've proposed for EDuke32 is here: xxx. Are you in a position to compile and test the code?

EDIT: Tested, didn't work. I'm not very familiar with NBlood's code but a similar fix as suggested for EDuke32 didn't yield a good result.

[PKz]

Hey all!

Here are a few notes about the stuttering problem.

1. The only eduke32 based game that runs smoothly for me is Nblood (since the very first version and up to at least version nblood_win64_20200624-11753). So whatever Nblood does that Eduke32 doesn't COMPLETELY eliminates the stuttering issue.
2. Eduke32 works properly at 60fps in 60hz mode and at 60fps/120fps in 120hz mode (in both g-sync and fixed refresh rate modes). Once you get any other fps the game stutters/skips frames/shimmers. While it's understandable in fixed refresh rate modes, it shouldn't be the case in g-sync mode. Which tells me that g-sync doesn't work in Eduke32 (eduke32_win64_20200623-9158-437e61efe build version) as it should. Unlike Nblood, which utilizes g-sync mode properly at whatever framerate values.
3. It seems like Eduke32 is completely smooth in g-sync range (31-144fps in my case) while you are standing still and just rotating the camera with the mouse/gamepad. The stuttering/frame skipping happens once you begin moving around.
4. The stuttering is different at different fps values. At 100 fps in 144hz mode stuttering happens at very precise intervals and appears as shimmering. At ~80-90 frame skips are more evident since they aren't that periodic. Etc.
5. The Ion Fury had exactly the same issue when it first came out. I had to refund it because of that problem, so I can't check if current versions have the same problem.
6. The stuttering/frame skipping is not relevant to framerates/frametimes. If you for example set the framerate to 100 in 144hz and get constant frametimes it will still stutter heavily.
7. The stuttering happens no matter what framerate limiter you use. I tried capping fps with the in-game fps limiter, with RTSS, Nvidia Control Panel and Nvidia Inspector. The visual artifacts are the same and the only difference is the additional 0.1ms of when using external limiters.
8. Setting r_glFinish to 0/1 doesn't really do anything.

I am playing on 144hz g-sync monitor in conjunction with GTX1080. The driver version is 446.14. That's somewhat irrelevant though, since I always had some framepacing issues in eduke32. After playing Nblood I really hope you will manage to eliminate this issue!

Please ask me if you need more info.

P.S.
Are there any power management or throttling settings active that could interfere with the program's performance?
-No.
Are your CPU or GPU downclocking? Are their temperatures higher than they should be?
-No.
Are you running on battery or plugged in?
-I am playing on a PC, and I don't have a battery.
Are there any background programs, tasks, or services taking resources away from the game?
-No.
Does disabling overlays such as Steam and Discord help any?
-It doesn't improve nor worsen the performance.

Diagnostic Questions

What FPS limiter settings are you using?
-I have tried all kinds of combinations. There is no difference between using RTSS, Nvidia Control Panel, Nvidia Inspector nor in-game framerate limiter.
If using NVIDIA, does enabling Threaded Optimization in the driver control panel help any?
-It doesn't improve nor worsen the performance.
Does turning off both Sound and Music help any?
-It doesn't improve nor worsen the performance.
Open the console ([~] in EDuke32/NBlood/etc, [Shift]+[~] in Ion Fury) and try the following cvars: sys_timer, win_systemtimermode, win_priorityclass. Typing them in by themselves will show the options that are available. Follow them with a number to change their settings. Run the "restartvid" command after changing any of these options to make sure they apply. Do you notice any difference?
-No, not really.
[Optional, Advanced] Some CPUs from 2017 onward may have a performance issue with their implementation of the High Performance Event Timer. Try switching Windows' QueryPerformanceCounter from HPET to TSC using the instructions at this link to see if there is any benefit.
-I have an older CPU.

If you wish to use VSync:

Is there any difference between turning VSync on in-game, and turning it off in-game and enabling it in your graphics driver's control panel instead?
-No, but if you enable it via Nvidia Control Panel, r_vsync is being forced to 1 in Eduke32.
Does the FPS Offset option in Options > Display Setup > Video Mode help any? Start with -1 and +1.
-It does affect the performance, but only because at different framerates the stuttering/frameskipping happens at different intervals as mentioned in notes above. It doesn't fix the problem.
Is your system capable of GSync or FreeSync? Is it enabled? The preferred way to enable GSync is to enable VSync system wide in the NVIDIA Control Panel (set to On, not to Fast Sync), disable any VSync options in the game, and tweak the FPS Offset option to your satisfaction. Some older GSync monitors may benefit from an FPS Offset around -3.
-Yes, that's how I use G-Sync. I follow blurbusters guides.
Does enabling Triple Buffering help at all? If so, does input lag increase?
-I don't use it in g-sync mode.
Open the console (explained above) and try different values for the r_vsync cvar. (Before r8612: r_swapinterval, r_swapcomplete) Run the "restartvid" command after changing it.

[doubletap]

just wanted to drop some quick lines here.

im running an utterly tweaked and optimized rig with r5 3600, gtx 1080 and win 10 pro 64.

all games and other source ports run perfectly fine.

ive noticed years ago already that eduke seems to have some deep rooted performance issues, that even seem to have severely increased now.

today ive tested and compared three versions of eduke.

1.eduke32_win64_20140613-4509
2.patched build on 8813 from this thread
3.eduke32_win32_20210713-9476-3191b5f41

#1 gives kinda relatively good / default performance with all renders, but performance drops are already noticeable, but there should be none considering the hardware power available.

#2 reported not in open gl mode when launching glinfo from console and generally poor performance.

#3 abysmal performance in both polymer and polymost, with opengl vsync on or off or chaning settings and cvars doesnt really do anything. glinfo querry works properly. polymost is still better than polymer in performance though. #3 fps drop to constant 39 (from 60 with vsync on) at a scene where #1 gave full 60 fps.

of all clients tested, #3 gives the worst performance.

hate to say it, but something seems to be terribly wrong deep inside the code.

hope you can figure it out. <3

[Danukem]

Polymer is unsupported and shouldn't even be mentioned in this thread. It's an abandoned, unfinished renderer and I wish it wasn't enabled at all since all it does now is make people waste their time complaining about it.

As for polymost: you mention a "scene" where the old build has way better performance. Is this a specific scene in a specific map you are using as a benchmark, or are you just saying that all scenes are like this? When you say it drops to 39 fps with vsync off, do you mean in polymost? With or without HRP? I imagine it would actually be helpful to the devs if a specific scene in a map could be identified where polymost performance is consistently better in old builds. I'm not even a dev, but reading "hope you can figure it out" after you give such vague and incomplete information is kind of maddening.

Using the latest build and running around in "Clear the Coast" (a fairly large and complex map) and using the upscale pack which should reduce fps, my fps never dropped below 160 and regularly exceeded 300.

[doubletap]

Danukem, on 15 July 2021 - 12:04 PM, said:

Polymer is unsupported and shouldn't even be mentioned in this thread. It's an abandoned, unfinished renderer and I wish it wasn't enabled at all since all it does now is make people waste their time complaining about it.

As for polymost: you mention a "scene" where the old build has way better performance. Is this a specific scene in a specific map you are using as a benchmark, or are you just saying that all scenes are like this? When you say it drops to 39 fps with vsync off, do you mean in polymost? With or without HRP? I imagine it would actually be helpful to the devs if a specific scene in a map could be identified where polymost performance is consistently better in old builds. I'm not even a dev, but reading "hope you can figure it out" after you give such vague and incomplete information is kind of maddening.

Using the latest build and running around in "Clear the Coast" (a fairly large and complex map) and using the upscale pack which should reduce fps, my fps never dropped below 160 and regularly exceeded 300.

the scene im talking about is the very first map hollywood holocaust, after you jump down from the roof, up to the crate, up to the ledge where the rpg secret lies, then look at the cinema.

theres a noticeable performance hit with all renders and with all builds and with hrp.

another area of fps drop is after you blast the wall open and enter the cinema entrance where the cashier is, or the toilet room looking at the mirror, and many other places that show more prominent fps drops in some builds and maps, than in others.

other maps seem to have better performance but also worse areas, with hrp, too.

it is definitely a very complex mixture of problems what we are dealing with here.

hope, because we all love eduke and fast performance, right.

hpet timer.exe test gives me perfect results, if im not mistaken.

synthetic test:

timer calls: 922,540.85
interval: 1.078 us

game test:

timer calls: 552,363.60
avg frames: 283.60
max frametime: 9.44ms
99th percentile: 4.24ms

will test this through again on another rig i have here with an r1700 and rx590 and e5 2689 and rx570 tomorrow and update my results.

update 1:
ash over my head.

i just tested the old setup once again and i think i found something.

with polymost on, latest build.

i stand with 30-40 fps on that scene, vsync on / off does not matter, but

turning off 3d models and detail textures, fps jumps from 39 to 500 (with menu in the background) and it runs like a charm! without menu / ingame getting 700-1200fps around that scene now.

so, turning on 3d models costs 200 fps, turning on detail textures alone even costs 400+ fps!

i think it runs with 3d models on solely and vsync on relatively stable 60 fps, but turning on detail textures then totally ruins it again.

maybe the issue lies with hrp...?!

i think stuttering or frame pacing i actually have zero issues and it is well coded, seems its all due to hrp and those two options, for humble me at least.

[GemaH]

Danukem, on 15 July 2021 - 12:04 PM, said:

my fps never dropped below 160 and regularly exceeded 300.

My fps never drop too. I use RTSS to measure it. Locked 60fps all the time on my 60hz TV.

Yet, the juddering is more noticeable then ever, despite RTSS reporting perfect frame rates.

Like the person who posted above me, i have no issues with other Source Ports. GZDoom runs perfect. Raze runs perfect. Kex engine DOOM 64 runs perfect. Some Quake 1/2 source ports i use, also perfect.

But eduke32 though? That one looks juddery. And anything else based on that as well. Ion Fury is also a bit weird for instance.

There's something about eduke32 that makes it look like it's not running as smooth as other engines, despite reported FPS being perfect. Fame pacing maybe?

Personally, i think it's something about the way the analog controller works. When i use the analog to look around, it's not smooth. When i use the keyboard keys, it's noticeably smoother.

This has been an issue for a very long time (i did my first thread about it in 2016) and even though gamepad support has been improved a lot lately, the juddering issues remain. Again, i don't think this has anything to do with performance.


Keep in mind though, playing on my 240hz Gsync monitor greatly improves this. eduke32 looks almost as smooth as Raze in this case. I assume you also use a similar monitor, considering your fps. But on the 60hz TV it looks pretty bad, regardless the settings.

[VGames]

BUMP

Out of nowhere yesterday eduke started running slower for me. I had a windows up date so I’m not sure if that was the issue but I think it was. My drivers are up to date. I thought it may have been something I recently modded into the game but I ran the last release of my mod I put on moddb which I know ran perfectly ok and it also ran poorly. Is anybody else having sudden issues like this as of lately? I use to run at 60 fps constantly 99% of the time but now it stays in between 50 to 60 fps and it dips down to 30 or so at any given time. Also I’m using polymost with bilinear filtering. Setting it to nearest makes no difference.

[Phredreeke]

If you haven't tried it already try r_vsync 2 in console.