[Person of Color]

Still can't get vsync to engage at all on my R9 290, either by using eDuke, Catalyst, or RadeonPro.

No one is going to take modding this shit seriously as long as it only works on one of the three vendors.

Someone fix this shit.

[Fox]

Does it works better if you turn off the lights?

[Person of Color]

There are people no less than three people who have programmed new DirectX renders for Deus Ex in their spare time, and we can't get one for fucking Duke Nukem? Polymer is shit and needs to die. No wonder everyone mods Doom.

"Sorry our elite port of a twenty year old game won't work on your Intel or AMD card." *lifts up nose and scoffs*

[Fox]

Does it works better if you turn off the fancy lights?

[DustFalcon85]

Plagman. Please do something a/b this just to please Viper. We beg of you!

[Mblackwell]

It's not Plagman's fault that the GL implementation on Intel is incomplete/behind the curve and the AMD implementation is half broken or slow.
People are already working on optimizations for Polymer however.

[Person of Color]

Mblackwell, on 16 November 2015 - 06:06 PM, said:

It's not Plagman's fault that the GL implementation on Intel is incomplete/behind the curve and the AMD implementation is half broken or slow.
People are already working on optimizations for Polymer however.

Are you fucking kidding me?! Dude, I just restarted my system after Duke Nukem Forever 2013 caused it to SHUT THE FUCK DOWN, TWICE IN A ROW. YES, LITERALLY. IT TURNED ITSELF OFF, THEN REBOOTED INTO THE FUCKING BIOS.

Vsync causes mouse lag. Playing with every conceivable setting in Catalyst or RadeonPro to remove the lag doesn't work. HEY GUESS WHAT TURNING IT OFF DOES?! GPU MELTDOWN LIKE THE STARCRAFT 2 MAIN MENU A FEW YEARS BACK.

No other source port has these issues. The code is fucking shit. Stop defending Plagman. He did a shitty job and I'm not the only one who thinks so. We need someone to step up and fix this. I can't even get past the intro for fucks sake.

[Lunick]

[Mblackwell]

r_maxfps is your friend

Edit: Also it specifically says in the DNF2013 readme "Polymer and the HRP are definitely NOT supported and are thus disabled." so you should probably not run with Polymer anyway. You'll want to still set r_maxfps however, since your framerate will be ridiculous.

Edit2: r_swapinterval is for vsync btw, not that I recommend vsync since it causes mouse lag. To remove lag caused by vsync you should force triple buffering. Normal double buffered vsync always causes a delay in response in all applications.

[Nevander]

For me, I run mine with Vsync off and r_maxfps set to 125. If I turn on Vsync, either my entire map glitches out if it's on adaptive or I get serious mouse lag and even some really weird stuttering that is very detrimental to my playing experience. When I run my game with the HRP, I use the Polymost Override and the old guns because I think it looks much better and a lot less lag. I don't try to run DNF2013 with Polymer, and when I play normal Duke 3D I turn off Polymer. Polymost does this weird "hall of mirror" and "pulsing light show" thing for me sometimes at some places in maps though. I am running an AMD Radeon R9 270X.

[Tea Monster]

Nobody has taken Polymer seriously for years due to performance issues alone.That and the model disappearing thing put an end to anyone who would want to use it bothering with it.

[NightFright]

Trying to be constructive:
There's still the classic renderer and Polymost to use. Nobody forces you to use Polymer, and we all know it still needs considerable optimizations.

[Mblackwell]

Models disappear in Polymost too. It has to do with how the engine calculates visibility.

[Plagman]

eat shit

[TerminX]

Person of Color, on 16 November 2015 - 06:15 PM, said:

Are you fucking kidding me?! Dude, I just restarted my system after Duke Nukem Forever 2013 caused it to SHUT THE FUCK DOWN, TWICE IN A ROW. YES, LITERALLY. IT TURNED ITSELF OFF, THEN REBOOTED INTO THE FUCKING BIOS.

Polymer might run like a crippled bag of dicks, but spontaneous reboots are a hardware or driver problem, every time. 100%. I think this is more of a daily reminder that you should back off on your overclocks until you figure out what the fuck you're doing.

[Paul B]

Person of Color, on 16 November 2015 - 06:15 PM, said:

