Splashscreen / Input thread

[Kangz]

I'd be nice to have a splash screen while the game starts (6 sec on my SSD with hot OS cache). Also we will want inputs to be processed in parallel of the game to reduce latency and enable neat tricks. The two are linked since with SDL all the windowing function must be done in the main thread, including getting new events.

An idea of architecture it to have the game create a new "main2" thread as soon as it start. While the main2 thread does the actual initialization, the main thread shows a splash screen. When the game is ready to show the first frame, the splash screen is removed and the game window shown. In order to be able to use the SDL window functions from other threads, main can receive messages that contain callbacks to be executed. Basically main wakes up on every new message or each 10ms and process messages and SDL events (SDL events are put in a queue to be consumed by Com_Frame).

Kangz has a proof of concept implementation of the splash screen only.

• Mentor: Kangz
• Knowledge: multithreading, SDL, event loop
• Difficulty: 6

Mentored projects on the Unv wiki

[Veyrdite]

The startup is about the same for me with a standard HDD. Does anyone have a situation where their startup is >=10 secs?

Splashscreen

IMHO splashes are horrible and I turn them off for as many things as I can 💃
If our startup becomes any slower then this might be advisable.

A "launcher" (with resolution + mod options) could perhaps do more than a splash screen? That could be useful in the future for 'organising pk3s' and other shenanigans that require a game restart with our current methods, but would require interfacing with a UI toolkit.

Input thread

(I'm assuming this is not necessary when we introduce a splash screen)
Disadvantages:

• increase input latency
• requires an arbitrarily slowed down (eg 10ms) IPC loop

Advantages:

• keeps track of keypresses if the game hangs
• ?

[Kangz]

I don't like splashscreens either but a 10 second startup is too long (users will double click again or think the program crashed). As for input latency, we can have the input thread wake up as soon as the input is available so it will barely increase latency. Plus we are thinking of making a renderer hack to forward the latest mouse movement and change the camera accordingly.

Also the input thread will avoid popups saying "it seems this program is hang, do you want to kill it?"

[Veyrdite]

To be clear: I'm getting about the same 6 seconds. I don't think many other people are slower, but I don't know. I have not tested on Windows for a while, for example.

I'm still suspicious of the overhead needed to accomplish this. At 60hz (vsync'd) we have around 1000msec/60fps=16.7 msecs of latency maximum, and this already annoys many players. What do you think the total latency increase would be like (ballpark figure?) and would it be stable, or go 'in' and 'out' of phase depending on how the loops in different threads are interacting?

[Kangz]

1-2 msec max compared to now.

[mwestphal]

here is a difff to include a splashscreen.
It demonstrate my differents tries to it, with one actually working.
The splashscreen is in a header, encodded in bmp format.
The unvanquished is shown only after the init is finished, using an extern, wich is not really clean.
http://pastebin.com/BkzizX31
also on my fork.

[mwestphal]

@Kangz Could you give more details about the way the input thread should work ?

[Kangz]

https://gist.github.com/Kangz/69c63d045191e885dcda it is a bit rough, tell me if you need more details.

[ghost]

There is currently a launcher, which is also a splash screen. I believe this would be enough to close this ticket.

[illwieckz]

We don't need splash screen anymore indeed but we still need to have an input thread to prevent the window manager to tell the user “The application stopped responding” with a “Terminate” button while everything is fine and the user will just close the game believing it crashed while it is fine it's just computing stuff…

[ghost]

Do this actually happen when starting game through the updated?

[illwieckz]

It always happen whatever the way it is started.

The only thing that is currently preventing the window manager to catch the freeze is when the startup is effectively quick, like using a fast computer, a fast file system, and having GLSL shaders already compiled. Loading nexe from dpk may also freeze the window (using DLL may then hides the problem). For GLSL shader compilation we can delay most of them at map load (where a meaningful message can be told to user to tell him to wait), but that's not fixing the underlying issue of freezing window.

[illwieckz]

We may still want to close this issue and open another one because so many things have changed. Now, the freeze happens after the first frame is displayed, we may even display an engine logo before the freeze can happen in the same window that will be used (without the need for a splash screen).

[necessarily-equal]

I don't think this has been resolved.

There are two issues here,

1. Having a splash screen
2. Having a separate thread that handles input

I think I remember reading illwieckz talk about how Dæmon should show an "Unvanquished Development" logo on start :)

[illwieckz]

I think I remember reading illwieckz talk about how Dæmon should show an "Unvanquished Development" logo on start :)

Yes, I was just too lazy to look for the related issue to mention it:

• Display a Dæmon logo at startup, before everything else can be displayed and before the game can do anything DaemonEngine/Daemon#384

I already took care of clearing the window the sooner as possible:

• Fill window with dark grey at creation time, fix #373 DaemonEngine/Daemon#374

But the need for an input thread is still there, definitely.

[illwieckz]

See also this PR to delay compilation of GLSL shaders that are not needed by the main menu:

• set r_lazyShaders to 1 for faster startup and prevent errors on first launch before being able to switch preset DaemonEngine/Daemon#519

And also this PR to tell the user at map load (when it's easy to display things) the engine is compiling delayed GLSL shaders:

• ui: re-implement the map loading messages #1470

All those PR are working around the “window freezing without feedback at startup” issue, though they fix others issues that's why they were implemented (primary purpose of those PR was not to work around the current issue).

[ghost]

I would be in favor to close this report and open one more focused on the input thread, as imo the splashscreen thing is fixed.
Also, just to be sure, can we have a list of systems (kernel + DE, and if possible the complete name of the OS instead of just kernel name+version) where «the window manager [...] tell the user “The application stopped responding”» ? Because to me, this looks like a windows-only issue, and while it's not a negligible issue, adding this information will help fixing the issue.

[illwieckz]

Because to me, this looks like a windows-only issue, and while it's not a negligible issue, adding this information will help fixing the issue.

I get it with Ubuntu and GNOME every time.