Amiberry: Smart centering from XML

[nemo93]

Hello @midwan :) @HoraceAndTheSpider is back and that's great! I'll see to somehow merge my repo with the one from @HoraceAndTheSpider.

Most important to me would be to carry over the "smart center" fields I added recently in my version. I've decided to go after "SCREEN_CENTERH" and "SCREEN_CENTERV" in XML. They could take 2 values: SMART or NONE. By default, all games will get the SMART values and if specified in a file value will be altered to NONE. Only a handful of games do require "horizontal centering" set to NONE (eg. Banshee and BodyBlows) hence the decision to apply a SMART value by default.
=> I can see here in Amiberry's code where the XML params may be extracted from. Therefore would you be open to add the aforementioned parameters? You could have a look of an updated whdload_db.xml. I'm really open to suggestion as it's a real pain actually while my many testings to open the GUI and tick the vert/horiz boxes each time :-)

I have similar question but to pass a specific KS rom straight from the XML? E.g. I'd like to enforce A600 KS Kickstart v3.1 r40.63 (1993)(Commodore)(A500-A600-A2000)[!].rom to fix Barbarian for good.

[HoraceAndTheSpider]

I’m sure that kickstart should already be the one enforced by the way that the a600 setting is used in Amiberry/the xml...

That was definitely the intention!!

So i think some investigation might be needed as to why it’s not being selected.

[HoraceAndTheSpider]

A do wonder if a better fix for Barbarian is maybe ask one of the WHDLoad devs to rebuild the slave and add in some blitter waits, avoiding the need for a slower cpu anyway

[nemo93]

hi @HoraceAndTheSpider :-) I got indeed a to-do list of packages I'd like to see updated (Drakken, BattleIsle, Barbarian, Skidmarks, etc). I'll do that at some point as it might be the best solution.

Regarding the KS selection I really need some doc or somewhere to look at to understand the logic. Do you have any pointer please?

For the record some titles will go straight to the "insert disk/KS boot" instead of going through the game: Explora/ChronoQuest (1&2), Escape from Colditz, etc. The default KS Kickstart v3.0 r39.106 (1992)(Commodore)(A1200)[!].rom is picked up instead of Kickstart v3.1 r40.63 (1993)(Commodore)(A500-A600-A2000)[!].rom which is the one allowing those titles to properly run.

[HoraceAndTheSpider]

The selection for the kickstart routine is a re-use of the quickstart code really.

When Amiberry/UAE scans the roms, they are all given a number effectively. This allows certain quickstart modes to be used.

So the code in question is in amiberry_whdbooter.cpp in this case. It does a 'test' to see if the A600HD KS is available, and stores this in a variable. It's possible that is more roms have been added into the base UAE code, the number use here is no longer correct. It uses this rom rather than the KS3.1 for A600 you have said works, so maybe this is the cause of the problem.

    // this allows A600HD to be used to slow games down
    int roms[2];
    roms[0] = 15; // kickstart 2.05 A600HD  ..  10
    const auto rom_test = configure_rom(p, roms, 0); // returns 0 or 1 if found or not found
    const auto a600_available = rom_test;

    if (a600_available == true)
    {
        write_log("WHDBooter - Host: A600 ROM Available \n");
    }

Later on, the code looks at the XML, and notes if the CPU is set to 68000. if it is, AND the A600HD rom is available, it is meant to 'Quickstart' into an expanded A600, otherwise (i.e. there is no rom available, or the game is 68020+) it defaults to a simple A1200 setup.

    if ((strcmpi(game_detail.cpu, "68000") == 0 || strcmpi(game_detail.cpu, "68010") == 0) && a600_available != 0)
        // SET THE BASE AMIGA (Expanded A600)
        built_in_prefs(&currprefs, 2, 2, 0, 0);
    else
        // SET THE BASE AMIGA (Expanded A1200)
    {
        built_in_prefs(&currprefs, 4, 1, 0, 0);
        if (strcmpi(game_detail.fast, "nul") != 0 && (strcmpi(game_detail.cpu, "nul") == 0))
            strcpy(game_detail.cpu, _T("68020"));
    }

