[Mark]

I was updating an old project folder ( the WGR2 sequel ) from version 4039 to the latest version. I saw a huge decrease in framerate under Polymer. 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. I haven't made a comparison with any other custom projects yet.

EDIT: I tested with 2 more custom projects, Graveyard and Project Blue Skies, and they both showed a drop of about 3 FPS with the newer versions. Not nearly as bad as the double digit drops in WGR2 but a drop none-the-less. Hopefully someone else can verify.

[Danukem]

That build includes a lot of revisions, from r4697 to r4777. I read through the changelog but none of them jumped out at me as obvious candidates for causing a slowdown. Only 2 of them even mentioned polymer, and they were these:

r4773 | hendricks266 | 2014-11-28 18:29:42 -0800 (Fri, 28 Nov 2014) | 1 line

Fix POLYMER=0 GTK C++ build. DONT_BUILD.

r4701 | terminx | 2014-10-29 10:06:20 -0700 (Wed, 29 Oct 2014) | 1 line

Fix MSVC warning in Polymer


----
Possibly it isn't even Polymer related. Maybe one of the revisions adds extra processing, and because Polymer is so CPU intensive, that causes a framerate drop.

[Tea Monster]

How on Earth did they manage to slow it down any further?

[Danukem]

Tea Monster, on 07 July 2015 - 02:10 AM, said:

How on Earth did they manage to slow it down any further?

And how on Earth did it take over 6 months before anyone noticed and reported it?

[Spiker]

How on Earth would someone distinguish between slugish and even more slugish Plus people rarely get new versions unless there is some major release or their version is extremly old. If they use Polymer at all (because of the s-thing ).

[Mark]

Since I use only Polymer I didn't test old vs new versions in Polymost. If I'm ambitious this afternoon I will.

[Tea Monster]

Very few people use polymer anyway due to previously existing performance issues or PAD*


*Polygon Aversion Disorder

[Radar]

I fully admit that I suffer from PAD.

[Steve 64]

I do like using polymor but it does make the game lag alittle when you blow something up like a building basically anything really, it a really nice feature in EDuke32

[SamusBailey]

Hey Guys im so sorry i wanst recording me playing this time, but... while i was playing today i noticed lots of points where my game would actually come to a halt and then load the music and everything back in and play from where i was.... i was in a vent and bam all of a sudden *screen freezes* and then this octo-brain"pusssssyyyyyyy" came out of no where noming on my balls :c please help If need be i can play and record until it happens again but it only happens so far with polymer on

[Danukem]

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.

[Hendricks266]

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.

80 revisions is a wide gap. Could you or Mark describe a specific procedure to get to whatever area renders measurably slower?

[Paul B]

Lately i've been using Windows 7 to play around with Mapster, which normally i don't do as a result of frame rate problems, where i don't experience the same problems as badly in Windows XP. In any case, what I think i've noticed, at least to me, is although the frame rate doesn't appear to be better in Windows 7 the game seems to run smoother when there is lower frame rates as oppose to before. It also definitely responds better to the draw distance maximizing fps when it can as Duke navigates around the map. Again all depending on what is visible to the player. I typically use Polymer render all the time.

I've uploaded a few screenshots to show some visual glitches and FPS jumps which are huge in such a small area with little draw distance.

lowfps.jpg shows my frame rate sucks. Move a bit to the right and i get great frame rates in highfps.jpg

Stairs.jpg shows the location in my map where you can go upstairs and downstairs. However, for whatever reason it works in Eduke thank goodness but not in Mapster. Strange bug.

Bulletsholes invisible wall.jpg - Shows that for some reason Eduke isn't drawing the sector properly and is getting confused with some over lapping sectors. These are all taken from 20150716-5303 in Windows 7 64Bit using the 64bit Eduke synthesis. These are also problems in previous synthesis builds as well. All screenshots are from therock.map. I find this a good map to test performance issues as a result of the heavy usage of SOS and TROR.

As for generic game hitches I'm not sure i can comment on that as that hasn't been an obvious problem for me.

I'm not trying to hijack this thread but only contribute to performance related issues as well as some other issues which if cleared up might help the overall game performance.

Attached thumbnail(s)

• 
• 
• 
• 

[Paul B]

