ZDoom

I've opened a PR for PostUITick. Submission thread [url=https://forum.zdoom.org/viewtopic.php?f=59&t=59739]here[/url].

The delay is completely gone when using it.

Unreal Engine 1 had something like that. It doesn't sound like a bad idea.

I can't help but wonder if adding a PostUITick would be too much.

UiTick happening right before P_Ticker is exactly why this 1 tic delay is a thing.

IIRC I put UiTick somewhere as much "outside" as possible so that it always gets called (even when game state is not valid at all, this was a gross hack to provide custom game state, which I think doesn't work now due to absence of RenderOverlay without playsim). I believe that's why it has no specific relation to playsim callback ordering.
It's only certain that UiTick happens before rendering, that's it :P
https://github.com/coelckers/gzdoom/blob/master/src/g_game.cpp#L1222

I also think that Events system needs some update according to the scopes, so that we can make purely ui or purely play event handlers (to be able to handle e.g. ThingDied in a ui scope without transferring values around).

Why not just make UiTick happen after the other tickers? That would remove the delay.

Many old things worked well: DOS, Windows XP, vanilla Doom... This doesn't make them right or future proof or bug free.

Yes, I'm not interested in so called time critical UI. But I'm fine if someone else will do it.
To me 'perfect tic-to-tic text rendering' is a nonsense and it only shows limitations somewhere else, i.e in other subsystems.

[quote="_mental_"]bla bla bla we don't need this[/quote]
It would make sense. It would. But there's one major thing that pretty much breaks all the logic above: this is worse than ACS. ACS allows perfect tic-to-tic text rendering so that you can do animation by replacing HudMessage with the same ID.
ACS is ...how many years old again? And it works well there.

(side note, also networking related: I don't understand why we need to transfer any messages from Play to UI like this, UI should scan events and draw everything, not messages directly originating from actors...)

[quote="Major Cooke"]I still think the function will be necessary. Otherwise, you're going to have people who will find it inconvenient like myself that they have to wait a tick in order to set up an appropriate system, and their time critical systems may not be all that flexible.[/quote]

I think you still do not comprehend the ramifications here.
Imagine a system where server and client are two separate machines. In such a setup you cannot do any UI-related action in zero time. It will always have to go over the network. Yes, that means an inevitable one-tic delay. It will also mean an additional one-tic delay for all current ACS HUD scripting that happens immediately because it completely ignores the mere possibility of a client being separated from the server by a network boundary. In such a setup the machine on which the script runs won't serve the display on which you intend to show the message and it is a technical impossibility to have that happen 'immediately'.

You can choose only two features from three: 'Doom', 'UI', 'time critical systems' ;)

Seriously, I cannot comprehend your complains. Here is the example.
Triple buffering is used quite often nowadays. It introduces one frame lag on top of required double buffering.
Many games are locked to 30 fps. And we are talking about in-game rendering, not only UI.
This, however, didn't prevent selling millions of copies per title for tens of millions units of so called next gen consoles.
For some reason developers and players are OK with it.

I still think the function will be necessary. Otherwise, you're going to have people who will find it inconvenient like myself that they have to wait a tick in order to set up an appropriate system, and their time critical systems may not be all that flexible.

Unless you're making each monster queue a message at once that shouldn't really matter. :P

By the way, I should probably remind Graf again that the ID and Layer parameters in the ZScript AttachMessage function declaration are missing.

[quote="Major Cooke"]I am already imagining how on heavier handed mods, these zscript hud messages would be a contributing factor to massive slowdowns on slaughtermaps in particular.[/quote]
:shock: why

Slaughtermaps lag because of constant sight checks and overcomplicated collision detection AFAIK. Let alone the fact that some monster logic is moved to ZScript, but that doesnt really contribute to lag, unless it's a 2004's PC.

Because this is also adding on a ~28ms delay, I think it would be better if there was an internal function. I am already imagining how on heavier handed mods, these zscript hud messages would be a contributing factor to massive slowdowns on slaughtermaps in particular.

Progress on my example message library is [url=https://github.com/OrdinaryMagician/icantbelieveitsnothudmsg_m]here[/url].

Due to the nature of the message queue, there's a minuscule 1 tic (28ms) delay between a message being added and it drawing on the screen, since the adding is done in UiTick(), which happens before all play tickers.

Would anything break if, in G_Ticker, E_UiTick was called after the other tickers, rather than before? This is the only way I can think of to get rid of the delay.