There is a 'simple' test later on to check for AGA/CD32 - if this returns a negative result, it downgrades the A1200 to a non-AGA machine and A600 chipset, to save emulation runtime.

[nemo93]

@HoraceAndTheSpider you were right regarding this number thing. By having a closer look at rommgr.cpp as well and by changing roms[0] = 15; to roms[0] = 20; (which I assumed would match KS ROM v3.1 (A500,A600,A2000)) this time all my games boot properly including Barbarian. Yay!

After doing this simple code editing I realized I didn't have the "A600HD KS" in my "bios" folder (Kickstart v2.05 r37.350 (1992)(Commodore)(A600HD)[!].rom) in accordance to the doc. This also could explain the situation. I'll retest with this A600HD KS inside the bios dir this time. I'm pretty sure it's going to work. If so then it's a matter of updating the Wiki/doc to ensure this A600HD Ks is there. Unless it's really best to go with KS ROM v3.1 (A500,A600,A2000) instead.

I'll look into adding the "smart" centering parameters as well and submit a PR if I have time.

_UPDATE_: as suspected it works perfect with the proper A600HD KS installed... Kickstart v2.05 r37.350 (1992)(Commodore)(A600HD)[!].rom (43b0df7b)

@midwan me again, sorry. What's your take on that issue please? The easiest would be to simply edit the doc/wiki somehow to ensure A600HD KS is always part of the user config for maximum compatibility. This will fix for good issue with Barbarian (Palace) and with other games for sure which were not booting properly. If not there emulator falls back to Kickstart v3.0 r39.106 (1992)(Commodore)(A1200)[!].rom which prevents the aforementioned games to boot or to properly run.
=> I realized this issue is being discussed in another thread which is completely separate. I could create another ticket for that.

[HoraceAndTheSpider]

We could always add a second test - if roms[0]=15 fails, then try roms[0] = 20 and use whichever is available.

Ideally we should have a pop-up display that tells the used they are missing a file that is needed for this game to be compatible.

[midwan]

@HoraceAndTheSpider
The default is OFF, but this can be changed by editing amiberry.conf and setting it to be ON: https://github.com/midwan/amiberry/wiki/Amiberry.conf-options

[HoraceAndTheSpider]

Thanks @midwan - i realised after i wrote my post that @nemo93 had covered this further up, and that the XML default will be smart 'ON' .... perhaps the XML default should equal the amiberry conf options, or in fact, be inherited from Hostprefs ?

Edit: having the option in both hostprefs and amiberry conf might be a bit confusing for users to know which one is taking priority

[HoraceAndTheSpider]

Possible order of precedence;

-> default OFF
-> If present in amiberry.conf, set the value (OFF/ON)
-> If present in XML, set switch OFF if currently ON. (Compatibility)
-> if present in hostprefs, set the value (OFF/ON) (ignoring all of the above), retain previous value otherwise.
-> Individual UAE file setting overrides everything (already implemented)

i hope @nemo93 is taking notes!

[midwan]

@HoraceAndTheSpider
What's the point of having this in hostprefs.conf also? Doesn't the setting in amiberry.conf cover the default behavior anyway? And then you can just override it with a config file (which can either come from a .uae config file, or an XML setting).

[HoraceAndTheSpider]

My thinking on the hostprefs was simply to keep this in line with the other options, as the hostprefs is for the auto-loading specifically, rather than the whole of Amiberry.

edit: i should have said above that UAE file setting overrides everything also ;)

[midwan]

It seems to me that hostprefs.conf already does more than it should, in the sense that it covers options that should be in amiberry.conf instead (default settings for the emulator).

It's OK to handle controller-specific things there, but perhaps we should avoid spreading configuration options in multiple files?

