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

@kas1e

I guess the benefit of a hack is that ARGB to BGRA can do with byte copy speed, also if done in picasso96.c instead of AmiGfx, you can limit the byte swapping to draw calls, when handled in the AmiGfx we have less control, and need to convert at least full lines.

I strongly recommend using native modes, to avoid conversions, however it can be useful to customize. Some demos or games might not support all formats.

@LiveForIT
I see you made some bunch of new commits, will test it now , but want to ask what you mean by "I strongly recommend using native modes, to avoid conversions". Did you mean that i can use some other modes somewhere ? I mean, what we have is the modes we have in OS4 made for us by drivers, and the same in OS3 emulation, we only have the modes created for us by P96.

Or you mean something different with that ?

PS. and thanks for continuing your work on, if we throw on you all the issues, it's only because we value the work you do, and we all want to make it all good, just because if not you're now taking the big task dealing with, no one will make it all ever.

@LiveForIT
Find out that since some time, we have broken Vsync : i do test todays commit as usual with demo called "Adam malyzt" from Ephedrena, and it start to be veeeery slow, and i can see through all the effects how "vsync" line is draws all over the places. Music also start to be choppy very much (probably because they sync it with vsync or something).

Can't say when this issue happens, but if i remember right some time ago there were some changes about vsync as i read in commits messages, so maybe that one.

I can find out what commit start to cause this, if you need it.

@kas1e

make sure #define debug_vsync_time is set to 0

It’s used monitor the speed of conversion routines and can add some overhead. Everything else is the same, BGRA and ARGB use same conversion for 8bit to 32bit (not sure how that works).


EDIT:

Adam Malysz vs. Wienerwurst is AGA demo, not a P96 demo, You won’t or should not see any effect in speed on AGA demos, my conversion routines are only used on P96 mode, AGA should be as slow as it was before.

@LiveForIT
Quote:

Yes, i surely have #define debug_vsync_time 0 in the ami-win.c

See how ugly is it now:




It did looks through that something wrong about vsync anyway.
Maybe it should'be "define 0" , but instead "undef" ?


But,

Quote:

Adam Malysz (as other Ephidrena's demos) do have code for both : AGA and P96. AGA when you run it as it, and P96 enables when you run from workbench, and you do have correct screenmode : 320x256x8bit if i remember right, or maybe even 320x512x8bit..

So, if startup of the demo find out this mode, then it runs via P96 8bit modes, if not, then AGA.

Almost all Ephidrena's demos of late do have this startup code supporting both AGA and P96. I remember it very well, because when i have my monstered A1200 with Mediator/voodoo3/PPC and all stuff, the Ephidrena demos were ones of not so many working on P96 friendly screens without issues.

@kas1e

that demo, tokk its time to start,
looks like it tries to switch mode all the time.

@LiveForIT
Quote:

Only now. It was faster (at least somewhere in commit ~100 or so) and only since some time it starts to be noticeably slower.

Quote:

Dunno, but it happens only lately, before it was ok.

@kas1e

yeh.... test button & p96speed program fix.

@LiveForIT
Quote:

Sorry, didn't get what you mean :) That some previous fix you do broke it ?

All I am saying, this demo was ok and good for some time back (around commit 100), but since some commits it starts to behave weird like that.

Btw, just in case, checked latest commits on "blue" color issue : it still here. But, can you explain what you mean by "I strongly recommend using native modes, to avoid conversions" ? Is it something we need to change in the OS4's screen modes or in OS3's screen modes ? Or you mean you will just fix it later, and not now ?

In terms of speed, there is no single difference if we compare old-working-good-hack-way, and the new, with blue-color-bug way. At least, operational WB is the same, and speed of loading of WB and images on it are the same. Didn't look like it something worth making it be with new bug (at least for now).

@kas1e

Quote:

on line 2910, you need to change:

*ppixel_format |= 1 << RGBFB_A8R8G8B8;

to:

*ppixel_format |= 1 << RGBFB_B8G8R8A8;

on line 3005, you need to change:

picasso_vidinfo.rgbformat = RGBFB_A8R8G8B8;

to:

picasso_vidinfo.rgbformat = RGBFB_B8G8R8A8;

That should do it, hope it works!

@kas1e

Quote:

it should not be.. more info needed, your console output etc.

@LiveForIT

Quote:

Sorry, I still lost :)

I mean, this change isn't in the repo ? If not, why not ?

Or you want me just to test and to confirm if it works or not ?

Quote:

You mean this change you quote should be in the repo already ?

@kas1e

We need config options for it, on WinUAE, you can pick the graphic card you want to emulate, that kind of thing.

Why we need config option for it, if we all do have on OS4 the same modes ? Only Radeon92xx maybe have BGRA ones, but then, together with ARGB.

I mean, I didn't see why we need it not to be just default and be done with it, if we all do have the same modes on all amigas, and only the very old ones do have both modes together. So even on old amigas users can choose correct screenmode.

@kas1e

Well, when tried to enabled more depth modes, they did not show up. so unless someone figure out why that is. We need to pick modes we want, to emulate or not emulate.

we want to be able to configure this because, some demos, game or program might not support all modes, and we use mode that game ,demo or program needs. Our native modes are there not relevant, if thats not whats needed.

@LiveForIt

I applied your changes to my sources and recompiled uae.

Yes, this fixes the "blue" tint on icons (Amiga OS 3.2.1) and the splash screen (3.2.1 and 3.9).

Not sure if this related to the color format change, or if this is due to your other change today, but the screen drawing is much slower now.

Edit:
Yes, using RGBFB_B8G8R8A8 instead of RGBFB_A8R8G8B8 is much slower.

@FlynnTheAvatar

if its slow, then your native mode is ARGB not BGRA,

but if so, can be that part of old hack is not fully removed.

@All
I wanted to ask if it was possible to have one of these betas that you are using.
I'd love to try them.

Of course I can't contribute anything (having no real hardware).

But I'd like to try them.
Because somehow I manage to adapt them to my emulation.

Thank you.

@white

You will find my compiled version on my personal OneDrive. Please see this post for the link:
Post with link to compiled version

@FlynnTheAvatar

(the first beta)
this is the "BETA" version of uae compiled by:
@FlynnTheAvatar
I tried to see if you had put other versions
but he tells me:

The item does not exist or is no longer available
The item has been deleted, has expired, or you don't have permission to view it. For more information, contact the owner of the item.

here my test with the "metropolice" demo-scene with your first "build" that you compiled.

of course I don't claim that it works perfectly
but I try to adapt it with my emulation.

there is currently no version available on onedrive i looked at.

Thank you.

my test (but it's not really important)

https://youtu.be/aGFGKjPSpNg