[No] changing openGL versions.

[cortlong50]

i cant help but notice that every time i install a new version of gzdoom the performance hit is worse than the last one. i run with vid_fps 1 constantly because im trying to make a pack that runs good but looks great and every time i drop in a new version i seem to lose 5 fps. i mean...maybe its placebo...it it doesnt feel like it.


but i remember playing zandronum compared to gzdoom 3.0 or even gzdoom 1.8 vs 3.0 that the performance hit was far less.

im wondering if there was a way to implement changing your openGL version or something that would help with this. ive heard zandronum uses an older version and i get straight 60s across the board on that no matter what im playing. so could switching to a less demanding GL version save people some FPS?

I mean...because at this rate nobody is going to be able to play my pack or any of the gzdoom focused packs unless they have beefy rigs. i just dont understand why an engine running doom gets worse frames than skyrim when i have bloom enabled. (now heres where someone derails this with a comparison of the two and how theyre completely different... which people seem to love doing)

so yeah, just wondering if thats possible and if anyone was interested in implementing it.

[Rachael]

The renderer changes and evolves and there is no "looking back" with it.

The most you can do is append things like "-glversion 3" or "-glversion 2" to GZDoom's startup for the compatibility modes - but there's no way to switch the renderer to a previous version of GZDoom. It wouldn't help, anyway - GZDoom is CPU-locked on older systems, and if your CPU is not powerful enough you're going to experience stuttering.

The problem isn't the OpenGL on these systems - it's that you are running more and more demanding maps on them that GZDoom can't handle with the CPU power given on them. This is actually painfully true with ATI's, in particular. ATI drivers also CPU-lock the system - and with GZDoom needing to run things like the BSP node walker and the scene clipper, it simply bogs the CPU down beyond the point of being able to give a suitable frame rate. If you have an ATI card, your best bet is to switch to open source drivers, if they are available. ATI drivers are utter shit.

[cortlong50]

The renderer changes and evolves and there is no "looking back" with it.

The most you can do is append things like "-glversion 3" or "-glversion 2" to GZDoom's startup for the compatibility modes - but there's no way to switch the renderer to a previous version of GZDoom. It wouldn't help, anyway - GZDoom is CPU-locked on older systems, and if your CPU is not powerful enough you're going to experience stuttering.

The problem isn't the OpenGL on these systems - it's that you are running more and more demanding maps on them that GZDoom can't handle with the CPU power given on them. This is actually painfully true with ATI's, in particular. ATI drivers also CPU-lock the system - and with GZDoom needing to run things like the BSP node walker and the scene clipper, it simply bogs the CPU down beyond the point of being able to give a suitable frame rate. If you have an ATI card, your best bet is to switch to open source drivers, if they are available. ATI drivers are utter shit.

i know you said no, but if you dont mind me continuing the discussion, lessdoiiiit.


i noticed that actually really bad with my previous computer...it had better specs as far as GPU was concerned (by...a lot) but for whatever reason it ran horrendously. now that this ATI info has come to light...thats definitely something nice to know...or bad to know? i do remember every time i updated drivers it was...a clusterfuck. whoever is in the drivers department definitely needs a new job over there.

i am running an i7 (first gen...not amazing but still 2.63ghz i believe) and whatever my onboard is (...a not great one, but it cranks most maps just fine). i mean...i guess my main complaint is that the performance is getting worse and worse to the of it completely making use of any of the advanced features hard to implement and still get play-ability out of. i am totally okay with 35s...because thats what i grew up on when i got my first doom floppy (when i was just a wee lad) but getting 17-20 when im just looking down a hallway seems kinda...bad. i dont know. i dont want to critique anything because i dont know exactly whats going on under the hood (i understand modern day rendering but still dont fully understand whats happening with gzdoom) but i just ran the same build i was testing with the version taht dropped on sunday and i noticed one room id enter (its huge and taxing) would get 35 frames before now gets 17 when looking north. thats a HUGE drop. if it were just a few i wouldnt say anything...but thats big.

again, i dont want to critique anything i dont fully understand but is there not any way to optimize performance?

