Stella Version 2.2 released

[+SpiceWare]

No biggie - it works

[vdub_bobby]

Okay, just went back in and...apparently I'm a moron. I was absolutely positive that I double-clicked on the GRPx/PFx things and could not change them no matter what. But it is working.

 

And thanks for the explanation of how the debugger works, and how the strobe buttons work. That makes sense.

 

I'm pretty sure that the ENAxx buttons don't work, though.

[Albert]

One thing I just noticed with Stella 2.2 while taking a bunch of screenshots: When you take a screenshot, it displays the,napshot Saved" box on the screen. Unfortunately, this lingers for 2-3 seconds and if you take another snapshot while that box is visible, it shows up in the screenshot. This makes it difficult to take several screenshots in a row, which can make it hard to "compose" shots. Would be great if Stella removed this message before saving the screenshot.

 

..Al

[+stephena]

One thing I just noticed with Stella 2.2 while taking a bunch of screenshots: When you take a screenshot, it displays the,napshot Saved" box on the screen. Unfortunately, this lingers for 2-3 seconds and if you take another snapshot while that box is visible, it shows up in the screenshot. This makes it difficult to take several screenshots in a row, which can make it hard to "compose" shots. Would be great if Stella removed this message before saving the screenshot.

 

..Al

This bug must have crept back in, since you reported it before 2.0, and it was fixed since then. I'll take a look.

[Albert]

One thing I just noticed with Stella 2.2 while taking a bunch of screenshots: When you take a screenshot, it displays the,napshot Saved" box on the screen. Unfortunately, this lingers for 2-3 seconds and if you take another snapshot while that box is visible, it shows up in the screenshot. This makes it difficult to take several screenshots in a row, which can make it hard to "compose" shots. Would be great if Stella removed this message before saving the screenshot.

 

..Al

This bug must have crept back in, since you reported it before 2.0, and it was fixed since then. I'll take a look.

Thanks, I appreciate it.

 

..Al

[+stephena]

One thing I just noticed with Stella 2.2 while taking a bunch of screenshots: When you take a screenshot, it displays the,napshot Saved" box on the screen. Unfortunately, this lingers for 2-3 seconds and if you take another snapshot while that box is visible, it shows up in the screenshot. This makes it difficult to take several screenshots in a row, which can make it hard to "compose" shots. Would be great if Stella removed this message before saving the screenshot.

 

..Al

This bug must have crept back in, since you reported it before 2.0, and it was fixed since then. I'll take a look.

Thanks, I appreciate it.

 

..Al

OK, this is fixed again, and will be included in the next release.

[+SpiceWare]

Any tricks to getting it to do screen shots under Linux? My iMac's in the shop so I compiled Stella on my Thinkpad, which runs Kubuntu.

 

When I first compiled it, the config flagged screenshots as not enabled. I installed PNG support and redid the config step and it flagged screenshots as enabled, but Stella say's no-go when I try to take one.

 

Stella also starts up quickly; but while I can see it, the interface is unresponsive for about 30 seconds.

Edited May 10, 2006 by SpiceWare

[+stephena]

Any tricks to getting it to do screen shots under Linux? My iMac's in the shop so I compiled Stella on my Thinkpad, which runs Kubuntu.

 

When I first compiled it, the config flagged screenshots as not enabled. I installed PNG support and redid the config step and it flagged screenshots as enabled, but Stella say's no-go when I try to take one.

It says snapshot support is enabled at the configure step? Do you see 'Snapshot' in the list of compiled options in Options->About (Tab key, click About button)? If not, then it doesn't actually included snapshot support after all. Also, exactly what message are you getting when trying to take a snapshot?

Stella also starts up quickly; but while I can see it, the interface is unresponsive for about 30 seconds.

If you're using OpenGL mode and don't have accelerated GL drivers, everything will be quite slow. Also, the first time it starts up, it scans all the ROMs and creates a cache file. If the ROMs are on a network drive, this can slow things down. As soon as you start Stella with a fresh/empty stellarc file, what does the interface look like. Do you see a dialog, but can't click on it? Or is there a 30 second delay before anything is drawn?

 

