What's the best/latest EUAE build for OS4?

@LiveForIT

One more bug:

Running in 1024x1280 in window mode, waiting when everything loads up (p96 with workbench). Hit close gadget in the window:
"returned with unfree signals 10000000!"

@kas1e

I think I found vram problem, maybe also the same as the test button bug.

@LiveForIT
Tested new version (as of commit #60) and there definitely good progress with lots of fixes:

-- bug with “test” button in prefs:screenmode gone!
-- VRAM leaks fixed!
-- unfreed signals when hit close gadget in window mode gone!
-- remember window size and position when switch to/from fullscreen/window and when iconify in the window mode works too !

Cool !

So, what left is:

-- 8 bit modes produce black screen
-- wrong rendering when we use big video modes (it's like one pixel didn't add somewhere, or added on wrong place).
-- missing HD resolutions in the piasso96 video modes, such as 1280x720 and 1920x1080
-- p96 error on the start with words "uaegfx and uaefgx both use Display ID: 50001000" (probably related to the missing HD modes)

Btw, I assume that currently we do have asl-requester when running UAE, and when switch between full-screen and window, just for easy testing and will be gone when P96 stuff ready ? Will be good to continue to use config's options like gfx_widht_windowed and gfx_height_windowed for window, and gfx_width and gfx_height for full-screen, and to choose in which run by default (full-screen or windows) to use those "gfx_fullscreen_picasso=yes" or/and "gfx_fullsreen_amiga=yes".

Keep motivated, P96 stuff almost done! That all should happen 10 years ago, but better late than never :)

@kas1e

Quote:
in window mode.
We need an 8bit buffer, then need to convert it to 32bit or 16bit bitmap, like Basilisk II.

in Fullscreen, we can maybe use native mode and skip conversion, but that also kills of scaling.
640x480 might need scaling, if native screen modes are too big.

this also similar to how need to handle 15bit modes, as we do not have native 15bit modes, we always need to convert image data, so always have scaling.

16bit, might need conversion, some older software might not to support for 16bit le format. But also believe 16bit was so common, in 90’s, so maybe not needed at all.
Of Couse we should use old alignment (2 or 4 bytes) not 16 bytes alignment, under emulation.

Quote:

it seems you’re of the opinion we should use native modes, instead of common width and heights used in the 90’s, I’m not sure about that, as the point of EUAE is to run software that is broken on AmigaOS4, so stretching it to fit, is preferred option.

Quote:

Yes, I agree, it nice to be able to fill the screen, at least in 32bit mode.
Quote:

I don’t see this bug, not sure if I can fix it.

Quote:

It's actually an uae prefs option, ask, custom, window mode I believe.
yes it’s a bit annoying, maybe it should not ask all the time, maybe it can done once, or if the requested screen is larger than the display screen.

Quote:

Yes, that make sense, maybe result of not having scalable windows before.
Quote:

That should depend on it its aga/ecs/ocs mode or picasso96 mode, maybe some stuff left, to fix. If it scales to wrong resolution.
Quote:

actually the hard stuff, might be what’s left.
when to convert, when not to convert, when to scale, and when not to scale.
Quote:

I think was working on Basilisk at time, can’t get EUAE compiling, you need to give thanks to the developers who fixed the configure scripts.

@kas1e

Richard Drummond was not focusing exclusively on AmigaOS, but BeOS, MorphOS, AROS, Linux, and so on, I think as long as he was working on it, no one took responsibility for making a proper AmigaOS version. As soon as the SDL version was out, there was no need for optimized amiga version, I guess.

Other UAE’s popped up FS-UAE, and PUAE, E-UAE labeled abandoned, and says so even now on the wiki page, then JIT for UAE work done, and EUAE so got some new life. (But only the PowerPC community did take notice.)

@all

Great progress guys!!

If there is need for testing stuff let me know!

@LiveForIt
Quote:

I think we can ditch all together anything which is not 8bit or 32bit. Because i checked now SDL version, and with SDL version picasso96 giving me only 8 and 32 bit modes. I do not know maybe it was me not setting 16bit ones, or it just can't be setup in the UAE+P96+SDL at all, but all i can say that 8 bit and 32 bit modes is more than enough for the P96 emulation at least. Everything else can come any time after proper release with your changes done, from anyone else, if there will be any needs at all. For us, IMHO, just 8 and 32 bit are important and enough for proper release. If later we will find the needs for anything else, anyone feel-free, etc.

