Stella 6.0 released

[snes2600]

Great to hear! What a tricky mess to sort out. :lol:

I think @stephena proposed to make changes to the Stella emucore (32-bit framebuffer alignment) if the test worked. Then it'll all show up on buildbot with the corrections. And we can be happy again until another (libretro) problem comes along.

[Shannon]

ok.  Sounds good.  I guess we wait now until stephana weight in.  

 

[+stephena]

3 hours ago, snes2600 said:

Great to hear! What a tricky mess to sort out.

I think @stephena proposed to make changes to the Stella emucore (32-bit framebuffer alignment) if the test worked. Then it'll all show up on buildbot with the corrections. And we can be happy again until another (libretro) problem comes along.

You mentioned that your fix may potentially cause a slowdown.  Can you point to the specific code that would cause this?  I want to see (a) how you did it, and (b) if integrating it at a lower level will cause slowdowns too.  I guess my main question is, where are your changes??

 

Also, going forward, I really need to set up an Android VM or something.  Can anyone point me to a good tutorial for that?  Some of these bugs are really hard to diagnose without seeing the error myself, and being able to test fixes directly.

[snes2600]

https://github.com/snes2600/stella/commit/0c43b1daea4c818a290ff6be7572f4349bbfe03e

I created a temporary framebuffer which is 32-bit aligned. For every getVideoBuffer() call, it does a lazy memcpy loop from (stella fb) to (temp fb) which is passed to libretro frontend. It's a small hit which most people won't notice I bet, compared to this one



https://github.com/stella-emu/stella/blob/master/src/libretro/StellaLIBRETRO.cxx#L153

That line would create a bigger slowdown I'd expect (128 poke calls). Which is probably for achievements. A necessary slowdown. And not worth exposing Stella ram from const to writable.



https://github.com/stella-emu/stella/blob/master/src/common/tv_filters/AtariNTSC.cxx

If you make the emucore aligned, you'll run into some fun problems with the ntsc files. Because the whole code I think expects 565 out pitch? Seems easier to just force the conversion in the libretro side.



https://www.android-x86.org/releases -- Android-x86 Lineage OS 14.0

I could not reproduce the pitch bug on this Android VM. Because I (think) real ARM hardware uses OpenGL ES which I've heard does funny stuff with texture caching.

1) But I used VMWare Player. Created a 10 GB HDD (SCSI). 2 CPUs. 2 GB RAM. Turned on graphics acceleration.
2) Booted cdrom. Created logical partition. Let installer use Ext4. Grub yes.
3) On bootup, use cmdline. 'e' twice. Add vga=999 nomodeset xforcevesa. 'b' for boot. Select manual resolution.
4) Wait forever for 1st time install. Afterwards it'll auto-detect your NAT and you should be online connected.
5) To root device, go to settings:tablet:build number. Keep tapping it lots of times.

Tried other Android images but couldn't get internet or past the boot stage.

[snes2600]

Also wanted to bring this up for discussion instead of github.


https://github.com/libretro/libretro-common/blob/master/vfs/vfs_implementation.c#L1038

int retro_vfs_mkdir_impl(const char *dir)


I didn't know this existed but it looks useful. Because you can create Stella folders similar to standalone.


Examples on how to get libretro system, save directories.
https://github.com/libretro/Genesis-Plus-GX/blob/master/libretro/libretro.c#L2614
https://github.com/libretro/Genesis-Plus-GX/blob/master/libretro/libretro.c#L2621


/Stella/nvram
/Stella/stella.pro
/Stella/stella.pal


Converting the save files to use libretro save api (memory streams) is not happening anytime soon.

Note that Atari Lynx Handy libretro core currently writes eeprom saves to folder atm; using same format and name as standalone. So same can be done for Stella.

[+stephena]

Thanks for the work on this; I will try to find some time soon to integrate the changes.  Regarding 32-bit alignment; the old TV effects code did do it that way.  This non-alignment is a new thing, so we can probably rework it.  Even if the final column or two is all black pixels, you'd never know the difference.  But at least it would be efficient.

 

Also wanted to improve on the directory structuring, so seeing how another core does it will be very helpful.

[Keatah]

16 minutes ago, stephena said:

Regarding 32-bit alignment; the old TV effects code did do it that way.  This non-alignment is a new thing, so we can probably rework it.  Even if the final column or two is all black pixels, you'd never know the difference.  But at least it would be efficient.

 

Does that mean the rightmost column of pixels would be missing from the final output image? Or am I totally misunderstanding what's going on here?

[+stephena]

3 minutes ago, Keatah said:

 

Does that mean the rightmost column of pixels would be missing from the final output image? Or am I totally misunderstanding what's going on here?

No, we could add an extra column or two to make it be a multiple of 4, then make those columns blank.  That way, we get the efficiency and correctness, and you would never notice the difference.

[+stephena]

I've created an issue for this on Github: https://github.com/stella-emu/stella/issues/504

[+stephena]

On 7/24/2019 at 4:13 PM, snes2600 said:

Great to hear! What a tricky mess to sort out.

I think @stephena proposed to make changes to the Stella emucore (32-bit framebuffer alignment) if the test worked. Then it'll all show up on buildbot with the corrections. And we can be happy again until another (libretro) problem comes along.

Seeing that you have a setup where you're able to test this stuff, can you try the following:

• Start with current code, no extra modifications
• Edit 'src/common/tv_filters/AtariNTSC.hxx': on line 111 change the "+ 5" at the end of the line to "+ 8"
• Re-test and see if that changes anything