The amiberry.conf file is designed to handle emulator default settings, so things like Aspect Ratio, Frameskip, default Quit key, default GUI key, H/V Centering etc. belong there I think. And hostprefs.conf can handle the controller-specific details only.

Or perhaps we should look into eliminating the need for hostprefs.conf altogether, and move what we need in amiberry.conf ?

[HoraceAndTheSpider]

It seems to me that hostprefs.conf already does more than it should, in the sense that it covers options that should be in amiberry.conf instead (default settings for the emulator).

Or perhaps we should look into eliminating the need for hostprefs.conf altogether, and move what we need in amiberry.conf ?

I'm absolutely fine with that approach. The simpler the better tbh. As long as there is nothing that you want the autoloader to do 'generically' which you do not also want amiberry to do by default also.

[midwan]

OK, then I'd prefer to keep everything in one place, for simplicity. :)
I've added several options in amiberry.conf recently, and we could add more as needed to cover our needs. About half or more of the options in hostprefs.conf are already in there. :)

The XML options can just override normal config options, as usual. And a .uae config file will also do that, of course.

[HoraceAndTheSpider]

OK, so lets assume hostprefs conf will be gone in time....

which has priority? the amiberry.conf setting, or the setting from the XML ? I am guessing the .conf becuase the user has made a concious decision to use that (e.g. if they wanted to disable sound on everything, or disable/enable centering on everything)

The .uae will override everything (as already happens)

[midwan]

Amiberry.conf will define the default behavior, the xml and any uae files
should be able to override it when specified.

On Thu, May 7, 2020, 14:44 Horace And The Spider [e-mail]
wrote:

OK, so lets assume hostprefs will be gone in time....

which has priority? the amiberry.conf setting, or the setting from the
XML ? I am guessing the .conf and the .uae will override everything (as
already happens)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/midwan/amiberry/issues/636#issuecomment-625232310,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA5ST5LMZ3YSQIUOKFE2WCDRQKUKDANCNFSM4MXEFZOA
.

[midwan]

So if we take the example of hostprefs.conf we have in the Wiki, shown below:

CONTROLLER_1=joy1
CONTROLLER_2=joy2
;CONTROLLER_3=joy0
;CONTROLLER_4=joy3
CONTROLLER_MOUSE_1=mouse
CONTROLLER_MOUSE_2=joy0
;RETROARCH_QUIT=TRUE
;RETROARCH_MENU=TRUE
;RETROARCH_RESET=TRUE
;KEY_FOR_QUIT=F12
;KEY_FOR_MENU=F11
;DEADZONE=33
;STEREO_SPLIT=1
;SOUND_ON=FALSE
;ASPECT_RATIO_FIX=TRUE
;FRAMESKIP=TRUE

And see what's missing in amiberry.conf, I see that we'd need to add the following options:

CONTROLLER_1=joy1
CONTROLLER_2=joy2
;CONTROLLER_3=joy0
;CONTROLLER_4=joy3
CONTROLLER_MOUSE_1=mouse
CONTROLLER_MOUSE_2=joy0
;RETROARCH_QUIT=TRUE
;RETROARCH_MENU=TRUE
;RETROARCH_RESET=TRUE
;DEADZONE=33
;STEREO_SPLIT=1
;SOUND_ON=FALSE
;ASPECT_RATIO_FIX=TRUE
;FRAMESKIP=TRUE

Do we need all of them, or are there any we can leave out you think?

[HoraceAndTheSpider]

The controller stuff is very much related to the booter and XML - depending on whether you are loading a mouse or joystick based game.

Everything else could be moved :)

If I can find where the Amiberry.conf is checked and applied I can take a look

[midwan]

With the latest commits, we have hostprefs.conf fully integrated into amiberry.conf now.
All options mentioned above, including some extra ones I just added, are accessible from there: https://github.com/midwan/amiberry/wiki/Amiberry.conf-options

Therefore I think we can safely close this issue now.