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

@kas1e

Yeh.. some stuff, should be better now.

@LiveForIt
Quote:

Sadly, but almost no changes. The same ~30 seconds for a start 32bit on 32bit screen, the same slow drawing of background.

So seems still something wrong. You can test it yourself: Just build a version which didn't have experimental merging, and count with timer : 15 seconds. And then latest one : 30 seconds. And it's interesting that it exactly twice slower, like, maybe drawing functions somewhere called 2 times now ? I even can see how the drawing of backdrop image start to be 2 times slower.

At the moment the best version we had, is the one before argb/bgra hack were removed. There everything was looking correctly and works fast. Latest ones slower in 2 times, and had this issue with colors.

@kas1e

I studied the picasso96.c code for a while, I can find a few mistakes, first making picasso96 memory writes slower, by trying to find part of screen that needs to update, in any demo or game almost all pixels will be updated, so this code only makes everything slower, also by dividing it up into lines, we can’t do complete wpa on complete screen. So probably less efficient.

(Sure if you only updating a port of the screen is better, if you’re running a desktop applications, that almost never update all pixels.)

regarding the ARGB / BGRA, the more and more I look at the code, I’m almost 100% sure its not a P96 bug in P96, I’m pretty sure it’s a AmigaOS3.2 / icon.library bug.

A nice workaround download icon.library from Aminet, that one support OS4.1 icons, and I think is also faster.

Or you can switch to BGRA mode if you want to, it’s just one-line change, yeh.... old hack also had to convert BGRA to ARGB, so no difference. Except we are not lying to the OS & Programs about it. And that’s most likely a good thing.

@LiveForIt
Quote:

That all sounds nice, but did you check it yourself ?

I tested your latest commits from today: it still slow like omiga1200 and takes 30 seconds for 32bit on 32bit screen loading, instead of previous 15 seconds before you merging p96 and ami-win. And not only loading speed is problem, whole rendering slower in two times. Just load up your OS3.x on 1920x1080x32 bit screen with the same p96 settings in os3.x prefs.

Just check it yourself with a timer by hands you will see that despite how it should be by idea, in end it slower in 2 times.

Quote:

Are you sure ? I mean, it's kind of bold statement taking into account how many ppls works on, and that on native hardware they have no issues with.

Also, don't forget the fact that there is issue with prefs:palette too, and with dopus4 colors too, and with StormC splash screen too.

It's not only about icons, it's about palette stuff or something of that sort.

Maybe it worth asking on eab os3 developers ? They surely will be happy to fix if there will be anything to fix. But, anyway, IMHO, this hack was originally in for purpose probabaly ?


Quote:

Can you point out in the new code what line need to be changed to make colors working correctly as before with icons/palette/dopus4/etc ?


What i trying to say: that all good to improve things, but now we have 2 new major problems : broken colors in palettes/icons/etc and 2 times (!) slower rendering. Of course, you may have many ideas how to improve things, but at least we shouldn't regress, as what the point to make “all correctly” if colors are broken and speed of rendering 2 times slower now ?

Even with previous "hack" in terms of RGBA/ARGB there wasn't speed issues. But now, wich hack removing and "merging" , we instead have slower everything and broken colors too :)

Anyway, just check yourself plz how the speed now when 32 on 32 workbench loaded. There still something calling twice, or something just wrong, which make all not better, but worse.

@kas1e

Your benchmark is not good benchmark, you need to run some demos.

@LiveForIt
Quote:

I just report the things I found right from the start, and which are important from user's POV. Even if it improves things somewhere, it still, bring a major issues with speed in other areas and something should be done about it, nope ?

Or you want just to keep it like this, even if it starts to be that much slower in 32bit on 32bit mode ?:)

Maybe you still forget to enable/disable something else, and it still does the same 2 times when render 32bit on 32bit screens?

Quote:

