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

@LifeForIt
Quote:

Tested:

So far, the issue with "uaegfx and uaefgx both use DisplayID: 50001000" and the missing 1920x1080 and 1280x720 modes is still here.

But at least now, when I run prefs:screenmode and choose any 32-bit mode and click on "test," I do get the test image. However, when I exit from "test" mode, the screen turns blue and nothing is visible, and the only way to exit the emulator is to press ctrl+alt+q.

Anyway, we can now choose 32-bit modes by hitting save, and on rebooting the emulator, it did use those modes, though with some rendering issues.


I made three short videos to demonstrate the rendering issues at 800x600, 1025x768 and 1280x1024:

800x600:



1024x768:



1280x1024:




As you can see, the higher the resolution, the smaller the working area, and everything you move to the right side appears on the left side of the screen.

The only mode where the size of the rendering is correct is 640x480.

If you run anything while using uaegfx 32bit modes (for example, any demo that requires a different video mode), the screen will turn blue as well, and only ctrl+alt+q will help you quit the emulator. But that's probably the same issue when we hit "test" in screen mode preferences and then exit from test. If I run the same demo when I reboot in "PAL" screen mode, everything works.

It's like, restarting of the video modes is broken, and this issue can be reproduced in 2 ways: either you run screenmode and hit "test" on any mode and try to exit from it, or you just simply run anything when you are on the workbench, and it should switch to another video mode.

Overall, we have made significant progress: we can now see rendering in 32-bit modes! Just some bugs to fix:

- Restarting the video modes did not work.
- Some bugs in the initialization process
- Rendering issues with any resolution greater than 640x480. 

@kas1e

Quote:

It should be built in somehow. They merged a few amiga.lib functions in. Well the tool type ones were as I use them but I forget how I linked them in.

If the AmigaOS target wasn't there it would look for nanosleep, usleep then finally SDL. Maybe using SDL would be good if it still uses it?

Quote:

Could be better using nanosleep() depending what it does. Because of the nature of AmigaOS; allocate, use, free, it needs to setup a simple timer beforehand. Might be best to add custom OS timer code that does this.

As to Delay(). Load up Snoopy. Activate device opens and look at all the timer.device entries airing AmigaOS dirty laundry.

@Hypex
Tested, and that's not all that bad. For Delay(300); it open 60 times timer.device, and 60 times close then. Mean for "5ms" it 1 open/close act.
But exactly the same happens for AmiDock and XDock while them running. They throw all the time open/close of timer.device, but also not thousand times, but not 2-3 times either.
I remember some years ago, some of us found that some function like a madman open/close thousand times timer.device, but it then were fixed.
Anyway, yeah, better to not close/open things lot of times without needs.


@LiveForIT
Btw, is there any technological reason why we can't render to the "full" size of the given video mode when use compositing?
I mean, if we open 1920x1080, why we can't render to the whole area, but instead render to 1369x1080 window?
It's Ranger says that it's 1369x1080, maybe that should be 1440x1080 instead, and those missing pixels explain the white border at the bottom?

At least SDL2 use composting and can use any modes, and Odyssey can have a video played in Fullscreen in 1920x1080 as well.

If we can deal with, then there will be no needs to worry about "white borders".

@kas1e

Quote:

No, just not done yet, or bugs.
and fake screen mode list..

@LiveForIT
Tested your new changes, including “getting closer” commit and one bug surely gone: this issue with wrong rendering size created in different resolutions as i show on videos: so, now, if I choose 1024×768 and click save, then it renders in new resolution as expected. Also gone issue “with part of screen being moved to the right and appears on the left”.

But some new rendering issue happens : everywhere like one pixel missing: fonts start to look a bit worse, like not all pixels are drawn. In the windows I can see it well, like some pixels drawn not on their correct place. And this did happen differently in different resolutions. The higher resolution, the worse this rendering issues are.

Additionally, another new issue arises, when I hit “test” in the prefs:screenmode it crashes in init_comp(), and ignore DSI didn't help need to reboot.

But sure getting closer, hope you will not burn out and can finish that p96 stuff :)

