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

@LiveForIT
Quote:

You can be sure most of amiga users who do test today any piece of software, didn't test it well enough, but just running/exit. If everyone will test it deep enough, they will find exactly same issues. Me and Flynn surely see the problem with colors on 32bit, and they really, really easy to reproduce by running dopus4 for example. Or playing with prefs:palette a bit.

Quote:

As i point many-many times already, the "pre-remove-hack" version of the UAE compiled the same as i compile it all the time, works correctly , and produce no issues with colors. Once you remove this hack or how it called, the issues are there. While everything is compiled just like before.


Quote:

I can only repeat myself another time : with Hack everything was fast, and works correctly. Once hack were removed, everything continue to be exactly the same by speed (at least loading of WB, opening directories on WB, moving of windowses on the WB), but giving wrong colors.

And as i show you before, i point out on the code which is guilty of, and to make it be back fast and good rendered i just had to revert removing of hack.

In the end of all, the hack was there for reasons, probably. I will write to Rachy and to Tony asking if they can give any advice for us, as it all start to be the same and the same. I was in hope you already reproduce it yourself long ago, but not it seems you didn't. So that the reason we need to cycle around again and again.


Quote:

The same issue happens with anyone's compile. My one, Flynn one, your one. It's just other ones who do test it didn't test it good enough.

If you don't mind, can i just buy for you os3.2, so it will be much faster and easy to check it on your side ? Yes, the bug happens also with the 3.5 and 3.9, just not that visibly from the start.


And IMHO, before we need to understand , why with hack all was fast, and good colors, and now, we have bad colors, but the same speed. And when we will know why, then we will know how to deal it.

But as it was there, it was for reasons, surely. I will ask, maybe authors will help us out with.

Mmh,

The Picasso96 version has an influence on this issue. I updated the Picosso96 version on my AmigaOS 3.2.1 installation from 2.0 (Aminet) to the latest 3.3.1 (Icomp).

The Palette issue and wrong icon colors went away. But the icons lose their color after some screen updates with JIT activated. Without JIT, everything is fine:
- Colors are correct
- Splash screen has correct colors
- Icons do not loose colors

It is just slow.

Edit:
Screenshot with missing icon colors

@Flynn

IMHO with latest P96 there can be all sort of issues (as the author wrote in the README, like he didn't support UAE with it, and if one want, he can use original 2.0 version).

What i mean that probably 2.0 need to be stayed as default and proven to be working.

@kas1e

Still, Picasso96 3.3.1 works better than 2.0.

It might be that there are some hacks in Picasso96 2.0 that need hacks in UAE to work...

@FlynnTheAvatar

I don’t think we should test with so new picasso96, pretty sure the clut stuff is the issue.

@LiveForIt
I just wrote to Almos (the e-uae author) and to Tony (winuae author) explaining them our problem, and asking if they know wtf happens.

Maybe p96 indeed have some issue which 'fixed' by this hack.

Possibly you're indeed right, and additional conversion did happen, but, not always, but in some rare cases. That can explain why we don't have issues with background pictures, other parts of OS, but just “somewhere”. And the fact that i didn't notice any changes in speed of loading/rendering with or without hack, can point out that even if swapping happens, it happens in some rare case, thus not affect the general performance. But i am only guessing there.

Possibly they can give us some information about. At least original ami-win.c were started by Almos, possibly he remembers about..

@Flynn
About your prefs:palette issues — yeah, i have something of that sort when test this issue we talked about.

It really starts to look, like, some palette based special cases do an impact. Not general coloring (as then how to explain that in the background image we have correct colors even with red and blue), but a “some cases”.

@kas1e

This are two different things..
the process of converting a raw into native, vs the process of blit 8bit image into a 32bit image.
8bit blit will uses the clut table..

however the strange thing.. is that clut table was never initialized, so should have worked before.

The colors are stored in state CLUT (upper chars), but they are not initialized on 16bit/32bit picasso96 screen, only when switch to 8bit mode and back, will the CLUT table be updated.

@LiveForIT
Quote:

But when we run on os4 32bit screen and OS3's 32bit screen, the clut table shouldn't be involved, right ?

@kas1e

Its possible that CLUT state register should be pointing to source bitmap, on a blit, if so, then something is really broken.

@LiveForIt
Tested latest commit 142 : something got broken again, demo "adam malyzt" show just a first scene, and nothing else. Like something got broken again with 8bit.

Also, seems that when UAE starts, there are not LEDS visibly anymore (while they enabled, and were visibly prior latest commits).

@kas1e

I think I must remind you, this thing is under development, you should be looking at debug text, too see produces correct results.

not sure how leds are displayed, not changed anything related to leds.

Maybe the issue is in "pen numbers", look inside ObtainBestPen function and similar.

@flash

Your right, that might be the problem, there is special part of code handles OS39, so you don’t have that library version, that code is not used.

Why I don't see this issues.

Also need to keep close eye on the "CM", maybe not set..

@LiveForIT
Quote:

To reproduce, you need or install OS3.2, or install on OS3.5/3.9 a StormC (to see the splash screen, where issues happen too when you run it on os3.5/3.9).

Quote:

You are about colors issues ?

If about broken colors, then that what i have when start UAE and it loads in 32bit mode:



But if you mean broken LED showing, then it is broken now on AGA screens, and didn't show. And this happens only in the latest commits. Few commits back, LEDs on AGA were showing correctly. You can set yourself in the UAE config LEDs to true, so they will be shown (at least, in few commits back, with latest commit it didn't work anymore).