It's very strange, since I do all Stella development in Linux, so things usually work fine there.

[gameprogram]

Yeah I'm on Fedora here and haven't had any problems, and I messed with snapshots a lot yesterday. I have a Kubuntu in a VM and it isn't giving me that problem. Weird.

[+SpiceWare]

summary for ./configure

Summary:
  OpenGL rendering enabled
  Sound support enabled
  Developer/debugger support enabled
  Snapshot support enabled
  Joystick support enabled
  Cheatcode support enabled
  Static binary disabled
  Profiling disabled

I ran ./configure once before I added the PNG libraries and had disabled for Snapshot support.

 

The ABOUT shows OpenGL, Sound, Joystick, Snapshot, Debugger and Cheats

 

When I hit F12 the status box shows "Snapshots unsupported."

 

Video's set to Software mode. When set to OpenGL the emulation runs slow.

[+stephena]

summary for ./configure

Summary:
  OpenGL rendering enabled
  Sound support enabled
  Developer/debugger support enabled
  Snapshot support enabled
  Joystick support enabled
  Cheatcode support enabled
  Static binary disabled
  Profiling disabled

I ran ./configure once before I added the PNG libraries and had disabled for Snapshot support.

 

The ABOUT shows OpenGL, Sound, Joystick, Snapshot, Debugger and Cheats

 

When I hit F12 the status box shows "Snapshots unsupported."

Try doing a 'make distclean', then do configure again and recompile. It could be that some files were compiled without the SNAPSHOT_SUPPORT #define enabled, and some were. When running a new configure, one should always do a make distclean first.

Video's set to Software mode. When set to OpenGL the emulation runs slow.

So the slowdown you're seeing is in software mode as well, or only in OpenGL? If software mode too, what type of hardware is this running on (video card, CPU, etc), and what window sizes are you using?

[+SpiceWare]

make distclean fixed the snapshot problem

 

The start-up slowdown occurs no matter what video mode I use. I've timed it and the timing of the events is:

 

0 - start Stella

1 - list of games shows up

35 - GUI becomes responsive

 

After the 35 it works fine.

 

I don't recall the hardware - I'll have to reboot under 98 as I don't know where to find the hardware under Linux.

[+SpiceWare]

Thinkpad T22 - model 2647-6CU

 

Video = S3 Savage/IX @ 1400x1050 8MB video RAM

900 MHz CPU Intel chip

384 MB RAM

Edited May 12, 2006 by SpiceWare

[Thomas Jentzsch]

The S3 Savage is definitely a very slow GPU and the IX is the slowest variation of the Savage. Though I am not sure if that completey explains your problem. Might be a driver problem (e.g. direct rendering/DRI).

[brpocock]

Okay, just went back in and...apparently I'm a moron. I was absolutely positive that I double-clicked on the GRPx/PFx things and could not change them no matter what. But it is working.

 

I had the same reaction the first time ... and then realized that the COLUPF was black, ergo, the "selected" pixels and the "empty" pixels were all the same colour regardless. Perhaps the same PEBCAK hit us both?

 

Beautiful debugger, btw, guys. The only issue I've got with it ... and it's nitpicky at best ... is that I don't see how to remove a breakpoint set on a scanline by right-clicking. I don't think I could have gotten my tile draw working without the Stella debugger...

[+stephena]

Okay, just went back in and...apparently I'm a moron. I was absolutely positive that I double-clicked on the GRPx/PFx things and could not change them no matter what. But it is working.

 

I had the same reaction the first time ... and then realized that the COLUPF was black, ergo, the "selected" pixels and the "empty" pixels were all the same colour regardless. Perhaps the same PEBCAK hit us both?

This will be addressed in the next version of the debugger manual, which is getting a huge overhaul as we speak.

Beautiful debugger, btw, guys. The only issue I've got with it ... and it's nitpicky at best ... is that I don't see how to remove a breakpoint set on a scanline by right-clicking. I don't think I could have gotten my tile draw working without the Stella debugger...

Right now, the only way to do it is from the commandline. For the next release, we'll have a more 'point&click' way of turning breakpoints on and off, and not actually require using the commandline at all.

[vdub_bobby]

