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

@kas1e

Just “PICASSO96_SUPPORT»

Quote:

You stubbled on a bug in EUAE, because you defined PICASSO96 instead, save sates is not supported in SDL, it looks like, and so we have the same bug in AMIGFX..

Savestate.c does not include picasso96.h so does not set PICASSO96 define, so this bug goes unnoticed normally.

Maybe add dummy functions, and print a warning..

There are a couple of issues with the configure tests. To fix the issues with the wrong sizes, I use the following:



I made some smaller fixes to the e-uae codebase (#-key under SDL, fix for setting timestamps on mounts) at https://github.com/salass00/e-uae.

@LifeForIt
Quote:

I do all tests always from scratch by deleting everything, clone the repo, and then. So that not it.

Quote:

I checked all .h and .c files in your repo, and all of them include "picasso96.h" , not <picasso96.h> , so should be not issue, but i just checking your latest changes in repo from 15 mins ago, you seems did fix build, so with only DPICASSU96_SUPPORT i can build it now.

Time to test!

@LiveForIT
So, tested.

Running it, and hit "chancel" so to have window mode, and it then says the same "can't open on public screen 'ask'" , instead open on other screen, but all white and nothing renders. So no window creates surely, because it want some public screen names "ask".

So, reboot, and then run again, but choose this time "1920x1080x32" as my workbench are.

It then open again the same screen as before which i can't see when to "amiga+m" and scroll workbench down. But, while before it at least starts in PAL mode, now it just crashes in "uaegfx" driver instead.

So while crash is to fix, i checked what kind of screen uae opens for me that i can't see it under other screens while it the same as workbench one, and :

Workbnech screen have flags:
ShowTitle HiRes AutoSCroll SharePens OffscrDrag LikeWB

The my other test screen (not the uae one):
exactly the same flags as Workbench scren.

And now, UAE screen:
Behind, Quiet, HiRes, AutoScroll, SharePens.

So, for first it have "behind" flag, dunno if it anyhow related to.

For second it didn't have OffscrDrag and LikeWB flags.

I assume we miss "LikeWB" flag, and that why we didn't see content of the UAE screen when scroll down WB ?

@kas1e

its SA_Dragable and SA_Exclusive, just delete this.

@LiveForIT
Yeah, that was it ! Just set SA_Exclusive to FALSE and SA_Draggable to TRUE and this works ! Probably we need to set it in repo as well, as it really cool feature , dunno why there can be reassons to disable it.

And i can scroll down the workbench now, and whole EAUE screen is fully scalled to 1920x1080 (While bring uaegfx crash, but still).

Is there way how to set all the borders to be "black" and not white ?

ps. Wathing demos on fullscreen in 1920x1080 looks cool for sure. Maybe it not resized well to the HD resolutions (leaving us with those borders on left and right), but it still looks much better as it was before , check this out:

@kas1e

Not sure If there is a simple why to do it, I only opened a window centered on a screen.

@LiveForIt
I remember we have this kind of issues back in mplayer times, and they were fixed somehow (At least for P96-PIP render). Need to find out old discussions, maybe it will help.

Is there also a way to scale things a bit "better", what i mean: to resize it more to 1920x1080 somehow ? Or compositing scaling algo is not that advanced ?

Btw, this white border on the bottom, looks like whole rendering area a bit of "on top", and should be shifted in some pixels down.

EDIT: find out old discussion about, only to find out that Joerg fix it somehow to not have white borders , but can't find the relevant commit for.. searhing

@kas1e

In mplayer I opened back window behind, I believe not so elegant.

@LiveForIT
I find out the mails with Joerg where he give me clue how to fix those White borders in P96-PIP, and i fix it simple by adding SA_Compositing, FALSE . While setting it to TRUE together with SA_WindowDropShadows to TRUE too, didnt fix those white strips (in original mail Joerg suggest to try this too). So in end of all it was SA_Compositing, FALSE. But then, can we disable it for our screen which use compositing ?:)

