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
User avatar
Kappes Buur
 
 
Posts: 4116
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 »

Xmas came early :D
thank you boris

seadon's greetings to all
User avatar
Nash
 
 
Posts: 17439
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Nash »

Hey boris, just wanted to drop you a THANK YOU for maintaining the program. :) Good work across the board!
User avatar
AFADoomer
Posts: 1324
Joined: Tue Jul 15, 2003 4:18 pm
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by AFADoomer »

A request:

Right now GZDB-BF does not seem to properly parse the 'mixin' statement in ZScript (See here for syntax info).

A ZScript file with a mixin causes the editor to throw an error of "Expected preprocessor statement, const, enum, or class declaration, got <Token.Identifier (mixin)>".

Would it be possible to add handling to the parser for mixins?
boris
Posts: 739
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

Thanks for the kind words.

AFADoomer wrote:A request:

Right now GZDB-BF does not seem to properly parse the 'mixin' statement in ZScript (See here for syntax info).

A ZScript file with a mixin causes the editor to throw an error of "Expected preprocessor statement, const, enum, or class declaration, got <Token.Identifier (mixin)>".

Would it be possible to add handling to the parser for mixins?
There's even a wiki page about it, I'm pleasantly surprised. I'm not really familiar with the ZScript parser, but I'll have a look at it.
boris
Posts: 739
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

Mixin support is in now. Works for my examples, and I can still load BoA maps without it exploding, so it looks like I didn't break anything in the process.
User avatar
AFADoomer
Posts: 1324
Joined: Tue Jul 15, 2003 4:18 pm
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by AFADoomer »

Fantastic! Everything appears to be working as expected on my end as well... Thanks very much!
User avatar
Kappes Buur
 
 
Posts: 4116
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 »

In the video, how does one go to highlighting the edges, as shown from 1:03 to 1:07?
Spoiler:
boris
Posts: 739
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

Kappes Buur wrote:In the video, how does one go to highlighting the edges, as shown from 1:03 to 1:07?
Spoiler:
It looks a bit different now: https://streamable.com/2dyim

You can toggle between enabling/disabling the handles with a key press (currently I plan to use Shift-W by default). A pivot handle (not shown in the video, it uses smart pivot) can be set by highlighting a handle and pressing another key (currently I plan to use Shift-T by default). It came to my mind yesterday, though, that it'd probably make more sense to enabling them while holding a key modifier (like Alt). They are already pretty packed though, and I didn't look into which combinations are still free with mouse clicks.
SanyaWaffles
Posts: 805
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 »

That's going to be an incredibly useful function. I really look forward to it being finished.
User avatar
Kizoky
Posts: 291
Joined: Mon Nov 14, 2011 9:59 am
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 11
Graphics Processor: nVidia with Vulkan support
Location: Around weirdos, I'm the biggest weirdo among them
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Kizoky »

For some reason GZDB thinks boolean variables are integer ones, has anyone had this issue?

For example, in ZScript you have (bool user_variable;), but that turns into integer when you are viewing the Custom tab
It's not a problem because 0 means false and 1 true, but for others it might be confusing and wonders why it's not working
boris
Posts: 739
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

I wasn't even aware that interaction is possible at all :D Good to know.

Anyway, there's actually code to handle bools, but they do get translated to int. Not sure why, since ZScript does have bool (unlike Decorate, apparently), so I guess it's an oversight. It also doesn't seem to handle any other int type (like int16 or uint8). The UDMF specs don't seem to specify how big their ints are, but I guess it'd be ok to represent all ZScript ints as UDMF ints - better than nothing. Not sure how other ZScript types that don't have a UDMF equivalent (like Vector2) should be handeled. Couldn't find anything about that on the Wiki.
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 »

I think it's because there is no bool in UDMF, or there was no bool option in the editor. I don't really remember why I did it like this. Or maybe it was for DECORATE compatibility.
For all I know, my code is explicitly handling bool as int. https://github.com/jewalky/GZDoom-Build ... re.cs#L859
So it's always possible to try to change it to bool and see what happens ;)
boris
Posts: 739
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

There is bool in UDMF (for example all flag properties are bool), and the editor supports it. The true and false keywords were only added in the 1.1 specs, though, so I assume before that they used the strings "true" and "false". DECORATE, however, has indeed only int and float, so I guess it's from there. Anyways, pushed a commit that changes the behavior and also adds support for int8, int16, uint, uint8, and uint16 (they all get mapped to UniversalType.Integer).
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 »

Hey, so I made a test merged version of an OpenGL GZDB-BF fork (by dp&Talon, from here)

Can someone test these and tell me if there are any issues?
x86: https://www.mediafire.com/file/zlecwnz2 ... 09.7z/file
x64: https://www.mediafire.com/file/vv7d5qan ... 64.7z/file

Advising to unpack this in a separate directory compared to regular GZDB, to avoid breaking existing stable editor.

Important things to check if possible: old hardware, Linux/Mac(WINE), GZDoom feature-intensive maps (models, dynlights, 3d floors)
Minimal OpenGL version is 3.2.

Known issues in this build (will be updated):
  • (fixed) skybox sides are flipped, IIRC north and south parts
  • not all OpenGL objects are unloaded according to dp; possible/expected to leak memory during prolonged usage
  • render distance fog is a bit broken
  • (fixed) high quality rendering is not quite different from low-quality rendering
  • antialiasing does not work
  • (fixed?) performance is noticeably lower
  • (fixed) 2D mode has transparency issues (lines, things out of things mode)
  • anisotropic filtering is off
  • texture loading (resource reloading) is slow (?)
  • does not work on WINE (not a priority though)
  • (fixed) does not work on AMD
    Spoiler:
I want to fix these and occasionally merge things into the main build, thus replacing DirectX with OpenGL.
Among major improvements here would be better Linux support (through WINE, as DirectX version used to work for 1-2 people out of 10) and support for user GLDEFS shaders from GZDoom.

There may be a chance of renaming the builder e.g. to GZDoomBuilderGL/GLDoomBuilder to avoid automatic breaking update from DX to OGL (I think current GZDB allows computers older than OGL 3.2).
This is actually based on feedback.
(Separately, does anyone know which OpenGL version is required by SLADE?)
Last edited by ZZYZX on Mon Dec 16, 2019 12:25 am, edited 10 times in total.
boris
Posts: 739
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

Tried it out, Windows 10 Home 64bit, Geforce GTX 970.

Is that a debug build? Performance is pretty atrocious (much worse than DirectX debug builds) in classic modes, visual mode is equally bad in this OpenGL build and DirectX release build. Resource background loading times also seem to be longer.
high quality rendering is not quite different from low-quality rendering
It definitely looks different than the normal build. Lines don't seem to have antialiasing enabled. Until you highlight them. Then they'll be "thicker" until you highlight another line.

Other things I noticed:
  • Things seem to have a lower alpha value outside of things mode, making them more transparent
  • Anisotropic filtering doesn't seem to be enabled in visual mode
There may be a chance of renaming the builder e.g. to GZDoomBuilderGL/GLDoomBuilder to avoid automatic breaking update from DX to OGL (I think current GZDB allows computers older than OGL 3.2).
This is actually based on feedback.
You mean finally calling it something else than GZDB-BF? I'm all for that!
Locked

Return to “Abandoned/Dead Projects”