Are you fucking kidding me?! Dude, I just restarted my system after Duke Nukem Forever 2013 caused it to SHUT THE FUCK DOWN, TWICE IN A ROW. YES, LITERALLY. IT TURNED ITSELF OFF, THEN REBOOTED INTO THE FUCKING BIOS. No other source port has these issues. The code is fucking shit. Stop defending Plagman. He did a shitty job and I'm not the only one who thinks so. We need someone to step up and fix this. I can't even get past the intro for fucks sake.

Tea Monster, on 17 November 2015 - 12:00 AM, said:

Nobody has taken Polymer seriously for years due to performance issues alone.

Person of Color - for some one who is so in tune with using a computer I'm quite surprised to see you come to such a bullshit conclusion. Obviously you're frustrated, but seriously give some thought to what you're saying before you explode cause it just doesn't add up and you know that.

I take Polymer very seriously. In fact most of my maps are made in polymer as I enjoy what TROR brings to the table and it will only get better once Polymer is polished. You guys are way too hostile towards an open source free project. It's because of the hard work of these developers that this game is even available for you to use. Be thankful and show some respect!

[MusicallyInspired]

Polymer works just fine on my system and I haven't seen any model disappearing issues yet. Whenever I play Duke it's with Polymer only.

You're the one who bought a Radeon card against all warnings and recommendations. But you said you didn't care...I guess you care now?

[Mark]

While not being thrilled about how long we have been waiting for a good optimizing, I'm not letting it stop me from making all my present and future projects in Polymer. I just have to work within certain limits. I can live with it for now along with a dash of hope here and there. To be honest, what I wait for the most is just a global light source and framerate increase. Other features would just be icing on the cake. That coupled with a setting for a model to stay rendered all the time would make me a very happy camper. I'm a simple man.

[Mblackwell]

Tea Monster, on 17 November 2015 - 12:00 AM, said:

Nobody has taken Polymer seriously for years due to performance issues alone.That and the model disappearing thing put an end to anyone who would want to use it bothering with it.

Decay is using it, and is better for it. I definitely take it seriously.

If a few bugs were fixed up I'd use it for all of my projects.

[Tea Monster]

I understand that people have jobs and real lives and so forth. Thats great. But the model rendering issue has been requested for years and years now and nobody has even replied to the request or addressed it as an issue in that time. Instead of "Sorry, kinda busy" or even "No can do, too much on" its either Hendricks standard "Dis gon B Gud" gif, and now Plagman has replied with... well, I'm not going to repeat it.

Respect needs to operate in both directions.

[Mblackwell]

"The model rendering issue" isn't just Polymer as I said. And I described what the problem is. There are a lot of ways of mitigating it, and in other threads we've (CON coders) brainstormed hacks around it for large models. You'll see a lot of model use in Decay, but you probably won't notice a lot of them disappearing.

[Mark]

I'm patting myself on the back for that one.

[icecoldduke]

I am working on fixing up Polymer. To say the polymer rendering pipeline is not optimized for performance is a gross understatement. The renderer stalls in a bunch of places because of bad design. This isn't to say anything bad about Plagman, he got it working and that is a huge undertaking.

You get poor performance with Polymer because of :
1) Hardware occlusion queries, the GPU will stall while waiting for the previous frames "Is object X" visible requests to come back. I am working on re-creating my software occlusion query system, this system will work in another thread and will greatly improve performance.
2) The renderer is doing matrix math via the driver. I have re-created my matrix math class to replace this functionality. This is less of a performance issue as it is very nasty.
3) Hardware State Changes - this hinders wavefront batching, this has been slightly fixed with Plagman's "bucket" system but there is still work to be done there.

The poor performance everyone is getting out of Polymer isn't because of your hardware, simply put Polymer is GPU/Driver bound because of it's design, not because of the complexity of what it has to render.

Mblackwell, on 16 November 2015 - 06:30 PM, said:

r_maxfps is your friend

Edit: Also it specifically says in the DNF2013 readme "Polymer and the HRP are definitely NOT supported and are thus disabled." so you should probably not run with Polymer anyway. You'll want to still set r_maxfps however, since your framerate will be ridiculous.

Edit2: r_swapinterval is for vsync btw, not that I recommend vsync since it causes mouse lag. To remove lag caused by vsync you should force triple buffering. Normal double buffered vsync always causes a delay in response in all applications.

Using vsync is the proper way to fix screen tearing. How vsync works is the GPU waits to flip buffers until vblank is complete. This can't be emulated with any other method. If vsync is slow for you, get a better monitor .

[Nevander]

icecoldduke, on 17 November 2015 - 08:39 PM, said:

