Page 89 of 97

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Fri Dec 06, 2019 6:35 pm
by Kappes Buur
Xmas came early :D
thank you boris

seadon's greetings to all

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Fri Dec 06, 2019 8:06 pm
by Nash
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

PostPosted: Fri Dec 06, 2019 11:45 pm
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?

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Dec 07, 2019 8:25 am
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Dec 08, 2019 10:00 am
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Dec 08, 2019 12:38 pm
by AFADoomer
Fantastic! Everything appears to be working as expected on my end as well... Thanks very much!

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Mon Dec 09, 2019 12:06 am
by Kappes Buur
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

PostPosted: Mon Dec 09, 2019 3:55 am
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Mon Dec 09, 2019 4:09 am
by SanyaWaffles
That's going to be an incredibly useful function. I really look forward to it being finished.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Dec 14, 2019 6:07 pm
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

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Dec 15, 2019 4:53 am
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Dec 15, 2019 12:15 pm
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 ;)

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Dec 15, 2019 1:38 pm
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).

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Dec 15, 2019 4:43 pm
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?)

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Dec 15, 2019 5:55 pm
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!