search

stella-emu / stella

A multi-platform Atari 2600 Emulator
https://stella-emu.github.io
GNU General Public License v2.0
618 stars 112 forks source link

Request: Debug overlay #593

Open andrew-davie opened 4 years ago

andrew-davie commented 4 years ago

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.

thrust26 commented 4 years ago

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.

andrew-davie commented 4 years ago

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!

thrust26 commented 4 years ago

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.

sa666666 commented 4 years ago

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.

thrust26 commented 4 years ago

Maybe it is time to check how complicated using multiple windows would be. That would ease development and offer some new possibilities.

andrew-davie commented 4 years ago

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 notifications@github.com 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.

thrust26 commented 3 years ago

@sa666666 So, how would we handle multiple windows?

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.

sa666666 commented 3 years ago

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.

thrust26 commented 3 years ago

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?

sa666666 commented 3 years ago

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.

sa666666 commented 3 years ago

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?).

thrust26 commented 3 years ago

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?

thrust26 commented 3 years ago

The optimal goal would be something like this:

Implementation thoughts: