What maps have lowest framerate with polymer+HRP?
#1 Posted 01 June 2017 - 12:57 AM
A good example is the recent Moontang by Captain Massive -- I wouldn't say it runs horribly, but it is a vanilla map with polymer lights added to it and it does put quite a lot of strain on my system when run with HRP and polymer with standard settings (5 lights + 5 shadows per surface).
If you have suggestions, please post links below!
#2 Posted 01 June 2017 - 02:45 AM
I have some good candidates for maps with low FPS but they are all part of mods so they don't qualify.
This post has been edited by Mark.: 01 June 2017 - 02:46 AM
#3 Posted 01 June 2017 - 06:03 AM
Mark., on 01 June 2017 - 02:45 AM, said:
Even if that is the case, culling non visible lights would add a good amount of performance to Polymer. I plan on fixing some Polymer issues that are specific to Shadow Warrior(showview and trans water for example), I hope we can merge any code changes you have.
#4 Posted 01 June 2017 - 06:10 AM
Mark and I have done more testing with other setups and found consistently excellent results.
The only refinement I can think of would be to check if points (maybe 4 to 8 ) further along/around the light radius are visible but while it would reduce flicker it would likely eat a chunk of regained performance in CON.
#5 Posted 01 June 2017 - 06:21 AM
Mblackwell, on 01 June 2017 - 06:10 AM, said:
Mark and I have done more testing with other setups and found consistently excellent results.
The only refinement I can think of would be to check if points (maybe 4 to 8 ) further along/around the light radius are visible but while it would reduce flicker it would likely eat a chunk of regained performance in CON.
That can be very inaccurate though. The correct solution is to light support to the gpu occlusion culling(basically draw a simple box into the occlusion culling and see if the gpu returns pixelcount > 0).
#7 Posted 01 June 2017 - 06:54 AM
i made a vanilla map that people bitched at me to 'fix' because it ran like shit when they used polymer + hrp
paulb's entrapped is a polymer map - it runs fine until you get inside the bank, then it bogs down
http://www.scent-88....M/map1/map1.php
http://www.scent-88....12_12/12_12.php
http://www.scent-88....entra/entra.php
there are probably more useful examples out there
This post has been edited by Forge: 01 June 2017 - 06:57 AM
#8 Posted 01 June 2017 - 09:27 AM
MB's "refined" light culling is in the HH remake I'm working on. It sure helps in some areas.
#9 Posted 01 June 2017 - 09:52 AM
Forge, on 01 June 2017 - 06:54 AM, said:
paulb's entrapped is a polymer map - it runs fine until you get inside the bank, then it bogs down
Thanks, I'll try these. I am also trying this solution out with Duke Nukem Eternity, which for me is completely unplayable when polymer lighting is on.
Mark., on 01 June 2017 - 09:27 AM, said:
That's Clear the Coast. I have tested with that. For me it's already playable with polymer + HRP without any special optimization.
#10 Posted 01 June 2017 - 11:41 AM
#11 Posted 01 June 2017 - 12:26 PM
Mark., on 01 June 2017 - 11:41 AM, said:
I think I will end up with something that is worth using as long as polymer is not optimized. As soon as we have PolymerNG, then my code should be thrown in the trash. As for modularity: yes, but to make it a "mutator", I have to add a little bit of overhead, because right now it is using calculations already performed in my Essential Duke mod.
Previous efforts at increasing framerate focus on culling lights. Mblackwell's code, as well as attempts that I have made along the same lines, are examples. What I'm doing here is something more radical: sector culling. I collapse distant sectors (along with their child sectors) to remove them from the rendering pipeline. It's a tricky business to collapse and restore the right sectors at the right time and not cause serious glitches, but it can yield big benefits.
My best use case so far is the beginning of Duke Nukem Eternity. Without the optimization, I get about 14fps in the first section of the level, even before the more complex sections come into view. With my optimization, I triple my framerate without any visual glitches (i.e. there are no lights or sectors visibly removed from the scene). What this tells me is that polymer is seriously over-rendering, or at least stuff that doesn't end up getting drawn to the screen is wasting a lot of cpu cycles. Unfortunately, my code doesn't yield very good benefits in situations where tons of stuff is on screen. So when you get into the thick of it, in the midst of the lights and the heavy level geometry, it's not much better than without the code, because my code isn't finding much to cull in those situations.
#12 Posted 02 June 2017 - 05:48 AM
Trooper Dan, on 01 June 2017 - 12:26 PM, said:
Previous efforts at increasing framerate focus on culling lights. Mblackwell's code, as well as attempts that I have made along the same lines, are examples. What I'm doing here is something more radical: sector culling. I collapse distant sectors (along with their child sectors) to remove them from the rendering pipeline. It's a tricky business to collapse and restore the right sectors at the right time and not cause serious glitches, but it can yield big benefits.
My best use case so far is the beginning of Duke Nukem Eternity. Without the optimization, I get about 14fps in the first section of the level, even before the more complex sections come into view. With my optimization, I triple my framerate without any visual glitches (i.e. there are no lights or sectors visibly removed from the scene). What this tells me is that polymer is seriously over-rendering, or at least stuff that doesn't end up getting drawn to the screen is wasting a lot of cpu cycles. Unfortunately, my code doesn't yield very good benefits in situations where tons of stuff is on screen. So when you get into the thick of it, in the midst of the lights and the heavy level geometry, it's not much better than without the code, because my code isn't finding much to cull in those situations.
Does your optimizations work with extended TROR sectors as well without glitching?
#13 Posted 02 June 2017 - 07:27 AM
Trooper Dan, on 01 June 2017 - 12:26 PM, said:
Previous efforts at increasing framerate focus on culling lights. Mblackwell's code, as well as attempts that I have made along the same lines, are examples. What I'm doing here is something more radical: sector culling. I collapse distant sectors (along with their child sectors) to remove them from the rendering pipeline. It's a tricky business to collapse and restore the right sectors at the right time and not cause serious glitches, but it can yield big benefits.
My best use case so far is the beginning of Duke Nukem Eternity. Without the optimization, I get about 14fps in the first section of the level, even before the more complex sections come into view. With my optimization, I triple my framerate without any visual glitches (i.e. there are no lights or sectors visibly removed from the scene). What this tells me is that polymer is seriously over-rendering, or at least stuff that doesn't end up getting drawn to the screen is wasting a lot of cpu cycles. Unfortunately, my code doesn't yield very good benefits in situations where tons of stuff is on screen. So when you get into the thick of it, in the midst of the lights and the heavy level geometry, it's not much better than without the code, because my code isn't finding much to cull in those situations.
instead of collapsing sectors why not keep an array of redwalls and then dynamically remove and insert the references?
Although in general any changes to sectors has the potential to destroy a lot of things including enemy paths.
#14 Posted 02 June 2017 - 11:26 AM
Mblackwell, on 02 June 2017 - 07:27 AM, said:
Although in general any changes to sectors has the potential to destroy a lot of things including enemy paths.
That's an interesting idea, although I would have to do some research before implementing it. It sounds like it would be more difficult to manage than what I'm doing now, but it might yield better results. I'm going to finish my current method, first.
As an aside: Developers, if you are reading this, please provide CON access (read only is fine) to anything potentially useful in the rendering pipeline. For example, if there is an internal list of stuff that is being rendered (walls, sprites, sectors) it would be very handy.
#15 Posted 04 June 2017 - 10:59 PM
Paul B, on 02 June 2017 - 05:48 AM, said:
It does not work with TROR. But it detects whether a sector has TROR and simply doesn't fuck with it in that case.
My code seems to have stabilized and I don't have any more ideas for improving it, so I may release it soon, if people are interested.
@Mblackwell: thank you for your idea of deleting/restoring nextsector references. While this didn't work well as a substitute for what I was doing, it did help significantly when used in combination with my other technique.
#16 Posted 06 June 2017 - 03:26 PM
Processor: Intel Core i5 3470 at 3.8 GHz on all Cores (2 of the cores can turbo up to 4.0 GHz) Motherboard: Gigabyte GA-Z77-D3H Revision 1.1 RAM: 4X4 GB 1333 MHz GPU: Sapphire HD 7950 Vapor-X 3GB GDDR5 OC PSU: ThermalTake 650W Smart
Even if I overclock my GPU from stock 850/1250 MHz to 1050/1500 MHz, I literally get the same performance. What I noticed is that the GPU usage is very low (Under 30%).
Is this an AMD issue?
I can run games like Prey maxed out 1080p with an average of 55 FPS. (60 most of the time, but minor dips into 48 in some places)
This post has been edited by Romulus: 06 June 2017 - 03:28 PM
#17 Posted 06 June 2017 - 04:26 PM
Romulus, on 06 June 2017 - 03:26 PM, said:
Is this an AMD issue?
It is not an AMD issue, it is a polymer issue. It is not optimized to actually use the GPU. Long story.
#18 Posted 08 June 2017 - 12:25 PM
#19 Posted 08 June 2017 - 12:52 PM
And then all the problems I had with my ATI X1650 card at the time...Plagman did do a lot of work back then to fix peoples' issues to be fair. At least it WORKS for everybody now, even if it doesn't run the best across the board.
#20 Posted 08 June 2017 - 01:04 PM
Tea Monster, on 08 June 2017 - 12:25 PM, said:
It's a sad situation, but I don't blame anyone. For the regular Eduke32 devs, it's not their area of expertise. Those who could do it are either too busy, have other priorities or in the case of icecoldduke is prohibited by his job.
The thing that irks me is that every time I try to do something relating to polymer I get burned. First it was because polymer was new and I went ahead and coded stuff on the assumption it would be optimized, and then it wasn't. Later I got burned because of instability -- things getting broken that used to work, and performance fluctuating with different builds (currently I guess it's quite a bit worse than it used to be for many users). And now I'm feeling a bit burned because I just spent over a week on a frame rate boosting hack, only to find that it's not good enough (I still think it could be, but, I'm not motivated to develop it further if no one seems interested).
So I'm at a place now where I want nothing to do with it.
#21 Posted 08 June 2017 - 01:38 PM
This post has been edited by Hank: 08 June 2017 - 01:38 PM
#22 Posted 08 June 2017 - 02:55 PM
Because of my ideas and style of modding I have no other choice than to use Polymer, broken as it is. I work around it when I can and accept the bad with the good. Its not always easy. I'm an old dog that doesn't want to learn a new game engine so this is it for me. Gotta use it.
This post has been edited by Mark.: 08 June 2017 - 02:58 PM
#23 Posted 08 June 2017 - 04:11 PM
I can guaranty you, if you ask enough people tonight, the right people, someone would love to lick your toes, maybe with Strawberry and Whip cream coated, or what ever it takes.
Someone, out there, can and would be willing to optimize Eduke32 Polymer - it's a matter of asking enough people, until one says, yes.
Meanwhile, I will do my stuff for basic and polymer. I refuse to give up on polymer.
This post has been edited by Hank: 08 June 2017 - 04:11 PM
#24 Posted 08 June 2017 - 04:28 PM
BTW TD, I'm going to try it in Decay and Graveyard tonight. Or did you already? Gah, I just remembered, they both need older versions of eduke too. Well, they don't have to look their best. I can test them in newest version and your mod.
This post has been edited by Mark.: 08 June 2017 - 04:35 PM
#25 Posted 09 June 2017 - 03:25 AM
This post has been edited by Mark.: 09 June 2017 - 03:28 AM
#26 Posted 09 June 2017 - 10:02 AM
Mark., on 09 June 2017 - 03:25 AM, said:
Did you see the PM I sent you several days ago where I noted that graveyard has a "enda" instead of "endevent" in your EVENT_SPAWN near the top of BLOAT.CON? I had to fix that before I could get it to run for me. By the way, it's a good idea to examine the log when it reports errors...it's often a very quick and easy fix!
Mark., on 09 June 2017 - 03:25 AM, said:
Good question. If they are in TROR sectors then it's no problem, because polymin will not touch those. But otherwise, yeah, I would expect problems. The RESPAWN sprites (or any other sprites for that matter) are not being moved by my code, but certain actors could be moved automatically to a new z position (like the birds you noticed). This is a problem that should only impact spawned actors, though: actors that already existed in the sector at the time it was collapsed are entered into an array and dealt with.
I don't know if this is feasible for the devs, but I think it would be cool if there was a level geometry equivalent of the t-sprite array. That way it would be possible to change the appearance of the level (e.g. which sectors are rendered) without impacting gameplay.
#27 Posted 09 June 2017 - 10:16 AM
I didn't ignore your PM. What happened is I changed the enda but forgot to click save in the editor. So when the newer Eduke popped up the con error window and stopped I just moved on to the next test project.
This post has been edited by Mark.: 09 June 2017 - 10:49 AM
#28 Posted 09 June 2017 - 11:02 AM
appendevent EVENT_EGS ife sectorchanged[sprite[].sectnum] 1 { set TEMPSECT sprite[].sectnum state restoresector } endevent
By the way, here's what should be a quick fix for the spawned sprite issue. Just paste this into polymin.CON.
Obviously, that code must go AFTER state restoresector is defined, because it calls that state, otherwise you will get an error.