7 | | The debugger should be able to pause execution. That means the thread running scripts will be paused inside its JS API calls, and the simulation will be in an inconsistent state. We could perhaps allow the engine to keep running (by using a reentrant game loop, or splitting the simulation into a secondary thread), but we'd need to be very careful since the engine isn't currently designed to do that. It might be better to implement the debugger as part of Atlas (which runs in its own independent thread), so it can communicate with an entirely paused engine, and also so it can use wxWidgets for the UI. |
| 7 | The debugger should be able to pause execution. That means the thread running scripts will be paused inside its JS API calls, and the simulation will be in an inconsistent state. ~~We could perhaps allow the engine to keep running (by using a reentrant game loop, or splitting the simulation into a secondary thread), but we'd need to be very careful since the engine isn't currently designed to do that. It might be better to implement the debugger as part of Atlas (which runs in its own independent thread), so it can communicate with an entirely paused engine, and also so it can use wxWidgets for the UI.~~ |