On Thu, 21 Jul 2005, Glenn Saunders wrote:
>>>
> As for having *everything* on screen at once... that's
> a lot of stuff
> :)
> <<
>
> What you do is have scrollable zones.
>
> You have a ROM zone and a RAM zone and a CPU zone.
We have that: they're tabs (like a properties sheet). You can't see the
contents of all the tabs at once, though: you use the mouse or keyboard
shortcuts to get to the tab you want.
> ROM and RAM would be scrollable and the CPU zone would
> normally be always completely visible.
With the tabbed design, RAM doesn't need to be scrollable (well, one day,
when we support viewing the extra RAM in various carts).
> Then you'd have an array of buttons and/or a command
> line area. You'd also have to have some area to list
> out your break conditions.
The command line is one of the tabs. We also have a few "global" buttons to
the right of the tabs, which are always visible...
Actually, why am I sitting here describing it? We have prebuilt Windows and
Linux executables, so it'd be easier for you to look at it yourself :)
http://www.hardcoders.org/stella_nightly/
> The current executing line would be highlighted and
> you'd color code lines that have breakpoints on them.
Planned for the ROM tab. You'll also be able to switch between disassembly
and source listing, assuming you've got a .lst file from DASM.
> Then you'd have a lot of navigational shortcuts. Like
> being able to pop the ROM display to a particular
> label or address, page up/down, hotkeys, contextual
> menus.
We're working on adding context menus to the GUI core. Actually, the GUI
core is "borrowed" from the ScummVM emulator, so it's mostly a matter of
copying the code over and tweaking it to work with Stella's event model.
You don't have to worry about keyboard shortcuts: I hate using a mouse
at all, so there will definitely be a way to do *everything* without
it. (Well, OK, maybe not copy-and-paste, but everything else).
> Also, the entire debugger itself should be a resizable
> window so if you have huge screen real-estate or dual
> monitors you can move the window over and maximize it
> while the game is running. It shouldn't be tied to
> the emulator window itself, even if the emulator is
> running in fullscreen.
I doubt that'll happen any time soon. You're right, it's a very good idea,
but it'd take pretty much a total rewrite of the graphics rendering code
to accomplish. I doubt we'd undertake such a huge project until we had
support for every feature we plan to add. Keep in mind, there are only
two active developers (me and Steve Anthony), and we both have full-time
day jobs. Our goal is to get Stella 2.0 out the door by September. That
means we'll have to do a feature-freeze about a month from now, so we can
debug all the features we're adding now that are (probably) not perfect.
We want to release quality code that *works* (I have to push out enough
untested, unfinished spaghetti code at work)!
So we won't be starting anything *now* that will take more than a month
to finish... After 2.0 comes out, I'll be taking a break (maybe even
writing a 2600 game!), then we'll see what there is to see.
Of course, anyone else who wants to help is invited to the party, too :)
Even if you're not a C++ programmer, we could use help with documentation
and testing, particularly from people who know the 2600 really well
(and there are some god-like 2600 programmers on this list...)
--
B.
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://stella.biglist.com
