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

@LiveForIt
Quote:

Not sure if we talk about my “way what I want” :) I think we do have a bug there, as things is working now not as you think it should work. Even with the monitor's settings (where i can choose aspect or full) the issues still here.

Let me try to explain it from another perspective:

With commit 61 all scaling were fine with AGA, in any video mode i select on the start (just the start was a bit wrong in full-screen of p96, but AGA modes were fine), but commit62 broke scaling of AGA screens in all the full-screen modes now. Be it 1920x1080, on 800x600 , or any else which different with the values you set in the gfx_width_windowed and gfx_height_windowed.

To take it short : scaling of AGA modes in full-screen do not work correctly now. While yesterday's one was ok. Now, you only can set “windowed” settings to 640×512, and on running choose 640×512 screen mode, and only then to have normal rendering (but that will be not scaled rendering, then). When scaling involved, (i.e., you select any other screenmode, be it 800x600 or 1920x1080) in any full-screen mode which differs from 640x512, will not scale correctly and add more black lines and on the left, and on the right.

While “window” mode didn't have these issues. Everything scaled correctly there, and AGA screens there looks as expected, and can be resized as you need. It seems that “full screen” code just go the wrong route with latest commit.

Hope now it's clear (tried to explain as much as i can with my bad English :) ). If i still explain it wrong, please be my guest, i can try to explain it from another perspective if need it. :) I just didn't see it as an aspect ratio issue, it more like miscalculation somewhere, because even 800x600 mode act bad now and add black borders (and even if it will work in 800x600, how you then can run workbench in 1920x1080, and then run AGA stuff from, to have it renders ok as yesterday ?)


Quote:

Those lines not need to hide IMHO, they should be there. As it was yesterday. It just as it should be and programmed by the demo i tried. Other AGA screens were ok and without black top/bottom lines. Those is of no programming issue, all ok there. Its the left/right black borders now added in any full screen mode except the non-scaled mode, which should be the same as gfx*windowed settings.


Quote:

IMHO, what we have there now (the bug we discuss) is not about aspect-ratio settings, but maybe just some miscalculation issue ?

Yeah, changing aspect by key can be good for developer-tests, but sure not important much now. Users setup configs one time as they need and keep using it. So if make anything about aspect ratio to be configurable, then it sure should be option in the config at first. At least as first thing. If you still will be in needs to have manual switching on-the-fly, then why not, just it shouldn't be necessary for user to have proper scaling hitting key combos always. :)

Quote:

IMHO again, but IMHO there are no needs to overflow the code base by additional GUI in the place where it's not needed it. At least if make any additional stuff, then by configure options as necessary, and all the stuff additional if you feel in needs of.

Quote:

Of course not, neither I test it whole days :) I'm just helping to point out on errors and bugs. And i think that we have broken scaling now with latest commit.

Try for yourself : setup gfx_height_windowed and gfx_widht_windowed to 640x512. Then run UAE, choose any screen mode (800x600, 1920x1080, 1024x768 , whatever else, just not 640x512 one) and run then some AGA demo or anything. You will see that scaling do not work correctly anymore. Black borders added, in any mode, and even mechanical change of the Monitor's settings to/from aspect/non-aspect didn't fix it. Normal rendering happens only when you set screenmode to the same as gfx_*_windowed params , so no scaling involved, and run the UAE on 640x512, but then, no scaling involved, P96 also looks bad, etc,etc.

Maybe it just miscalculation issue which affect only full-screen rendering ? Because even in 800x600 it added those black lines on left and right and make whole picture be smaller horizontally.

Window mode as i say don't have this problem, i can resize it anyway i wish, and everything fits into the window size very well, even if i resize it to the full 1920x1080 screen.


Even if i play with "Full/aspect" settings of monitor, there is still the same issues. Try for example to choose 800x600, while have 640x512 in gfx*windowed settings of UAE : you will have black borders on the left and right. Now even change from "full" to "aspect" in the monitor's settings, just make those black borders on the left and right be bigger (when switch to "aspect"), but in the "full (non aspect)" mode, it still has again black borders at the left and at the right, just a little bit smaller.

That why i think we do have miscalculation bug there introduced yesterday.

@kas1e


Yes, that make sense, they are not 100% perfect matchs.

640/512=1.25 (narrower per height)
640/480=1.33
800/600=1.33 (wider per height)
1920/1080=1.77 (wider per height)

If output is wider, then what is displayed then naturally it has to add some black borders.