Quote:

Dunno if we talk about the same thing, but will try to explain a bit more detailed about:

You do run UAE on 1920x1080x32 screen, and then :

1. Switch to 640x480 in P96: everything scaled (of course), but looks good. Everything clean, as it expected to be.
2. Switch to 800x600 in P96 (but of course on the same 1920x1080 screen). It of course also scaled, but now, things start looks worse. I can see some pixels missing, some pixels added around the whole thing.
3. Switch to 1024x768 in P96 (of course via the same 1920x1080), now things start to look really bad. Much more missing pixels, much more added pixels on the places where they shouldn't.
4. Switch to 1280x1024 in P96 (on the same 1920x1080 screen), it's about the same bad as in 1024x768.

I do some calculate from all modes being scaled to my 1920x1080 screen:



So, in first mode, all crystal clear. In second one rendering start to be worse, and 3rd and 4th is the worst possible. With pretty noticeable missing pixels and added other pixels on wrong place.

That expected to be like this? I mean, first mode have “3” in the X, and Y have 2.25, but visually everything fine absolutely. Then other modes have numbers after the decimal point, and maybe math a little be broken in current code about ? Maybe it needs to round some numbers so to better look ?

Quote:

Yes, 32bit P96 modes need it to have all resolutions including HD ones, and 8bit modes for HD resolutions can be postponed to maybe-someday-if-there-needs-at-all.

Quote:

I think that is can be a side-bug of the HD video modes not being able to set up by P96 while they already were setuped by P96 when running over SDL version.

I mean when start UAE in SDL mode, we do have in the list of screen modes 1920x1080, 1280x720, etc. But when we run our version, it brings this error and no HD modes available in prefs:screenmode. My bet it's the same single problem.

At least IMHO it will be correct to make the HD modes be avail in the prefs:screenmode first, and then check out if this P96 error popup again, or there will be none. But it's high chance that it will be autofixed once HD modes will be shown in the prefs:screenmode.


Quote:

I just find that UAE have 4 options related to full-screen/window:

amiga.screen_type=
amiga.publicscreen=
gfx_fullscreen_amiga=
gfx_fullscreen_picasso96=

When all of them empty, then we do run in window mode of the gfx_widht_window and gfx_height_windowed values. All fine there, like in documentation stated.

Then Amiga.screen_type mean if you set “custom”, then it should find the closest possible mode to match configured dimensions (which is probably gfx_width and gfx_height). So, i set gfx_widht and gfx_height to 1280x1024, and set the “custom” , it didn't ask for the screenmode on running, that correct, but (!) rendering in p96 screen is broken : and by X/Y and by colors. I do check what kind of screen is created : it is 16 bit. So no surprise things broken by rendering and color then. Why it chooses 16bit, and not 32 – dunno. My WB is 32 bits, and in P96 set 32 bits, so probably “find closest to match resolution” code a bit broken ?

Then hitting there ctrl+alt+c, again bring ASL requester, while shouldn't as we switch to window mode, which we do setup by the gfx_window_heigh and gfx_window_width.


So as far as i can see there we have 2 issues:

1). When we have amiga.screen_type=custom, then code to get "better matched" screenmode for full-screen use 16 bit instead of 32 ones.

2). When we run it by default in the window or in the full-screen, then, pressing ctrl+amiga+alt always bring asl-requester, while shouldn't as there already gfx_window_heigh/width and gfx_widht/gfx_heigh is set which mean values for the window and screenmode (or if not exact in full-screen, to match the best screenmode to the values from gfx_widht/gfx_heigh).


Anyway, progress is superb.

@LiveForIT
Checked then new commit about "adding native modes" , and:

p96 error on the start with words "uaegfx and uaefgx both use Display ID: 50001000" gone ! As well as HD modes are present in the list of screenmode in prefs:screenmode now too ! Yeah, 2 bugs gone at once ! :) cool!

But i do find some logical error (not a crash or bad rendering, just a logical error), to reproduce:
To reproduce:

