DRD Team

Graf Zahl wrote:I have seen this happen when playing in non-fullscreen on a window size that, when the window's frame gets added, is larger than the display's resolution. In this case Windows will make the viewable area smaller than the intended viewport and the top and right will get cut off.

Is there a way to prevent it from reverting to the "wrong" window size after it's adjusted? Because I resize the window and after I close the program and start it again, the window size is back to the way it was before my adjustments.

To be honest, this code has been inherited from ZDoom and it's - well - not in the best shape...

Here are the benchmarks, both with and without dynamic lighting, of those two spots at the beginning of deus vult 2. If you know of any other WAD that would make a better benchmark, let me know.

The benchmarks should be directly comparable. In other words, each entry is the same spot with the same dynamic light settings.

I also use static VBOs in the old version. It didn't look like using dynamic increased performance any, and I seem to remember there being problems with that setting and AMD cards. I could be misremembering though.

Ralgor wrote:If you know of any other WAD that would make a better benchmark, let me know.

Try Frozen Time with this save file.

So, it looks like the beta is faster using FrozenT.wad and that save file, especially with dynamic lights on.

It seems like the "Finish" stage is the only one that's really slower, while everything else is generally faster (especially with dynamic lights on.)

Currently playing through Tormentor's The Ultimate Torment & and Torture. I've run into a problem involving reflective surfaces when combined with dynamic lights. What you get is a massive lag while at the same time the reflective surface does some sort of flickering.

Spoiler: This is from the first map (TNT01)

---

I tested this with development build 796-g8169991 - it works fine.

I went to the same spot in TUTNT and took some benchmarks.

It seems like this area is significantly slower on 2.0.2 with my setup, but I'm not getting any further issues with the area. No flickering, or unexpected slowdowns (other than the normal slowdown caused by having a lot of dynamic lights on the screen.)

Also, I've run into an issue. GZDoom 1.8.6 sees the 2.0.2 saves, and shows them as loadable, but gzdoom 1.8.6 throws an error when you try to load them (something about expecting a compressed file?). Then, if you try to save in 1.8.6 while there is a 2.0.2 save available, it sort of crashes. I mean "sort of" in that there's no error, but the video shrinks to the lower left hand corner with a resolution of about 320x200 or something (this is a guess... it's pretty tiny.) The game is ended, and all you can really do is navigate the menu to quit.

Edit: Apparently I was using a slightly out of date version of the map (1.06). However, the newest version works just as well (1.08).

The savegame issue is a known problem. Something about the dynamic light save state has changed and the save version had not been bumped. It's just a beta, after all...

So, anyway, that driver's numbers look really good. I'm a bit puzzled why the Finish stage gets stalled a bit with the 2.02 version it almost seems that the implementation of persistently mapped buffers is not yet perfect. Maybe it'll get sorted out.

But please, can you also run a benchmark on Frozen Time with the savegame? That map pushes the renderer to its limits and shows best how good the driver actually is.

My second set of benchmarks is from that savegame in FrozenT.wad. The file names have "frozent" in them.

And in that case the new beta version IS faster.

To be honest, I'm not too worried about slowdowns when I'm getting hundreds of frames per second anyway. I'll take the speedups when the renderer is actually struggling.

Ah. sorry, I missed that one - I only saw your first and last ones.

... and if AMD could *JUST* eliminate that insane draw call overhead... A single glDrawArrays call on AMD costs 20(!!!) times as much time as on NVidia with the same CPU and that will slow the best graphics card down with code that is bottlenecked by the amount of draw calls...

AMD is usually much slower to support the newest OpenGL stuff, so there's a good chance they haven't optimized glDrawArrays with ARB_buffer_storage yet or something. Also, what little information I can find implies that MAP_COHERENT_BIT could potentially be slow. If I had to guess, the AMD drivers are just brute forcing that bit to make it work, but it's slow.

Unfortunately the structure of the code doesn't really seem conducive to eliminating that, since right now you're just using VBOs as a way to reduce function call overhead. I don't see where any of the vertex data is actually being reused.

What development environment do you use to work on GZDoom?

No, it's definitely not the buffer mapping that slows down the draw calls. The vertices for flats are stored permanently, and there the same slowdowns appear (unless, of course, the driver is too stupid, which with AMD wouldn't really surprise me.)
Vertices for walls are not reused, the maintenance overhead would be a lot higher than the savings - and for sprites it wouldn't even make sense.

You can check the immediate mode fallback code with the -gl3 command line option.

As development environment I am using Visual Studio 2013 Professional.

Graf Zahl wrote:This restores support for OpenGL 3.3. A workaround has been added to enable the lighting code with the reduced feature set of the older hardware.

Bah! You would have to go and do that after I already upgraded my video card.

(It was needed anyway. )

I need to remember to try this out. I don't think I have any visually demanding maps yet, though. I guess anything by PyroScourge should work.

I don't really need any more benchmarks.
I already got info for GL4.x hardware from AMD, NVidia and Intel and it looks good on all of them, I also got info on NVidia and AMD for GL 3.x hardware and it doesn't really lower performance on them, so all seems fine.

I'll probably do a real 2.x release some time in the next weeks, when I find some time to add a bit of stuff that's on my list but I haven't found the time yet to look into it.