Of course this is all silly, as true aspect ratio is the monitors max resolution (probably). And not 800x600, we are just fooling the algorithm.

We assuming square pixels, and that might not be true at all, if the monitor stretches the output.

@LiveForIt
Yeah, just were curious why all were fine with commit 61, but start to be wrongly worked with 62 one..

Anyway, tested your fresh commit 63, and can say that:

1). issue with overwriting the window borders when in window mode, gone!

2). scaling of AGA screens on 1920x1080 screen (or any other one) works fine now again! More of it : if i go to the prefs:Screenmode, and start testing different resolutions (being on 1920x1080 screen) , they all fill the whole screen and when i hit "test" button, and when choose to use new screenmode.

Looks pretty cool, really. Thanks a bunch for fixing it all !

What you think to do next ?:)

IMHO there only 8bit support which missing (at least that what need it really for some old software) and maybe thing like "custom" settings of pub screen should not decide 16bit, but instead 32bit ones ?

@kas1e

Quote:

ok, so this stuff is dangers, it does affect a lot stuff in unexpected ways. it changes the aga/ecs/ocs display output buffer, it messes with height and width of the buffer.

@kas1e

Quote:

not sure about any of that code really, not sure what do with it yet. I'm thinking about deleting it.

@LiveForIT
Quote:

If didn't use it, then things go bad for AGA screen. On 1920x1080 no scaling then (at all), and we do have the same as it was with SDL : small window on the big 1920x1080 screen. The only way to make it be ok, is to use those settings.

I was under impression, that scaling works exactly because you add support of compositing, just with gfx_*_windowed settings i can control it. Because if not use those settings, and comment them out, then in 1920x1080 all the aga screen small like 640x480 opened on the 1920x1080 screen. I.e. no scaling at all. Just like it was with SDL version.

But if i set those settings, then everything fine and works as expected. At least with commit #63 all fine again.

Quote:

You mean the part of code which handle "custom screens" ?

@kas1e

Quote:

All I can say, is mess around with gfx_widht_windowed and gfx_height_windowed, you get some crazy results, it goes nuclear here.

These settings control the AGA buffer, they do not control the scaling exactly, but they do effect height and width of the buffer.

try 1600x1600

@LiveForIT

At least gfx_height/width_windowed can control the size of the AGA screen, and then scaling actually works.

See how good it with commit #63, if i do use "gfx_width_windowed" and "gfx_height_windowed" set to 640x512:



As you can see, all modes open up fine, all modes scaled well, all works as one expected it to work. And in full screen and in the window mode.


If i comment out those "gfx_widht_windowed" and "gfx_height_windowed", then everything in a mess. No scaling happens at all. See you yourself on that video where i just comment out those 2 parameters in the UAE config:



As you can see, the only time when scaling indeed works as expected is to use gfx_width/height_windowed params. If they commented out, then you no scaled rendering.

Try yourself to disable those 2 values, and run uae, and choose any screenmode bigger than 640x480, and you will see that scaling simple didn't work then.

@kas1e

thats becouse you set also gfx_width and gfx_height.. comment out this too.

I don't use gfx_lowres and I don't use gfx_double

@LiveForIT
Commenting gfx_widht and gfx_height together with their "windowed" brothers make it looks better indeed: at least it fills screen in boot menu, it works better, BUT(!) then i have again black borders in the AGA screen when run some test software.

If I uncomment back those 4 settings (so 1920x1080 for fullscreen and 640x512 for window), then no black borders and all ok, as on my latest video in previous post.

And i know why there black borders : because when you comment out those gfx_*_windowed options, it then take the default ones , which are 720 x 568: that why we have black borders when those values didn't change - because of default nature

@kas1e

no black borders if you disable aspect

@LiveForIT
Quote:

Me too. gfx_lowres always in FALSE, and gfx_linemode=double are default UAE settings for that kind of options (check the configuration.txt, they point out those default values as well).

Quote:

For me they are (you can see on second video in previous post). And i also do have gfx_corret_aspect to false. The only time when i can get rid of black borders with commit63, is to use those 4 gfx values. But even if you didn't use them, windowed ones will have default 720x568. So even if you didn't use them, they use you :) The same as gfx_height and gfx_width. Even if you don't use them, then they mean 800x600 as default values for the UAE.

What software you use to test aga modes ? The boot-menu one is not good for this kind of test, but some AGA demos/games/software good for sure. So try to load up WB, then run some AGA HD demo from, or diskmag, or software which need AGA : black borders there.

Once change default 720x568 windowed settings on the 640x512, everything start to be ok, and black borders gone.