-- run UAE, set/save in P96 sreenmode to 1920x1080, quit from UAE.
-- in the .uaerc do this:




Now, when you run UAE in window mode : everything fine. Window opened 640x480 of size. Quit from emulator, run it again, but this time choose "1920x1080". So it opens 1920x1080 screen as expected, but on that screen open a window of 1440x1080 size ! While of course, it should open 1920x1080 rendering area as well as we do have gfx_widht=1920 and gfx_height=1080.

But, you still can make it works as expected: For that you do run in the window mode, hit "ctrl+amiga+s" to switch to full-screen, and select 1920x1080 : and this time, it opens again as expected on 1920x1080 screen, and rendering area as expected also 1920x1080.

So it seems the issue is when we run first time exactly in full-screen. But if we run in the window, and then switch to full-screen, all ok. Or, we run in full-screen, then switch to window, and then back to full-screen it's again fine. But if we run right from start in full-screen, we do have this 1440x1080 rendering are.

It looks like that when we run in full-screen, at first we on the amiga-native screen (which sets to 1440x1080 when on 1920x1080 screen) and then, when WB loaded and picasso96 should switch to 1920x1080, there is not such switch happens. But when you switch to window mode, and back to full screen – then it switches to full rendering area.

Another case how to make it works from the start in 1920x1080 mode, is to set gfx_width_windowed and gfx_height_windowed to 1920x1080, and then even in fullsreen it will runs in 1920x1080 p96 mode :) Which kind of strange, as why it *_windowed options make impact on the fullscreen ones (it should be gfx_width and gfx_eight imho?)

Magnificent work! I did some smaller tests, and the AmiGFX version seems to be much faster than SDL.

For example, opening the text editor in StormC4 takes several seconds on SDL, while it is instantaneous on AmiGFX.

There are two smaller issues with hosting directories as drives that might be worth looking into:

- Mounting the root directory of a host drive (e.g. RAM:) duplicates the entries when running "dir" on the guest.

For example, I mount the host RAM: as Shared: in AmigaOS 3.2:


- Setting the "s", "p" or "h" permission on a file will create a _UAEFSDB.___ file with the permissions. But on AmigaOS4, you could just set the permissions directly.

Yeah, speed wise it surely faster. I did noticed it few days ago that SDL version take 38 seconds for full startup till full ready to use 3.2.1 WB, but new Amygfx version take just 18 seconds for the same. I still didn't know wtf, as imho pure swith from sdl to amygfx rendering should't speed up a loading that much. Maybe it just that i use latest gcc11 now ..

@kas1e

Quote:

if the emulator has to spending most of its time in the GFX emulation, then there is little left for CPU emulation.

Of course, it matters, worst case having to emulate / convert every pixel, one by one. CPU copy vs GPU copy.

Maybe it does show something wrong with SDL, or maybe what SDL has to do is too generic.

@kas1e

Quote:I don't know anything about UAE and its config parameters, but I couldn't help noticing that you have misspelled "width" as "widht" in several places.

You might want to check if that is an error in your actual file? If it is, that might explain UAE rendering an unexpected width.

Best regards,

Niels

@nbache

Computer languages, does not care what variables are named, it be called s7xi3456dd and it worked the same. Why its not working perfect, is because people testing it while its being changed / written.

Of Couse it’s nice to get spelling error corrected, but its not required.

@LiveForIt

I know (having lived a life with CS and systems development ). I was just wondering if kas1e's spelling was not matching the one the program (currently) expected.

Best regards,

Niels

@nbache

When someone says spelling mistake, its most often me , as to kas1e comment, yeh these things are not used.

@nbache
Yeah, just typing mistakes in the forum, on the config it is "width"


@LiveForIT
Quote:

Seems only gfx_width and gfx_height not used, but gfx_width_windowed and gfx_height_windowed for sure used (i can control by them a size of the native amiga screens). I.e. with yesterday's version when i set there 640x512, then all amiga aga screens opens correctly in full-screen for me , on the 1920x1080 screens and fill whole area (with today's commit there is regression in that terms).

So, tested your latest "a few changes" commit:

-- the good thing is that those "gray" borders in the modes which do not fits in fullsreen are black now ! Yeah ! Especially i like how pal "boot menu" looks like now with black borders, just like real thing :)

