[Mark]

I picked a corner in E1L1 and took a screenshot with versions 4593 4677 and 5295. I didn't use any of the latest revisions because they crash me to the desktop before anything loads on the screen. Thats for another day....

It would be great if someone else could do the same test to confirm this. I am using Polymer of course and the HRP in 32 bit mode 1680 x 1050 on an old Nvidia 9800 GTX+ card

Attached thumbnail(s)

• 

[Paul B]

Mark., on 22 July 2015 - 10:54 AM, said:

I picked a corner in E1L1 and took a screenshot with versions 4593 4677 and 5295. I didn't use any of the latest revisions because they crash me to the desktop before anything loads on the screen. Thats for another day....

It would be great if someone else could do the same test to confirm this. I am using Polymer of course and the HRP in 32 bit mode 1680 x 1050 on an old Nvidia 9800 GTX+ card

Please try: http://dukeworld.duk.../20150721-5307/

That should fix the crashing issue's you might be experiencing with later versions. Also make sure when you have polymer selected that you have 32bit also selected in the eduke launcher. I'll try to mimic the same configuration that you are running.

**** UPDATED **** Okay I get similar results with an NVIDIA GPU 660 and the HRP + Polymer + Polymer lighting. It appears the slow downs are directly associated with the dynamic lighting in Eduke. If you turn off dynamic lighting from the console (R_PR_LIGHTING =0) the FPS dramatically improve. While I believe this lighting is a work in progress I would recommend not enabling R_PR_LIGHTING for the time being until they make improvements to this feature.

If I had to guess the code that handles the lighting should be handled by the GPU and not the CPU. Perhaps, the CPU is what is calculating the lighting resulting in slower performance which why a faster GPU doesn't appear to have any impact on performance.

So I guess your question is: What has possibly changed to Polymer dynamic lighting that has impacted the FPS between said versions?

[Mark]

I tried 5303 and 5307 before my previous post. They crashed. I didn't check the logs yet because I was focusing on the slowdown issue first.

All of my projects depend heavily on Polymer lighting so disabling it is not possible.

[Paul B]

Mark., on 22 July 2015 - 12:29 PM, said:

I tried 5303 and 5307 before my previous post. They crashed. I didn't check the logs yet because I was focusing on the slowdown issue first.

All of my projects depend heavily on Polymer lighting so disabling it is not possible.

Well, run the Eduke debug.exe and after it crashes upload the associated log file on here so the dev's can take a look at the contents and try to isolate where the problem might be coming from. Because Polymer at the moment doesn't crash on my rig on version 5307. The Dev's are very keen on resolving bugs but they need the detailed log reports before they can do anything about it.

I always like to take a vanilla Duke.GRP copy it to a new folder, download the latest synthesis into that folder and try it without any mods to see if it runs without crashing in Polymer. That will tell you if its a custom settings problem or a behavior with your PC hardware/software configuration.

[Mark]

I won't bother unless others start having the same crash. It might be something on my end.

EDIT: I just downloaded and extracted the 5307 32 bit debug version and it has bad data in the files. Oh well.

[Paul B]

Mark., on 22 July 2015 - 12:36 PM, said:

I won't bother unless others start having the same crash. It might be something on my end.

Well then why complain at all if you're not willing to contribute something?

[Mark]

As I said in the previous post, " thats for another day" I'm not complaining. I'm focusing first on the slowdown issue and how far back it was introduced. I'm not terribly concerned at all about the latest few revisions right now. I'm not going to bother the devs with something that may be on my end only. I'll wait to see if anyone else has the crash before I make an issue out of it.

[TerminX]

It looks to me like your screenshot from 5295 has the maphacks for the HRP loaded, while your previous two don't. That's not a valid comparison at all.

[Spiker]

LOL Nice troll Mark. You thought noone will notice the lack of lights in the first 2 screenshots?

[Mark]

Other than the light how can you tell? I was under the assumption that the first 2 screenshots were taken as the light flickered out and the 3rd one captured while it was on. All I did was exchange the eduke32.exe file in each case. I had no idea that had anything to do with maphacks. So if maphacks are the framerate killer they need to be looked into. But then, I don't have them in my custom projects which also slow down. Its so confusing.

[Paul B]

Mark., on 22 July 2015 - 02:21 PM, said:

Other than the light how can you tell? I was under the assumption that the first 2 screenshots were taken as the light flickered out and the 3rd one captured while it was on. All I did was exchange the eduke32.exe file in each case. I had no idea that had anything to do with maphacks. So if maphacks are the framerate killer they need to be looked into. But then, I don't have them in my custom projects which also slow down. Its so confusing.

I'm not sure what maphacks are, but i get similiar FPS results as Mark does with the HRP / Polymer & Dynamic lighting turned on. Seems as though with Dynamic lighting enabled coupled with the HRP there is a big hit on FPS.
Dynamic lighting enabled without HRP there is still a slowdown but not nearly as bad.