Here are two screenshots from the same computer except running on Windows XP. You will notice the FPS in XP is double that of Windows 7 on the same computer. The performance difference between the two operating systems is by far very noticable and XP definitely is a way better performer when it comes to playing Eduke.

Attached thumbnail(s)

• 
• 

[Mark]

Hendricks266, on 18 July 2015 - 05:54 PM, said:

80 revisions is a wide gap. Could you or Mark describe a specific procedure to get to whatever area renders measurably slower?

In my case you would have to download and run my whole custom project and the first map.

Version 4593 at map start..... Polymer off = 175 FPS Polymer on = 67 FPS

Version 4777 at map start .....Polymer off = 175 FPS Polymer on = 20 FPS

In this case it is a relatively simple outdoor area that is isolated from the rest of the map by white walls and a closed ceiling door. Just 4 SE49 lights.

EDIT: and IIRC areas of poor performance in the large map drop from about 20 FPS in 4593 down to 13 FPS with 4477. So you can see why I need every drop of speed I can find. Luckily this is more of an adventure game and the low framerate in some areas won't get the player killed like if they were going up against a horde of aliens.

[Tea Monster]

When are you guys going to realise that the devs don't care about polymer and that Polymer will never get fixed? Move on.

[Mark]

Hendricks was requesting some info. In the mean time I just go back to the last good version. The end. If fixes are made I will try a newer version. If not, I stay where I'm at. I did that with my Graveyard project and I'll do it with this new one.

[Hendricks266]

Tea Monster, on 19 July 2015 - 12:12 PM, said:

When are you guys going to realise that the devs don't care about polymer and that Polymer will never get fixed? Move on.

------------------------------------------------------------------------
r5266 | Plagman | 2015-06-14 18:42:31 -0500 (Sun, 14 Jun 2015) | 1 line

add pr_nullrender variable to toggle drawing and updating GL buffers
------------------------------------------------------------------------
r5267 | Plagman | 2015-06-14 18:42:52 -0500 (Sun, 14 Jun 2015) | 1 line

Fix automap lines in Polymer mode
------------------------------------------------------------------------
r5294 | Plagman | 2015-07-12 22:46:35 -0500 (Sun, 12 Jul 2015) | 1 line

Polymer: store map data in a single buffer with a unified vertex type.
------------------------------------------------------------------------
r5295 | Plagman | 2015-07-13 11:01:18 -0500 (Mon, 13 Jul 2015) | 1 line

Polymer: fix synthesis warning.
------------------------------------------------------------------------
r5296 | Plagman | 2015-07-14 02:08:44 -0500 (Tue, 14 Jul 2015) | 1 line

Polymer: add preliminary support for batching draws.
------------------------------------------------------------------------
r5297 | Plagman | 2015-07-15 00:14:08 -0500 (Wed, 15 Jul 2015) | 1 line

Polymer: fix regression with Y-flipping bit.
------------------------------------------------------------------------
r5298 | Plagman | 2015-07-15 03:23:00 -0500 (Wed, 15 Jul 2015) | 1 line

Polymer: upload bucket indices through pinned host memory.
------------------------------------------------------------------------

[Altered Reality]

Tea Monster, on 19 July 2015 - 12:12 PM, said:

When are you guys going to realise that the devs don't care about polymer and that Polymer will never get fixed? Move on.

Maybe they're following the same policy as the MAME team: "Meh, who cares about our software getting slower and slower? Hardware's gettng faster and faster, that'll fix it!"

[Danukem]

Hendricks266, on 18 July 2015 - 05:54 PM, said:

80 revisions is a wide gap. Could you or Mark describe a specific procedure to get to whatever area renders measurably slower?

I could not myself, but in my previous post I did note that there were only two revisions in that range (r4701 and r 4773) that mentioned polymer. Seems like that would be a good place to start.

[Tea Monster]

I thought that optimizing meant making it faster, not slowing it down by 40 fps. I guess Hendricks was right about non-programmers not knowing what they were talking about.

[Paul B]

Tea Monster, on 21 July 2015 - 04:49 PM, said:

I thought that optimizing meant making it faster, not slowing it down by 40 fps. I guess Hendricks was right about non-programmers not knowing what they were talking about.