I'm just running few demos after I'm waiting 30 seconds to show up workbench, and typing in 2 times slower console, and demos seems the same by speed, i can't see difference. They were good and fast before, too. The one of demos which were not so fast before : the same not so fast now too, i see no differences.

Or you have some particular example which now noticeable better ?

PS. And with latest version something really broken with keyboard now. Not only hotkeys not works, but also the "/" symbol now type "-" instead. And instead of "_" i do have "+" now. Also symbols <> mapped to wrong keys too. Before touching the keyboard code all were fine of course.


To summarize, we do have 3 new issues now:

1). palette issue
2). speed of whole rendering on 32bit x32bit screen reduced in 2 times
3). the keyboard changes cause not only hotkeys to be different, but broke some characters typing.

@kas1e

the demos I'm running is:

loonies-multiverse
unique-subside-final
apx-mayh
nebula by dual crew

@Kas1e

Quote:

Your, benchmark, does say something about ideal speed, I agree.

as I see we are at cross road.

intelligent automatic line skips, vs manual line skips.
The automatic case slows down gfxmem_bput, gfxmem_wput, gfxmem_lput, to find part of screen that need to update. I believe that has huge impact on speed, in positive and negative ways it seems, the transfer is to VRAM is what is slowing your benchmark down, it seems. By changing the behavior.

Now if don’t want to sacrifice the speed of gfxmem_bput, gfxmem_wput, gfxmem_lput, by some kind smart refresh system, then we don’t know part screen is update, we are back to manual line skipping.

I’m not sure everyone will be happy about going back to the stone age, but bout methods has there pluses and minuses, it be nice to have option to select what method to use refresh the output bitmap.
Quote:

No it does not do that anymore…
maybe is_vsync() is the wrong place put the code, to begin with, I will try move the code.

@all: thanks for your work! I am happy that we get a newer version of UAE with Compositing.

Since a while i am testing around.

For Speed. A while ago i got a config from kas1e and maybe i use it but played around very much ;)

I just found out that "comp_optimize" was set of false and in another config which felt faster it was true. Now i have it "true" and all things are much faster (Sysinfo from 4000 to 15000 Dhrystones on X1000). Maybe checking your settings may help a bit.

Another problem is scaling for me. While playing around with an Indivision MK3 on my A1200 i learned much about scaling and found out that an emulated screen content should be a multiple of the amiga resolution.

In a FullHD screen, a PAL image should not fit into the whole screen as it is now. It should respect the Amiga resolution.

For instance:
320x256 (PalLores) -> 640x512 (PalHiresInterlace) -> 1280x1024 Emulation Screen -> this is perfect, i use it also on my FullHD Monitor as Screenmode, it is a bit blurry but better than native because the current UAE scales up to 1080p in height an i get no good pixels (different pixel sizes -> also no clear scanlines are possible).

So for fullHD it should be 1024 pixels in height, than center it into the screen. A nice feature would be, if 1080p would be used only for Overscan (it would be an Overscan size of 270 -> 540 and in my Indivision settings it is perfect for most games).

Anyway. In 1280x1024 i can work and it is fine. Currently i do some testings in DeluxePaint and here i need pixel perfect pixels. But for fast screen switches, i set also my OS4 Workbench to this size. It would be nice if i could Use FullHD and fast switching ;)

Another issue: I don´t like the "Lock Mouse" Icon in the window mode. First, it is ugly as hell. Second, i don´t can back to OS4 Mouse (only with shortcut for changing screen/window mode).

Maybe you have AmigaForever. Here you can press ESC key for some seconds and the focus changes back to the main System. This works very well and intuitive.

Thanks!

EDIT: I use an older compiled version, found on discord around christmas.

@vsync: as i remember right, vsync is broken on OS4. Maybe it also can not work in emulation. In our games it works not well, i don't know if it is a driver issue or an update of GUI Settings (i am not shure but there was an update a while ago and after it, it also did not work on workbench screen).

If you get vsync work for a smooth gameplay in UAE, you are my hero ;)