sorry for the long comments. im not one for brevity. thanks for the quick reply though!

[_mental_]

You should try bench CCMD with different GZDoom versions at exactly the same location using exactly the same configuration file.
This will save benchmarks.txt with lots of performance information.

The command needs to be used at least three time in a row in each GZDoom version to get stable results.
Do not forget to set vid_vsync and vid_maxfps CVARs to zero before using it.

After that you can (or cannot) confirm changes in performance for the particular map spot across various releases.

[cortlong50]

You should try bench CCMD with different GZDoom versions at exactly the same location using exactly the same configuration file.
This will save benchmarks.txt with lots of performance information.

The command needs to be used at least three time in a row in each GZDoom version to get stable results.
Do not forget to set vid_vsync and vid_maxfps CVARs to zero before using it.

After that you can (or cannot) confirm changes in performance for the particular map spot across various releases.

ohhh, good call. lemme give this a shot. i did just overwrite my previous GZDOOM version, so let me see if i still have the old .zip lying around. ill get back this with results.

[Rachael]

If not, old versions can always be found here. I disabled the main download links because of the security flaw but the archive always works.

[drfrag]

I understand you're on intel integrated video. GZDoom has always been heavily CPU dependant but recent versions have introduced a lot of eye-candy and i guess now you need a real graphics card to play with advanced features enabled. The old renderer (fixed function?) was pretty fast even on really crappy hardware. Zscript also adds some overhead if i'm not wrong.
Edit: What i don't get is that you're asking for an older renderer and want to use advanced features at the same time, which advanced features are you talking about BTW?

[cortlong50]

If not, old versions can always be found here. I disabled the main download links because of the security flaw but the archive always works.

i just dont wanna be one of those dudes who releases a pack and goes "you have to play it with this specific version of gzdoom"...everyone including me...hates that hahaha. but for my personal runthroughs i may do it. i always keep 1.8 in a folder because that version to me was one of the best. it just ran great.

I understand you're on intel integrated video. GZDoom has always been heavily CPU dependant but recent versions have introduced a lot of eye-candy and i guess now you need a real graphics card to play with advanced features enabled. The old renderer (fixed function?) was pretty fast even on really crappy hardware. Zscript also adds some overhead if i'm not wrong.
Edit: What i don't get is that you're asking for an older renderer and want to use advanced features at the same time, which advanced features are you talking about BTW?

nothing crazy, i mean on my personal runs i play with bloom, but nothing too wild (would love to get the SSAO working but its a little too taxing....bummed about that one) but i mainly mean the features gzdoom was made for. 3d floors. crouching. transparent water. fog. stuff like that, im not trying to reinvent the wheel or even repolish it...im just trying to get that fucker to spin really fast and create something gorgeous that is still practical. i just noticed without changing anything it took a performance hit after i updated and really felt like i should bring it up. i would hate if doom got to the point where it wasnt even playable for people on lower end machines.

[_mental_]

GZDoom is far far FAR advanced then good old Doom.exe for DOS.
Everything has its price. You can either afford it or not.

There are Choco, Crispy, PrBoom+, etc. Use one of these and be happy.
But if you want to have many enhanced features available then you cannot have the same system requirements.

Comparison with any other games designed for hardware renderer is just silly.
Graf and other devs answered such questions many times. With Doom it’s impossible to utilize many techniques used in modern games.

[cortlong50]

but...i feel like youre missing the point. my main concern is that i downloaded and extracted the newest version and noticed a 5+ frame drop in some areas and up to 15 in other areas compared to the previous version.

im mainly trying to bring attention to that...i dont think justifying that big of loss of performance is really the answer. that seems like an optimization issue.

was there any rendering changes or visual changes that took place in this latest version that would cause that?

also sorry i havent run benchmark yet. ive been working my ass off.

[Kotti]

Since 3.0 there were really no relevant changes. Have you checked that the dropoff is directly related to the new version? If yes, running a benchmark test is really the only way to see what caused it.

[_mental_]

