Need a animated loading screen

[STiX92]

NEED IT, cuz it´s cool and stuffs, and also it gives the users hope that the game is loading and havnt died.

[kevinortegren]

:+1:

[doqunbop]

Does not seem possible. Rendering to shared context seems to have no effect, switching contexts works, but causes the loading of map to fail to create the buffer objects, thus making the game unplayable. Seems that unless we move loading of assets to a parallel thread, loading screen can't be animated.

[kevinortegren]

Possible solution: Have Awesomium running on the main thread again and cut up the SurfaceTexture to smaller pieces and update them only when needed. This will most likely remove the lag spikes caused by awesomium as there will not be a full screen texture to upload to GPU every time. This will in turn make it possible to render a sequential loading screen.

[XenofoR]

At first glance this would not work. Each texture would need to be mapped to a unique webview in awesomium(Martins will have to correct me here if I am wrong). This would mean that to transfer data to them all, we would need a seperate java call for each view which in turn would give horrible performance.

[doqunbop]

Kevin is right in that moving the GUI processing to main thread would remove the lag spikes, but at the cost of making the lag permanent instead of spiking. That's not an option.

JavaScript calls are executed from the GUI thread, so it should not affect performance as much. Even if we move texture transfer to main thread, I believe JS calls and input could still be handled in a separate thread. The problem with multiple views is that they would most likely overlap each other, causing even more redundant texture transfers. We already have a full-screen damage/pain effect, for example. Also, by not having a full-screen GUI, we'd lose the biggest advantage of Awesomium we have right now - the ease of making and remaking the whole GUI and custom GUIs.

I plan to try to remove the lag spikes by implementing an extra texture for the GUI, which will be used to buffer the textures in background. That should remove the need for mutex locks on rendering and thus should remove the spikes. No guarantees though.

[kevinortegren]

I didn't know that the JS calls were the expensive part, sorry. The damage/pain effect could easily be added to the main rendering pipeline instead of awesomium if needed. Thoughts on the extra texture implementation mentioned by Martins: Use 2 Pixel Buffer Objects with two textures to transfer the pixel data asynchronously to the GPU. By ping-ponging the 2 PBOs there will be no need for glFenceSyncing(or mutex locks) to ensure texture read and write order, at the cost of rendering the GUI with one frame latency. This could probably be done on the main thread without any performance costs.

[kevinortegren]

Removing wontfix issues