e-uae-amigfx version is that one exactly from sourceforge. And second one, also from sourceforge just compiled over SDL1. Which one to use choice for yourself, both have flavs. I choose SDL one because of better handling of window/fullscreen modes (while it still suck, but better than in amygfx version)
Then, there was 2 little attempt to improve it a bit (from what sourceforge latest code are): Salas00 add "Add support for hardfiles >2GB on AmigaOS 4.x." https://github.com/salass00/e-uae
Then i later add to SDL version "alt+enter" to switch between window/fullscreen modes, and compiled all over 8.2.0 GCC + -O3 optimisation and newer SDL1 (so iconification works, etc). And if i remember right add that Salas00's patch too. There is latest binary : http://kas1e.mikendezign.com/aos4/uae/uae_no_mcrxr.zip
But to answer on your question like is anyone for real working on this now : no. At least no one publicaly says so, or setup some github account so we can see progress.
But i for one wish some normal modern EUAE, and that what for real can be good to have:
1). SDL2 instead of SDL1 2). alt+enter to switch between window/fullscreen 3). Rewrte totally rendering-to-amigaos-screens part to use Compositing. Because as it now, it just suck hard : can't open normally in big screen, didn't have filters, can't be normally resized, all the time problems with correct mode settings. 4). something bad with multitasking : once you run it, it didn't feels like app from amigaos, its like take out everyting, when you alt+m from it when it in fullscreen it just pauses, and so on. 5). Update core from winuae/fs-uae/whatever, but in general for me it not that important in compare with normal rewrite of amigaos specific parts. Besides it surely will be harder to do properly with JIT, so some bedroom coder will be of no help here.
thanks for the comprehensive answer. WinUAE/FS UAE have come so far it would be great if someone was able to port over all those changes. I know it's independent project but you'd think OS4 rights owners would want to have the best possible implementation of it especially it really is accurate 'software custom chips' for all but the most realtime critical use cases i.e. flashy demos which look nice but which are not "must have"
I I'm thinking about doing something about EUAE for where long time, most likely keep thinking about it, maybe after messing with utf8.library I have look at it.
Yes there is a lots to do and fixed on EUAE, as you talked about, and also it be nice to get bsdsocket emulation working as well.
Maybe add iconification, add hot keys for frame skipping, some way to pause the emulator maybe, some way lock mouse inside of window.
Get EUAE to respect configuration file again, for window mode / fullscreen mode.
Not sure way it is like it is now, is it because of runinuae maybe?
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
How hard it would be to update UAE for the AmigaOS like systems to the latest official version (4.5.0) ? I remember that atleast up to version 1.0 Richard Drummond was able to keep it up with regular updates without too much problems
@LiveForIT Find out that you've been tinkering with the EUAE for now, and see that you already use the latest version with the ppcjit and salas00 addons, and that you added compositing support there.
So I want to ask: do you wish to spend some time on it, or is it just for your own pleasure to add a few bits and be done with it?
I ask because some things irritated me for a long time in our old UAE, but one in particular stands out even now:
When you run anything in EUAE in fullscreen mode and then switch to the workbench and scroll the workbench down, graphics output from EUE just stops. You can also move the workbench screen up and down to make it work. When it stops, EUAE's graphics output stops as well. I feel like a MS-DOS app rather than an AmigaOS4 app. :) Maybe that's already fixed automatically when you add compositing?
And, while I understand that no one wants to spend that much time on it, there needs to be a lot of cleanup of the entire EUAE source code: to open and close libs in the correct places, to initialize all unitialized values, to build it using gcc 11.3 and fix all of the warnings it throws, and to replace depricated functions too.
More of it: I always dreamed that it would be really good if one could just put the current SDL1 code out of the code mess into some separate file and then create another one for SDL2. So, to make it easy to completely ditch SDL1 in favor of SDL2, That will bring a lot of new functionality and auto-fix some bugs, and you will most likely be able to use compositing over it in places where your own didn't work, for example.
Yeh.. I was thinking about spending some time on it, it shamefully bad.
The native GFX was always a lot faster than SDL build, don't know why..
the native GFX build lacks P96 Gfx emulation, that needs to be added.
On my list:
* Add drag & drop support for ADF. * Get EUAE to remember last floppy path from ASL. * Look at P96 emulation. * look at BSDScoket emulation. * Look at SCSI emulation, never got CDROM auto detected. * Smart refresh, active / none active window (different task pri, frame skip.) * Iconify button in window frame. * Fullscreen button in the window frame.
Don't know I will successful on all, any improvment is improvment.
what I will not do, is spend time on updating the EUAE core, chipset emulation etc.
Quote:
When you run anything in EUAE in fullscreen mode and then switch to the workbench and scroll the workbench down, graphics output from EUE just stops. You can also move the workbench screen up and down to make it work. When it stops, EUAE's graphics output stops as well. I feel like a MS-DOS app rather than an AmigaOS4 app. :) Maybe that's already fixed automatically when you add compositing?
Maybe, some of the CGX stuff in it, maybe its causing problems. Should maybe be removed and cleaned up.
Quote:
And, while I understand that no one wants to spend that much time on it, there needs to be a lot of cleanup of the entire EUAE source code: to open and close libs in the correct places, to initialize all unitialized values, to build it using gcc 11.3 and fix all of the warnings it throws, and to replace depricated functions too.
Almost all of that is done already. Pretty sure common parts are ok, so I don’t need to look at this.. only the Amiga parts can be sloppy.
Edited by LiveForIt on 2022/12/4 18:20:15 Edited by LiveForIt on 2022/12/4 18:21:07 Edited by LiveForIt on 2022/12/4 18:25:52
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Is there anything wrong with ? I currently checked and my os3.2 runs in fullscreen 1920x1080 on x5000 via euae. That of course via SDL, maybe amigfx have issue with ?
Quote:
* Iconify button in window frame.
You mean when in amycgx mode ? Because SDL one have iconify already.
Quote:
* Fullscreen button in the window frame.
You mean usuall os4 gadget called "rezie to screen" ? Or you want to make special button somewhere ?
Having scaling algos will be nice as well (i.e to have old demos to run on 1920x1080).. But that all already a lot of work.
Is added compositing improve anything in terms of speed and whole rendering ?
Having scaling algos will be nice as well (i.e to have old demos to run on 1920x1080).. But that all already a lot of work.
Already done in mplayer, so maybe not a lot of work, if we only need cut & paste a bit.
Quote:
Is added compositing improve anything in terms of speed and whole rendering ?
Not sure, maybe it does, it does detach the bitmap from window, so maybe less interference from intuition. Primarily it stretches output to screen, so it fits so does matter what resolution you pick. And allows you to resize the window, if you think graphics is bit too small. Technically its extra work, but only done on VSync, so does not add a lot of extra work, and the operation is a GPU operation, so does not effect CPU emulation much.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Is there anything wrong with ? I currently checked and my os3.2 runs in fullscreen 1920x1080 on x5000 via euae. That of course via SDL, maybe amigfx have issue with ?
SDL is fine, but not AmiGfx, don't know why that is.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
SDL is fine, but not AmiGfx, don't know why that is.
Probabaly because those who works on, were expected that SDL will be the main one, and ditch amigfx one.
Honestly speaking, our SDL2 today is absolutly native os4 library, so maybe it worth just to migrate to SDL2, and not worry with AmiGFX anymore.. Through maybe AmiGFX is good for very old machines..
For now AmiGFX version is almost mandatory on Sam machines, SDL version runs but a bit jerky expecially in some bigger games or when running AmigaOS 3.1 even with JIT enabled. maybe it will faster with SDL2
For now AmiGFX version is almost mandatory on Sam machines, SDL version runs but a bit jerky expecially in some bigger games or when running AmigaOS 3.1 even with JIT enabled. maybe it will faster with SDL2
Copy that. And if you have Sam440ep-flex with PCIe HD card, it is even bigger need ( SDL is relatively slow there ).
And I don't know how complex is it, but very nice bonus is also have some native acceleration ( except SDL ) with amiGfx. ( like MorphOS have functional parameters "amiga.use_overlay=yes" and "sdl.use_gl=yes"
Only idea form non-coder
AmigaOS3: Amiga 1200 AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000 MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
I I'm thinking about doing something about EUAE for where long time, most likely keep thinking about it, maybe after messing with utf8.library I have look at it.
Yeah I've noticed a few issues over the years. The most major is you can't trust it to write directly to HDD volume as it crashes doing so. Next that P96 is missing. Wanted to use the JIT version but found it's fast with no RTG support. Because P96 needs SDL. Given P96 should give direct RTG support I thought it was strange it didn't use AmigaOS or P96 directly. But when I looked the UAE builds apparently needed SDL for RTG. Next I would say key mapping is all wrong as RunInUAE ignores shift key.