SDL2 Questions/Bugs

[ghost]

Hi, I just compiled your SDL2 version on the Pi 3 and noticed the following -

'Fast Copper' has been removed. Is this going to make the emulation a lot slower, especially on a Raspberry Pi ? On testing the demo 'Big Time Sensuality AGA' the sound slows right down (which didn't happen on the latest UAE4Arm) and the game 'Jim Power' is over 20fps slower.

When enabling the drive lights they appear at the bottom middle of the screen with a black bar all the way to the right of the screen.

Frameskip is on by default ? This reduces the frame rate to 25fps.

When starting a game the screen is about 640x256 even though the Display Options say the screen is 640x200. Is the screen supposed to automatically change resolution ?

Very small mouse pointer in GUI.

Keep up the good work.

[midwan]

@windale Thanks for the feedback! Regarding your questions: 1) Fast Copper is an option that does not exist in newer versions of UAE, probably because it was incompatible or caused problems. In the latest versions for UAE4Arm it was also changed to be disabled by default. In harmonizing the code with WinUAE 2.8.1 (and upwards), I've removed it from the code and replaced the copper routines with those of the newer WinUAE version. I haven't noticed any speed problems with it.

2) I haven't tested Big Time Sensuality, but I will. Jim Power is in my list of tests and I've already narrowed down what causes the slowdown, so I'm working on a fix these days - something that should affect everything for the better I hope.

3) I've noticed that problem and I'll get it fixed. We should handle it on a separate/dedicated issue however.

4) This also probably happened due to the merges from WinUAE. I can disable it by default.

5) I'm experimenting with the resolution thing a bit, and currently the idea is this: Assuming the display setting is set to PAL, then resolutions are usually: 320x256, 640x256, 640x512, 1280x256, 1280x512 (if we don't count overscan). These double perfectly on modern 5:4 displays that can do 1280x1024 and can display them without any distortion. Hence, if no resolution is specified, I'm using a default internal resolution of 640x256 (ignoring what the display options shows, unless it's manually set to something of course) and then use the GPU to scale that to full screen on your monitor, keeping the correct aspect ration always. If you change resolutions in the system, that is handled correctly and the GPU takes care of scaling it up to full screen again.

Eventually my aim is to see if we can get rid of specifying a resolution manually completely. I'd like to see if we can have the system work more like a real Amiga, where the resolution change is handled by the emulator automatically and always shown full screen regardless of what native resolution you have.

6) The mouse pointer size in the GUI depends on the native resolution you're running on. What resolution did your Pi have when launching the emulator?

[ghost]

I only tested one demo (Big Time Sensuality AGA) as this has copper effects but I just tested 3 more games that use copper (James Pond Robocod AGA, Trolls AGA and Oscar AGA) and they seem to work fine.

When you say 'scale to full screen', a lot of Amiga games have the big black bar at the bottom of the screen (640x256) but if you change the resolution to something like 640x216 it fills most of the screen and keeps the aspect ratio (Much like WinUAE's 'autoscale' feature). You mean it will automatically do this ?

I'm using a 1080p resolution at 50 Hz.

[midwan]

@windale It will automatically scale whatever resolution you choose on the Amiga side (let's say, 640x256 for HighRes, or 320x256 for most games) into the best possible match that would fill the screen, while keeping the aspect ratio. So, no black bars on the top/bottom, but there will be black borders on the left/right if you're on a 16:9 resolution/monitor.

The best fit would be a 5:4 monitor that does 1280x1024 natively AND at 50Hz, but I understand that many won't have such a monitor.

For your example on running on 1080p, it will scale 640x256 to 1080p (top and bottom are filled) and expand as much as possible while keeping the right aspect ratio, so you will have black borders on the left and right side of your screen.

[ghost]

I can live with black bars on the sides as I always play retro games in the correct 4:3 aspect. I hate the stretched 16:9 look that distorts the aspect ratio. If it can fill more of the screen and keep the correct aspect then it's a bonus.

Should it be doing this already or that's currently in progress ?

[ghost]

Just using this to bump, not sure if you saw my other two bug reports (the OCS/ECS bug is a big one). Everything going to plan or you're just taking a well earned break ? :)

[midwan]

Everything is proceeding normally, I'm a bit busy implementing some updates these days and fixing the bugs that came with them.

Once they are fixed, we'll have drawing and custom chipset routines updated from WinUAE, which I expect might fix some of the compatibility glitches.

[a7mag3ddon]

Jesus windale just because you don't get an instant reply to a bug report does not mean it has been ignored or not seen, we all get EMA's EVERYTIME you make a post!

[ghost]

@a7mag3ddon Allright, calm down ! I only asked. Another lurker. What does it matter to you anyway ? You haven't helped. I thought he hadn't seen it because he never added the BUG tag. I won't bother trying to help anymore.

[midwan]

Closing issue since the bug(s) mentioned are already on separate issues