Big video about E-UAE on AmigaOs4 !

@All
In the last month, i working on the video about E-UAE, where describe basics and the roots (i even find and build very first UAE 0.1 for OS4), show how current E-UAE behave, compare with old E-UAE, discuss compositing, how it emulates latest os3.2.2.1, how integrate dbl-click support, etc, etc.

Hope some of you will find it interesting, or, at least, kind of entertainment.

The music used in the video are from rloaderror/Ephidrena, and used with his permission, of course. There is :



Thanks for watching!

@kas1e

Nice video!

Did you build euae 1.0.0 yourself? With a cross-compiler I presume?

Since compositing is used, does it also enable hardware filtering modes?

I can recall that I've played once with having video output mapped as texture in a warp3d windows. This also allowed hardware scaling and hardware filtering. But that was two decades ago. Maybe the same can be done with Nova as well. Not sure if there's a benefit over composting. Maybe it allows better control over filter modes. The one that that annoys me the most is that I can count the pixels.

Edit: Is this the most up to date guide to create a cross-compiler environment? https://www.amigans.net/modules/newbb/viewtopic.php?post_id=116486

@geennaam

Yeh, you can.
Probably should be an option to enable / disable.

The issue is that its only partially hw scaled, for example if you have a 320x256 resolution it sw rendered/upscaled to 640x480 in AGA mode, then it can scale to what screen you selected, with hardware scaling for example 800x600, so changing option perhaps does make not so much difference.

you also get stupid diamond artifacts, depending on shade/pixel pattern, that might also not be what you want.

@kas1e

WOW!! Thanks so much for sharing your video. Very interesting and well done.



I also use E-UAE on my OS4 system to emulate AmigaOS 3.2.2.1.

In my case, I use full screen mode so it looks like the Classic Amiga has taken over the system.

Since my system is a MicroA1 with 256 MB RAM and onboard Radeon 7000 graphics with 32 MB graphics RAM, I keep things very simple to conserve system resources. For example, I don't use compositing effects.

But, it is very interesting to see what can be done with a powerful machine.

Thanks,

redfox

@geennaam
Yeah, i use crosscompiler for, but be aware i didnt use very latest version of liveforit's code, as after last commits (merging ones) there were pretty noticable speed issues, so i build code somewhere prior last 10 or so commits.

As for crosscompiler, i wrote small tutorial about, it still should fits: https://os4coding.net/blog/kas1e/how-b ... utils-2232-gcc-830-cygwin

As for filtering, as far as i can see in comp.c of latest commits filtering not enabled (maybe some linear one enabled by default,dunno)

@redfox
Thanks, but i only show what others do :) Sadly liveforit givingup once new issues arise which need attention and fixing, but at least in current form, when you build not very latest code, its good enough. Lot of things can be polished, but it still much better in compre of how it was year ago

thanks @kas1e and all involved.

Great video.

@kas1e

Hi, any chance ti share such E-UAE complied version you build?

TiA

@jabirulo
It's version from LiveForIt sources, just some commits back, till the moment he does "merge" commits which introduce speed issues. And in my build i just add some "hardcore set of 1920x1080" mode of my Radeon exactly, so it is surely no-go for other user's machines. I just was in hurry to make a vid, so didn't polish code, just made it doing what i need in the areas i need. :)

@kas1e

Display 8bit graphics on 32bit screen is not the best option, 8bit to 32bit converter is not near copy speed.

