GZDoomBuilder-Bugfix, a maintenance fork of GZDB
- Kappes Buur
-
- Posts: 4120
- 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
Xmas came early
thank you boris
seadon's greetings to all
thank you boris
seadon's greetings to all
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Hey boris, just wanted to drop you a THANK YOU for maintaining the program. :) Good work across the board!
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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?
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?
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Thanks for the kind words.
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.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?
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Fantastic! Everything appears to be working as expected on my end as well... Thanks very much!
- Kappes Buur
-
- Posts: 4120
- 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
In the video, how does one go to highlighting the edges, as shown from 1:03 to 1:07?
Spoiler:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
It looks a bit different now: https://streamable.com/2dyimKappes Buur wrote:In the video, how does one go to highlighting the edges, as shown from 1:03 to 1:07?
Spoiler:
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.
-
- 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
That's going to be an incredibly useful function. I really look forward to it being finished.
- 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
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
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
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I wasn't even aware that interaction is possible at all 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.
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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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
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
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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).
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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):
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?)
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:
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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
Other things I noticed:
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.
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.high quality rendering is not quite different from low-quality rendering
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
You mean finally calling it something else than GZDB-BF? I'm all for that!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.