Beta Uae4All Additions

[john4p]

Let's add some features to the Pandora port of UAE4All and make them available in this thread.

Pickle just released the source of his UAE4All-port: UAE4All Source

Addition I: Vertical adjustment

Yesterday I implemented the possibility to move the displayed area vertically at any time with L + dpad up/down.
So while we still can't fully display the displayed area of games using more than 240 lines we can now for example have a look at the cutoff part at the bottom (of course then the top will be cutoff and vice versa).

You can also use it to center the displayed area for games with less than 240 lines (if you want the black bars on top and bottom to be of equal size.)

Just download the file
View attachment 446
to your Pandora and unpack it with "unzip -e uae4all.zip" somewhere on your SD-card.
Now add your kickstart 1.3-file either named "kick13.rom" into the "kickstarts"-subdir or put it in the same dir where uae4all is and name it "kick.rom".
Put some ADFs into the "roms"-subdir.
Finally call ./runme.sh from a terminal. You will be prompted to enter your system password (it's needed to really use the 50Hz-mode).

Now load a game and run it. Adjust the displayed area with L+dpad up/down.

The file
View attachment 447
has the only changed source-files.


Btw., everything was done on Pandora (changing the code, compiling and linking UAE4All).

 

[Macleod]

Good work John4P
Glad to see someone working on improving UAE4ALL.

I tested this and it works well.
Only thing I noticed was that I could only select one disk in the menu.
'a' key worked but the others did not.

Also seemed a little slower than previous version, but that might be my imagination.

 

[john4p]

I tested this and it works well.
Only thing I noticed was that I could only select one disk in the menu.
'a' key worked but the others did not.

That's because I (unintentionally) also uploaded my default UAE4All-settings where only 1 drive is active.
Just go to "More Options" and then set "Number of Drives" to 4, then you'll be able to insert ADFs with Y into DF1:, with B into DF2: and with X in DF3: again.

Also in my config "Sync threshold" is set to 100. Maybe that makes it a bit slower? Just set it to 50, then it should be exactly like you're used to.

 

[Macleod]

Ahh......thanks again.
I thought I must be doing something stupid.

Are you looking at the save files by any chance?
I noticed your file structure has a save directory.

 

[TitanUranus]

Why can't the Pandora UAE4All display more than 240 lines? Is this likely to be a permenant problem? On the Wiz "Project X" had no bloody power up bar and it really bugged my gonads.

 

[john4p]

Are you looking at the save files by any chance?
I noticed your file structure has a save directory.

The structure is exactly like in Pickle's UAE4All.pnd. The save-folder is for when you select "Auto-save" in UAE4All. Then it should automatically generate .ads-files when you save so the ADFs remain untouched. If Auto-save is off the saves should be written directly into the ADFs.
Unfortunately neither option works in this port (yet).
I'll try if I can find the problem.

Why can't the Pandora UAE4All display more than 240 lines? Is this likely to be a permenant problem? On the Wiz "Project X" had no bloody power up bar and it really bugged my gonads.

It's because of its display with 480 pixels height. As long as there's no (easy-to-use) hardware-scaling available for the Pandora we are stuck with doubling pixels, meaning some are cutoff for games with more than 240 lines.

Of course I could add a non-doubled mode, so you could see the complete 320x256 pixels or even 360x288 pixels for some games.

But then we'd only have a tiny, tiny part of the Pandora's 800x480-display used. For example SWIV would look like this:

But there will be a hardware-scaling option via OpenGL ES in the future so we can then just scale any gfx to use the full height of the Pandora's screen without anything being cutoff. The result will look good - only a bit smoothened and not as sharp as the plain doubled gfx.

 

[cosam]

OK, heading OT for this thread maybe but...

It's because of its display with 480 pixels height. As long as there's no (easy-to-use) hardware-scaling available for the Pandora we are stuck with doubling pixels, meaning some are cutoff for games with more than 240 lines.
...
But there will be a hardware-scaling option via OpenGL ES in the future so we can then just scale any gfx to use the full height of the Pandora's screen without anything being cutoff. The result will look good - only a bit smoothened and not as sharp as the plain doubled gfx.

Yeah, lack of hardware scaling in SDL (I take it we are talking SDL here) is a bit of a thorn in the side at the moment. If I had some faint idea as to how to go about remedying that I'd look into it as it appears all the pieces are there and "only" need putting together. I believe we have experienced minds working on it already though.

However, depending on how SDL is being used it can be quite easy to draw to a raw frame buffer instead. If you're just drawing pixel-by-pixel it's really just as easy as writing to an SDL surface. The advantage is that you can then do hardware scaling with op_runfbapp. The disadvantage is that you can't use SDL event handling any more (although to be honest that's not that hard to replace either). Thankfully you can still use all the SDL audio stuff whichever way you go. It's probably the third time I've posted this link in as many days but it deserves the exposure ;-) http://pandorawiki.org/Kernel_interface

 

