Do we have fast, accelerated, bug-free, supporting scaling SNES emulator ?

@LiveForItQuote:

Unfortunately you are wrong, WarpSnes also supports 16-bit mode, tested at fullscreen x2. This is the Os4Depot version that has white borders on the full screen.

@kas1e

Yes it's strange, it works perfectly on my Radeon 7000 on the ua1, my guess was also something with the screenmode parameters not matching.

What if you enable the #define EMU_DEBUG in the framework.cpp file?

Can you post the screenmode outputs from your machine in case it differs, however that shouldn't matter you should still get trash on the screen.

It's like we need some command to push the graphics to be rendered, which is not needed on the older hardware (atleast ua1, maybe others)

Yes i tested all 16-bit and 32-bit modes, and the RGB-format is converted by P96EncodeColor to the selected screenmode so it should always be correct.

The code for setting the black screen is in the amiga.cpp file, and it also works on the ua1, i tried setting purple as a test, and sure thing it changes.

Maybe possible to check the sdl-code to see what they do different?

Edit: Meanwhile i will look into the suggestions and feedback from @samo79 , thanks a lot. So i'll do some work on the gui-part.

@Olle

Same problem under Sam440, all still black in fullscreen...
But I could test it on AmigaOne aswell so to more or less match your dev machine

@Olle
Enabled debug in framework.cpp, and that what i have when run in fullscreen:


Not sure if it correct that firstly we have widnow/screen addresses ok, and then another time with 0x0 ?


But then, i tried to run this warpsness on my Pegasos2 (which had Radeon9250, so no modern RadeonHD or RadeonRx) : and it also gives me black screen ! But, this time i don't have window 0x0 and screen 0x0 at the end of debug output, but still black screen.

What is common between all my os4 machines, is that they all up2date and use latest graphics.library and co. Maybe your OS4 aren't up2date and this can be a difference between your and our setups ?

@Olle

Strange things can happen if you render into screens bitmap, instead of screens rastport bitmap.
perhaps this what is happening.

Or perhaps in ARGB or BGRA is pretty common problem when using composition, that Alpha channel is not set.

What I noticed in the code is that it does

Lock Bitmap
Get address of Video Mem
Unlock Bitmap

And then use the pointer acquired throughout lifetime of the program. Without locking again. I am not sure if this still works as expected. I think locking/unlocking should be around the function copying data to the video mem.

That's something I would try to change first (myselves no time till at least the weekend). Or try to paint when copying a small rectangle in "known colors" to see if there is any video output at all.

Code uses the Window's Rastport.

@TheMagicSN

If it's a user-private bitmap, then this should be fine.

Strange that according to Olle, it seems to work on his MicroA1... but it doesn't on Sam440/Pegasos2

@Capehill

It is the Window's Rastport's Bitmap as far as I can see (I only had a quick look at the code, didn't have time for more yet).

Still I think to check if anything is displayed at all by drawing a red rectangle in or whatever might be the easiest check if something principial goes wrong. If I have the time on weekend I will look in more detail at the code.

@samo79

I would not be suprised if Olle is still using OS4.1 (not FE) as he's been away for some years and that changes in OS4.1 FE makes this old code not function as expected anymore.

@smf

Right, then we need to see what version he still using

@Kas1e,
Yes, ignore the last 3 debug entries. :)

@TheMagicSN,
Good catch, i will check it. Yes it's the Rastports bitmap so that could be it. I will make a quick test-version and send to @samo79 to see if it makes any difference.

Edit, i see now that i allocate my own private bitmap for window-mode, but do the locking/unlocking to retrieve the P96_BMA_MEMORY pointer for screens, and only do this once.

Since @Capehill mentions it should work with private bitmap, this could indeed be the issue then.

@All,
The last thing i apparantly did at some point was to install a clean system, the backdrop picture reads "Amiga OS Final Edition 4.1", the workbench titlebar reads: "Amiga OS 4.1 - update 8".

It's from 2014, i believe i temporarily used an external powersupply because i purchased the final update for Amiga OS and wanted to have it installed to check all new features. ;)

I assume it's outdated? But i installed latest SDK, and when i tried to compile some stuff using std::string, i got a message i needed newer libs to run the application.

I tried to use the built-in "update software"-feature to install any outdated libraries, but nothing found.

I did however just check the amigaos.net website, and read on the wiki about drawing graphics, that we should now use graphics library instead of picasso96 which was preferred prior to 4.1

So, maybe i should revise the code and see if that solves the problem?

@Olle

Have to admit I still use P96 for such stuff myselves (even Heretic2 OS4 version does ). But like you I have been away some years.

@olle

You should have installed AmigaOS 4.1 Final Edition, then you have to download

FinalEditionUpdate1.lha (for AmigaOne)

And

FinalEditionUpdate2Hotfix.lha

First, unpack the update 1 and install it, then reboot and install the second update and you are updated...

Download: https://www.hyperion-entertainment.com/

@TheMagicSN,
Ah, yes and it should work of course. We are slowly getting back on track. :D

@samo79, my reads update 8, but i will do as you say to be sure, thanks.

I will send you a test-version in a few minutes.

I changed to use my own private bitmap for screen as well as for windowed mode instead, no locking / unlocking needed according to the docs.

Edit, now i know why i used that method, because now i need to blit the image. However now i get the *exact* same issue as you guys are. I added the blit, and now it works, but i have a white border. :D

I will try to fix the border and send to @samo79 for testing.

@samo79

I have to correct you a little bit there.
Finaleditionupdate2hotfix.lha is for the ones who downloaded finaleditionupdate2 early as there was some mistakes there.

So the correct steps is update1 and then update2.

The original update 2 package has been updated since then.

@smf

On my download folder there is only the hotfix as a real second update

@Olle

Update 8 was just a convenient name gived by users... after the plain AmigaOS 4.1 we had 6 official updates, and after that various other separate single updated files downlodable from AmiUpdate (78 files circa)

If you already have Amiga OS 4.1 FE you only needs these two big updates and nothing else

Ok,

Some good and bad news. Yesterday i fixed the issue with black screen and also fixed the white border.

I also added 3x and 4x scaling + scanlines and some more things.

Today after trashing my wardrobe to find my serial, i registered and downloaded the final-update 1 and 2.

After installing final 1, it worked fine, after final 2, my dh1-partition had read-error, and once it booted into workbench the partition says "uninitialized" :O

This is the partition where all sources are, i did backups from my dh0-partition to dh1 in case something would go wrong, but i did not expect my dh1 partition to get trashed. Only afterwards i realised my sdk: assign is on dh1, so it did write to it.

Anyhow, the partition is using SFS, what is the best way to try to fix it, if possible?

Here are some screenshots.

https://www.dropbox.com/scl/fi/u9gak9o ... ye4h4zz4d6kq7lmlxm3e&dl=0

https://www.dropbox.com/scl/fi/namxwm7 ... xg6cm98obpjuo1fruryj&dl=0

All suggestions welcome, as all my energy just drained. :(

Edit, @samo79 atleast has a semi-working version from yesterday.

And some good news again,

Booted from the Final edition CD and dh1 works just fine. Going to do a complete backup now, as i probably need to format it with other partition settings, maybe not use sfs anymore?