I'm not missing the point. You didn't do a benchmark but continue to complain about FPS drops with no factual information.
Many times we saw more than enough errors in performance measurement leading to completely wrong decisions about GZDoom development.
Also, you were trying to compare performance of GZDoom and Skyrim. So I told you why this is plainly wrong.

Post you hardware spec and startup log please.

[drfrag]

i just dont wanna be one of those dudes who releases a pack and goes "you have to play it with this specific version of gzdoom"...everyone including me...hates that hahaha. but for my personal runthroughs i may do it.

You don't need to do that, for legacy hardware there are a couple of unofficial ZDoom versions with the old GL renderer merged in. ZDoom LE is based on 2.8.1 and has a patched GL renderer from 1.8.4 (requires only GL 1.2). ZDoom32 is based on 2.9pre and has a patched GL renderer from 1.9.1.

i would hate if doom got to the point where it wasnt even playable for people on lower end machines.

That's why i created those versions with lower system requirements.

I'm also awaiting your bechmark results. Could you please add ZDoom32 to them? (i haven't tested it on modern hardware). The download link is below my avatar.

[cortlong50]

Since 3.0 there were really no relevant changes. Have you checked that the dropoff is directly related to the new version? If yes, running a benchmark test is really the only way to see what caused it.

that was actually one of my questions. i was curious as to whether anything happened on the rendering side that couldve caused it or if it was something on my end.