@LiveForIt
Quote:HW accelerated functions like WPA include some setup overhead, therefore they can only be faster for very large changes. For small changes using CPU writes to VRAM instead is faster.

deleted double post

@imagodespira

i only get 18707 i sysinfo, thats like 040 speed



25% compared to 060 / PIV on Pixel Write, I think that’s a bit low.
this why do not like this smart stuff, if anything I want it to be faster.

@kas1e


Quote:

the problem is that on the Amiga keyboard layout, is 3 keys after 0, but pc keyoard you have only 2 keys after 0, so missing "-" key was mapped down to RShift, (as the symbol is on PC keyboard), but that key was already used by "/" on Amiga keyboard layout, so that key now mapped to the menu key.

Also on PC keyboard on numpad "+" is lot larger, so one key less, pluss "num Lock" key takes up space, so two keys had to mapped to the HOME and END keys, this where you find "(" and ")" keys

@LiveForIt
Quote:

The speed issue of course need to be fixed to be back on the previous level. Not sure if it is vsync issue, it just looks like everything draws on 2 (!) times slower now. Like the same operations repeats two times.

Can't you test it yourself on your setup, just by running last version and previous version ? It very visibly that things just so much slower now in whole rendering, and it really looks like some slow method of rendering used, or double-rendering somewhere, dunno.

IMHO, it's the bug #1 to deal with before going further.

As well as issue with broken Palette and now broken keyboard too after keyboard changes.

Quote:

Not about ideal speed, but for the speed which were there from start, which we should only improve, but not downgrade instead..

Quote:

Users doesn't care about how everything work internally, for them matter if everything works out of box, have no broken colors, and fast. You can't bring on them explains like "i go proper coding way, sorry this one cause a broken palette, keyboard and slow speed for you" :) If you call proper works on normal speed a "hacks", then let the hacks be in.

@LiveForIt
Quote:

All i can say : before keyboard works as should, all keys were correct and ok. Now, after you change the keyboard's code, the keys are broken and can't be used properly. Not only one key, but many.

So, what about put working code back ? Or if you want to keep your new code, to fix it, so it will work as before and mapped correctly ?

I start to fear, the more we change lately, the more things we broke with excuses that it all ok and should be like this… Hope to be wrong, but colors, speed, and now keyboard are things which need to be fixed.

@kas1e

Quote:

We had keys not mapped to anything.

Quote:

There is no code to put back.
there no keyboard mapping, it was 1 to 1 maping.

that resulted in some keys you can't be pressed, this keys had find space on PC keyboard some how.

@LiveForIt
i tried the X1000_SDL Version and get 35k Dhrystones.
As i currently try to pixel and work with Deluxe Paint and Personal Paint, i see the improvements there (DPaint: Draw Circle with Antialiasing is a good test, PPaint take a PNG image and scale it down with dithering to 32 colors).

But i in real work scenario i don't need the Speed. But it may help for games (Epic Intro flies).

The perceived speed is better in compositing version (maybe only in my head, but it is snappyer also in games with scrolling)

@LiveForIt
Quote:

Let me rephrase it again : that not so matter how and when and blblal. The result is : before keyboard was ok, all character were working. Now, after you change keyboards code, i can't use some keys, and other ones are mapped in different place, and not as they expected to be, and not as it was before.

Hope it clear now.


Quote:

Sorry, i still don't get it. I mean, i get that you have an explain of that, but the new way which you add didn't work as good as it works previously. Now keyboard is broken, and i can't type some symbols. Before all were fine.

Can you make it works like before , i.e. before changing keyboard's code ? So all keys will work fine again.

ps. strange that i need not only do bug-hunting work, but explaining that some things are broken and need to be fixed. Someone should pay for ! :)

@imagodespira

I know their special fix for X1000, one of instruction that had to be replaced in JIT compiler, I wonder if that fix is missing, or I have compiled it in a special way.

@kas1e

No I can't, it did not work before.