-- bug with inability to switch to the correct video mode on first start in full-screen also gone !


But, it did have 2 new issues :

1. when we run in window mode, the borders of the window also black (even the resize gadget of window). So probably when you do fillrectcolor, you didn't take into account borders of window in window mode.

2. when we run AGA screens on 1920x1080 screens, it didn't scale now properly to fill the entire screen as it was with commit #60, but add instead a black color borders. Like we always in 1440x960 window (while, Ranger says that window is 1920x1080, so it rendering-calc-issue probably?)

It was quite cool in previous commit, that in 1920x1080 scaling were filling whole 1920x1080 area.

See, how it was with yesterdays commit (good, whole 1920x1080 used):



And now how it with latest one (looks like 1440x960 window again, while in ranger show it 1920x1080 window):



With previous commit (when entire 1920x1080 were filled) it was really cool, and made a feeling like you watch TV movie when run AGA screens, just like you are on real thing.

Is it possible to keep new fixes you do, but revert the ability to scale well to entire 1920x1080 ?

To add, i do have 640x512 for gfx_height_windowed and gfx_width_windowed when tested yesterday's and today's commits.

And while with yesterdays commit those values make an impact on the size of the AGA sreens, in today's commit if i set 640x512 or 640x480 it didn't change anything.

So looks like yesterday those values make sense, but today it use some defaults which we can't change by gfx_height_windowed and gfx_width_windowed

@LiveForIt
Thinking a bit more, maybe it should be something like "keep_aspect_ratio" option used (uae already have such opyion) which will control the way of scaling ? Like when in true, scale as it now , when false scale how yesterday (whole screen)

@kas1e

Yes exactly.

Anyhow, if you change the screen, it will fill the compile display, if the p96 screen resolution is the same as the native screen/display.

@LiveForIT
Quote:

You mean that “gfx_correct_aspect” will be the option we will use to make it works (so to fill whole screens) ? Because I just tried this option with today's commit, and it didn't make AGA/PAL screen to fit the entire 1980x1080 screen. While with build done with yesterday commit, we can make entire 1920x1080 screen filled.

There are the options I use for tests:

gfx_widht=1920
gfx_height=1080
gfx_width_windowed=640
gfx_height_windowed=512
gfx_lores=false
gfx_linemode=double
gfx_correct_aspect=false
gfx_center_horizontal=true
gfx_center_vertical=true

The workbench in the os32 set to 1920x1080x32 mode.

Then, if I run yesterday's commit UAE in window mode, and once wb loaded hit “Switch to full-screen”, and then run AGA demo, it then fills the entire screen (like on the first video i show), no big black borders at the left and right sides.

But, with today's commit (with the same UAE settings), doesn't matter if i run in window mode and switch to full-screen then, or if i run from full-screen from beginning : running of AGA screens never filled the entire screen, and keep it like i show it on second video. Like, the aspect ratio thing is enabled always, even if i set it to false.

See how it with yesterday commit:
(hit open in the new tab for fullscreen image)


And same settings but today's commit:
(same hit open in the new tab for fullscreen image)


The only way to make it fill the whole 1920x1080 screen, it's to keep gfx_width_windowed as 640, but the gfx_heigh_windowed to 320. Then the entire 1920x1080 screen filled, but of course it looses many vertical/horizontal lines then, and everything looks quite ugly in compared to how it was yesterday.


That of course issues in the full-screen mode. With window mode, when i resize it to the entire 1920x1080 screen, it renders as expected with no black-borders at right/left. But probably that expected as window-mode resizing do not have aspect-ration enable/disable code ?

@kas1e

Maybe its counter intuitive.

4:3 aspect is 800x600 mode, so if pick that screen mode in the ASL Screen Selector, AGA mode will stretch to fit the 800x600 screen (4:3 aspect), instead of a 1920x1080 (16:9 aspect), so it should stretch to fit nicely. I expect your monitor to always stretch, but some monitors might have an aspect option, that might get in the way of what you want.

The black top & bottom border is over-scan pixels, no options to hide this, yet.

I think changing aspect can be nice as a hotkey option but enabling config option to be nice too.
or maybe a small run time GUI, with few options. That is not a priority.

I only work on this only few hours a day, don’t expect miracles overnight.