If that fixes the problem, then I can rearrange some code to make this permanent.  I don't want to make any invasive changes here until we know for sure that this is the part of the code causing problems.

[Thomas Jentzsch]

5 hours ago, stephena said:

• Edit 'src/common/tv_filters/AtariNTSC.hxx': on line 111 change the "+ 5" at the end of the line to "+ 8"

Wouldn't that require to change "-5" in line 104 into "-8" too?

[+stephena]

There may be other changes required.  For now I just want to see if that change has any effect at all, since I'm unable to duplicate the problem on my systems.  At least it would point us in the direction to work on.

[+stephena]

For all future correspondence concerning the 'pitch' bug, please redirect it to https://github.com/stella-emu/stella/issues/504.  This thread is getting full of messages that are really specific to that particular issue.

[israelg]

I can confirm that the latest Stella core (nightly) works OK without artifacts on android (multi threaded rendering is disabled) 

[+stephena]

12 minutes ago, israelg said:

I can confirm that the latest Stella core (nightly) works OK without artifacts on android (multi threaded rendering is disabled) 

OK, good to hear that this is finally fixed.  Now we can move on to other issues ...

[israelg]

Which "other issues .." ?

[+stephena]

1 minute ago, israelg said:

Which "other issues .." ?

https://github.com/stella-emu/stella/issues  It never ends ?

[Shannon]

I'll add to the news regarding the 32-bit aligned saga..

 

I have confirmed that the PSC version is corrected.  I downloaded the latest build bot and the problem is corrected.  The frame rate on Galaga and Mappy, however does drop some.  The problem did not exist on the previous version. 

 

After some tinkering I discovered that turning on threaded video solves the framerate on those two games.  All other DPC games run just so fine.  So it is just those two games which probably push the DPC a little more than other games.  Threaded video seems to help enough to bring them up to speed.
 

This seems to pretty much confirm what stephena was saying in the above issue thread regarding more use of the ARM emulation.  So consider problem solved, no degredation,  This is about as good as it is going to get for PSC owners.

Thanks to all for your help and involvement!

[snes2600]

Two ideas came to mind for Libretro.

1) Create new CPU method that allows us to memcpy a new RAM block. Avoiding the 128 pokes that creates some slowdown to support achievements. Although I doubt Mappy would drop to 53 fps because of it.

2) Create a libretro option to control framebuffer size: Full, Resize. Full will always create the 568x312 or something buffer. Resize will recreate lores 256x240 (ish) or hires 568.

This can greatly affect shader fps on potato graphic cards with non-blargg, as it's 256x256 vs 1024x1024 for glsl.


I might try pushing for both, to close performance "loopholes" on weaker systems like Core2. Or I suppose future generations of $5 RPI Zeroes.

[+Andrew Davie]

Thank you once again for stella.
I have one question/request - when debugging in standard theme I get green text on red background like the image. This is totally unreadable for me, even with the screen a few inches from my face. Very difficult anyway. But other than that, I like the theme colours. The "light" theme makes everything readable but is otherwise ugly as. Would it be possible to address the contrast in this red/green area and perhaps consider alternate colours? Yellow on blue is readable. White on red is probably readable. green on red... isn't!  Of course I may just be colourblind

 

[+stephena]

18 minutes ago, Andrew Davie said:

Thank you once again for stella.
I have one question/request - when debugging in standard theme I get green text on red background like the image. This is totally unreadable for me, even with the screen a few inches from my face. Very difficult anyway. But other than that, I like the theme colours. The "light" theme makes everything readable but is otherwise ugly as. Would it be possible to address the contrast in this red/green area and perhaps consider alternate colours? Yellow on blue is readable. White on red is probably readable. green on red... isn't!  Of course I may just be colourblind

Please create an issue on Github for this.  Thomas J. is our resident 'UI-looks' guy, and I'd like him to see this too.

 

https://github.com/stella-emu/stella/issues

[+Andrew Davie]

4 minutes ago, stephena said:

Please create an issue on Github for this.  Thomas J. is our resident 'UI-looks' guy, and I'd like him to see this too.

 

https://github.com/stella-emu/stella/issues

Done. Sorry, I wasn't aware of the proper place to put the request.

[+ZeroPage Homebrew]

I'm not sure if this is a bug or if it's intentional behaviour or if it's 'a Windows thing' in Stella 6.0.1 (Win10Pro). When I have Stella in full screen in one monitor and then click on another program running in a different monitor, Stella minimizes. It doesn't minimize when Stella is windowed, only when full screen.

 

This may not be a big deal to people with one monitor (it may actually be preferable) but when I'm capturing/streaming video and want to adjust the position or size of the captured full screen of Stella in my streaming software, Stella minimizes and I can't see what I'm adjusting for anymore.

Edited August 30, 2019 by ZeroPage Homebrew

[Keatah]

I like and prefer the behavior of Stella as it is now. Changing basic behaviors as such described starts to confuse or create discord. And that gives a bad rap to emulators. 

 

A compromise could be including options to change the behavior as long as the original long-standing behavior is available and defaulted to.

 

in other words no changes to OOTB operation.

Edited August 30, 2019 by Keatah

[+stephena]

It's not surprising that there might be 'strange' behaviour in multi-monitor setups.  I personally don't have such a system, and hence have never tested in this scenario.  Going forward, it seems that multi-monitor is becoming more common, so I guess we will have to look into that kind of setup.

 

I just created an issue for this: https://github.com/stella-emu/stella/issues/531.  No idea when we can get to it, but I agree that it's something that needs to be fixed.