9.Work:pro_2023/gfxconvert.library/gfxconvert_files/test> test
vpal: 00000000, srcMem: 5b72f008, destMem: 58120008, pixels: 307200
from CLUT to CLUT gc_copy_mem8 - pixels per msec: 1136486 , mb per msec: 2.17, duration: 2 sec
vpal: 5b72f008, srcMem: 58120008, destMem: 59f78008, pixels: 307200
from CLUT to R5G6B5PC convert_8bit_lookup_to_16bit_2pixels - pixels per msec: 466636 , mb per msec: 2.23, duration: 2 sec
vpal: 59f78008, srcMem: 5b72f008, destMem: 5a542008, pixels: 307200
from CLUT to A8R8G8B8 convert_8bit_lookup_to_32bit_2pixels - pixels per msec: 234393 , mb per msec: 2.01, duration: 2 sec
vpal: 59f78008, srcMem: 59ff8010, destMem: 5a542008, pixels: 307200
from CLUT to B8G8R8A8 convert_8bit_lookup_to_32bit_2pixels - pixels per msec: 265267 , mb per msec: 2.28, duration: 2 sec
vpal: 59f78008, srcMem: 59fb8010, destMem: 5a542008, pixels: 307200
from CLUT to R5G6B5 convert_8bit_lookup_to_16bit_2pixels - pixels per msec: 515020 , mb per msec: 2.46, duration: 2 sec
vpal: 59f78008, srcMem: 59f88010, destMem: 5a01e018, pixels: 307200
from R5G6B5PC to CLUT function name not found - pixels per msec: 278937 , mb per msec: 0.80, duration: 2 sec
vpal: 00000000, srcMem: 59f78008, destMem: 5a00e010, pixels: 307200
from R5G6B5PC to R5G6B5PC gc_copy_mem16 - pixels per msec: 621312 , mb per msec: 2.37, duration: 2 sec
vpal: 59f78008, srcMem: 59fb8010, destMem: 5a542008, pixels: 307200
from R5G6B5PC to A8R8G8B8 convert_16bit_to_32bit - pixels per msec: 252518 , mb per msec: 1.44, duration: 2 sec
vpal: 59f78008, srcMem: 59f98010, destMem: 5a542008, pixels: 307200
from R5G6B5PC to R5G6B5 convert_16bit_lookup_to_16bit - pixels per msec: 218726 , mb per msec: 0.83, duration: 2 sec
vpal: 00000000, srcMem: 59f78008, destMem: 5a542008, pixels: 307200
from A8R8G8B8 to CLUT function name not found - pixels per msec: 211660 , mb per msec: 1.01, duration: 2 sec
vpal: 00000000, srcMem: 5a542008, destMem: 5a66e010, pixels: 307200
from A8R8G8B8 to R5G6B5PC convert_32bit_to_16bit_le - pixels per msec: 231628 , mb per msec: 1.33, duration: 2 sec
vpal: 00000000, srcMem: 5a542008, destMem: 5a66e010, pixels: 307200
from A8R8G8B8 to A8R8G8B8 gc_copy_mem32 - pixels per msec: 301516 , mb per msec: 2.30, duration: 2 sec
vpal: 00000000, srcMem: 5a542008, destMem: 5a66e010, pixels: 307200
from A8R8G8B8 to B8G8R8A8 convert_32bit_swap - pixels per msec: 295372 , mb per msec: 2.25, duration: 2 sec
vpal: 00000000, srcMem: 5a542008, destMem: 5a66e010, pixels: 307200
from A8R8G8B8 to R5G6B5 convert_32bit_to_16bit_be - pixels per msec: 250060 , mb per msec: 1.43, duration: 2 sec
vpal: 00000000, srcMem: 5a542008, destMem: 5a66e010, pixels: 307200
from B8G8R8A8 to A8R8G8B8 convert_32bit_swap - pixels per msec: 296755 , mb per msec: 2.26, duration: 2 sec
vpal: 00000000, srcMem: 5a542008, destMem: 5a66e010, pixels: 307200
from B8G8R8A8 to B8G8R8A8 gc_copy_mem32 - pixels per msec: 299366 , mb per msec: 2.28, duration: 2 sec
vpal: 5a542008, srcMem: 5a552010, destMem: 5a5e8018, pixels: 307200
from R5G6B5 to CLUT function name not found - pixels per msec: 279398 , mb per msec: 0.80, duration: 2 sec
vpal: 5a542008, srcMem: 5a562010, destMem: 5a5f8018, pixels: 307200
from R5G6B5 to R5G6B5PC convert_16bit_lookup_to_16bit - pixels per msec: 218419 , mb per msec: 0.83, duration: 2 sec
vpal: 5a542008, srcMem: 5a582010, destMem: 5a618018, pixels: 307200
from R5G6B5 to A8R8G8B8 convert_16bit_to_32bit - pixels per msec: 251596 , mb per msec: 1.44, duration: 2 sec
vpal: 5a542008, srcMem: 5a582010, destMem: 5a618018, pixels: 307200
from R5G6B5 to B8G8R8A8 convert_16bit_to_32bit - pixels per msec: 250214 , mb per msec: 1.43, duration: 2 sec
vpal: 00000000, srcMem: 5a542008, destMem: 5a5d8010, pixels: 307200
from R5G6B5 to R5G6B5 gc_copy_mem16 - pixels per msec: 620851 , mb per msec: 2.37, duration: 2 sec
vpal: 5a542008, srcMem: 5a552010, destMem: 5a5e8018, pixels: 307200
from R5G5B5 to CLUT function name not found - pixels per msec: 276787 , mb per msec: 0.79, duration: 2 sec
vpal: 5a542008, srcMem: 5a562010, destMem: 5a5f8018, pixels: 307200
from R5G5B5 to R5G6B5PC convert_16bit_lookup_to_16bit - pixels per msec: 218726 , mb per msec: 0.83, duration: 2 sec
vpal: 5a542008, srcMem: 5a582010, destMem: 5a618018, pixels: 307200
from R5G5B5 to A8R8G8B8 convert_16bit_to_32bit - pixels per msec: 251596 , mb per msec: 1.44, duration: 2 sec
vpal: 5a542008, srcMem: 5a582010, destMem: 5a618018, pixels: 307200
from R5G5B5 to B8G8R8A8 convert_16bit_to_32bit - pixels per msec: 251596 , mb per msec: 1.44, duration: 2 sec
vpal: 5a542008, srcMem: 5a562010, destMem: 5a5f8018, pixels: 307200
from R5G5B5 to R5G6B5 convert_16bit_lookup_to_16bit - pixels per msec: 218419 , mb per msec: 0.83, duration: 2 sec
9.Work:pro_2023/gfxconvert.library/gfxconvert_files/test>