here are the benches. the first one was fresh off of a restart. the second was after playing "noendinsight" for a while. that way i could get an idea with it having a little bit of the cache used up (more curiosity on my part) third is with a complete shut down. battery removal and complete reboot (my girlfriend kicked my power cord out and my computer went to shut down but i got it plugged back in before it could while playing "noendinsight" and this actually made me curious as to whether or not this was the culprit for such a HUGE drop (sounds weird...but after working in IT for 5 years i dont rule anything out anymore. i had a lady whose mouse would use 512mb of ram on a 2gb rig. it was the weirdest thing ive ever seen...well not the weirdest but yeah)
the fourth is from the previous version i had installed. the numbers are similar but there is a few frames missing, but at this point im just confused. there are such large drops.

anyway. hopefully this will explain whats going on. i was sure it was the newer version...but these frame drops are now confusing to me. i did my best to line up shots in the same spot. and yes there are TONS of sprites in this area, its a benchmark area where the objects can be toggled on and off for older computers.

BENCH1

---

Map MAP06: "MUCH MORE GRIEVOUS",
x = 7530.4194, y = -5852.7091, z = -22.9983, angle = -82.0898, pitch = 6.5918
Walls: 1914 (0 splits, 2 t-splits, 2592 vertices)
Flats: 351 (2060 primitives, 11471 vertices)
Sprites: 820, Decals=0, Portals: 3
W: Render=11.206, Setup=10.640, Clip=1.457
F: Render=1.369, Setup=0.126
S: Render=5.155, Setup=0.914
All=50.641, Render=27.638, Setup=14.054, BSP = 0.900, Portal=53414713.245, Drawcalls=4.341, Finish=7.668
DLight - Walls: 0 processed, 0 rendered - Flats: 0 processed, 0 rendered
Missing textures: 0 upper, 0 lower, 0.000 ms
28 fps

BENCH2

---

Map MAP06: "MUCH MORE GRIEVOUS",
x = 7798.6982, y = -6026.1747, z = -22.0516, angle = -83.3203, pitch = 0.5273
Walls: 1216 (0 splits, 0 t-splits, 1564 vertices)
Flats: 217 (1321 primitives, 7408 vertices)
Sprites: 809, Decals=0, Portals: 1
W: Render=0.736, Setup=0.775, Clip=1.002
F: Render=0.840, Setup=0.084
S: Render=4.571, Setup=0.875
All=28.270, Render=15.797, Setup=3.387, BSP = 0.638, Portal=0.078, Drawcalls=3.832, Finish=8.429
DLight - Walls: 0 processed, 0 rendered - Flats: 0 processed, 0 rendered
Missing textures: 0 upper, 0 lower, 0.000 ms
16 fps

BENCH3

---

Map MAP06: "MUCH MORE GRIEVOUS",
x = 5034.5070, y = -5947.1344, z = 55.0000, angle = -32.3438, pitch = -6.0645
Walls: 6145 (0 splits, 16 t-splits, 7212 vertices)
Flats: 2038 (7910 primitives, 41948 vertices)
Sprites: 1070, Decals=0, Portals: 7
W: Render=1.736, Setup=2.021, Clip=3.249
F: Render=3.405, Setup=0.277
S: Render=2.656, Setup=1.087
All=35.602, Render=15.823, Setup=9.110, BSP = 2.447, Portal=10602486.221, Drawcalls=4.185, Finish=4.520
DLight - Walls: 0 processed, 7 rendered - Flats: 9 processed, 0 rendered
Missing textures: 0 upper, 0 lower, 0.000 ms
27 fps

BENCH4

---

Map MAP06: "MUCH MORE GRIEVOUS",
x = 5072.7584, y = -5980.8821, z = 41.0000, angle = -29.5312, pitch = -12.5684
Walls: 6091 (0 splits, 16 t-splits, 7136 vertices)
Flats: 2038 (7866 primitives, 41714 vertices)
Sprites: 1075, Decals=0, Portals: 7
W: Render=0.000, Setup=0.000, Clip=0.000
F: Render=0.000, Setup=0.000
S: Render=0.000, Setup=0.000
All=0.000, Render=0.000, Setup=0.000, BSP = 0.000, Portal=0.000, Drawcalls=0.000, Finish=0.000
DLight - Walls: 0 processed, 7 rendered - Flats: 9 processed, 0 rendered
Missing textures: 0 upper, 0 lower, 0.000 ms
32 fps

ALSO, i just noticed the menu blur option in the GL options....man i love that effect hahaha it looks killer


after running these benches i played it again and immediately got the frames i started complaining about. here are the benches.

---

Map MAP06: "MUCH MORE GRIEVOUS",
x = 5043.3064, y = -5954.4469, z = 55.0000, angle = -42.7148, pitch = -2.0215
Walls: 6135 (0 splits, 16 t-splits, 7204 vertices)
Flats: 2029 (7898 primitives, 41902 vertices)
Sprites: 1075, Decals=0, Portals: 7
W: Render=1.724, Setup=2.077, Clip=3.342
F: Render=3.215, Setup=0.268
S: Render=2.735, Setup=1.099
All=38.279, Render=17.731, Setup=9.066, BSP = 2.253, Portal=17549563.850, Drawcalls=3.738, Finish=8.457
DLight - Walls: 1 processed, 8 rendered - Flats: 15 processed, 0 rendered
Missing textures: 0 upper, 0 lower, 0.000 ms
24 fps

[cortlong50]

i just dont wanna be one of those dudes who releases a pack and goes "you have to play it with this specific version of gzdoom"...everyone including me...hates that hahaha. but for my personal runthroughs i may do it.

You don't need to do that, for legacy hardware there are a couple of unofficial ZDoom versions with the old GL renderer merged in. ZDoom LE is based on 2.8.1 and has a patched GL renderer from 1.8.4 (requires only GL 1.2). ZDoom32 is based on 2.9pre and has a patched GL renderer from 1.9.1.

i would hate if doom got to the point where it wasnt even playable for people on lower end machines.

That's why i created those versions with lower system requirements.

I'm also awaiting your bechmark results. Could you please add ZDoom32 to them? (i haven't tested it on modern hardware). The download link is below my avatar.

this sounds super interesting! id love to find something that i could get higher frames out of more stressful packs for personal use! let me do some benches (my laptop isnt modern) but id be glad to help you out!

okay so after playing with zdoom32 here are the results (couldnt get it to print a bench for some reason, even after messing with permissions)
so test one was in the same spot without truecolor enabled. i was getting about 30-33 at the area the previous benches were performed. its a super taxing room so thats expected. everywhere else in the map was around 50-55
test with truecolor enabled was pretty rough. 17-(the highest)19. again this area isnt optimal, but with truecolor there is a pretty hefty performance hit. surprisingly it rendered all the 3d floors and all that good shit and taht was pretty impressive seeing that in the zdoom style rendering.