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

@kas1e

Quote:

Yep. there is hack in picasso96.c, it does some byte swapping when it should not need to etch.

Can be interesting to compare it with other UAE’s, is it just EUAE or FSUAE and others as well.

Quote:

Not expected, looks like you can only pick one 2bytes per pixel mode, so you have R5G5B5 or R5G6B5 or R5G6B5PC.

shapeshifter needs R5G5B5

@LiveForIT
Checked commit #118: issues with blue color on32bit still there, but there is also new issue which wasn't there in commit #116 : when you run 32bit on 32bit, and then from os3 wb run the 8bit prod : it split the screen on 2 parts, and the bottom part empty, and second part contain the top part of the image which should be fits in the whole screen.

I.e., the entire 8bit screen shifted down by 50% now. So or this issue of “centering p96 screen” commit, or of “Cast” commit. I think it can be “Centering” one, because with my test all were centered before as well, while now it shifted down on 50 of working area.

AGA screens didn't have such problem, only 8bit on 32bit p96 screens.

@LiveForIT

Tried commit #124, so far that what I find:

-- If we run on 32bit os4 screen, then go to prefs:screenmode and choose 15 bit mode, and hit “test” button, it gives us green screen.

-- If I save 15bit in os3's prefs:sreenmode and then run on 16bit OS4's screen, then it gives black screen only.

-- 8 bit modes stop working on 32bit screens: it didn't draw even 50% as before, but instead just giving black screen and crashes. AGA modes continue to work fine.

-- coloring issues (that “blue” issue) in the 32bit modes, still here.

@kas1e

Quote:

Can’t check, don’t have that wb version.

Quote:

I mostly messed around window mode, maybe a bit overlooked.

Quote:

Will check.

Quote:

Nice.

Quote:

I’m clueless to what’s causing this, I can only guess most likely some hardcoded stuff for x86, need to unit test, find functions that produce wrong colors. A lot of places use image depth instead of image format, BGRA format is assumed in many places. Can also be caused by transparency, as initialize screen with base color, like red, green, or blue, if color is black with 0 alpha, it might not replace base color. It might also not be in picasso96 but can be elsewhere in UAE. There two possibilities I stumble on by luck, or we need test cases, to narrow down where issue is coming from.

The hack used LE format BGRA insted of ARGB to som byte swaping here and there, we don't want to go back to the hack.

does the icons look fine in R5G5B5 mode?

@LiveForIt
Quote:

What you mean?:) I didn't mean any specific WB version issue, i mean if we on running of UAE choose the 32bit screen, and when UAE load up OS3's workbench (usual workbench, nothing specific), and i go to the system:prefs/screenmode and there choose any 15bit mode, and hit "test", then, all i have is just green screen, and nothing else.

So in short: running UAE on 32bit screen, and then inside the UAE select 15mode in prefs:Screenmode, and hitting “test” button cause everything to be filled by flat green color. Without anything rendered on the screen.


Quote:

Probably, all i can say that if you choose to start UAE in the 16bit amigaos4 screen, while being set UAE's prefs:Screenmode to 15 bit mode, it just didn't render anything and give a black screen


Quote:

That issue about only 50% of 8bit screen being drawn, it happens in the commit #118. In the commit #124, even 50% didn't render anymore, everything just black and more of it, it then simple crashes.

Quote:

We of course better to deal with without previous hack, but we need to know what this kind of hack did and for what. In the worst case, we can put it back.


Quote:

As i say 15/16 bit modes simple didn't work (at least in full-screen): when i run UAE on 32bit os4 screen, and choose in os3's prefs:screenmode 15 bits, then everything green. And if I save os3's prefs:screenmode as 15bit mode, and then restart UAE and run it on 16bit OS4's screen : then everything black.

In other words, in full screen mode, 15/16 modes didn't render anything.

@kas1e

Quote:

AmigaOS3.1, AmigaOS3.1.4 and AmigaOS3.5 do not have a test button.
i don't own AmigaOS3.2


AmigaOS 3.5 does not have icon color problem.
you can use a different icon.library

@LiveForIt
Quote:

Basically "test" button only show the problem in easy way, without needs to restart UAE. But bug happens the same when you just start UAE on 16bit os4 screen while os3 one set to 15. Not a green color this time, but a black one.

But strange, i always remember "test" button being everywhere. But probably too much use OS4 and only have OS3.2 (which at least kind of more or less "updated" in usability in compare with previous versions)

Quote:

I hope you are joking :) It all works with hack pretty well, without speed loss, so if you feel not motivated enough to find what this happening and what was that hack for, then maybe it is just worth to put hack back and be done with ?

