stella
stella copied to clipboard
stella-emu
Request: Debug overlay
With Command-L (MacOS) I get the text overlay giving me TV format, frame rate., etc. It would be really nice to allow configuration of other things to display here.
For example, if I wanted to watch a particular variable/memory location.
Would be nice in the debugger to be able to go something like "watch.word var23". and from then on as an overlay I see the value of that variable as a word or "watch var23" as a byte maybe watch bank:address[16] to watch a 16-byte array at address in the given bank Perhaps have a text file you can type your watches into so you don't need to redo them all every-run. watch "file.txt" would load the watches from the file.txt
I just think this would be really handy and very powerful for debugging. Just thought I'd ask, see if any others like the idea.
It mirrors what I used to do back in the '80s - setup a realtime display of variable/location values. Can be extremely useful to see what's going on.
The current overlay is quite a hack, because the framework is not well prepared for such things. I suppose we have to design something more general.
Also I suppose watching one value might not be enough. So we would need something a bit more flexible.
Finally we should check what is not already covered by the debugger and if it would make more sense to add it there.
I had intended more than one value. That's why I Included the option for a file to specify the values to watch. As to adding into the debugger -- no, this is not what I am requesting. The debugger window is not visible when the game is running. I want a watch on variables in real time as the game is running. This is not a debugger option/request!
I understand, but maybe it would be more useful to add an option which allows to keep the debugger active. So you would be able to play the game inside the debugger.
Another option is to open another window which contains whatever we want to show. SDL allows multiple windows to be open, so it's at least a possibility. But TBH, it's easiest to add it to an extended overlay on the current window, depending on how much data we want to display, of course.
Maybe it is time to check how complicated using multiple windows would be. That would ease development and offer some new possibilities.
I also thought a separate window would be a way to do it. That is my preferred option, if possible! I can see lots of stuff, like a time-history graph of stuff, for example. A visible real-time memory heat map. All in the future, of course.
But being able to display variables, loaded from the Sym file (and bank could be included here easily enough if the source is written to output bank info) Being able to display arrays of stuff (say, one line showing a 16-byte array), with the variable name and address shown Then you could move on to neat stuff like putting breakpoints on change of value. That would be cool.
Anyway, just a simple value display for multiple addresses would be a great start.
On 17 Mar 2020, at 10:54 pm, Thomas Jentzsch [email protected] wrote:
Maybe it is time to check how complicated using multiple windows would be. That would ease development and offer some new possibilities.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/stella-emu/stella/issues/593#issuecomment-600054359, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD5JZC7EDB3SHW5TP5N3TCDRH5XHNANCNFSM4LNGPDLQ.
@sa666666 So, how would we handle multiple windows?
- would dialogs finally become real, modal windows? (maybe that would be a good first step?)
- should it be possible to have the launcher open in parallel with the emulation?
- how about emulation and debugger window?
- all three, plus overlays?
- ...
I doubt our current framework is even close to be prepared for more than one window/dialog at a time, but I do not understand the window handling good enough to really judge here. But for sure this would allow for a better UI.
SDL2 supports multiple windows, although I've never played with it too much. It basically uses a 'window ID' to identify the window.
The current code has all dialogs in a stack, which are rendered by walking the stack and calling render() on each one. I suppose we would still need a stack, but of windows instead??
There's also the issue of event handling. Currently, events are sent to the top-most dialog, and there is no concept of windows moving behind one another. It's using the simple 'painters algorithm', essentially. I don't know how complicated it would become to do event handling on multiple 'top-level' windows.
This is a pretty major update, but I don't think it's impossible to do. One concern is on systems that don't support multiple windows (R77, for example). If we add multiple windows, we still need to support the current functionality in such cases.
Couldn't we do multiple stacks and event handlers? The OS should know which stack (if any) is active (top most window active) and then only the event handler of the active stack takes care. Also the OS should take care of windows moving behind one another.
No?
As for R77 (and user preferences), we could close inactive stacks. The problem remains, that each dialog of a stack should be a window. Hm... Would it help that the order is fixed?
Yes, the OS will take care of some of it. We would need to experiment, of course.
As for R77, there is no concept of a window at all. You get a framebuffer to draw pixels into, and that's it. And a windowing environment can't be added to it, since it would require an X server to be running, and we've already determined that it would slow down the graphics too much. Not to mention the amount of work involved with integrating an ARM-based X server into the R77 codebase.
Honestly, I think having the debugger (and related stuff) be in a separate window is a good compromise. R77 and most other similar systems won't have debugger support enabled anyway, so it takes care of two problems at once.
In the end, we need to sit down and decide how much 'windowing' we really want? Does every dialog go to a new window? Some of them can't, since they're meant to be overlays and not drawn separately. Basically, the UI in Stella was designed for drawing everything into a single framebuffer, so introducing windows is quite a change. And not just in the code, but also in the design itself (as above, what goes into a new window, and what stays in the current one, etc?).
In the end, we need to sit down and decide how much 'windowing' we really want? Does every dialog go to a new window?
Yes, that should be the goal. For the R77 we might have to find a simple alternative (pseudo windows, like today). IMO we shouldn't limit the mainline just because of R77.
Some of them can't, since they're meant to be overlays and not drawn separately.
Overlays are not dialogs. :smile: They are another window stack which is always (displayed) on top of the other stacks.
...introducing windows is quite a change. And not just in the code, but also in the design itself (as above, what goes into a new window, and what stays in the current one, etc?).
Definitely! And probably we shouldn't do that as a big bang, but step by step. Where we also can learn from our mistakes and failed ideas. But where to start best?
The optimal goal would be something like this:
- launcher, emulator and debugger get their own window (Multiple Top-level Interface (MTI)), the OS handles which one is active
- each of them gets its own (or one common?) dialog stack, with each dialog becoming a modal (OS again) window
- also each of them gets its own (or one common?) overlay window list, overlays are non-modal and always on top (OS)
- messages will be overlays too
- the launcher should allow starting a new game any time (to define: what if e.g. the emulator has an open dialog? See common dialog stack)
- while the debugger has focus, the emulator window should follow
- while the emulator has focus, the debugger should follow (problem: update frequency, speed)
- the user should be able to define if he/she wants a MTI or the current SDI interface.
- (complex) widgets should be reusable for overlays. This way each element of the debugger could become its own overlay if the user wants too. Same for options (per tab). I know this would require a lot of rework, but it would prevent that we have to duplicate code for overlays. Anyway, this is something for maybe (much) later.
Implementation thoughts:
- each window will have its own framebuffer
- launcher, emulator and debugger:
- one common event handler?
- separate event handlers?
- maybe only one, common dialog stack? So all three top level windows are blocked when a modal dialog is open.
- I am sure there are many more details to think about...