I anyway tried adding SA_Compositing, FALSE to OpenScreenTags() and that didn't help, the same as SA_WindowDropShadows, TRUE as well..

@kas1e

OT: Perhaps one day you will add this to your MUI MPlayer port?

@LiveforIt
Quote:

Maybe some flag to CompositeTag should deal with white borders ? I may ask in os4beta list, maybe some can bring an idea about..

@kas1e

I scale composition to the window, this why just easier center window, it can be change so stop doing that, I guess.

@LiveForIt
Quote:

You mean that can help with white borders to make them black ?

@kas1e

yes, if the window corver, what you call borders.

@LiveForIT
Quote:

I call as border those big white borders on left, on right, and a little bit on the bottom of whole screen. Those big white areas on video i shown above. Not the window's borders (i even didn't see them), but the color of the screen, on which we place our window. Screen's background. Which when window on top of it, made for us it looks like we have big fat white borders, while they are left-overs of default white color of public screen we created.

@LiveForIT
Tried your latest commit as of now: https://github.com/khval/e-uae-1-0-0/c ... 1146d6bb458ee04c5c665b580

with that fix in gfx_set_picasso_state(), so i give it a go with uaegfx (which i use with sdl-render and where it works) and while in your version uaegfx still didn't works as expected, but at least not crashed now, but bring this window:



(yeah, 2 times uaegfx and uaegfx, like 2 instances of the same running and fail).

Hitting ok let me to load up WB (on the PAL) , and in the prefs:screenmode i do have list of uaegfx modes, but, HD resolutions disappear, i.e. no 1920x1080 as before, and no 1280x720. Other ones from 320x240 till 1280x1024 are there.

But clicking on any mode in the list and clicking "test" cause one single screen shown, and nothing can be done, but "alt+ctrl+q" works, so emulator didn't die, just a video.

If i reboot again, and instead of "test" click "use" on one of screenmodes, then it tries to set new video mode and it just draw single frame and video die, but alt+ctrl+q again works for quit from emulator.

But at least we have list of modes now which probabaly a good progress, but still strange why HD modes disapper from this list.. I tested original gfx-SDL build, on the same hardfile, and HD modes surely there.

Also checked window mode: nope, same issue, when you run uae binary and hit "chancel" , then it says "cannot open UAE window on public screen 'ask'. I do check code, and indeed you have in ami-win.c that:



What is that "ask" screen are ? Maybe some leftover forgotten ?

ps. Btw, and seems DebugPrintfs change bring a bit of compilation errors:

@kas1e

Quote:

I'm not working on SDL, if there bugs in SDL I don't know about it, and I wondt fix.

What is that "ask" screen are ? Maybe some leftover forgotten ?

config options, see uae manuall.

stick to 32bit for p96 mode,
no support 8bit at all (black screen)..
and I have lots to do..

@LiveForIt
Quote:

That was me not very clean on the explaing, fixed in above post. I of course didn't mean SDL version not working, it was about your new version, with SDL i only mean that with SDL i use uaegfx and it works as expected.

I.e. with SDL when i run SDL-gfx version of UAE over my hardfile with os3.2 install with uae-gfx/p96 all fine, but when i run over your new version it give me this issues:

1). When you run UAE with your current rendering, the uagfx do not add the HD screenmodes to the list in the OS3's screenmode. While, when running via SDL rendering, everything fine, all modes here. There is no bug in SDL in this terms, but there is bug in our new version instead.

2). When you run UAE with your current rendering, we have the error:

Quote:

Maybe that error is the reasson why HD modes missing.

3). When i hit "ok" after this error, WB is laded in PAL mode, and if i go to prefs:screenmode and choose any screen mode there, then when it tries to sets, nothing happes. Only one frame blit on screen, and nothing else. So i had to "ctrl+alt+q" to exit from. But maybe that expected to be like this for now ?

All of this i test on the same os3.2 installation with uaegfx/p96 (that good for tests and to find out issues).

Quote:

Yeah, i only test 32bit modes so far.

@kas1e

Just pushed the last changes for today, should work a bit better.