[john4p]

That'd be too much work for me (and I can't guarantee I'd even be able to change everything needed). Would be great if someone would do that, of course.

Or if someone would put "all the pieces together" and add hardware-scaling to our SDL...

This evening I'll upload ugly softstretched (using SDL_SoftStretch) versions of UAE4All. In some games it's not all that ugly (e.g. Stunt Car Racer, Lotus, Hunter, SWIV).

But as this softstretch-method is slow you'll need to set frameskip to 1 (which is still 25fps) and the Pandora's CPU speed to 750MHz. But then it's "fullspeed" (with clear sound).

 

[cosam]

That'd be too much work for me (and I can't guarantee I'd even be able to change everything needed). Would be great if someone would do that, of course.

Heh, doesn't look too hard (famous last words). Looks like one could adapt or replace sdlgfx.cpp and basically substitute a frame buffer pointer for prSDLScreen->pixels. You can see the rough SDL -> FB conversion I did for Dega here (just search for FB_RENDER). Code needs tidying up but you get the idea.

 

[john4p]

Thanks. Looks like one could just use plenty of your code almost 1:1. Still you'd also have to change gui.cpp and all that input-stuff. Too much work, sorry.

But all the sources are available. Anyone up for it?

 

[john4p]

Addition II: Software-stretch

Added (ugly) software-stretching using SDL_SoftStretch.

Three resolutions are available (select one before starting UAE4All):
320x200 (stretched to 768x480 pixels) for games like Stunt Car Racer, Lotus, Wings, Gods and many more
320x216 (stretched to 716x480 pixels) for Turrican I and II
320x256 (stretched to 608x480 pixels) for full PAL games like SWIV, Superfrog, Alien Breed and many more

There's also the default, non-stretched
320x240 (doubled to 640x480 pixels)
selectable.

The default 320x240 mode is fullspeed at 500MHz with frameskip 0 for most games.

The 3 softstretched modes need 750MHz - then they're "fullspeed" (with clear sound) if you set frameskip to 1.

The softstretched modes are ugly, but it doesn't look too bad in 320x200 for Stunt Car Racer and Lotus.
Also SWIV in 320x256-mode doesn't look bad.

NOTE: in the softstretched modes if you press Start to switch to Joystick-mode you don't see the joystick-icon (but it works).

The new "L + dpad up/down" vertical adjustment is included, too.


Example for 320x200: Stunt Car Racer

gets scaled to =>

Example for 320x256: SWIV

gets scaled to =>

Download from here: outdated - see last post for current release (with fixed mouse controls)


Unpack it with "unzip -e uae4all.zip" somewhere on your SD-card.
Add your kickstart 1.3-file either named "kick13.rom" into the "kickstarts"-subdir or put it in the same dir where uae4all is and name it "kick.rom".
Put some ADFs into the "roms"-subdir.
Finally call ./runme.sh from a terminal. You'll get to select the refresh rate and then the resolution mode.

 

[TitanUranus]

Looks good, pity about the performance hit it takes though. Really glad to see someone working away on this though - makes me really want to get my pandora soon so I can play around with it!

 

[gaterooze]

john4p, that's some great effort to give us folks a lot of options! Thank you.

 

[milkshake]

Addition II: Software-stretch

Added (ugly) software-stretching using SDL_SoftStretch.

Three resolutions are available (select one before starting UAE4All):
320x200 (stretched to 768x480 pixels) for games like Stunt Car Racer, Lotus, Wings, Gods and many more
320x216 (stretched to 716x480 pixels) for Turrican I and II
320x256 (stretched to 608x480 pixels) for full PAL games like SWIV, Superfrog, Alien Breed and many more