Attached thumbnail(s)

• 
• 
• 
• 

[Mark]

My understanding was maphacks are just text to fix the angle adjustment of models when they replaced the original 2D sprite. Maybe they add SE lights to the maps too.

[Hendricks266]

Mark., on 22 July 2015 - 02:32 PM, said:

My understanding was maphacks are just text to fix the angle adjustment of models when they replaced the original 2D sprite. Maybe they add SE lights to the maps too.

Yes, the HRP maphacks also add Polymer lights to map-specific locations, beyond the ones that the game adds to sprites like projectiles and switches.

[Altered Reality]

TerminX, on 22 July 2015 - 12:56 PM, said:

It looks to me like your screenshot from 5295 has the maphacks for the HRP loaded, while your previous two don't. That's not a valid comparison at all.

[LeoD]

Altered Reality, on 23 July 2015 - 05:35 AM, said:

Does this light stay on when maphacks are off too?

Hendricks266, on 22 July 2015 - 05:15 PM, said:

... the ones that the game adds to sprites like projectiles and switches.

So yes, unless you turn off Polymer lighting altogether.

[Nokiaman]

Mark., on 22 July 2015 - 10:54 AM, said:

I picked a corner in E1L1 and took a screenshot with versions 4593 4677 and 5295. I didn't use any of the latest revisions because they crash me to the desktop before anything loads on the screen. Thats for another day....

It would be great if someone else could do the same test to confirm this. I am using Polymer of course and the HRP in 32 bit mode 1680 x 1050 on an old Nvidia 9800 GTX+ card

Wow you're right! I just tried 4593 and E1L1 runs buttery smooth with Polymer and Adaptive Vsync where as latest version lags all over.

[Mark]

It was pointed out in an earlier post that the older 4593 version did not have the same "maphacks" for Polymer lights as the newer Eduke versions. So to make a proper comparison you have to type in the command r_pr_lighting 0 into the console to turn off the Polymer lights. In my case the old version is still faster with or without the lights.

Or you can try a custom map for testing without having to worry about typing anything into the console.

[Nokiaman]

Well even the low FPS I had in mods that don't have those map hacks run better now so dunno. In any case I am sticking with the old version.

[SamusBailey]

Trooper Dan, on 18 July 2015 - 05:23 PM, said:

This thread was created to report a loss in framerate after a specific revision which was painstakingly identified. If the developers aren't going to investigate that after being provided with the revision number, then it's extremely doubtful that they would investigate generic game hitches which have been happening since the first release.

I cried and smiled


I'm a dummy I went and played it without polymer, and was just having the same issue hue hue

all is well though billy here is wondering if duke thinks hes cool or something with them glasses he has on

[Tea Monster]

I thought I'd play a bit recently. I downloaded the lastest snapshot and ran it with the HRP 'autoload' pack from the HRP website. I experienced stutters and slowdowns and I've never remembered having any of that before. I'm running a GTX 760 and an i7.

[Mark]

What previous version were you running?

[Tea Monster]

No idea, it was about a year ago.

EDIT: Derp - maybe more than a year. eduke64-r3973-20130719

[Mark]

Maybe its the combination of the slowdown I mentioned and the added lights from maphacks since the old version.

[Hendricks266]

Mark., on 15 August 2015 - 03:21 PM, said:

It was pointed out in an earlier post that the older 4593 version did not have the same "maphacks" for Polymer lights as the newer Eduke versions.

You may have misunderstood that post. No lights have been added between these versions. The hardcoded sprite-lights and the maphack-based lights have been around just about as long as Polymer has been public. What TX thought were HRP maphacks may have just been the flickering of the sector where you were standing. Altered Reality was a smartass and asked if the hardcoded fire light came from a maphack.

As far as I can gather, there are two or maybe three stacked issues here. One happens in your WGR2 map because of Trooper Dan's flickering SE lights. Another is always present.

Two possible bisection endpoints include:

Mark., on 06 July 2015 - 04:12 PM, said:

So doing the trial and error with many versions I narrowed it down to the last good working version was 4696. After that a whole schmitt-load of changes were made and the next release 4777 has the slowdown.

Mark., on 20 July 2015 - 12:57 PM, said:

4599 was the last good version. Next one, 4639 was bad. So its between those 2 now.

I still need to set up and confirm test cases in order to identify the issues, but my time (and developement environment) has been held up by more pressing concerns.

[Nokiaman]

These FPS drops are odd. Whenever I turn on Shadowplay to record them they disappear
But even then the game is still not as smooth as Classic/Megaton is.
This is even with R_PR_Lighting 0 and Vsync ON

It says 60 FPS yet it feels so uneven.

Mostly noticeable when jumping and picking up RPG. It can get worse than that obviously.