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.
Locked
dpJudas
 
 
Posts: 3163
Joined: Sat May 28, 2016 1:01 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by dpJudas »

I don't think many people bought a high resolution monitor to run it at a low one. :)
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

btw, it became even faster after putting some PBO in it (hopefully did it right)
Now is just as fast as SlimDX version was.

(also, debug build now writes GL_DEBUG_OUTPUT logs)
(and supposedly I put glGetError() everywhere where it's needed now...)
(additionally: did you know that calling glGetError() on a null context causes endless GL_INVALID_OPERATION?)

Updated the test builds (viewtopic.php?p=1128175#p1128175), duplicating here for convenience:
x86: https://www.mediafire.com/file/zlecwnz2 ... 09.7z/file
x64: https://www.mediafire.com/file/vv7d5qan ... 64.7z/file

3D mode seems to still be slower. Though only like 10% slower compared to 200%+ slower which was in the 2D mode.

Separately: yup, does not work under WINE. Exact cause is mysterious for me right now. Will need to debug later.
dpJudas
 
 
Posts: 3163
Joined: Sat May 28, 2016 1:01 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by dpJudas »

The patch looks correct.

Maybe the 10% slower is due to the sampler issue? At least given Graf said using sampler objects improved performance considerably for GZDoom there probably will be some measurable improvement for GZDB as well.
User avatar
SanyaWaffles
Posts: 841
Joined: Thu Apr 25, 2013 12:21 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Windows 11 for the Motorola Powerstack II
Graphics Processor: nVidia with Vulkan support
Location: The Corn Fields
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by SanyaWaffles »

Honestly this is awesome that OpenGL is finally coming to GZDB on Windows. The current mode is very stable for me on Windows and performance is fine... then again for now detail isn't as complex as some of the examples. And it fixes the problem I had with sluggish performance due to my high res sprites.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

dpJudas wrote:Maybe the 10% slower is due to the sampler issue? At least given Graf said using sampler objects improved performance considerably for GZDoom there probably will be some measurable improvement for GZDB as well.
I removed glTexParameteri calls, after which everything went bilinear but no change to performance :)
User avatar
Player701
 
 
Posts: 1707
Joined: Wed May 13, 2009 3:15 am
Graphics Processor: nVidia with Vulkan support
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Player701 »

It looks like the auto-updater is broken for me. Every time I press "Update" whenever I get a new release notification, the following happens:



If I close the editor manually before the updater tries to do it, everything works fine. The version of the updater is 1.05. My OS is Windows 10 1903.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

This is a bug with 32-bit updater. 32-bit updater is not able to update 64-bit GZDB. Not sure at which point updater became broken like this...
You could try downloading the full archive from DRDTeam and unpacking it manually (also rewriting the updater, supposedly with 64bit version).

This may/may not get fixed later. Updater's self-update is a bit broken atm. The most I could do is offer an option to "retry", but it would require updating the updater, which is a bit broken... that's some recursive issue ;)
User avatar
Player701
 
 
Posts: 1707
Joined: Wed May 13, 2009 3:15 am
Graphics Processor: nVidia with Vulkan support
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Player701 »

Ah, I guess the updater cannot update itself. Okay, I'll download a new version manually and see if it fixes the issue.
boris
Posts: 773
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

ZZYZX wrote:This is a bug with 32-bit updater. 32-bit updater is not able to update 64-bit GZDB. Not sure at which point updater became broken like this...
You could try downloading the full archive from DRDTeam and unpacking it manually (also rewriting the updater, supposedly with 64bit version).

This may/may not get fixed later. Updater's self-update is a bit broken atm. The most I could do is offer an option to "retry", but it would require updating the updater, which is a bit broken... that's some recursive issue ;)
I think it never worked. I fixed the problem 2 months ago. I also made a post in this thread that the updater has to be updated manually. For whatever reason the updater was always running in 32 bit for me, even though it was set to be compiled for "any CPU". And 32 bit processes can't access all info of 64 bit processes (and probably vice versa), so the 32 bit updater couldn't shut down the 64 bit version of GZDB-BF.
User avatar
Kappes Buur
 
 
Posts: 4171
Joined: Thu Jul 17, 2003 12:19 am
Graphics Processor: nVidia (Legacy GZDoom)
Location: British Columbia, Canada
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Kappes Buur »

