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

@kas1e

Its just there so, you don’t get a black screen, if you open UAE on 8bit screen.

(UAE used to dither AGA screens, on 8bit in full screen not sure what happen to that.)

@LiveForIt
Quote:

you mean opening 32bit UAE on 8bit OS4's screen ? Or opening of 8bit's UAE screen on 8bit's OS4 screen ?

Anyway just checked opening of 32bit's UAE screen on 8bit OS4 screens : indeed, it's gray color now :) Through probably no one will open 8bit on 32bit, the opposite one is the one will often be used: when you open different UAE modes on 32bit os4's screens.

But When i run UAE on 8bit OS4's screen (while have UAE's set to 32bit), and then trying to run ephderena's demo : it shows in very tiny screen area, and after a second simply crashes in DX_SetPalette.part.0().

@kas1e

Loadrgb32(…) crash’s is a mystery,
I’m pretty sure the table is garneted correct.
I'm pritty sure table size should be fine.

it does not always happen.

if it’s not what I experienced; it can be a function pointer not reset issue. (when switching modes.)

Yep. We need to change OS4 resolution, as its now, not scaling means it’s a bit dangerous, maybe.

@LiveForIt

Just fired up the SDL version of E-UAE 1.0.0, and I noticed that SDL is using 32bit BGRA.

The same color order the hack used you before you removed it.

Maybe BGRA is really the correct order...

@FlynnTheAvatar

Why should it matter? Should it just work in any order?


die hacks, die hacks!!!

@LiveForIt
We all hope you're busy installing os3.2 in those days, so to be able to see this issue in full :)

As for hacks, yeah, sure. But if we (you) will not find the way to make it renders the same good and fast as it was with hack, then maybe worth to put hack back ? Of course not right now, but at least when you will officially give up to fix it without hacks ?

@kas1e

INVOICE, 2023-01-09, Amedia Computer France SAS
It sure takes time to send a package, no tracking number yet.

@LiveForIt
Yeah, seems Amedia is not fast enough. I got my one from retropassion, and they were very quick with.

@All
Is anyone know if it possible in our current EUAE to setup keyboard's keys as i want them to be ?

By default, i do have working keys on numeric numpad : 8 and 2 for up and down, 4 and 6 for left and right, and 5 for the fire. Is there a way so i can remap them to the keys i need inside E-UAE config?

@kas1e

Is there not a debug rom, or something to test keyboard, it useful check keyboard mapping.

the joystick options joy0 / joy1 normaly maps to keyboard, read the docs.

@LiveForIt
I not need the joy0/joy1 mapping, what i need is to change the default mapping of keyboard.

EUAE have few default presets : kbd1, kbd2, kbd3.

kbd1 i use now, and it means numeric numpad.
kbd2 is to use left/right/up/down
kbd3 is to use F/H/T/B/left alt

What i asking, is not default pre-set, but ability to assign my own keyboard keys to the usual joystick actions from config file. I want to make "w"s"a"d" to be left/right/up/down for all the games which use joystick for.

I.e. something like

kbd.action =
kbd.up =
kbd.left =
kbd.right =
kbd.down =

So you set the keys you want.

Of course i can create "kbd4" and assign keys as i want in the source code of uae, but that kind of workaround, while will be good probably to not some option to just set the keys one want without default presents.

But maybe kbd4 way is faster and more easy.

@kas1e

found the DiagROM,

https://www.diagrom.com/index.php/download/

I know for some time, something wrong with keyboard maping.

last time did anything, like coding in AMOS/UAE, I created a new keymap
to do so, using a keymap editor from Aminet.

@kas1e

Is that not kind of silly, considering it might depend on game you’re playing.

@LiveForIT

Did our current version have some settings to tell to open window in the center of the public screen ?

I.e. i just have amiga.screen_type=public, and the opened window always opens on the X0/Y0 of workbnech screen. While, it can be handy (and even maybe it should be a default) , to open it in the center of workbench screen.

I mean query current resolutions by X/Y of workbench, and depend on the size of the opened window calculate to open it in the center, instead of X0/Y0.

While i think this should be just default behavior (in SDL version it also centered by the way) , still, if you against, it can be added as some new option. But gfx_window_centered and co are busy already with other "centering inside the window".

@kas1e

Did our current version have some settings to tell to open window in the center of the public screen ?

no it just remebers where window was before it was iconifyied.

the center option is only used in 8bit fullscreen mode.

@LiveForIt
Quote:

As far as i can see, nope, we don't have this option. But i think it should be just default behavior of the "amiga.screen_type=public" option. At least it sounds logical.

@LiveForIT
Tried your experiment with merging p96 and ami-win : loading of the 32bit workbench on the 32bit screenmode now much slower. Just 2 times slow as how it was before. Before it was 15 seconds, now it about 30 seconds.

I even can see how background image now draws slower too in 2 times.

Seems like whole rendering 2 times slower now.

Also, hotkeys do not work anymore too , like ctrl+alt+q for quit, ctrl+alt+s for screenmode choose, etc.

@kas1e

the ALT and Amiga keys are swapped, to avoid conflict.

its LALT+M to switch screens insted of Amiga+M as conflicts with AmigaOS4.1, As result its now CTRL+LWIN+Q insted of CTRL+LALT.

Right, sounds logical. That needs to be not forgotten to point out in the readme when there will be proper release, IMHO.

@kas1e

As for slowness issue, well it should have no negative effect on it, actually it should be faster now, as I’m using WritePixelArray that should accelerated, instead of memory copy routines in Picasso96.c

@LiveForIt
Probably some old code or some mistake somewhere left then, but i tested again after reboot : yeah, everything slow in 2 times when it comes to the rendering 32bit on 32bit screens.