@kas1e

I think I know, why gfx_width_windowed, gfx_height_windowed is a bomb..

On MorphOS they have problem with CyberGraphics / WritePixelArray, so they must make the buffer the same as bitmap, they are not using the correct bpr.

just removing cgx should fix it... might need to do it in steps.. as it breaks when I try to remove everything.

@LiveForIT
Quote:

Not that I understand what you mean by "bomb", because for me, they work as expected, and only with 640x512 settings for them, I can have working scaling without black borders.

And those options, good anyway, give you ability to control size of AGA screens, so you can have all the size correctly.

Yesterday i tried as you suggest to comment out 4 GFX options, and still, in any screenmode i do have black borders (because it swith to default 720x568). Only with 640x512 in gfx-*-windowed options, we do have correct scaling in full screen of all modes. If we comment them out (so back to defaults) then always black borders in pal screens, even if you say there should't be. They not "that" big in this case, but still borders there with all modes.

But anyway, OS4 and MOS developers long time didn't work on the same projects anymore, so probably ditching CGX will make code better to read and easy to maintain, that for sure.

@kas1e

Well it crashed here, so better to fix it.

@LiveForIt
Quote:

Mm.. didn't notice crashes in commit63.. maybe something new changed localy?

Btw, just in case you test yesterday AGA modes on "boot menu" when comment those "gfx" options : in boot menu "borders" just filled by the color of the background of boot-menu, not by black one, so you may take it falsely like there is no borders : but there they are, just move mouse to the right and to the left in this boot-menu screen, and you will see borders there.

That of course, when we comment those 4 options, and default 720x568 are used.

Interestingly, i found in last few days of tests, that quite much software and demos do use "true 8 bit" screens in late of classic days. Even diskmags (like jurassic pack, excess) open up the start/end pictures on real 8 bit screens, and for engines do use AGA modes. Or demos from Ephidrena - they all mostly use 8 bit screens, and not AGA. I assume some of Elude's, Mawi's, etc demos also 8 bit ones and not AGA ones.


EDIT: oh, new commit64, time to test !:)

@LiveForIt
Tested commit64 in full-screen/window modes: visually all as with commit63 (good). I.e., with gfx_*_windowed commented do have borders, with 640×512 no borders, all fine as before.

In window mode also works as before, all ok.

At least on brief check, no regressions.

Also tested amiga.screen_type=custom instead of "ask", and it looks like the code handling "custom" option a bit tricked : for width and height it uses the same gfx_widht_windowed and gfx_height_windowed.

I.e. you set "custom", and it then takes the gfx_width_windowed and gfx_height_windowed and create a real amiga screen of this size (and with 16bit dunno why) !

I.e. it not only control the AGA output buffer, but also these values used by the "custom" option code to create a real screen from. While, probably custom code should use instead gfx_widht and gfx_height. But then, how to find correct depth, to not set 16bit one ?

@LiveForIT

Ha, found in original ami-win.c that:



Rachy have just not implemented it, that why it keeps using 16 bit, probably.

So i hardcore set 1920x1080 and just replace the depth order in preferred_depth[] = {15, 16, 32, 8};, so not to have 15,16, first, but 32 one instead. And then with "custom" option i am able to start in full screen in 1920x1080x32 screen without ASL requester :) The only issue then, when i hit "ctrl+alt+s", it again ask about screenmode , like it not "custom" set, but "ask" instead . But i assume that expected for now..


PS. Btw, seems speed of loading a bit faster with commit63 too. I.e., now the time between i hit “enter” to run UAE binary, and full working wb3.2.1 : 15 seconds.

Maybe that the result of deleting those copy of buffers with cgx ?

@kas1e

Who knows, yeh it looks a bit faster, who knows how cyber gfx stuff is emulated wrapped, it can also be some buffers now being 32 bit aligned buffers, fewer cache misses maybe.

The native gfx lib stuff is GPU accelerated that’s guarantied.

Quote:

I did not delete any buffers, I have deleted a lot of code, that’s because they have code for different version of CGX in there as well, I did not need the duplication, (that also makes the code a bit hard to read).

Instead of stuff everything into one .c fil they should considering split it up.
Yeh I’m not fan putting code in .h file, as static’s are the same as inline functions, I can understand why they wanted it in the same .c file, it makes code more compact.

The code can look a lot nicer, and more readable if they did not jam everything in there that’s for sure.

@LiveForIt
Find out you have another commit today with added conversion routines. That probably in preparation for 8bit support in p96 ?