Apologies for asking a question here as it's neither a bug report or a feature request. If there's a more appropriate channel to ask please let me know!
When using Amiberry with RetroPie I'd like to set some config options that apply to all games I launch. I believe the place to do this is in _amiberry.conf_ but it seems some of the options I'd like to set only exist in the _.uae_ files.
The first thing I'm trying to solve is stopping games loading like auto-height is enabled. I want to keep 4:3 aspect ratio, but with the original height rather than removing any letter-boxing. Currently I use the following in _amiberry.conf_:
default_correct_aspect_ratio=yes
default_auto_height=no
default_width=640
default_height=512
default_fullscreen=no
When I launch a game these preferences seem to be honoured, except for _default_height_ which I assume is set from the _SCREEN_HEIGHT_ value in _whdload_db.xml_ (typically around 400px). Is there somewhere I can globally override this so it always uses the values from _amiberry.conf_, or is my only option to create a _.uae_ file for each game?
Secondly, I'd like to always display the WHDLoad splashscreen when I launch a game so I can set "trainer" options if desired. It looks like there is an option _whdload_showsplash=true_ but this doesn't appear to work if set in _amiberry.conf_. Again, is there somewhere I can set this globally or do I have to set it individually for each game?
Finally, in order to set the "trainer" options on the WHDLoad splashscreen I need to have my mouse configured in Port 0. In _amiberry.conf_ I set:
default_controller1=joy1
default_controller2=mouse
This seems to correctly set my mouse in Port 0 and my joystick in Port 1, but it also appears to set the device type to joystick and you can only control the mouse if you manually set it to either "Default" or "Mouse". If I save a _.uae_ config without changing it manually this is what I see:
joyport0=mouse
joyport0_mode=djoy
Hopefully there are easy answers to these questions, although perhaps the expectation is to just create a _.uae_ for each game? I'm finding Amiberry and Retropie work so well together with WHDLoad that it's the only way I want to play games now. I'll keep an Amiberry build running on Manjaro for messing around in Workbench, but if I want to play Amiga games I'm going to stick with the RetroPie solution as it's so convenient!
I'm in the exact same situation as you @jonpatterson. Regarding the mouse issue for the trailer, my understanding is that the configuration in the file _whdload_db.xml_ has a better priority than the one in _amiberry.conf_. So we should create an .uae file each time to get a mouse. And, yes, it's often.
Our problem seems that the following configuration lines are almost at every game description in _whdload_db.xml_ :
PRIMARY_CONTROL=JOYSTICK
PORT0=JOY
PORT1=JOY
For instance in BattleSquadron_v1.6.1_NTSC, which needs a mouse, for his trailer and for the 2nd player.
That sounds strange because the common hardware configuration back in the Amiga days was one mouse and one joystick. We only plugged a 2nd joystick in rare occasions.
hi @jonpatterson and @Yserra! Allow me to try to answer your questions. I'll do my best.
@jonpatterson / @Yserra: the whdload_db.xml file is intended to ease life of Amiberry users and I understand it's not the case here. I don't have any NTSC games at hands so not easy for me to test. Yet I'll be glad to edit whdload_db.xml in order to reflect any changes you deem necessary. Raise a ticket issue on HoraceAndTheSpider's github and I'll have a look.
@jonpatterson: you appear to be right in the steps you described. The amiberry.conf should be taken in consideration. At least it is for me on my setup (a pi4 + retropie). Same as above if some games deserve fine-tuning in whdload_db.xml submit a case as mentioned.
@jonpatterson: regarding trainers (aka CUSTOMs) I know some games packages do not properly trigger the Workbench screen. Which allows you to click on items you'd like to turn on. For instance R-Type is one of them. And I don't know why :( I don't have much time to look deeper but I will. Best way to workaround it is to force within a .uae exactly the trainers you want. Check for a list of available trainers on whdload.de. Trainers are also listed in whdload_db.xml. Then follow the steps detailed on Retropie forum, in that post.
Reference of Custom configration - Amiberry Wiki
Thank you for your answer @nemo93
And accept all my apologies: actually the mouse issue happens with all the WHDLoad games, even the ones that are not listed in the _whdload_db.xml_ file, so it can't be an issue from it. And, by the way, it happens in all WHDLoad games except for the ones where it is specifically written "PRIMARY_CONTROL=MOUSE" and "PORT0=MOUSE" in whdload_db.xml.
So the question remains: how/where could we tell Amiberry that the mouse is connected and should be recognized as a real mouse for all WHDLoad games?
At the moment the mouse is recognized by default only in the ADF games when, in _amiberry.conf_, I have:
default_controller1=joy1
default_controller2=mouse
default_controller3=
default_controller4=
default_mouse1=mouse
default_mouse2=joy1
I tried to add these lines in amiberry.conf, but with no success:
joyport0=mouse
joyport0_autofire=none
joyport0_friendlyname=Mouse
joyport0_name=MOUSE0
joyport0_mode=mouse
How to reproduce the issue: take any copy of _BattleSquadron_ in WHDLoad format and try to use the mouse during the trailer or during the game. You can't. Then press F12 and go to the Input panel. On port 0: you see "Mouse" / "No autofire" / "Joystick". It should be written: "Mouse" / "No autofire" / "mouse" (or "default").
By the way, wouldn't it be a fair idea to have "PRIMARY_CONTROL=MOUSE" and "PORT0=MOUSE" for all the games in whdload_db.xml? If I remember well, we used a 2nd Joystick on real Amiga only in very rare occasions (I will raise a ticket about that on HoraceAndTheSpider's github).
Thanks for taking the time to reply @nemo93! You are correct in that, for the most part, preferences set in _amiberry.conf_ are respected when using WHDBooter. For example _default_line_mode_ is respected, but settings such as _default_horizontal_centering_ and _default_vertical_centering_ do not appear to be.
This is fine, and I see the reasoning behind it. Part of the problem is the fact I'm using RetroPie on a 27" monitor on my desk, so using a zoomed picture to fill the screen doesn't look so good. However, if I was using RetroPie on my TV and sitting at a distance I'd probably want it to be zoomed like it is by default.
In some ways it seems like the _SCREEN_HEIGHT_ set in _whdload_db.xml_ is slightly redundant, as _default_auto_height_ in _amiberry.conf_ is trying to achieve the same thing? Would it make sense if, when _default_auto_height_ is set to false in _amiberry.conf_, it respected the _default_width_ and _default_height_ the user has set? Perhaps @midwan can advise if that is possible to implement, or whether it would cause problems?
Regarding the mouse issue, it seems like what might help would be to allow a setting similar to _joyport_mode_ in _.uae_ to be set in _amiberry.conf_. That way a user can set something like:
default_controller1=joy1
default_controller1_mode=djoy
default_controller2=mouse
default_controller2_mode=mouse
Either that, or perhaps we just need the mode set to _default_ behind the scenes for all _default_controller_ settings rather than _djoy_?
If I remember the code correctly , Setting PRIMARY_CONTROL=MOUSE on every game would mean that Every game would use a mouse instead of the joystick.
Since the majority of games are joystick based, we default to joystick as the primary control and then set mouse for those games that need it only.
What you want to do is ensure that the defualt mouse input for Amiberry is set to the real mouse (mouse0) (in Amiberry.conf - formerly in hostprefs) and not , for example joy1 (where a joystick can be used to control mouse games)
Also here:
default_controller1=joy1
default_controller2=mouse
default_controller3=
default_controller4=
default_mouse1=mouse
default_mouse2=joy1
You should remove the line default_controller2=mouse
You are here telling Amiberry’s to use your host mouse as the second joystick on two player games.
This may be producing some undesired behaviour
I suspect what you are asking is why don’t we have port 0 connected to the value of default_mouse= on joystick 1 player games? (The value of this can be your real mouse or a controller) ...
The answer is that for a regular joystick 1 player game there should not really be a need to have the mouse connected in most cases. Those that do need it should be set by the xml.
The WHDload “splash” is a byproduct of updating whdload in the booter. The original version had this navigated by joystick or mouse (in the old whd booter) and there was an intention to have this controlled by the Amiberry menu in the future (which is why you can save the settings in the .uae)
The solutions are;
We set all games to default port 0 to the mouse - this has the undesired side effect of us needing to add 2 player joystick games to the Xml , setting port 0 to joystick by force.
We update the booter to include a joy->mouse mapping tool (eg joymouse) loaded on bootup
@Yserra
For instance in BattleSquadron_v1.6.1_NTSC, which needs a mouse, for his trailer and for the 2nd player.
I would argue those situations are rare though but we can cater for them in the xml of the names of the affected games are known.
Unfortunately there are no right answers here- either the games that use multiple joysticks (more common in my experience) are the default, or the games that need joystick+mouse are the default - either way the other one has to be known in the repo files so that those cars can be picked up.
Because the xml is universal to all users, we can’t offer the users the chance to pick their preference either .
@jonpatterson
there is an option whdload_showsplash=true but this doesn't appear to work if set in amiberry.conf
This is a bug and will need fixing - this option is intended for exactly the case you describe
@HoraceAndTheSpider thank you for this answer: "Because the xml is universal to all users, we can’t offer the users the chance to pick their preference either ." That's exactly my point.
May I suggest that the WHDLoad engine in Amiberry configure too many things per game?
I mean, it's great that it auto-configures CPU/Chipset/Kickstart/RAM because those are specific to each games.
But I still don't understand why the WHDLoad engine configures the monitor resolution and the inputs, since they are specific to the user's hardware. I have a 4:3 VGA monitor, a real mouse, a real keyboard and a real joystick. This is the hardware I use for all the games and it is perfectly configured with all ADF games thanks to the generic _rp-a1200.uae_ and _rp-a500.uae_ configuration files.
Why don't we have a kind of _rp-whdload.uae_ that would let each user configure his own monitor and his own inputs for all WHDLoad games?
Like @jonpatterson, I thought at first the _amiberry.conf_ configuration file would do that job. But apparently not.
@Yserra
I don't think there's a need for a separate "special" config file, that's what's amiberry.conf is for.
If things don't work as expected, then I believe this should be treated as a bug. But first we have to decide what the expected behavior should be:
autoload featureAt which stage should the amiberry.conf information be handled? Which one should take priority if there are different options between the XML and amiberry.conf ?
@midwan
I vote that the XML file never configures the mouse (EDIT : all the inputs, actually) or the graphic resolution. They should be configured by a generic configuration file (let's say _amiberry.conf_) to be global to reflect the user's hardware configuration.
@HoraceAndTheSpider
I just checked at the Amiga games database, hol.abime.net. Apparently, there are on Amiga 930 2-player games - with some of them using the mouse, like Battle Chess or Simulation games - and there are 2696 WHDLoad games, most of them with a trailer window where you click on an option with a mouse. So I definitively think that's not a good idea to have a XML file that sets 2 Joystick by default when it doesn't know if a mouse is necessary.
Here, I would like to draw your attention to these lines in the your Amiberry-XML-Builder.py script:
# building the hardware section
if use_mouse1 == True:
hardware += ("PRIMARY_CONTROL=MOUSE") + chr(10)
else:
hardware += ("PRIMARY_CONTROL=JOYSTICK") + chr(10)
Sorry, I'm not a coder. But maybe we could have something as simple as:
else:
hardware += ("PRIMARY_CONTROL=DEFAULT") + chr(10)
I would also like this if possible. It seems very restricted at the moment. I would just like to be able to override -
-turn off the screen zooming for all games so it displays like an original Amiga
-set mouse as port 0 and joystick as port 1 like an original Amiga
Retroarch UAE gives a lot more freedom for user preferences but I like the speed increase of Amiberry !
Also, there is an option in Retroarch UAE that displays the WHDLoad splash screen Only when there are changeable options. This would also be a welcome addition.
Coming back to this, so we can decide the way forward.
Currently, this is how things work:
The "default" options in amiberry.conf are there to provide the default behavior, if something is not set.
If we have .uae config files or WHDLoad XML information, those take priority since we assume the user has made changes that prefers to keep for the given game.
The whdload specific splash screen option is not part of amiberry.conf (at least, not yet). It is saved in .uae files only, for now. It can of course be added as a "default" behavior in amiberry.conf, but as mentioned above, this would be overriden from any .uae config file or the XML contents for specific titles that have them.
So the questions are:
Let's get this discussion going so we can decide on the best solution.
I think there are two things I'd like to be able to do:
With that in mind, and to answer your questions, I'd like see the existing behaviour changed as the only other way to achieve what I'd like is to set a _.uae_ config for every game.
As for potential solutions, I'd suggest if the user has set default_auto_height=no in _amiberry.conf_ then it should use their default_width and default_height and ignore what is in WHDLoad XML. If a _.uae_ config exists for the game then it should have overall priority. I'd as soon see the width and height removed from WHDLoad XML as if you want the same behaviour I think you can just enable auto height?
Regarding controller preferences, from what I recall setting default_controller1 and default_controller2 in _amiberry.conf_ already achieves what I'd like. The problem is it incorrectly sets the mode to joyport0_mode=djoy which is wrong if you are using a mouse. So, either add joyport0_mode to _amiberry.conf_ or default it correctly for the device?
Thanks for coming back to this @midwan, appreciate you giving it your time!
Yes, I agree. As previously said, I think original resolution with black borders etc. should be the default. The zooming method is reducing the resolution of the screen so that it fills 16:9 aspect correct ? So potentially you're making hires screens low res to fit the screen instead of zooming ?
I also think that mouse in port 0 and joystick in port 1 should be a amiberry.conf possibility. I tried a few demos and found that I couldn't use the mouse because it was set to joystick ?
And also be able to use the WHDLoad prefs file so that a default quit key can be set. Which is needed to save anything in a lot of games. You can also make the Splash screen only appear when there are selectable options.
Thanks midwan .
@WindyWinston
Just a note: I assume you are referring to the Auto Height function, when you say "zooming"? If so, it's not changing hires to lowres, it instead changes the configured height value depending on how many lines are actually drawn on screen. The result is usually closer to the wide screen aspect ratio, so it is stretched to fill the screen with less black borders around, than the original picture.
OK, so from what we've gathered here, the list of priority should be as follows:
Do we all agree?
Additionally, I'll add the Splash screen option (and any other that might be missing) in the amiberry.conf file as well, so you can configure all your WHDLoad related default settings there. Anything you haven't configured, will be picked up from the XML file as the last fallback.
However, this means that you can no longer have customized width/height values per game, as that was normally done in the XML file. The default width/height values in amiberry.conf would always take priority, unless of course you created your own .uae file for each game you wanted to override this.
@midwan
Just a note: I assume you are referring to the Auto Height function, when you say "zooming"? If so, it's not changing hires to lowres,
I was referring to those custom resolutions in the XML file which are lowering the resolution to fit 16:9. The Auto Height function is great (and the proper way to do it) if needed :)
Regarding the splash screen options and configurable quit key. At the moment when loading a game it never displays a splash screen even if there are configurable options, you have to hold the fire button every time and a AMOS program appears ?. No offence, but I find the Retroarch UAE WHDLoad booter a lot more user friendly than this AMOS booter. It's just a complex startup-sequence, you can even summon a file requester to select a different slave or read a text file! SplashDelay=0 ConfigDelay=-1 will only display the splash screen when there are selectable options and will remain onscreen until the button is clicked or firebutton but you probably already know this !
I agree with your order of priority. Hope everyone else does. Thanks 👍
@WindyWinston
I'm not sure what you mean by "Retroarch UAE WHDLoad booter" and "AMOS booter". Amiberry used to have a solution based on AMOS in the first version of the WHDLoad booter, but that has since been replaced with an AROS based approach.
@HoraceAndTheSpider
Got any input on this? Considering you were the one to implement the original version, I think your point of view would be valuable here.
OK, so from what we've gathered here, the list of priority should be as follows:
1. .uae config file (if it exists) 2. Amiberry.conf options 3. XmlDo we all agree?
This sounds good to me and gets my vote, although would also be keen to hear @HoraceAndTheSpider opinion. Don't want to disregard any of the great work he's done, and perhaps I'm missing something with regards to whether the _autoheight_ setting in Amiberry can achieve the same thing as the width/height values in the XML.
Basically if we give amiberry.conf priority for the Width/Height values, then we might as well remove those from the XML altogether. The width/height defaults are always populated in amiberry.conf (they are included in the default file bundled as well).
The auto-height is nice but doesn't always work well with all games (some might show glitches, usually those that do tricks with the height on each frame, e.g. Blood Money intro screen). So that would be better off being handled "per game" (i.e. in the XML?) as it differs in each case.
@midwan Ingore me ! I forgot I was still using a hybrid version and hadn't changed it back. I still wouldn't mind having the ability to use the options from the WHDLoad.prefs file though. (Change quit key, splash options etc.)
So is it already possible to default mouse port 0 and joystick port 1 in the amiberry.conf ? and also ignore the custom resolutions in the xml and display it the original res ? I get confused with this emulator on how to do these custom options. In the Retroarch Amiga emulator you just set it in the options menu. Midwan, if you haven't seen or used the Retroarch PUAE emulator, give it a shot. It has a Cycle Exact option and Sonninos has added some really nice options like auto height and width (which can be toggled on the fly), onscreen keyboard and a lot more. Maybe you can get some ideas from his code. His WHDload booter is nice because you can read the readme files/instructions etc and select a different slave on games that have multiple (Pinball Prelude).
@midwan, actually if giving a better priority to Amiberry.conf is the only way to ignore the Mouse options that the XML configures, so I vote for it.
And my 2 cents: it would have made sense that the XML configuration had the best priority if it was only related to games preferences. I stil don't understand why the XML interferes with input options that are end-user-only choices.
Please test with the updated dev - I've added a few changes there (shown above) that should fix the issues mentioned here.
Specifically:
.uae config is 1st priority, and the fallback is whatever you have in amiberry.conf for those values.amiberry.conf: default_whd_buttonwait and default_whd_showsplash. These control the default behavior for those functions, if no .uae file is loaded first (which would override them).amiberry.conf for the first available controller/joystick. This used to be set to joy1 back when we used Keyboard as Joystick as the first (joy0) controller, but since that has changed in dev (Keyboard as Joystick inputs have their own shortid named kbd) this was incorrect.I've tested this with R-Type 2, and a PS4 controller. It seems to work as expected for me, but please let me know if you find anything...
Thanks for the fast turnaround on this! Will pull the dev branch tomorrow and give it a try!
Did some testing this afternoon using the _dev_ branch with RetroPie. Everything seems to be working very well! The priority system for screen size is working nicely, allowing me to set a global preference in amiberry.conf but override it on a game-by-game basis using the .uae config if required. I tried quite a few combinations with several games and didn't notice any problems.
The WHDLoad splashscreen is also working well now, appearing for all the games I tried and giving me mouse control to select the various options. Tested this with some mouse based games (Lemmings, Cannon Fodder) and some joystick based games (Turrican 2, Jim Power In Mutant Planet, Moonstone).
Thanks again @midwan, this is everything I hoped for and more when opened this issue! Also see some other really nice features in there, looks like 3.4 is shaping up to be an awesome release!
@jonpatterson
Great that it works for you! Let's see if anyone else finds anything to object, otherwise we can consider this as "fixed" for now.