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

@white

It seems I must create a new link every time I update the version :(

The current beta is here: https://1drv.ms/u/s!ApOoV0ole8uGp-hrpmbqp-RTVE-PbA?e=gFZymX

@FlynnTheAvatar

Thanks again.
i downloaded it.

@FlynnTheAvatar

I think you shared a bit to much.... can browse a lot more than just UAE. take care...

@Skateman

Thanks. Hopefully, this works now:
https://1drv.ms/u/s!ApOoV0ole8uGrdccqZANTe6RLmp-1Q?e=SxCtP8

@FlynnTheAvatar

Is the file archived... ?

@FlynnTheAvatar

I have shared it on discord.

@Skateman

No, it is not.

@FlynnTheAvatar

Forgot the execute flag.... stupid me..

@LiveForIT, Flynn
Quote:

Veeery strange. I did delete whole repo, download the latest one (commit #139). And when i run on 1920x1080x32 i _definitely_ have the blue color issue right there.

Icons, dopus4, palette. All have them. Once i just do set in os3s p96 mode on 16bit, and hit "use", then colors fine. But in 32bit it certainly not fine and the same blue issue is here.

It's not only blue, by the way, it also has the wrong "brown" color too.


@Flynn

Are you sure you tested 32bit os4 screen, and in os3 prefs you surely have 32bit set too ? I just need to be sure, because dunno how it can be, that previous version of the UAE prior to hack-removing works fine, and no blue colors issue was, and last ones keep having the same issue.


@LiveForIT
Ephidrena's demo works ok again on 8 bit. And I can be wrong, but it seems to start to be a little faster ?

@kas1e

I manually edited src/gfx-amigaos/ami-win.c and changed the lines. The patch is not in the repo yet.

@kas1e

Quote:

Your right. I double initialized it, when noticed the screen was not initialized, (I did not notice because it was different function, the old code did not take in count of the change in screen depth.)

So, screen switch should be faster.

@FLynn,LiveForIt

Quote:

Sorry. I completely and absolutely lost now.

Before we removed the hack, we have all fast, and no bug.

Now, how we can make it be the same fast and with no bug as before ?

As far as i understand, Flynn tried this "modes swap" and while it fix the bug, it make it be slower much, that correct ?

Because with original hack, everything was fast, and renders correct (point out that maybe it is worth to keep hack then ?) It's cool to remove hacks in favor of correct code, but if with hack it was fast and no-bug, then why we need to go correct way, and make everything be slower-no-bug or not-slower-but-with-bug ?

@kas1e

the old hack can't possibly handle corner cases.
it will tell the emulated OS it has ARGB mode, but will byte swap everything beheld close doors. but on bitmap locks, it does know the format, it only handles simple 32bit reads and writes.
Maybe why its called a hack.

Quote:

Like which ones ?

Quote:

But then, how it is possible that we don't have speed issues when hack was in the place, and now, without the hack we do have the same speed, just wrong colors ? I mean, if hack byte swap something, why we didn't notice speed loss ? Or it happens only in some very rare cases ?

Quote:


At least with this hack in place, I didn't notice anything to be slower, but instead the same as it now, but with correct colors. We do have now the same speed, but with color's issue. And if replace it like you say, it then slows things down.

What i mean : why we not make the hack be default behavior (as it fast, and render things correct for us), and add some options like "no_ARGB_hack", so if one ever will find anything he needs to be not with hack, can use it ?

Or, is it possible to speed things up so the new-no-hack-way will be the same by speed as it was with hack way ?

@kas1e

I wonder, are you cross compiling? Can be configure script has messed up something?
I asked on discord and no one there, had any color issues.

WORDS_BIGENDIAN has to be set on PowerPC, so don’t get any byte swapped stuff when you should not.

If going slow when picked BGRA, then that’s not your native mode.
do you have same color problem on UAE I compiled? Or is this only with one you compiled?

@LiveForIt

Skateman has reported same issues today,
so I guess I have to keep looking.

@LiveForIt

Not sure if that helps, but I compile uae on my X5000.

And I updated the binary to the latest version. If I use Windows to copy the file, I do not need to recreate the link.

@FlynnTheAvatar

did you try last changes, did it help?

@LiveForIt

No, sadly not.

But I noticed something strange: After opening Prefs->Palette, the icon colors are somewhat fixed. If the icons are redrawn, the colors are mostly correct. It does not fix the splash screen, though.

Additionally, selecting any of the upper four colors (used by icons, not WB), the color is replaced by the wrong (blueish or redish) version. Selecting another color fixes the previously selected one, but now the next one is wrong.

Some pictures:

After opening Palette:
https://1drv.ms/u/s!ApOoV0ole8uGrddKPv3C2fagEHqAJg?e=GP092Z

Selecting color 4:
https://1drv.ms/u/s!ApOoV0ole8uGrddJcy3PV9bPJdMOng?e=1uW2Yy

Selecting color 5:
https://1drv.ms/u/s!ApOoV0ole8uGrddHhki9zxNeRnGbBA?e=vgXRqa

This is using A8R8G8B8.