@LiveForIt

Did i understand right, in the window mode we also use compositing now ?

Why i ask, that seems it's the first time we can run in window mode which is resizable: not with SDL, not with old AmiCGX driver we weren't able to resize the window, especially with native Amiga modes. At least that how i remember it. Now, while it still not very ideal, it pretty cools still ! Check this out:



Maybe someday if you will be done with p96 we can add on top some kind of popular scaling algos on top... As i remember from ScummVM and DosBox, the best one in terms of speed/quality tradeoff is a HQ2X one.

Compositing default one is probably some kind of linear scaling ?

@kas1e


Did i understand right, in the window mode we also use compositing now ?

Yes, and its one of the major improvements, your no long stuck with a few tiny pixels.

Quote:

Yes, there stuff, to do, like remember window size, pos, and so on when iconify, and also maybe when switching between fullscreen and window mode. (not a priority)

Quote:

Yes its cool.

Quote:

Sure, you can add what everyou like, composition uses GPU and has low CPU overhead, maybe shaders can do better, but that’s not something I’m familiar with. So, what we have now is all you’re going to get from me. With exceptions of a few bug fixes.

I’m more interested in looking at other neglected parts of EUAE.

@kas1e

Its progressing nicely

@LiveForIt
Quote:

If didn't consider the remain bugs, then yeah, those things will be good to have for final release:

-- remember window size and position when iconify
-- remember window size and position when switch from window to full-screen and from full-screen to window back.
-- Don't know if it controlled already by configs, but will be good don't bring ASL requester when we switch to/from window/full-screen, but open window always on workbench screen, and full screen open the same as workbench one, or, use the mode we set in config for full screen.
For remembering the size/position of window when switch can be used the same code from iconify probably?
-- use whole screen in full-screen mode to fill all the area (so no needs to deal with “white borders”, as they will be not seen).


And for current bugs which need to deal with (at least if we take as the last change an “Getting closer” commit) can point out on those:

-- switching of video-modes didn't work when we run anything from workbench which need other than P96 mode, instead giving blue screen. But if we then do switch to window mode, then blue screen gone, and we can see the correct rendering. Probably issue with re-init of video modes between P96/Native ones?
-- crash in ami-win.c's init_comp() when we hit “test” button on any video mode in the prefs:screenmode. Crashlog point out on line 1358, which is:

-- wrong rendering when we use bigger video modes (it's like one pixel didn't add somewhere, or added on wrong place), which looks like distorted font then.
-- missing HD resolutions in the piasso96 video modes, such as 1280x720 and 1920x1080
-- p96 error on the start with words "uaegfx and uaefgx both use Display ID: 50001000". Maybe that error is the cause why we didn't have HD modes in list ?
-- when we in window mode with P96 workbench, then resizing of window leave big part of window being not updated. There is video to show how this bug looks like:



And this bug happens only when we use P96 modes, when it amiga-native modes resizing fine. Can add only, that the size of the non-updated part, is the size of the original window size in which we run by default.

That probably all at the moment. At least that what i find from my tests.

Keep motivated, this stuff really cool!

Btw, do we need to keep that USE_CYBERGFX and USE_CGX_OVERLAY ifdefs in our version ? IMHO, there are no needs anymore for ? And removing them will make code looks much better and cleaner, while keeping them make no sense anymore. IMHO of course. At least in gfx-amigaos's files, this make no sense anymore.

@kas1e

IDCMP_NEWSIZE, IDCMP_REFRESH or something.
not sure, but I think the AGA screen is drawn into the RTG screen.
that code is maybe not needed, when we use composition, I made some changes but had to revert because of a black screen issue.

Custom screen mode use AGA height and width to find screen mode, not picasso96 width, height.

@LiveForIT
Quote:

At least when I run in full-screen with 1440x1080x32 mode first, and then run some AGA demo from it : it shows a blue screen, but (!) if we do ctrl+alt+s to switch to window mode, then in window mode demo renders fine and all visibly. And the same if i do it another way : run in window mode, run AGA demo from, have blue screen, switch to full-screen : demo renders fine.

