GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Wed Dec 18, 2019 3:58 pm

Graf Zahl wrote: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 :D

I hope it will be renamed, I never liked typing GZDBBF.
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia, Canada

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Wed Dec 18, 2019 8:15 pm

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Thu Dec 19, 2019 2:02 am

Kappes Buur wrote:
Graf Zahl wrote: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 :D

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

I also like UDB and there is no GZ in it :D

dpJudas wrote: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...
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Thu Dec 19, 2019 2:17 am

Which CPU and GPU are you using?
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby _mental_ » Thu Dec 19, 2019 2:19 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Thu Dec 19, 2019 2:22 am

The official branch is the one ZZYZX has - I just don't have push access to it. :)
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby YukiRaven » Thu Dec 19, 2019 2:31 am

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
User avatar
YukiRaven
 
Joined: 10 Jul 2018
Location: Colorado, United States
Discord: YukiRaven#6258
Twitch ID: Yuki_the_Cat
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Thu Dec 19, 2019 3:29 am

Sent invitation to dpJ.

dpJudas wrote:Which CPU and GPU are you using?

GTX 950, i5-6400, Windows 10 x64
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby boris » Thu Dec 19, 2019 3:39 am

Ultimate Doom Builder is very pretentious and provides more of a target for Bethesda.
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Graf Zahl » Thu Dec 19, 2019 4:36 am

Not really more than "Doom Builder". The "registered" part of the trademark is "Doom", not "ultimate".
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Thu Dec 19, 2019 7:34 pm

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Graf Zahl » Fri Dec 20, 2019 3:32 am

dpJudas wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Fri Dec 20, 2019 3:53 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Graf Zahl » Fri Dec 20, 2019 5:34 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Fri Dec 20, 2019 5:44 am

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

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.
Last edited by ZZYZX on Fri Dec 20, 2019 7:09 am, edited 1 time in total.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

PreviousNext

Return to Abandoned/Dead Projects

Who is online

Users browsing this forum: No registered users and 0 guests