I also got a first mail from Almost, he says that he don't know much GFX code of the UAE. All he says, that maybe that part is a hack, although as it seems to him it is checking the bit depth of the screen and trying to select the RBG mode accordingly.

He also thinks as it seems like 16-bit screen depth would indicate RGB mode with 5x6x5 bit per component and 32-bit is the standard 8-bit per component ARGB.

And it doesn't look like a hack to him, but he didn't know GFX part of the UAE much, so .. Maybe Toni will know more about.

@kas1e

I don’t think I have StormC, unless it’s on a cover CD if I’m lucky, I order AmigaOS3.2 but its going take some time, to get here.

The problem does not show up on OS3.5, you need OS3.9 or OS3.2, there is OS check in AmiGFX, you can try setting OS39=false, and see what happens.

@LiveForIT
Quote:

I set os39 = false; in the graphics_setup(), which seems the only one function where os39 value is set. And it makes no difference to issue with colors, sadly.

ps. interesting, that I have exactly the same issue if i set 32bit screenmode in OS3, and then run it on OS4's 16bit screen. Just in this case is much-much slower than with 32 bit on 32 bit.

Quote:

If i understand correctly : it is. Just not with pure os3.5 install, you need to run 3d party apps to see the issue (like StromC).

@LiveForIt
Some more interesting find:

If i go to prefs:palette, change a bit of anything (just a single bit of anything) and then hit "use", then , when workbench is refreshing, i can see for a single m-second that it was of the correct color.

I made a video to show it, see (i slow down the speed of video much, just so you can see how process looks like):



There i just slow down the re-init process in video-editor, so you can see what happens (but in normal speed that happens in a second, so i only by accident noticed that for a bit of time it has normal colors).


Start watching careful and have a look always on the "system" icon with that boing-ball on top. From the 10th second, you can see :

-- i hit "use" in prefs:palette and workbench start reinit
-- on the second 19, you can see that colors are OK ! See on the System icon, the boing ball start to be red, and all other icons start to be of correct color.
-- then , after this phase, workbench show up, and again, with wrong colors.

So, colors are drawn correctly when workbench about to be inited or something, but then, on top, overwritten with “wrong” colors ? It looks like 2 pass happens or something, one correct one, and one incorrect one ?

@kas1e

I made a video running the Eniga demo and switch through several videomodes...

https://photos.app.goo.gl/gLB4YmNp1GdoBf8b8

In some modes while the demo is running the colours also go wrong.
When switching screenmodes i try to see if the system is still a bit responsive so i fiddle around a bit with the browser in the video..

@All
I apologize for the OT,

In your configuration what you select:
I mean for example in Workbench emulated for example OS 3.2

"uaegfx"
or
"picassoIV"

I personally am using "uaegfx" with Picasso96 installation

Thank you.

@Skateman

Planar (PAL/NTSC) is not a support output
No cooper list work on AmigaOS4, so that will never work!!

UAE uses a lot CPU resource; I don't expect anyone going to be able to do a lot in background. (and we can't load balance, no SMP support yet officaly, ask SSolie when)

the delay between modes, can be due to lookup tables,
there is one lookup table I'm not sure what does! (can be fun to remove and see what happens!), I think one is used for AGA..
(Can be some duplication as well.)