It's more like some initialization sequences missed, because if it auto-fixes when i switch between window/fullscreen, then it IMHO about re-initialization of native Amiga modes.

PS. will it be good idea if i will post all the bugs related to p96/compositing we have on the github bug-tracker for easy tracking them, or at this point it makes no sense ?

@kas1e

That’s, not the same issue.

But the P96 to AGA, AGA to P96, is also now solved, some problem with resource leek, unfried signals, that’s all. When I find that problem, I can push the changes.

No need to report bugs on github at this time, I experience the same problems as you do.
(Exception is the TEST button issue, as I don’t have OS3.2, only 3.1 and somewhere 3.1.4, I have also somewhere 3.5)

@kas1e

Quote:

When I checked it out a few times there was a hive of activity with timer.device. It was hard to tell why it was being opened so much given a process should only need to open it once. Since I was just monitoring activity it just looked a bit too much for existing processes.

Quote:

LOL. It was more of an issue in the slower 68K days, given each time a port and request would need allocating if not already, and the OS device list searched by name one by one. But I still think any OS functions using timer.device should keep resources open and store in the process structure for repeated use.

@LiveForIt

Quote:

That's cool. Is it only window mode? Next to adapt resize to full screen.

Also, I found out UAE isn't the only one with folder HDD problems. I've had this issue on FS-UAE where searching a folder HDD crashes. Turns out it might be related to international characters. Don't know about ours.

https://eab.abime.net/showthread.php?t=112817

@Hypex

Quote:

it's also used in fullscreen mode.
Of course, tries to keep aspect ratio, this way we have gray borders, (that should be a prefs option, not enforced like its now.)

Nice progress. Thank you!!!

@LiveForIt

Quote:

Problem found, unrelated problem, when UAE switch between Fullscreen and window, sound is reinitialized, but not closed first. Technical its does not make any sense.

@LiveForIt
Cool, tested! Good progress for sure:

Issue with running of Amiga native screens stuff from p96 system works: checked in window mode, checked in full-screen mode, and switching in process between window/full-screen. Now all ok. I didn't test it very well, but brief tests show that it's working fine now.

Next, issue when we in window mode with P96 workbench, then resizing of window leave big part of window being not updated —gone too. All fine now.


Then, issue with when we hit "test" button in prefs:screenmode changes : now it didn't crash in the ami-win.c's init_comp(), but giving some other error. To reproduce i load up workbench in 1280x1024 and then in prefs:Screenmode choose 800x600x32 and hit “test”, then screen immediately closes and switch me to the console, and report in console:



Now after 10 or 15 seconds (the time used in screenmode when you hit “test” button), we do have one more time the same error (when it probably tries to back to original p96 resolution, but can't), and only ctrl+c help and quit from emulator.

Other issues like wrong rendering in bigger resolutions, missing HD modes and p96 error on the start with words "uaegfx and uaefgx both use Display ID: 50001000"—those didn't change.

And i think there is graphics memory leak now: I just run the docky which show how much VRAM memory remain, and find out that with every change to the new resolution, it increases the video memory usage, and when i change it again, do not freed, but instead accumulated.

So you can just go to prefs:screenmode and many times switch between 2 the same resolution by hitting “save” button, and you will see how VRAM with each switch eats. Exiting from emulator do not free VRAM memory either.

But so far there is progress for sure. I will stress-test it a little more.

@kas1e

it will use more vram in p96 mode now, as will allocate two bitmaps, one for AGA and one for p96.

This is to avoided confusion, and rendering problems, but should be freed when going back to AGA mode.

@LiveForIT
Quote:

That no problems IMHO if there will be 2 bitmaps. Of course if switching between modes will freed previous allocated memory, because if not, with every new run on anything on any other video mode, you will have less and less vram.


Quote:

Issue even without involving AGA modes : just run on p96, go to prefs:screenmode, choose any other p96 mode and hit "save". You will see how memory eats. Then one more time : more memory eat. The more modes you change (even the same ones) the more VRAM gone. Exit from emulator didn't freed leaked VRAM too.