They are optimizing all areas of code which overall will improve the overall fps since most of the game is heavily based on CPU. I've noticed gradual improvements over the years. It's just a slow progression and these dev's already have a lot on their plate. I'd like to know how you came up with 40fps loss that's pretty specific. I guess it would all depend on what features of Polymer are being used which contributes to the overall performance problems.

[Mark]

The 40FPS he is referring to is from my test posted higher up this page. I was in contact with Hendricks to narrow it down to which non-svn'ed version started the issue. He downloaded the project in question and is looking into it. Regular Duke maps and my other custom projects are not suffering nearly so bad as the one in the tests but there is a slowdown in the single digits with the newer versions. ( for me )

[Paul B]

Mark., on 21 July 2015 - 06:00 PM, said:

The 40FPS he is referring to is from my test posted higher up this page. I was in contact with Hendricks to narrow it down to which non-svn'ed version started the issue. He downloaded the project in question and is looking into it. Regular Duke maps and my other custom projects are not suffering nearly so bad as the one in the tests but there is a slowdown in the single digits with the newer versions. ( for me )

Thanks Mark for the clarification. I accidentally skimmed over it.

[Mike Norvak]

Mark., on 21 July 2015 - 06:00 PM, said:

The 40FPS he is referring to is from my test posted higher up this page. I was in contact with Hendricks to narrow it down to which non-svn'ed version started the issue. He downloaded the project in question and is looking into it. Regular Duke maps and my other custom projects are not suffering nearly so bad as the one in the tests but there is a slowdown in the single digits with the newer versions. ( for me )

Maybe he can also address the issue with my maps on Polymost, where fps dropped from a descent rate to red numbers on later synthesis.

[Danukem]

Guys, if fps has dropped between revisions due to rendering issues, then that should show up in vanilla maps as well.

[TerminX]

Altered Reality, on 19 July 2015 - 04:01 PM, said:

Maybe they're following the same policy as the MAME team: "Meh, who cares about our software getting slower and slower? Hardware's gettng faster and faster, that'll fix it!"

How obnoxiously obtuse. It's fine with me if you don't particularly understand software development and have no grasp of the concept that sometimes optimizations in certain areas equal regressions in others, but please, keep ignorant comments like that to yourself.

[Paul B]

Trooper Dan, on 21 July 2015 - 10:00 PM, said:

Guys, if fps has dropped between revisions due to rendering issues, then that should show up in vanilla maps as well.

Is that really accurate? The vanilla maps wouldn't have the use of the new S.E for lighting \ smoke effects \ TROR which may take their toll on the FPS. I'm guessing where the slow downs may occur are based around these newer effects within the Polymer as oppose to the original level design. Since the original Duke maps weren't built upon Polymer's new features they probably won't exhibit the same behavior as mentioned in modern versions of the duke map file. Which may explain why Mark notices fps drops in his maps but not others.

For us non programmers (Speaking on behalf of myself) I can only speculate since I don't really know what's going on behind the scenes.

There was an instance for me when Paralax skies seemed to have a significant impact on FPS especially when the ceiling of the paralax texture meets the floor. But it could have just been an isolated incident with the last map I was working on as a result of heavy use of TROR and large open areas.

[Danukem]

Paul B, on 21 July 2015 - 10:20 PM, said:

Is that really accurate? The vanilla maps wouldn't have the use of the new S.E for lighting \ smoke effects \ TROR which may take their toll on the FPS. I'm guessing where the slow downs may occur are based around these newer effects within the Polymer as oppose to the original level design.

Sorry I wasn't being clear. What I meant by "vanilla" was maps that use the base tileset and base CON code. That could include user maps that take advantage of TROR and SE lights or even the HRP, so long as they don't include custom art/models or special code. My point was that we don't need to make it hard on the developers to isolate the problem. Any number of user maps that already work with the base game will do.

[Altered Reality]

TerminX, on 21 July 2015 - 10:20 PM, said:

How obnoxiously obtuse. It's fine with me if you don't particularly understand software development and have no grasp of the concept that sometimes optimizations in certain areas equal regressions in others, but please, keep ignorant comments like that to yourself.

That was a sober description of the actual philosophy followed by the MAME team, and they said it themselves LOTS of times in emulation forums, whenever someone complains about a performance decrease from one release to the next. The only part of my post that might have been inaccurate was assuming that the developers of the Polymer renderer also swear by that philosophy.