@LiveForIt
Quote:
I am mostly about issue with 1920x1080 mode alone with "merge" commits: things starts slower now and mouse suttering, etc.. If you have motivation, and wish to be annoyed by me with bug-reports, i will gladly back to help you with bug-hunting and testing :)

@kas1e

gfxconvert.library is new project I’m working on,
I think it be better to move conversion routines out,

1. because code is shared between Basilisk and UAE.
2. It makes it easier to optimize.

And I can now benchmark conversion routines without worrying about Picasso96 smart refresh system.

Because that’s a completely different discussion. Is that a PCI to PCIe adapter your using? so you limited the bus speed, that can effect things.

@LiveForIt
Quote:

Nope, i didn't use PCI bridge in my X5000. You probably forget, but it's the same old issue we discuss back in months in another topic: when i and other user trying to explain that after "merging code" commits things start to be slower , mouse start shutters, etc, but then you start says all fine and bored with all this :)

Issue we talked about in other topic start to happens after "merge commits": probabaly something was deleted, or added, or so which start causing speed issues , but does not matter how hard we trying to explain you that after "merge" things start to be worse in few areas, we wasn't lucky in..

@kas1e

Where did you find the fixed version of electric ocean?
Or did you patch it?

@LiveForIt

gfxconvert.library seems to be really a great idea.
Do you plan to release it as open source?
What could be the overhead caused by use of external function calls?

@flash

It won’t add much overhead, as it copies complete lines.

@LiveForIt
Quote:
I just find one on my HDD from times when help BriteLite to test his prods on OS4. Not sure if it was released in public in that form or not.. If i remember right, you can set from command line the size and co.

If you release it as open source, community could provide to optimise it even more, implementing also AltiVec routines and specific asm code.
This project could be really strategic for emulation of 8bit and 15/16bit screens on NG Systems.

@kas1e

Impressive video, I'm sure in the last phase of your video you pushed your x5000 to its limit

But it was great to see how things work.

Nice! That glUAE towards the end looks perfect. Just enough work to not dump 1,000's of games on disk that I'll never use but not so much work I won't want to do it for the games I really do want to bring over from A1200.

@Majestro
Quote:

On pegasos2, 12 years ago, when there wasn't JIT or compositing, i was able to run just a single UAE instance with AladdinAGA, and even then, i had to set frameskip to 1, to be able playable. Now with latest E-UAE with JIT and compositing and on X5000, i can run all the stuff in many instances..

If you in interest how it was on old pegasos2 12 years ago with 12 years old E-UAE, there is (but you are warned, low-quality camera-phone video):

https://youtu.be/-HKoBSF7wm0

Peg2 was ok to just run on single game, or a demo. But nowhere close as, X5000.

6 years ago when i first time got my hands on X5000, i made just fast video about EUAE on it (but that was old UAE, and do not remember if with JIT at all, probabaly not):

https://youtu.be/PAGlC9uo644


@MartinW
Quote:

Yep, that truth. In end of all you just need 20-30 games, and 10 demos in some directory, which you may run few times in a year :) I just dig in into again because my son start to use all this computer crap, and so i give him all amiga stuff instead of PC :)