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 dpJudas » Sun Dec 15, 2019 8:52 pm

I don't think many people bought a high resolution monitor to run it at a low one. :)
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sun Dec 15, 2019 10:56 pm

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.
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 » Mon Dec 16, 2019 2:23 am

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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby SanyaWaffles » Mon Dec 16, 2019 2:50 am

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
SanyaWaffles
Wouldn't be an epic gamer if I didn't commit a few war crimes.
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 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 » Mon Dec 16, 2019 4:01 am

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
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 Player701 » Mon Dec 16, 2019 7:06 am

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
Player701
 
Joined: 13 May 2009
Location: Russia
Discord: Player701#8214
Operating System: Windows 10/8.1/8/201x 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 » Mon Dec 16, 2019 7:40 am

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
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 Player701 » Mon Dec 16, 2019 8:09 am

Ah, I guess the updater cannot update itself. Okay, I'll download a new version manually and see if it fixes the issue.
User avatar
Player701
 
Joined: 13 May 2009
Location: Russia
Discord: Player701#8214
Operating System: Windows 10/8.1/8/201x 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 boris » Mon Dec 16, 2019 10:12 am

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.
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Mon Dec 16, 2019 12:27 pm

+++ and --- :D
I like it, very handy.
Thx
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia, Canada

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby leodoom85 » Mon Dec 16, 2019 5:50 pm

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
leodoom85
Dodge this.....
 
 
 
Joined: 15 Sep 2014
Location: Earth-shaking Chile
Discord: leodoom85#6202

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby YukiRaven » Mon Dec 16, 2019 7:37 pm

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.
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 dpJudas » Mon Dec 16, 2019 8:03 pm

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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby YukiRaven » Mon Dec 16, 2019 8:12 pm

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
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 » Mon Dec 16, 2019 11:29 pm

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...
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 1 guest