At least, the hack does not affect the speed (at least nothing visibly so much), but give us the proper rendering in the most usable, fast loaded and fast operated 32bit mode.

And OS3.2 is probably much more tested and better in compare with much older OS3.5, where things make works just because it wasn't done right and working by mistake (or because didn't support something, which newer do).

Anyway, tested new commit #127:

What fixed:

1). Bug with 8bit gone. Now it shows fine again. AGA also continue to work, all fine in this regard.

2). Running in 32bit mode OS4 screen, and then in prefs:Screenmode of OS3 choose 15 bits more and hit “test” now works fine. Same for all other modes, be it 8bit, or 15, or 32 or PAL screens. In this regard, you probably did all the best with already ?

3). 15 but OS3 on the 32bit OS4 screen works well now too : and colors are fine too, should to say. Icons have correct colors for sure.


What remain broken:


1). Running 15 bit OS3 on 16bit OS4 screen renders, but renders by wrong colors. Should I provide a screenshot for ? It renders , i can see things, just a mess of colors.

2). Switching between window mode and full-screen. It's enough to start in 32bit mode, run then some demo in AGA (like TBL's RIFT), then switch to window mode : all fine. And then switch to full-screen again -> problem starts. Then does not matter if you switch back to window , or back to full screen again all the time no rendering, but only some old last bitmap written.

3). blue colors icon in 32bit mode, still there. Maybe indeed better to put hack back and be done with ? Of course hacks bad, but if that issue will take lot of time to deal with properly, maybe hack is not that bad ?

@kas1e

Quote:

I think you have that backwards regarding EUAE, EUAE is old and where few as worked on it, and changes has been minor, at last time EUAE was updated, OS3.2 did not exist.

I do not know, if the color problems talked about in source comment about hack, if they are different. Most likely different, but we only so far noticed it in the icons. We really need test cases to really check all function to see if they do what’s expected. Or we can continue stumble blindly in the dark, and it’s going to take long time, for it get fixed. If we cover up the problem it’s never going to get fixed, and we don’t know the cause of it.

Quote:

For now I don’t know how PAL modes work, and I have not looked too deeply at it, my time is limited. Can be some OS feature something I have missed, WPA might do conversions on AmigaOS4, if so, is it faster or slower, then my own custom routines. For now, I don’t think its something we should worry about right now.

I also think picasso96.c might have some optimization opportunities, there lots of mem copy routines, that might be replaced by faster equals, it will depend on memory alignment, better to look for the bugs first.

Quote:

you don’t need to, I know about it,

@LiveForIt
Quote:

If you want, I can help with. I can just build the latest working commit where we have no such issue, and then, find out in the next commit what code change exactly cause this, then, we will know from where it comes.

At least what we know is that it works as need it till some commit, and then all start to be “blue”. Find out the exact code causing this will be surely a step to find the roots.

Quote:

What you mean when saying “can be some feature missed” ? As far as i can see, the PAL modes work good and as expected. Or you find some bugs there as well ?

@kas1e

SysInfo is broken on AGA mode, its pushed to the side, and squashed. it was like that before I made any changes.

@kas1e

We need a test for:

p96EncodeColor
p96WritePixel
p96WritePixelArray
p96WriteTrueColorData.
p96ReadPixel
p96ReadPixelArray
p96ReadTrueColorData
p96RectFill

just make they produce the correct color or result.
also what you write should be same result, as what we read.

We should not need any test for:
p96 locks / unlocks, p96 bitmaps,p96 screens.

@LiveForIT
Btw, speaking of P96 : it was long ago deprecated in favor of just graphics.library, and those p96 only keeps for backward compatibility. So maybe it is worth to just use graphics.library ones all around ?

Through, of course, need to be sure about no-speed regressions as well.

For example p96WritePixelArray() should be of course WritePixelArray().

Or do you mean test those p96 functions inside the UAE, i.e., inside emulated OS3 ?

@LiveForIT
Ok, find out “blue” issue:

It in the commit where you “try to enable more modes”. In the same commit you change ami-win.c (to add more modes code) and in P96 comment out the workaround.

This is the commit:
https://github.com/khval/e-uae-1-0-0/c ... df5daa05994218a8224969401

Now, I revert the change to the p96 workaround as it was before, and it DIDN'T FIX a problem ! It's the same ! So it is NOT about hack !

So, the issue was the change in the ami-win.c

Then, I just revert the change in ami-win.c, and everything works fine again (with p96 hack, or without, that does not matter):


I.e. i put in case PIXF_A8R8G8B8: picasso_vidinfo.rgbformat back to the 9 as it was before, and not to 6 and instead of your current:



