Currently, if something happens that causes lag, the whole spring interface will become unresponsive, and the only way to deal with the situation is to kill the process in task manager.
Would it be somehow possible to separate the UI into an own thread, so that in such event the user can still control the interface, menues, pause, gamespeed etc, even when the simulation itself it lagged badly.
I tried to search for similar threads, apologies if this has already been suggested.
Separate UI from simulation
Moderator: Moderators
-
SirMaverick
- Posts: 834
- Joined: 19 May 2009, 21:10
Re: Separate UI from simulation
Generally yes.Jools wrote:Would it be somehow possible to separate the UI into an own thread, so that in such event the user can still control the interface, menues, pause, gamespeed etc, even when the simulation itself it lagged badly.
Afaik: Spring MT has own threads for GUI, but uses locks to access the simulation state. That means if the simulation lags bad it has to wait for the lock. You can prevent that by duplicating/caching the simulation state. Happy coding!
Re: Separate UI from simulation
yeah, as knorke said, spring-multithreaded is pretty much that.
if you want more... wait a decade or two, and we'll be there, maybe.
it has been discussed in multiple dev meetings. it is a lot of work, and introduces new, very hard to debug possible problems.
threaded simulation + desync -> :*(
if you want more... wait a decade or two, and we'll be there, maybe.
it has been discussed in multiple dev meetings. it is a lot of work, and introduces new, very hard to debug possible problems.
threaded simulation + desync -> :*(
Re: Separate UI from simulation
No, threads have absolutely nothing to do with this.
The solution is to do client side `prediction' of the UI.
So a unit would get a sim order queue, which is what it actually uses, but it would also have a client-side order queue, which is what is visible on the screen.
When the user gives a new order, the client-side order queue is updated immediately so that the user has immediate feedback, while the sim order queue has to wait for a roundtrip to the server before it gets to see the new order.
Same thing applies to menus / pause / gamespeed etc.: it needs client side `prediction' of the state the UI element will probably get after the roundtrip to the server.
To retroactively fit this into Spring is a lot of work, as nothing has been designed with this in mind.
The solution is to do client side `prediction' of the UI.
So a unit would get a sim order queue, which is what it actually uses, but it would also have a client-side order queue, which is what is visible on the screen.
When the user gives a new order, the client-side order queue is updated immediately so that the user has immediate feedback, while the sim order queue has to wait for a roundtrip to the server before it gets to see the new order.
Same thing applies to menus / pause / gamespeed etc.: it needs client side `prediction' of the state the UI element will probably get after the roundtrip to the server.
To retroactively fit this into Spring is a lot of work, as nothing has been designed with this in mind.
Re: Separate UI from simulation
@Tobi
I assume he suffers more of local cpu lag (FPS) and not network lag.
I assume he suffers more of local cpu lag (FPS) and not network lag.
Re: Separate UI from simulation
Yes, I certainly suffer mostly from CPU lag.
This happens for example when I'm joining a game mid-game and the simulation needs to catch up, but then there's something else on my computer that needs attention (like skype call etc...): in those cases it would be nice to be able to pause spring even though it's busy.
I also get CPU-lag when I experiment with my forest fires gadget, but that's my own fault for making the near-infinite loops :)
This happens for example when I'm joining a game mid-game and the simulation needs to catch up, but then there's something else on my computer that needs attention (like skype call etc...): in those cases it would be nice to be able to pause spring even though it's busy.
I also get CPU-lag when I experiment with my forest fires gadget, but that's my own fault for making the near-infinite loops :)
Re: Separate UI from simulation
Hmm, ok.
Then for sim UI things (giving orders, changing firestate/movestate, etc.) both (threading + prediction) would actually be needed, and for non-sim UI things the threading might be sufficient.
Then for sim UI things (giving orders, changing firestate/movestate, etc.) both (threading + prediction) would actually be needed, and for non-sim UI things the threading might be sufficient.