BlitterStudio / amiberry

Optimized Amiga emulator for Linux/macOS
https://amiberry.com
GNU General Public License v3.0
643 stars 86 forks source link

Some questions to the new (since 5.7.0) section of WHDLoad in the Amiberry GUI #1343

Closed NoobieMaks closed 3 months ago

NoobieMaks commented 3 months ago

I was very curious about the bugfix to issue #1328 which was part of the latest release 5.7.1. Unfortunately I must say that nothing has changed for me. Battle Isle has still the same error.

It's generally not clear for me what this section should be able to do and how, there is no Wiki description of this new part.

1. As far as I see the Custom Fields show the same options as the WHDLoad splash screen does before. I thought when I check them at the game start I will see the same options also activated/checked at the Amiberry GUI in the Custom Fields. But this is not the case. Only the Button Wait option is really taken over from the splash screen before.

2. Then I tried to save these Custom Fields per game-uae-file via Amiberry GUI Custom Fields. And yes the uae-file has the right entries (whdload_custom1=1 and so on), but when I start the game again, these Custom Fields are shown as unchecked in the GUI. Only the global option Button Wait is recognized already at the splash screen and then also in the GUI. It seems the config-file-entries do not count.

3. The navigation in the Custom Fields window can only be done per mouse. I can navigate through the whole Amiberry GUI per Controller but into this window not. Should this be so?

4. Specific Battle Isle question: Before 5.7.x the game start was possible with a simple change of the uae-file-line at the bottom -> from 0 to 3 -> "whdload_custom1=3" With 5.7.1 it should work again, but should the GUI Custom Field Custom 1 show anything when the uae-file has this entry 3 instead of 0? The game still shows only Custom Field 2 - named "Load Game Position". The other 4 Custom fields do not have any editable menu.

giantclambake commented 3 months ago

Indeed, I can recreate this here wrt preview/x86-64 and using BattleIsle_v1.9_1991.lha

-- if you change whdload_custom=$ fields in config.uae file, these don't get reflected in whdbooter splash...ie; you still have to alter these manually in the splash screen.

@NoobieMaks .... can you try the following?...;

Ensure you don't have any config.uae files present associated with this title...

