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

@LiveForIT
Tried the latest commit for today (#152) : LEDs are working ok again on the AGA screens, but, when i tried to run Ephidrena's adam-malysz from 32bit workbench, it just simple freeze the OS4 and i had to reboot. Tested few times, always same.

@kas1e

Can be some issues remaining, or some problem I have not yet solved, yeh, I think there might some memory corruption going on.
But, a more interesting question do you get the color problems? After I did forced a clut update.

@LiveForIT
Yes, issues with color in 32 bit mode still there.

Did you check the video i post about ? With that thing when we re-init workbench and it's icons, and for a while, the normal colors show ups, and then bad colors overwrite on top. Like 2 pass of 2 rendering.

@kas1e

Yeh... but that was before the last commits.

@LiveForIT
Quote:

Yeah, i tested latest commit #152, and can say that when i run it on 32bit mode, and doing nothing : issue still here. All blue.


But, i found a very interesting way to “fix” the colors. For that, i need to do that:


--- run on 32bit mode.
--- once top bar of workbench is shown (but not load up background, etc.), run "prefs:palette" while workbench is in loading state. And do nothing.
--- now, once workbench load ups, colors refreshes, and start to look correctly !

But this happens _only_ if you're fast enough, run prefs:palette while workbench loaded. Like, the prefs:palette call or do something, which may an impact on this.

See how it looks like on video:




So what we can say is that running prefs:palette in the process of the workbench loading, do fix the final coloring looks. What it all mean ?:)

And as you can see, colors fixes after background image is drawn (and if you have in the same time opened prefs:palette of course).

And fixing of colors happens only if you run prefs:palette in the process of loading of workbench. If you run it after workbench is loading and background image shown, then nope (but if i remember correctly, before, i was able to fix colors by running prefs:palette , change a bit, and hit use, now i seems can't do it, but i can do it in the way i describe it)

@kas1e

So what we can say is that running prefs:palette in the process of the workbench loading, do fix the final coloring looks. What it all mean ?:)

Maybe because it was only partially fixed, there was one function I missed, as the clut table is only used when drawing, it not be updated on vsync.

As far as I can see clut table should unchanged unless, I manually update it, inverted coolers should not have been possible, I can see no peace where its set.

get_color(…) function is only used allocate a color index from the native screens, it’s not actually used to set colors (even if it does), some of the demos I think too few colors are allocated, but that will only effects AGA screens. I think it can be good idea to decouple it from the native color table if have we have a true color screen, like workbench. The xcolor table itself can also slow down pixel rendering, maybe as its type of virtualization of color table. I might be wrong about it.

@LiveForIt

In your commit "Some palette functions moved to video_palette.c" you added the array uint32 load32_p96_table to the file gfx-amigaos/video_palette.c

This breaks compilation on gcc10 and higher.

I am not sure how to fix it. It depends on whether the variable in video_palette.c and ami-win.c should be the same instance or not. Right now, gcc less than version 10 treat them as the same.
If this is the wanted behavior, we just have to add an extern to one of the two declarations.

If the variables should be different in both files then we have to rename one instance.

@FlynnTheAvatar

I think something is wrong with GCC 8.4.0 that I use, it should not be possible as table is declared more than one place, and should produce an error (none of tables are static), one should be extern, as in defined somewhere else. Something is broken as you say, I have some crashes in loadrgb32(…), The GCC is complains a file not found, some time, and when recompile, error goes away.

I hope we can get GCC 10 on OS4.1 / AmigaONE as well.

@LiveForIt

Quote:

We have both GCC 10 and 11 available.

@LiveForIt

As I said, throwing errors for multiple declarations of variable is a new feature of GCC 10 and above. Older versions silently assumed that the other instances should be extern.

Please see https://gcc.gnu.org/gcc-10/porting_to.html (-fno-common).

Not sure what you meant with your comment regarding GCC10. SDK 54.16 contains multiple GCC versions, including GCC 10.3.0 and GCC 11.2.0.

@LiveForIt
Quote:

We do have long ago GCC10 and GCC11, and not only for AmigaONE, but for any OS4 hardware. As others mention: the latest versions of GCC for OS4 were included in the latest SDK. That include GCC10 and GCC11. Some of us already use it for few years via manual build of Adtools repo, but with new SDK that all were included in, and everyone can use any version he wants now.

When George prepares new SDK, some of us were against of including gcc8 and gcc10, as it didn't make big sense as gcc11 is the last one we have already (also included in SDK), but still all the version were included in case of someone needs to make some experiments with, which may a bit confuse pals when install new SDK and didn't read it careful when installing it.

Anyway, sticking on 8.x on OS4 today make no sense anymore, just use GCC 11.2 from latest SDK.


As for errors, the reasons for most new errors coming from GCC 10, 11 and 12, is the fact that they not tolerate anymore to bad code practices by default, and as Flynn says, many warnings are turned into the errors now. You of course can hide them with special switches, and continue to build it like it was on 8.x, but that is hiding off potential errors.

And yeah, you will have new errors from all your projects probably when will recompile over GCC11 and co, but those will be real errors you need to deal with, just older GCC were forgiven for them.

@FlynnTheAvatar

Not a new feature.

No, you used to get a link error, if you had more than one of the same symbol, maybe how symbols are created is changed.

@kas1e

Pretty sure I had gcc 6 or something before installing latest SDK.

@LiveForIT
That probably 8.x you have (before we had 4.x, then switched to 8.x). The 6.x version were mostly used by those who do compile things for “Tabor”, and the 6.x one was the latest which can compile SPE code (that why it was included in the SDK as well).

So… or you have 4.2.4 (very old one), or 8.4.0 (a few years old one), while most of us already use GCC 11.2.0 (the latest included in the SDK).

It is always better to be on the latest GCC, at least 11.2 one not _that_ forgiving of bad code practices as it were in the 4.x/6.x/8.x times.

If you use a cross-compiler, it is pretty easy to build GCC11.2 for, but if you use amiga-native compilation, then better to just update the SDK to the latest one and choose 11.2 on the installation steps. Or just make a full installation of the whole SDK, and then by the script coming with the SDK, select the default GCC in use (by this way you may have many GCC installed at the same time, and decide the one you want to use currently).

You guys are awesome 👏. Keep up the good work.

@LiveForIt
Tried to build today's version to see how 32bit colors issue reacts now, but wasn't able to build it as have undefined references to convert_16bit_to_8bit coming from ami-win.c.

They defined in video_convert.h, but nowhere in the code present.

@kas1e

looks like something not commited yet...

@LiveForIt
With latest commits, seems to be builds again.

Tested 32bit screens : issue with colors still there. Tested also running of AGA and of 8bit screens on 32bit ones : all fine.

So far the only issue is that “pen” issue we do have there. It probably needs some more debug…

PS. did you get os32 already ?

@kas1e

thats not what I have worked on.
Not yet regarding AmigaOS3.2

Ordered from Amedia-Computer, I no tracking number yet..
I guess it takes time to put things in boxes and get someone to pick it up.

@LiveForIt
Quote:

Cool ! At least when you will be easy to reproduce, it will be surely easy to debug…

Btw, i see in comments of latest commits you add some 8 bit gray scale conversion from 32bit, can you explain what the needs of it and where it uses ? (want to make a test about as well)