Using vsync is the proper way to fix screen tearing. How vsync works is the GPU waits to flip buffers until vblank is complete. This can't be emulated with any other method. If vsync is slow for you, get a better monitor .

For me it's not "slow," but rather super stutter filled. I can't move or look around standing in place without my screen being jerked around like a dog's chew toy. This can happen even without the HRP and on the 64-bit eduke. This is why I use r_maxfps and turn Vsync off. Much smoother gameplay.

[Hendricks266]

Tea Monster, on 17 November 2015 - 04:59 PM, said:

Hendricks standard "Dis gon B Gud" gif

icecoldduke, on 17 November 2015 - 08:39 PM, said:

I am working on fixing up Polymer.

[Mblackwell]

icecoldduke, on 17 November 2015 - 08:39 PM, said:

Using vsync is the proper way to fix screen tearing. How vsync works is the GPU waits to flip buffers until vblank is complete. This can't be emulated with any other method. If vsync is slow for you, get a better monitor .

Vsync is also a good way to add input latency and I hate input latency (even small amounts bug the crap out of me). I actually almost never use vsync and never have, unless tearing is ridiculous. As for my monitor I use a fairly nice 16:10 S-IPS panel.

[Player Lin]

That's why eduke32 has fps limit CVAR(r_maxfps), when Vsync didn't worked well.

[icecoldduke]

Player Lin, on 18 November 2015 - 04:46 AM, said:

That's why eduke32 has fps limit CVAR(r_maxfps), when Vsync didn't worked well.

You realize that vsync is implemented on the driver side right? The app requests vsync to be enabled and then will stall during the page flip while the GPU waits for vblank. If your having problems with vsync its your setup not eduke32.

MBlackwell said:

Vsync is also a good way to add input latency and I hate input latency (even small amounts bug the crap out of me). I actually almost never use vsync and never have, unless tearing is ridiculous. As for my monitor I use a fairly nice 16:10 S-IPS panel.

If the app is implemented poorly, yes you would be correct. Input should be handled in separate job. EDuke32 is missing a jobs system and for the stuff I'm adding I have a basic one in there locally. After some of this polymer stuff I'll move the input stuff into a job.

But no matter what the game is going to stay in lock step with your monitors vblank. I would say your monitor is fine, what is your GPU? What drivers are you on? What video input are using? HDMI? DVI? What's your OS?

Literally on OGL its one function call to enable vsync "wglSwapIntervalEXT", whats interesting though, on some drivers(I've tested this on NVIDIA), you can actually set negative values here to enable adaptive vsync. I don't know if the cvar in eduke32 is hooked directly into the parameter that goes into that function, but you can try setting that cvar to -1 and see what happens. If not I can compile a build tonight that you can try with it being set to -2 and let me know if that helps or not.

Nevander said:

For me it's not "slow," but rather super stutter filled. I can't move or look around standing in place without my screen being jerked around like a dog's chew toy. This can happen even without the HRP and on the 64-bit eduke. This is why I use r_maxfps and turn Vsync off. Much smoother gameplay.

I would say see the previous statement I said to Player Lin, on the off chance I'm wrong you can take cell phone video with vsync on vs with r_maxfps, because I can't understand what your trying to describe.

[Nevander]

icecoldduke, on 18 November 2015 - 07:09 AM, said:

I would say see the previous statement I said to Player Lin, on the off chance I'm wrong you can take cell phone video with vsync on vs with r_maxfps, because I can't understand what your trying to describe.

I wish I could but my cellphone is a potato. There was a video I saw before that accurately showed what my problem is. Let me see if I can relocate it.

EDIT: Found 'em. Mine is IDENTICAL to the second video.
Source: https://forums.duke4...tteringhitching

[icecoldduke]

Nevander, on 18 November 2015 - 08:20 AM, said:

I wish I could but my cellphone is a potato. There was a video I saw before that accurately showed what my problem is. Let me see if I can relocate it.

EDIT: Found 'em. Mine is IDENTICAL to the second video.
Source: https://forums.duke4...tteringhitching

Based on taking a quick glance at the code, trying setting the vsync cvar to -1, that should enable adaptive vsync if your card/drivers support it. Adaptive vsync will only wait for vblank if you are running at high frame rates, if your FPS drops it won't wait for vblank which should minimize the stuttering.

You can also try -2, basically if I remember right -1 locks the screen to 60hz and -2 should lock it to 30hz, and if your framerate drops below either 60hz or 30hz respectively the GPU won't wait for vblank.