Is there a way you can read the resolution of the screen/game then stretch the screen appropriately so we dont have to pre select it, would save a lot of fiddling.
Obviously leave an option for un-stretched mode too for those that don't like anything other than 1:1 or 2:1 pixel ratio.

 

[TitanUranus]

I have an idea that may quickly and efficiently help a bit here. This might look like shite, or it might be a lot of work or not possible at all... Please let me know, and be gentle when you tell me why I'm a complete tit and it won't work and even if it did it'd look too rancid to be worthwhile.

So we have 256 lines to stretch in order to fit it into 480 lines? Well what if every third line was filled a blank (black line or neutral grey, whichever is nicer on the eyeballs) like scanlines added to some emulators on the PC? I understand it's not exactly brilliant, but it would help fill 430 lines (rough calculation). If that screen resolution is as tight as I think it is this might look quite acceptable (though a little distortion in the aspect ratio is inevitable, I doubt it would be a killer - this is an idea for a quick teporary solution).

I suppose it may look smoother to the eye if you could do the following pattern... Double 2 lines, don't double the next line just draw it once... repeat till screen is filled, which I think might add up to 430 lines approx. If you are clever you could take this idea further, but my brain is going to start hurting if I continue.

Please bear in mind I'm just trying to convey the idea with my limited 25,000 word english vocabulary not computer speak - and like I said before maths is not my strong point so you might need to check it first

 

[DaveC]

ISo we have 256 lines to stretch in order to fit it into 480 lines? Well what if every third line was filled a blank (black line or neutral grey, whichever is nicer on the eyeballs) like scanlines added to some emulators on the PC? I understand it's not exactly brilliant, but it would help fill 430 lines (rough calculation). If that screen resolution is as tight as I think it is this might look quite acceptable (though a little distortion in the aspect ratio is inevitable, I doubt it would be a killer - this is an idea for a quick teporary solution).

I suppose it may look smoother to the eye if you could do the following pattern... Double 2 lines, don't double the next line just draw it once... repeat till screen is filled, which I think might add up to 430 lines approx. If you are clever you could take this idea further, but my brain is going to start hurting if I continue.

You need an even integer scale to do the scanline thing you speak of otherwise there will be black lines in some places but not other spots. That would be hideous.

What you describe for number 2 is what his "ugly" mode is doing. That is why it is "ugly", the pixel sizes are not the same and that also causes scroll ripple. Some pixels are doubled while others not. It is also known as fractional scaling as it isn't an integer but a fraction like 1.2:1 or something like that.

 

[Pickle]

john4p, can you commit the changes back to the svn at sourceforge? If you have an account or create up ill give you write access.

 

[john4p]

Is there a way you can read the resolution of the screen/game then stretch the screen appropriately so we dont have to pre select it, would save a lot of fiddling.
Obviously leave an option for un-stretched mode too for those that don't like anything other than 1:1 or 2:1 pixel ratio.

PSPUAE does that - it has a great autozoom-feature. I'll wait until its sources are available again (they have server-problems so downloads give 0kb).
Of course I'd also let the default 320x240 (doubled pixels) mode active. It still looks and plays best.


@TitanUranus: Not a bad idea. But Dave is right - it would look hideous (although it's just a handheld screen).

john4p, can you commit the changes back to the svn at sourceforge? If you have an account or create up ill give you write access.

Thanks, created the account "john4p".
But I just compiled 4 different versions of UAE4All (for 320x200, 320x216, 320x240 and 320x256) - the modified runme.sh lets you select one of them.
So there isn't 1 source currently.
But I could just add the softstretch-stuff as comments in the code.

 

[cosam]

But I just compiled 4 different versions of UAE4All (for 320x200, 320x216, 320x240 and 320x256) - the modified runme.sh lets you select one of them.
So there isn't 1 source currently.
But I could just add the softstretch-stuff as comments in the code.

Maybe add some command line options to set the resolution? Even just setting the values as #defines and #ifdef-ing around your changes would be better than nothing for now.

I may well have a crack at a frame buffer option...

 

[john4p]

Of course this is currently just a quick 'n dirty ('n ugly) solution. I'll check them into svn with #ifdefs for now (if Pickle is okay with that). Maybe it's not worth investing too much effort into this softstretch because the code won't be reusable once hardware-scaling is added to SDL (or if you directly implement framebuffer-access). Once we have hardware-scaling the ugly SDL_SoftStretch should just be thrown into trash because there really will be no use for it anymore.