I put back previous :




And blue-bug issue gone.

At least we know now, that the bug is the change of this code, and not related to this p96hack/workaround. And to make it works again even with the latest source code, all I need is to change it back like that.

Btw, also, what I should to note probably, than when we run UAE with this change in ami-win (with previously saved screenmode), on the running, it gives us PAL mode and ask to choose a screenmode again. We select then again 32bit screenmode, and it starts to be “blue-bug”. The same happens visa-versa: if we save a screenmode with your change, and then revert to the old previous-code, then it also asks for screenmode to select again.

Which point out that the list of the available screen modes (or array of them) are changed, and probably, they start to be put in the array of all the screen modes in different order, and so, this is just not anymore the same 32bit mode, but some other one maybe ?

Will experiment a bit more now, but probably you already have a clue why it happens ?

Maybe picasso_vidinfo.rgbformat is not RGBFB_A8R8G8B8 by some reassons with your new code ?

@kas1e

Quote:

Nope.

Quote:

Becouse 9 is PIXF_B8G8R8A8, this is the hack.
that’s what you get when you endian swap everything. (so issue is gone), problem with PIXF_A8R8G8B8 format is now hidden.

I did not understand it at first, I did not get why got wrong format. back then piasso96.c exited in middle of bitmap lock. and system froze. i just stuffed number in there from output log, stop it from freezing my OS.

I have added support for PIXF_B8G8R8A8 in picasso96.c/p96RectFill so you don't get bad colors. with some code changed back.

I want to support PIXF_A8R8G8B8 and PIXF_B8G8R8A8 without assumptions.

Quote:

so you don't know.

@LiveForIT
Quote:

It's not only about put 9 instead of 6, it also needs to put previous code which i quote back too. If i just simple change 6 on 9 i have black screen and nothing works, it should be back and 9, and other code too.

Quote:

Of course i don't know, i only find out where things go bad, and in which part of code.

While we don't know what this happens, maybe worth to put previous code back, and then let it be like this until we didn't understand what happens ?

Or at least add prinfs all over the places and find out what wrong exactly, and what differences between new (non-working) and old (working) code ?

In end of all, i can just write to Tony Willen (winuae author) and ask about those things, he surely can have a clue about.

@LiveForIT

Btw, regarding blue color : this is not only icon's issue. I tried dopus4, and they're it the same: all the red colors are blue too.

The same blue/red problem happens in the Prefs:Palette: you're just enough to click anywhere in this “color circle” to see how all colors are mirrored instead.

So this is a common issue across everything, and not only icons.

Regarding other stuff: I also do test your yesterdays commit, and now 15bit modes of OS3 renders fine on OS4's 16 bit screens. Through it have some strange bug : the top bar of workbench are black, and when moving the mouse over top bar, it starts to be visibly pixel by pixel.

@kas1e

I have no problems with mirrored colors (In Dopus4 palette prefs or AmigaOS3.5 palette prefs, and colors look fine here.).

I think it’s likely your native RX drivers has 32bit mode that use BGRA mode. I don’t do any conventions in 32bit, so AmigaOS3.1 thinks your BGRA screen is an ARGB.

So when you tell UAE to use BGRA it should all be fine.
(change the code.)

@LiveForIt
Are you on old gfx card like radeon9250 ? Or you use the same as most of us radeonhd/radeonrx ?

Because i dont have any special settings, i have all as everyone have. I have only one set of 32bit modes: the ones our drivers give us.

Also, is the fact that code were done with "hack" before and works, didnt point out that there were reasson for ?

Are you trying to say that only me have this issue and only on my setup ? Like radeonrx problem ? But then many of us use radeonrx.

I will check on radeonhd just in case. But the fact that this code was here tells something imho.

@All
Can anyone test plz latest code from repo and check how 32bit works, and if you have same issue as me ?

I have the blue tint on icons and some images (StormC splash screen) on AmigaOS 3.2.1 on 32bit modes using RadeonHD 3.7 and 5.14 (Radeon R7 250).

Edit:
The icons are okay on AmigaOS 3.9, but the StormC splash screen has the same wrong colors as under AmigaOS 3.2.1.

So, not only icons are affected, and it happens on different AmigaOS versions.

@LifeForIt
So, as Flynn point out it also radeonhd,
and also on os3.9 too, just not on icons, but in other places.

Looks like colors is wrong in palettes or so..

But at least we know it happens on any os3.

We can try mail Rachy to ask why it was like this and what reassons for this code was

In any case that bug is problem which we need to deal with. Keeping it like it now not fits for end users of course. They surely will say that 32 mode broken doest matter how it will be explained