+++ and --- :D
I like it, very handy.
Thx
User avatar
leodoom85
Posts: 684
Joined: Sun Sep 14, 2014 6:40 pm
Location: Earth-shaking Chile

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by leodoom85 »

Tried the thing, updated and all, used the x86 build. Two things.
First, having antiviruses on, the updater executable is recognized as a trojan. Disabling the AVs temporally will be enough to download the zip.
Second, I can't see the normal and visual mode...at all. However, the menus and all the other stuff are ok.

EDIT: Tried a fresh install. Same thing happened. RIP......gonna revert it back to r3017....least I tried :D
User avatar
YukiRaven
Posts: 43
Joined: Mon Jul 09, 2018 11:13 pm
Graphics Processor: nVidia with Vulkan support
Location: Colorado, United States
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by YukiRaven »

I got the 32-bit version launching with both Mono and Wine, but the moment it tries to render 2D or 3D mode, I get a crash. However, the crashes are each a bit different. I have a backtrace from wine-4.21 here: https://pastebin.com/0Zwm5A5k I usually use the 32-bit version with Wine with relatively few issues.

Mono 6.0 gives me this with both the 32-bit and 64-bit versions: https://i.imgur.com/w9mkqoq.png I'm not able to try a newer Mono right now, sadly.

FWIW, dpjudas's branch on github compiled and got into 2d/3d mode for me just fine using Mono. BUT... it had an odd behavior where it behaved as if the Alt key was always depressed once I loaded a map. Otherwise it seemed to work.
dpJudas
 
 
Posts: 3163
Joined: Sat May 28, 2016 1:01 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by dpJudas »

YukiRaven wrote:FWIW, dpjudas's branch on github compiled and got into 2d/3d mode for me just fine using Mono. BUT... it had an odd behavior where it behaved as if the Alt key was always depressed once I loaded a map. Otherwise it seemed to work.
You mean the native mono build? Its main outstanding issues are that there's no raw input and no SendMessage implementation.

Both of those could probably be solved on the C# side of things by falling back to using winforms APIs for reading the mouse and sending events to the UI thread.
User avatar
YukiRaven
Posts: 43
Joined: Mon Jul 09, 2018 11:13 pm
Graphics Processor: nVidia with Vulkan support
Location: Colorado, United States
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by YukiRaven »

dpJudas wrote:You mean the native mono build? Its main outstanding issues are that there's no raw input and no SendMessage implementation.

Both of those could probably be solved on the C# side of things by falling back to using winforms APIs for reading the mouse and sending events to the UI thread.
Correct, a native 64-bit Mono build of the code at https://github.com/dpjudas/GZDoomBuilderGL

iirc, I had to modify the project files just slightly because of a slight incompatibility with my Mono install. But otherwise it worked fine. I didn't mention it or open a PR since I figured it was pretty specific to my machine and my slightly old version of Mono.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

leodoom85 wrote:Second, I can't see the normal and visual mode...at all. However, the menus and all the other stuff are ok.
OS, GPU? Any warnings in the console? 32bit or 64bit editor?

Also, it seems WINE has broken SwapBuffers... although for me it crashes claiming that something something attempted to call null even before it shows the main window (as opposed to X11 cursor which was in two traces already)
Honestly I'd report this to WINE tracker :roll:

My guess is that it may be that Windows' multiple contexts are entirely broken on WINE while working with OpenGL, and it does not understand that we can actually try to swap buffers without having a valid display (yet or at all). Not sure though... In this case it may help to no-op SwapBuffers until there is a meaningful window.

Basically X11DRV_ClipCursor takes a rect pointer and stack trace may only end with it in case rect to clip the cursor to was null. I cannot currently search the WINE source, but that's it...
Locked

Return to “Abandoned/Dead Projects”