This will be addressed in the next version of the debugger manual, which is getting a huge overhaul as we speak.

...

Right now, the only way to do it is from the commandline. For the next release, we'll have a more 'point&click' way of turning breakpoints on and off, and not actually require using the commandline at all.

A feature request for the debugger: hotkeys for the scanline button and the frame button.

[brpocock]

A feature request for the debugger: hotkeys for the scanline button and the frame button.

 

While we're at it... "breakpoint at (pixel/cpu cycle per scanline)" would be icing. (Having spent the past two days making sure PF2 updates and HMOVE's happen at Just The Right Cycle...)

[+SpiceWare]

Will the debugger work OK on the new MacBooks at 1280x800 or a MacBook Pro at 1440x900?

[+stephena]

This will be addressed in the next version of the debugger manual, which is getting a huge overhaul as we speak.

...

Right now, the only way to do it is from the commandline. For the next release, we'll have a more 'point&click' way of turning breakpoints on and off, and not actually require using the commandline at all.

A feature request for the debugger: hotkeys for the scanline button and the frame button.

This has already been implemented, and was present since 2.0:

 

Alt l - advance scanline

Alt s - step instruction

Alt t - trace instruction

Alt f - advance frame

 

The manual (even in its current incomplete form) is your friend

 

Edit: Oops, I just noticed a small bug. Stepping or tracing won't actually change the TIA image unless you're already in trace mode (have advanced by a scanline at least once already). This will be fixed.

Edited May 17, 2006 by stephena

[+stephena]

A feature request for the debugger: hotkeys for the scanline button and the frame button.

 

While we're at it... "breakpoint at (pixel/cpu cycle per scanline)" would be icing. (Having spent the past two days making sure PF2 updates and HMOVE's happen at Just The Right Cycle...)

Seems easy enough to add ...

[+stephena]

Will the debugger work OK on the new MacBooks at 1280x800 or a MacBook Pro at 1440x900?

If you refer to resolution, the debugger is currently a 1024x700 window, so it should be fine on both of these systems. Otherwise, there should be no difference, as Stella generally doesn't know (or care) what OS you're running on.

[+SpiceWare]

yep - that's what I was referring too. My Thinkpad is on its last legs and I'm used to a 1440x1050 display. I'd love a 17" MacBook Pro, but only have budget for a MacBook and I'm not using credit cards anymore. I'm doing everything on AMEX as it has to be paid at the end of the month and my debt level is finally dropping.

[+stephena]

Again, I'd be very interested in having you beta-test some possible solutions to these problems. Stella for the GP2X runs on a 200MHz machine with no slowdowns (except for Pitfall2), so I know the codebase can be fast. In some cases, it's an apples to oranges comparison anyway, since z26 doesn't have 3x and 4x rendering modes, while Stella does. How do both compare on your PC when each one is run at 1x or 2x?

Most games indeed run just fine. Some (like my own game Superbug) run slow only at 3x or 4x. But one of the most egregious examples I have come across is the binary from Paul Slocum's music kit. It runs slow no matter what video settings I use, while in z26 it runs like a top.

I've added new rendering modes in what will be Stella 2.3 (due this month). The following are some results of CPU usage at 2x mode in both Stella 2.3 (internal code) and the latest version of z26 using the ROM you supplied (all numbers approximate):

 

Stella software rendering, dirty rectangle merging: 60% CPU

Stella software rendering, no rect merging (similar to z26): 24%

z26, no rect merging: 23%

 

And for comparison, Stella OpenGL mode: 3% !!!

 

Basically, dirty rect merging is fastest at lower resolutions, but is bad when a lot of stuff is changing onscreen (which is the case with the ROM you supplied). Non-dirty-rect merging is slower overall than dirty-rects, but is more consistent than dirty-rects (it takes a set amount of CPU over all ROM types). And OpenGL just creams all other modes

 

This is on an 800MHz Linux machine with Intel 950GMA hardware. In other words, fairly low-end stuff.

[mos6507]

I used Stella on OSX on a MacMini (PPC) over thanksgiving and I noticed that it would do this slow fadeout when changing modes. This makes using the debugger a PITA. Is this an OSX thing or a Stella thing?