Edit whdboot/game-data/whdload_db.xml --> find the snippet related to the BattleIsle_v1.9_1991.lha file, add the custom1 field as per below (if you don't like angry canetoad, use something else =), and save the XML changes;

                        <custom>
                        C1:L:Angry Canetoad:None,1,2,3
                        C2:L:Load Game Position:None,1,2,3,4,5,6,7,8,9
                        </custom>

Launch amiberry GUI->WHDLoad panel --> Select file (ie; BattleIsle_v1.9_1991.lha) -> Custom Fields --> change value to 3

ex

Click OK -> CPU & FPU panel --> Select 68020 --> Start //see note below

Emulation should start correctly, and game title should run (it does here =)

@midwan -- if you follow on here with F12->WHDLoad panel, the Custom Fields appear to be reset to 0 ...bug?

Note: This title.lha will crash&burn requesting at least 68020 CPU .... it seems odd to me that directive isn't included in the XML ...I conducted a test;

More or less here emulating a basic A500 with 512K/1M, kickstart1.3, booting the wb135.hdf file from AF, with attached harddrive directory (Games: / DH1: volume).

Install BattleIsle from 3 floppy images to DH1: ...install completes successfully. Double click on game icon, it throws an amigaDOS error (in Deutsch) which I read as a request for 68020...ergo... --> F12 -> CPU and FPU -> Select 68020 -- and then Reset....once workbench is up and running, double click on game icon, games starts and runs correctly.

It's rather odd ... this title should start and run from a basic A500 setup, which it actually DOES when going by the GUI -> Quickstart and floppy image route (also ./amiberry floppies/"Battle Isle (1991)(Blue Byte)(Disk 1 of 3).adf" works fine), but 'for some reason' and AFAICT, if the game program detects it's being launched from a DH*: device instead of DF0:, it kisses the 68kay goodbye, and coddles the '020 instead...but I don't think it's that simple ; it may also be the amount of RAM detected ....but whatever, it's really really strange it suddenly demanded 68020, given the hardware being emulated was on a 68000 profile (IRL this would've been an A500 rev.6a with fatter Agnus and an A590 with half the ramfield being populated)...weird...

@NoobieMaks ...I seen you've got some active tickets on Horace's github, you might like to query there, why CPU=68020 is not included in the XML, although it's apparently needed =)

giantclambake commented 3 months ago

Just a quick addition... you would think a logical contraction, might be C1:L:Angry Canetoad:3 , so the value is always '3', however this does not work for the 'L' switch me thinks.

What does work however, if you edit the XML as above, start amiberry and load the whdload.lha, change CPU type and change the Custom Field value to '3', then start the emulation and when the whdbooter splash appears, hit F12 and goto Configurations -> Save, the resultant config.uae file will have the correct name, and all these changes are correctly saved.

However, in the run-me case this only works via the GUI->Configurations panel route ...ie; cmdline invocations and GUI->Quickstart or WHDLoad panel routes to load BattleIsle_v1.9_1991.lha all fail to start (or parse the configurata?)...and you have to manually change Angry Canetoads=3 and start emulation...ie

GUI->Configurations-> double click on the BattleIsle_v1.9_1991 entry -> emulation starts directly using that config.uae, and game starts and runs....

The invocation of ./amiberry conf/BattleIsle_v1.9_1991.uae does not work.

HTH

midwan commented 3 months ago

This is actually a bug that I missed. The custom UAE config files were loaded before parsing the XML contents, so any options contained in the XML would override the config file values. It should be the other way around: XML comes first, and if a .uae file is found, that is loaded on top.

NoobieMaks commented 3 months ago

@giantclambake: I followed your way:

  1. deleted the existing uae from Battle Isle
  2. edited the whdload_db.xml with C1:L:Starting Trick: None,1,2.3
  3. started Amibery via +START AMIBERRY
  4. gone to WHDLoad panel and selected BattleIsle_v1.10_199.lha as auto-config-file
  5. changed cpu to 68020 and Custom Field 1 from None to 3
  6. clicked START
  7. AND IT REALLY STARTED

This work around start would be a possibility to start the game, my other way is to use a save state from my older build, this also works, I start the game and go to the savestates panel and choose my save state and it runs. This is my favourite way until this bug is not solved, I do so with other games to skip long intros or password requests.

Some observations in these tests:

@midwan: Have you also thought about the naviagtion in this panel? It's not possbile per controller, I always need to connect my mouse additionally, only for this one panel.

NoobieMaks commented 3 months ago

@midwan: Please allow me another question, do I understand right, since 5.7.1 the order of the recognition of the configurations has changed, and this is not only for the WHDLoad settings, it is for the whole uae-file. Is this the reason why I don't see my very individual made Custom controls anymore?

Seems to be so since 5.7.0 -> I was so focused and happy about other things like ps3controller driver, possible navigation, default soundcard, auto-crop function, player 3+4 support, that I did not recognize that I lost the function of my individual custom controls.

midwan commented 3 months ago

BattleIsle now works as expected, if you have saved a custom .uae config with the changes required. Ideally of course, these changes should go in the Slave file (for the custom1 field) and the XML (for using an A1200 config for this title).

The navigation in the custom fields is tricky, as the fields there are dynamically generated depending on the title you load (and what the slave defines as available custom fields, and field types). I cannot set navigation without knowing the actual fields used beforehand, at least not with the current GUI toolkit (guisan).

giantclambake commented 3 months ago

@NoobieMaks ~ thanks for testing ; being primarily on x86-64, I don't check the v5.x.x amiberry branch very much =)

As for the BattleIsle snippet in the XML ...citing: http://whdload.de/games/BattleIsle.html

version 1.0 (16.03.00) done by Wepl:

Ergo, the XML really does need changing, to take into account the last line above =) ..ie; CPU=68020. The custom1 field should also be fixed (in the XML for amiberry's sake ;)

giantclambake commented 3 months ago

BattleIsle now works as expected, if you have saved a custom .uae config with the changes required. Ideally of course, these changes should go in the Slave file (for the custom1 field) and the XML (for using an A1200 config for this title).

The navigation in the custom fields is tricky, as the fields there are dynamically generated depending on the title you load (and what the slave defines as available custom fields, and field types). I cannot set navigation without knowing the actual fields used beforehand, at least not with the current GUI toolkit (guisan).

Do I presume rightly here? --> From the GUI, you cannot save a line like whdload_custom1=3 to the associated config.uae file, if the custom1 field isn't set in the associated XML snippet?...(ie; necessitating that such a change has to be made by manually editing the config.uae file directly?)

I was kinda hoping the Custom: field in the WHDLoad panel would accept the string 'custom1=3' , and save that value to the whdload_custom1= line, based on a match to the 'custom1' hint ...but of course, that is not the case ;)

It could be said the GUI user is a little inconvenienced here, however that observation really only matters if there's other whdload.slaves out there, that are the same as the BattleIsle titles, wherein this value isn't exposed by the XML. AFAIK however, so far the BattleIsle titles are the only ones that display this specific behavior, so it likely doesn't matter? =)