FrodeSolheim
Members-
Posts
11 -
Joined
-
Last visited
-
Days Won
1
FrodeSolheim last won the day on January 7 2017
FrodeSolheim had the most liked content!
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
FrodeSolheim's Achievements
8-Bit Processor (3/7)
21
Reputation
-
On-screen keyboard (with Amiga keys, not "PC") is being worked on at the moment (Some more information about in-progress work at http://eab.abime.net/showthread.php?t=100873). I will also add some way of overriding OpenRetro configs with local config, but prioritizing getting out a new version of FS-UAE first
-
Version 2.9.4dev is out Yes, it's not perfect, but at least it's somewhat consistent. The alternative seems worse: If games are saved based on the archive name (because of no match in the game database), and then later at some point, the database is updated - a match is found, and now the save directory name is based on game database information. No, I was more thinking that a user could add a config (to override the defaults) if he discovers that a WHDLoad game does not work properly with the default settings. I haven't implemented this. Can wait and see if it is actually needed first. 3D Pool for example has both 3DPool.slave/.info and 3DPictures.slave/.info. See https://github.com/FrodeSolheim/fs-uae-launcher/blob/master/fsgs/amiga/whdload.py for an incomplete list (look for primary_icons). This list was used with my WHDLoad importer, but is now also included in FS-UAE Launcher so the Launcher will handle these ambiguous archives.
-
Hi, I've been somewhat busy lately, so I haven't responded to the questions which has cropped up here. I will do so, however, soon In the meantime, I might be able to interest you with a status report: Support for forcing PRELOAD has been added (defaults to on, can be disabled with a setting): https://github.com/FrodeSolheim/fs-uae-launcher/issues/50 Automatically apply config from game database if archive is recognized https://github.com/FrodeSolheim/fs-uae-launcher/issues/34 This is implemented now, and will be released with FS-UAE Launcher 2.9.4dev. Short description: By default, if you start fs-uae-launcher with a path to a WHDLoad archive, it will derive the variant UUID from the files in the archive, and if FS-UAE Launcher finds this variant in the game database, it will use the config from the online game database. You can disable this by adding the new --no-auto-detect-game parameter. If the variant is not found, or --no-auto-detect-game, it will try to automatically generate a config for the game (A1200, 8MB fast RAM, automatically find slave / extract WHDLoad arguments, etc). PRELOAD will be forced automatically (can be disabled by an option). A change in functionality is that now, when launching with a WHDLoad archive as parameter, the name of the archive will be used as save dir name. This applies regardless of whether the variant was found in the game database or not. So the save data is basically tied to the archive name. (On the other hand, if you launch fs-uae-launcher with an UUID, the launcher will generate the save dir name). Look for matching .fs-uae config when starting with a WHDLoad archive as parameter https://github.com/FrodeSolheim/fs-uae-launcher/issues/51 Plan to implement soon, will probably do something like @Zombeaver's suggested, but maybe slightly more basic. For example, if a .fs-uae config file is found with the same name as the WHDLoad archive, load config from that one. In any case, note that this is only "needed" if the automatic config is not good enough, and/or a match in the game database was not found. Better handling of WHDLoad archives with multiple slaves / icons https://github.com/FrodeSolheim/fs-uae-launcher/issues/52 New issue registered. Check issue for more details (also consider subscribing if you are interested). I have added the new issues to my previous post containing a list of issues, and also updated the list marking issues as done
-
@Eirulan I haven't promised it - but I think it is likely with at least some kind of functionality in that regard. However, I can also see that it could also amount to opening a can of worms, so it may not be that easy to cover everyones desires. It may still be necessary with a 3rd-party app for less common cases ;-) Thanks for helping make FS-UAE an attractive option for a wider audience @Zombeaver You're welcome (and also welcome to test if you have not already) It's very common for the slaves to already have sensible defaults (i.e. PRELOAD, etc.) in the .info files. I know because changes to whdload_args on openretro.org are quite rare (but it happens). An option to force PRELOAD is certainly possible. I haven't considered it yet, because I have focused mostly on the online game database, and not much on just "running" a local WHDLoad archive directly. Maybe it is never detrimental... http://whdload.de/docs/en/opt.html claims that "This option should be enabled always". So an alternative is to add it (always) to the auto-generated WHDLoad.prefs file. If the goal is to be be able to "run" a WHDLoad archive (without the online game database), there are a few cases where the automatic configuration may fail: If the whdload args contained in the .info file are incorrect/insufficient. If the slave is too big to fit in 10 MB RAM (happens for a couple of games). If the slave needs other options such as CD32 gamepad (I *could* in theory check the archive name and enable that automatically if the archive name contains CD32. But I don't think that will work always, because the slaves are intended to run on desktop Amigas, and at least for some slaves, . If the slave contains more than one .info file (that's the case for at least a couple of dozen slaves, e.g one .info for intro, and one for the game itself). In this case, the Launcher does not know which one to pick, and now it picks no-one. I could change that so it picks the first one, or try to pick the one which matches the archive name best, but it's (presumably) impossible to make that perfectly. Maybe try to pick the .info file with exact same name as the WHDLoad archive before the first underscore, or something. Though my main focus is to make the game database integration work as well as possible, I'm also happy to improve running WHDLoad archives without the database, as long as the features makes sense and does not detract too much from other improvements! One idea, which might be good, now that the "automatic" functionality works better with regards to WHDLoad arguments, is to add support for an .ini side alongside the WHDLoad archive, say for example: Lotus2_something.lha Lotus2_something.ini And if that .ini file exists, the Launcher could read overrides from that file in the (hopefully few cases where the "automagic" fails. For example to override the WHDLoad arguments, or change pad to CD32 mode. Example: [whdload] whdload_args = Lotus2.slave CUSTOM1=2 joystick_port_1_mode = cd32 pad With these improvements, you could be able to just point the game frontend of your choice (LaunchBox) to a directory with WHDLoad .zip and .lha files, and just specify fs-uae-launcher as the emulator, needing neither the game database nor configuration files. What do you think? (PS: I think I must also need to implement a feature where the save state directory name is created based on the WHDLoad archive name if running without a config or uuid. I think it will just use the default save directory currently).
-
Here is a list of issues (many new, some existing) in the github project(s) relevant to the video / thread: Disable floppy clicking sound when loading a WHDLoad archive as a HD https://github.com/FrodeSolheim/fs-uae-launcher/issues/46 Done Recognize specific WHDLoad archives and apply oagd.net config automatically? https://github.com/FrodeSolheim/fs-uae-launcher/issues/34 Done Extract WHDLoad args from .info file when loading a WHDLoad archive as a HD https://github.com/FrodeSolheim/fs-uae-launcher/issues/48 Done Add new launcher option to specify global WHDLoad quit key https://github.com/FrodeSolheim/fs-uae-launcher/issues/47 Done Option to force PRELOAD for WHDLoad games https://github.com/FrodeSolheim/fs-uae-launcher/issues/50 Done Warp mode mapped on universal controller by default? https://github.com/FrodeSolheim/fs-uae/issues/142 Support injecting quit key event to WHDLoad slave when quitting FS-UAE https://github.com/FrodeSolheim/fs-uae/issues/143 Add atari-color-fix as an internal filter (before the shader stage) https://github.com/FrodeSolheim/fs-uae/issues/144 Function to export launch-stub-files for database games https://github.com/FrodeSolheim/fs-uae-launcher/issues/25 Look for matching .fs-uae config when starting with a WHDLoad archive as parameter https://github.com/FrodeSolheim/fs-uae-launcher/issues/51 Better handling of WHDLoad archives with multiple slaves / icons https://github.com/FrodeSolheim/fs-uae-launcher/issues/52 It's possible to subscribe to the issues you are interested in, so you'll get updates in progress. Also, it's actually useful for me if you do (for the issues you are interested in). That way I have easy access to testers, or if I want to ask questions about usage requirements
-
I've also got an improvement request to the launcher here: https://github.com/FrodeSolheim/fs-uae-launcher/issues/25 ("Function to export launch-stub-files for database games"). Sounds very much like the "FS-UAE Exporter" in the video. So that's something the Launcher might be able to do by itself in the future.
-
(I couldn't figure out how to split up a quote in the UI when replying..., so I inserted individual quotes manually) relative_temp_dir is a very recent option, available in version 2.8.1! I worded myself quite badly there. I meant that it does not work like that today, but I can quite easily implement an improvement to the launcher so it can (in most cases) extract the slave arguments from the .info files Yes, that's exactly what I meant (I probably should not write forum posts when I should have slept instead ;-)) Actually, there was a bug in 2.7.15dev (and 2.8.0) where the shaders were not loaded correctly. Fixed in 2.8.1! Of course! But I thought it would be useful for people to be aware of the unpublished variants, and what you can do with those! No criticism of your video implied And thank you for helping people using FS-UAE One additional comment: The savegame dir name bug when launching games via UUID parameter has been fixed in 2.9.1dev. That fix will probably also be backported to a new 2.8.3 bugfix release.
-
Hi, I registered here so I could give some feedback to the video. First off, I think it's great that people are creating videos about FS-UAE I'm adding a lot of comments here, roughly in chronological order (with regards to the video). Hopefully most comments are interesting or useful. Great video btw! Very well put together Kickstarts are indeed is a nuisance. But unfortunately, I cannot bundle them with FS-UAE :-/ The Amiga 3000 ROM wanted by FS-UAE is indeed in TOSEC. The TOSEC file name is Kickstart v3.1 r40.68 (1993)(Commodore)(A3000).rom. However, it's not really used any much for gaming. The comment you make in the video about most games being set up with an Amiga 1200 model really only applies to WHDLoad games. Most floppy-based games work best with the default Amiga 500 model, and I highly recommend using the A500 model (without any additional config!) as the default point for floppy-based games (except AGA games or games requiring Kickstart 2.0, etc). And then only tune the config if needed. The floppy drive clicking sound is actually automatically disabled when using WHDLoad games with the online game database. I should consider disabling it when loading a WHDload archive directly as well. Warp mode mapped to game controller by default? Makes sense, I'll have to review the default mapping soon. If you are going to use unsafe_save_states = 1, then you should also use relative_temp_feature = 1. This will make the save states much more likely to work! The relative temp feature may become default in the future, but it needs to be explicitly enabled for now. An error in the video regarding the scanning of WHDLoad games. The names of the archives or files do not have to match anything. Each individual data file for a specific WHDLoad game is looked for by checksum against the local file database! A comment related to one of the replies in this thread: Creating your own WHDLoad install *should* be compatible with the ones from the online game database (*). I've made a lot of effort to make that possible: * .info files are ignored (they will be unique for each installation) * Each individual file which is required is looked for by checksum. The archive containing the files does not have to match anything. The files for a WHDLoad install does not even have to be in the same archive. (*) There can be a few exceptions, and it requires you to use the same disk versions and install options. About WHDLoad arguments and missing PRELOAD when giving files directly to the database; Actually, the launcher could (and should) extract the default WHDLoad arguments from the .info icon file within the WHDLoad game archive. I already have code for doing this (used when importing configurations to the online database) so I can improve this. But, using the online game database is a good idea anyway, so you'll get any fixes submitted by users (corrections to the default arguments, extra configuration needed, etc). Cyber Assault does have a configuration in the database. It's not published because all games are "unpublished" by default until metadata is added and someone sets the published status. I've done this for Cyber Assault now (It lacks a cover image though). Btw: New feature in FS-UAE Launcher 2.9.1dev is that you can actually enable an option to show/play/test "unpublished" games from the online database. You could think of these game configs as being in "beta". About the WHDLoad quit key. You are entirely correct about the save game issue. I have been thinking about creating a feature in FS-UAE, where, if it knows it is playing a WHDLoad game, the QUIT action (either action_quit or initiated from the menu, or the window close button, or whatever) then FS-UAE will inject the correct quit key - if it knows it - and wait until the WHDLoad slave quits. (Repeated quit actions will probably need to override and close FS-UAE regardless, an onscreen message could appear saying something like "Quit event sent to WHDLoad. Quit again to force FS-UAE to close immediately".) WHDLoad.prefs is (when not overriden) auto-generated by FS-UAE Launcher. I can add an option to specify quit key in Launcher settings so you don't have to muck about with the prefs file manually. More fool-proof also But, it is also a slightly better idea to register the quit key per slave in the online database, to avoid the global quit key conflicting with in-game keys. E.g. F10 in Desert Strike if I recall correctly. This will work very nicely if the WHDLoad quit feature is implemented in FS-UAE, and the Launcher just tells FS-UAE what the game-specific quit key is. About my name, you are actually pronouncing it *incorrectly* The atari-color-fix shader is indeed included with FS-UAE (it's embedded in fs-uae.dat) Enable with shader = atari-color-fix (no file extension for built-in shaders). I really should do the atari color fix internally before the shader stage (as a special filter with a separate option to enable it) so it can be combined with other shaders. When this is done, we can add information to the online database (or just use the halfcolorbug tag) so the fix is automatically applied for the games in question. Maybe with an option in the Launcher to not apply the fix (for those wanting an authentic, yet dark, experience). There are a lot of games and configs in the online database, and there are certainly problems with some of them. I do encourage you to submit fixes to the games (via the "Edit" tab), and also leave a comment in the "Discuss" tab as to why the fix is needed, if it is not obvious. The edit page can be a bit daunting, but it is moderated, so don't be too afraid to put something wrong there. Just write about your intention in a comment Or just write a comment without editing if you're uncertain how to do it. Example: If you find a WHDLoad variant in the online database with an A600 model, and it works better with A1200, instead of creating a new offline configuration, *please* go to the edit page for the game (there's even a shortcut button for it in the launcher), choose "amiga_model", type "A1200", and click the "Add / Update" button - you need to log in first though. I have corrected the configuration for Citadel, of course! (Also updated the config for Hostages). You are correct about the quit key override not working with 68000. That's a hardware limitation (the feature WHDLoad needs to override the slave's quit key requires 68010 or higher). About CD32 games. If you use a proper CD32 game (model = CD32, CD image), then FS-UAE Launcher will default to using CD32 Gamepad mode. But *WHDLoad* ports of CD32 games is a different matter. These are ports of CD32 games meant to be played on a desktop Amiga, such as the A1200 or A4000. The desktop models defaults to joystick mode. If the game needs the CD32 Gamepad mode, and is incorrectly configured, please submit a fix to the online database (joystick_port_1_mode = cd32 pad). I've only had time to watch the FS-UAE-specific part so far, but I'll watch the rest soon so I know a bit more about how people use FS-UAE