GZDoomBuilder-Bugfix, a maintenance fork of GZDB

[Kappes Buur]

How about "Ultimate Doom Builder". It not only implies something better but is also a nice play on the title of Doom 1's first re-release.

That would abbreviate very nicely to UDB

I hope it will be renamed, I never liked typing GZDBBF.

[dpJudas]

I pushed another optimization to my branch. Panning around in 3D mode in Frozen Time is clearly faster on my computer now when comparing it to the D3D9 version.

[ZZYZX]

How about "Ultimate Doom Builder". It not only implies something better but is also a nice play on the title of Doom 1's first re-release.

That would abbreviate very nicely to UDB

I hope it will be renamed, I never liked typing GZDBBF.

I also like UDB and there is no GZ in it

I pushed another optimization to my branch. Panning around in 3D mode in Frozen Time is clearly faster on my computer now when comparing it to the D3D9 version.

Not noticeably faster for me. I have a shitty CPU though. I think we need to add a proper FPS meter...
Also: GZDB does not cull/clip stuff aside from viewport, I wonder if it's possible to multithread the calculations before pushing it to GPU? Just in theory for now.

edit: studio complains that /arch:SSE2 is invalid. Maybe that's why.
edit2: 32-bit build compiles without warnings, seems to be slightly faster...

[dpJudas]

Which CPU and GPU are you using?

[_mental_]

I would like to check the latest version, but there are two branches in active development.
How about a separate repository for UDB, with all cross-platfrom and OpenGL changes pushed to its master branch?
All collaborators will have push access, so no changes will be lost occasionally.
Also, maybe let's start a dedicated topic if the new name is settled.

[dpJudas]

The official branch is the one ZZYZX has - I just don't have push access to it.

[YukiRaven]

Just a general sort of report...

Gave the latest version posted by ZZYZX a go, both 32-bit and 64-bit. Native mono still gives me the same exception, but Wine + Mono does not :D However, Wine + Mono is unbearably slow, much slower than non-GL GZDB on Wine. The resources for my current project (about 130mb of zipped textures is the bulk on an NFS filesystem) take about 10 minutes to load compared to maybe 15-20 seconds. Once they load, the editor is still unbearably slow, where it takes a second or two to update the screen in 2D mode. 3D mode runs a bit better, but not much, unless I turn off all things. Other things I noticed:

• The program complete froze when I adjusted the rendering settings to my usual ones (128 dynlights, 16x AF, no AA, no HQ rendering, bilinear in 3D mode) while it was still loading resources. If I waited until they finished loading, it didn't freeze.
• In 3D mode, I usually have highlighting turned off. Normally a selected surface still turns red, though, but it didn't with Wine + Mono.
• The crosshair is about 8x larger in 3d mode 0_o

Next I tried the 32-bit version with the Wine + .NET prefix I've been using with normal GZDB. It actually runs great this way, with both 2D mode and 3D mode running mostly smooth. The resource loading also doesn't take 10 minutes :D I never expect it to run completely smooth in 3D mode with my maps, so that's fine - it never did even in Windows, either. So, Wine + .NET works for me.

Also, I like both UDB and GLDB, though GLDB reminds me of GLDV, a debugger for Go :-P

Specs, for the record:
GeForce 1080, driver 440.31
Core i7 2700K
12GB ram
Slackware Linux 14.2
Wine 4.21 with wine-staging applied, compiled from source
My native Mono is v6.0

[ZZYZX]

Sent invitation to dpJ.

Which CPU and GPU are you using?

GTX 950, i5-6400, Windows 10 x64

[boris]

Ultimate Doom Builder is very pretentious and provides more of a target for Bethesda.

[Graf Zahl]

Not really more than "Doom Builder". The "registered" part of the trademark is "Doom", not "ultimate".

[dpJudas]

Doing an unconditional memcpy of 4096 bytes to report errors was not the best strategy:



Edit: After fixing that, the native code and the OpenGL calls are no longer the current bottleneck according to VS's built-in profiler:



Edit 2: did a few more optimizations. On the C# side I reduced the usage of dictionaries and hashmaps as they were (and the remaining still actually are) the main bottlenecks in the system. On the C++ side I stopped clearing the OpenGL context as that seemed to heavily affect especially loading performance for some reason.

[Graf Zahl]

usage of dictionaries and hashmaps as they were (and the remaining still actually are) the main bottlenecks in the system.

Tell me about it. At work I have to deal with a project that uses dictionaries and hashmaps everywhere, and the performance is appropriately poor. I really don't get why some people use these features even for things where a plain vanilla struct is magnitudes better for, both in terms of robustness and performance.

[dpJudas]

I can understand why they are used in higher level stuff where they do improve quality of life a lot for the developer. It is just that in a performance critical part of the code they come up short. In that sense they aren't much different from their C++ equivalents of map, set and vector.

The biggest issue for me when it comes to C# is that I am not that familiar with their arrays (particular if you can subdivision them) and other techniques to avoid using the GC in the critical render loop.

The good news is that it already runs a lot better.

[Graf Zahl]

Vectors are harmless, the problem is normally when data is not properly structured and then put into a dictionary to avoid thinking about properly structuring it.
Just last month I had to refactor such a thing at work, and I made damn well sure that the replacement does not use dictionaries, except where needed by the underlying system.

[ZZYZX]

Seeing great FPS improvement in the latest branch in 3D mode.

Looking up "Dictionary" shows me pretty much half of the codebase, though. 654 references... I'd say not fixable.
A lot of these are e.g. almost all resources loaded in DataManager, which means — are used a lot during rendering.

Though here we already get to the original GZDB, which is not very important to optimize in the context of OpenGL performance

A bit more on Dictionary: I suspect at least part of it that could be fixed is actor states for thing rendering. Not entirely sure though.