ZDoom

Currently I'm working on a ZScript menu that has a fade out/fade in transition when created. It works just fine, but I feel like there's a lot of gross code that runs continuously in the Tick() function in order to control the dim amount each step of the fade transition. I am not completely sure if this is tantamount to bad practice or if you're even able to do this, but is it possible to call something akin to wait() or delay() in a function? I was thinking of making a for loop that sets the dim amount to the iterator in a for loop but it would obviously dim the screen immediately without a call to a delay function.

If not, is there some sort of method you more experienced programmers would use in order to make a maintainable and clean way of handling something like this entirely within the Tick() function without going overboard with something resembling a rudimentary state machine?

I'd probably just transfer some of the variables from function-scope to object-scope, then separate the logic into another or several other functions, depending on what all it entails. Hell, depending on how you have everything set-up, object-scope variables might not be necessary.

It's probably just gonna have to be that way huh? That's okay, it doesn't look too too bad. I can't help but to feel like this current method is sub-optimal but I suppose it's what needs to be done.

I can assure you, this is how actual programming works - stuff like Delay() is pretty well within the realms of scripting languages that don't deal with the inner workings of how a program works.

Internally, implementations of delay() et.al. are just sugarcoating around something that really works like ZDoom's Tick(). But they have to do all the heavy lifting of preserving the state internally so not surprisingly they may end up far more costly because they may have to preserve a lot more state than is actually required.

You can just have a look at the ACS VM to see how it works. When a delay instruction (search for PCD_DELAY) is hit it will set the script to a 'delayed' state and then end execution. Then, when the next Tick() call arrives it will check the delayed script's state, and if the counter has run down, restore it and continue from the position where it left off.

Oh I see now. Thanks a lot for the insight, that's pretty wacky. It makes a lot more sense seeing it described in an ACS context and I understand that that's just not how things work, like I can't magically make a ticker out of a function of my choosing.

I suppose if I really think about it, it doesn't make sense if that were possible the way I described it unless (speaking strictly outside of ZScript right now of course) you dedicated a single thread to each object and wait()'d them? I really have no clue how clocks and objects in gamedev work. Like, I got the basic idea, but when it comes to designing a program around it, I tend to not realize my limitations until I ask.