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

@kas1e

yes, they are.
(Some of routines does 2 pixels in one operation.)

I found these routines to be pretty efficient. But they done on the CPU, so it not as fast as direct rendering, but they are useful for window mode.

In Basilisk II I had to use buffer all the time, but E-UAE I only need it, if I must convert.

This why I think the “ASK” option, might be time to delete.
Scaling will not be option in all modes, but that be fine I think.

@LiveForIT
Quote:

Aha got it

Quote:

You mean totally delete this option from amiga.screen_type configuration ? If so, we then will be in needs to have with this deletion new gfx_depth option probably (as Rachy planned back in times) so users can specify the depth they need.

Or you just mean to delete it from constant switching to/from window/full-screen, and spawn it only one single time on running if this “ask” option set ?

@kas1e

Fullscreen:

AGA modes will always use 32bit output with scaling maybe.
(true color mode needed becouse of cooper)

P96 8bit will always use 8bit no scaling, closest mode.

P96 15bit will always use 16bit with scaling.
P96 16bit will always use 16bit with scaling.
(no point using 32bit, adds no colours, only needs more data to be moved)

P96 24/32bit will always use 32bit with scaling.

Yep, so we don't need ask, we will need to know monitor aspect ratio. when looking for mode.

@LiveForIt

Sounds good, all with scaling, but only worry 8bit p96 with no scaling … Is there no way to make p96 8bit be scaled too ? I'm just thinking of how it will look like when one run 1920x1080x32 in P96 on the same opened screen, then run the AGA stuff (and which scaled well, so no monitor re-sync happens). But when it will be 8bit p96 software running from 1920x1080xp96 screen, it will then switch from 1920x1080x32 to something else, like 640×512 and re-sync monitor, etc…

Quote:

You mean making "custom" option of amiga.screen_type settings be default one and just rewrote auto-search code to take gfx_widht/gfx_heigh, and probably need to introduce gfx_depth ?

@kas1e

no, composition is only 16/32bit.

Quote:

yeh something like that.

@LiveForIt
Quote:

Ah, that bad .. Probably only way then software scaling, or some mambo-jambo like covert to 16 bit, scale, and convert back to 8 bit.. But that to be seen, maybe all will be fine as it.

@LiveForIt
Btw, on what compiler you build your local versions ? I assume 8.x one ?

Why I ask: I do use GCC 11.3, and this one is not that tolerate to some warnings and bad-code practices, so, that why there need to do:

1. in src/main.c comment out include "bsdsocket.h" (to avoid multiple definition of `socketbases')
2. in src/md-ppc-gcc/support.c add "extern" before frame_time_t timebase; (to avoid multiple definition of `timebase')
3. in src/audio.c add "extern" to uae_u16 dmacon; " (to avoid multiply definition of 'my_dmacon').

I can make those small changes and pull commit to your repo, if you don't mind, of course. Those change should make no impact on anything else, just the latest GCC will be ok with.

@kas1e

Just PM me your e-mail and I add you to the repo.

@kas1e

Last commits, don’t expect anything to work… I'm in the middle of rewriting code.

@LiveForIt
Right, was about to try it :)

@LiveForIt
I see bunch of new commits, is it in kind-of-working shape now and tests can be done ?

@kas1e

It's work in progress as normal.

Well its not crashing anymore, I have some work to do on bitmap / buffers I belive, also I’m not sure correct function pointers are used.

@LiveForIt
Right, so will test it too then

@LiveForIT
Tested commit #83

All tests done with:

amiga.screne_type=ask
gfx_widht=1920
gfx_height=1080
gfx_width_windowed=640
gfx_heigh_windowed=512

On running choose 1920x1080x32 : P96 WB loads fine in the same mode, and the speed of whole loading the same 14-15 seconds as with latest tested commits. So there are surely no regressions.

Next, tried prefs:screenmode and button "test" with all the 32 bit screen modes: all fine too. The same as "use" of those 32bit screenmodes reacts as before.

So in terms of P96 and 32 bits all seems ok.


Next, to issues:

1. When run on 1920x1080x32 screen, and tried to change in prefs:screenmode on any 8bit mode, it then gives black screen or all sort of diagonal/vertical/horizontal lines of different colors. If i tried to run on 1920x1080x8 bit screen, it still opens 32bit screen, and when i tried to change in prefs:screenmode on 8bit screen i do have the same.

So, to make it short, 8bit P96 modes all didn't work.

2. AGA modes didn't work now too. For example, if i hit both mouse buttons, and should have visibly boot-menu, all i have is black screen. If i run uae, and hit "Esc" (so to open on wb screen in the window), i can see that color in the window even didn't change till p96 starts, it looks the same gray like this area didn't have anything to be drawn into.

I also did try to run some TBL's rift demo (the one i use to test all this), and now instead of actual content it also shows a black screen. While demo works, sound coming.

The last AGA/8bit test was running JP19 diskmag which use 8bit screen for drawing title/finish pictures, and AGA for drawing mag itself : both modes didn't work and produce black screen.

And in serial, before whole machine totally freeze, i have lots of that:

Quote:

Before new rewrite the title pic in diskmag was black screen of course (as it 8bit screen), but the AGA part (mag itself) were ok.

So to summarize:

1). AGA modes didn't renders anymore (black screen)
2). 8 bit modes didn't renders as before, but, instead of black screen only, it also sometime produce some random gfx trash.
3). Heavy crash-lockup with words about "btimap can not be the same as comp bitmap" when switch between non-working 8bit and non-working AGA.

@kas1e

We can’t convert to itself, we need extra bitmap..
so should be close to getting convertion rutines working.

AGA stuff, is not tested, and will be worked on last.

So, some of issues will go away as well, when I change how screens work, as for now, ASL requestor is useful for testing.

@LiveForIt
Quote:

Yeah, at least and when i hit the "test" button in prefs:screenmode when choose 8bit screen, it also saying the same as when i swith from aga to 8bit :"bitmap can not be the same as comp bitmap". So yeah, the same issue.

Quote:

Yep, those moments can be dealt with later, for testing this requester helps.

@kas1e

Quote:

No its not, i think messed with WritePixelArray format.
the error is only for P96, so this is a messs.

@LiveForIt
Quote:

Why not : in both cases it was opening of the 8bit screen. In the case when we hit "test" button in prefs:screenmode, and in the case when we tried to open 8bit screenmode from diskmag (and it's again open the same p96 mode, because this is the one i set in the preferences of mag). So that the same issue mean "open 8bit p96 mode". I didn't mean AGA there, just 8bit modes. Just in case with pure "test" in prefs:screenmode it wasn't freeze, as it tries for few secs and then exit, but in dikmag it was freezing because of open 8bit mode for much longer time.

EDIT: Tried commit #87, AGA mode works again. 8bit modes produce green screens, and in the console says:

@kas1e

Yes, I think you find something there..
looking at init_colors() thing.

Fixed that, now I have a system freeze no crash, its stuck somewhere.

@kas1e

Another milestone retched, enjoy.

As for 15/16bit modes:

It looks like E-UAE filters screen modes based on display output, I guess it makes sense on XWindows or SDL, so adding 15bit / 16bit modes does not help, it also keeps a valid screen modes list somewhere.