ZScript Discussion

[Major Cooke]

That'll most likely also make ZZYZX's event handler system easier to deal with I assume?

[Graf Zahl]

It won't change anything about how VM objects are dealt with. It's just that the type system tended to crash a lot when trying to optimize some stuff because it could happen that some of its content got lost in the garbage collector, and this was causing all sorts of crashed because other parts were still referencing those deleted types.
But to allow the types to be static it was first necessary to do a lot of other stuff that played wild with this stuff.

[ZZYZX]

I'll never understand why rheit cooked a system that needs a fullblown enterprise-level garbage collector at all. Unless that was an experiment at creating a garbage collector.
Because I'm pretty sure python-like reference counter along with very simple circular reference checking task would work for Doom.

[Graf Zahl]

Randi always liked complicated solutions for complex problems. You'll find that trait in many parts of ZDoom, just have fun reading the old archiving code which I ditched last September as a good example for something that grew so complicated that it became a problem in itself.

The garbage collector as such is ok, but what's causing most of the problems is that it needs active intervention to work (that'd be the write barriers) and that it'd crash badly if that care is not taken. Unfortunately I have no good solution for that part and it's what's causing most of the crashes.

But the icing on the cake was to make lots of stuff GC'd objects that didn't need it, the reason for that being that as designed there was no possibility to have an object with a type descriptor that could be left out of the GC. This was the first thing I changed now, you can now release an object from the GC while still having type descriptors and other niceties.

A good analogy here is that the foundation for an entire city was built based on the specifications for one type of house, but as soon as other types were needed it turned out that the foundation did not meet the requirements.

[Rachael]

That happened in the renderer as well - a lot of parts which dpJudas revamped already in QZDoom.

I think the problem also has a lot to do with the age of the project - inevitably, when you keep piling stuff on you have to do cleanups eventually.

[Major Cooke]

Graf, will the draw functions work with the menu stuff at the same time? Or is it going to still be like the issue of the PowerDraw thing, or whatever it's called?

And... Will it be possible to finally add animations to the menu items? I.e. I've always wanted to try and make the menu fade out from one to another.

And another thing, will we ultimately be able to position things with some form of x and y coordinate?

(Can MenuSound be changed to a virtual as well?)

[Graf Zahl]

Patience, patience. I started simple to verify that the menu code could actually run scripted functions. The draw function has been exported already, so obviously I plan to use it. The same for the dynamic arrays. The menu code makes heavy use of them so they got to be working. You'll see more in the coming days.

[dpJudas]

That happened in the renderer as well - a lot of parts which dpJudas revamped already in QZDoom.

The renderer's problem was more that the code was never moved out of the original r_* files as its feature set grew. The renderer you see in QZDoom now is actually almost identical to ZDoom's, except I sorted the functions and variables into groups and then wrapped each group in a class. Then I made the variables and functions private in a group, unless they were referenced elsewhere. And last I took all the public variables and turned them into get/set functions to reveal all the places where hacks modified state not belonging to their group.

I think the problem also has a lot to do with the age of the project - inevitably, when you keep piling stuff on you have to do cleanups eventually.

Absolutely. But I think part of the problem has also been that even the initial version of Doom used a very classic 90's "let's pass information via global static variables" design. It made sense in the low memory days as you had to rely on so many static arrays as your way to manage memory. Unfortunately that approach doesn't scale very well.

[Graf Zahl]

Absolutely. But I think part of the problem has also been that even the initial version of Doom used a very classic 90's "let's pass information via global static variables" design. It made sense in the low memory days as you had to rely on so many static arrays as your way to manage memory. Unfortunately that approach doesn't scale very well.

In my opinion the main problem has been that instead of cleaning up while extending the feature set, all new features were just tacked on using the same approach. When I added per-tier texture offsets for walls I also tried to get some other line properties split up, like light level or wall color. It failed because I was unable to track down the dependencies of the global variables involved.
It's a bit funny, on the one hand ZDoom used some advanced concepts like the class hierarchy for its actor system but all the global cruft was nearly unchanged, if not made worse, when I started working on the code.

[Major Cooke]

Will menus always pause the game or will there be a bool to allow for game continuance? Seems like there would be, considering multiplayer and all.

[Graf Zahl]

The menu system itself will remain as it is, i.e. pause in single player and not pause in multiplayer. But in both cases it' block game input - just like it is now.
I am not trying to reinvent the wheel here, the goal is to export the code so that modders can write their own menus. And it will continue to require MENUDEF to set up relations etc.

[Major Cooke]

Understandable, but hopefully it'll have more flexibility like the ability to check cvars and/or display different menus based on what items a player has. Yes, I'm looking at D4D in particular. That upgrade menu is held together by silver duct tape aka a crapton of keyconf aliases which makes it rather hard to be flexible. This requires the 'wait' command in order to really work instead of keeping the game paused due to processing things.

[Graf Zahl]

Well, the point is that you can do do your own coding for some menus and/or their items so you should be able to solve that.

[Player701]

Last time I checked - was long ago, maybe things have changed since then? - MENUDEF could only be used to replace the existing menu setup, not to extend it. Therefore, it was impossible to play with two mods which defined their own menus and wanted them to be accessible from the main menu - one of them would always override the other. Has it indeed changed or is ZScript going to make it possible at last?

(edit) If you don't understand what I mean, compare to how UT2004 handles mutator options. Each mutator can get its own menu section on the mutator configuration tab, or even a separate openable window, complete with any GUI elements the developer would like to have. I was hoping ZDoom would eventually get a kind of a "Mod Menu" extendable via a ZScript API, which would allow a mod to add its subsection(s) there for easy configuration. What's important here is that different subsections wouldn't conflict with each other if there was more than one mod active.

[Major Cooke]

Okay, so just to clarify, is the Ticker function what we should use for time-like things?

Say for example I want to animate a menu option that, when highlighted, moves to the right over the span of 1-3 tics and back over when the cursor goes off. Also fades to a different color and blinks akin to Doomsday Engine. How would I do that?

(Also, holy shit Graf, your avatar... )