Is there a roadmap of potential improvements?

[eduo]

Hi!

I'm not sure if this is the right channel, and of course feel free to ignore this if it's not something that can be shared.

Is there a roadmap of potential improvements in the pipeline? I understand iDOS has been a BUMPY RIDE, to say the least, over the years and thus a roadmap may never have really been a priority.

There're a few things I see requested over and over and it would be nice to know how far from the plans they are. None of the items below is a formal request or requirement, but various ideas that have been asked about, floated or compared to other solutions out there. Many of these may have been implemented already in DOSBox-X, DOSBox-Staging, DOSBox-Pure or other variants, since many are common requests.

• GUI: Ability to load disks, folders, floppies and CDs in portrait mode. Also avoiding the "…" in iPad Stage Manager.

• GUI: Allow changing speed by clicking the green "100%" led.

• UX: iDOS being capable of pausing one running emulation when another is opened (tapping on a package) asking if it should be closed to open the new one or if it's a disk image asking if it should be mounted.

• UX: Ability to use the GUI to mount more image formats (at least those supported by DOSBox itself, most of which are not selectable for mounting from the menus but can be mounted via the command line). It's not clear which formats are supported via the GUI nor possible to define which letter should be assigned.

• UX: Ability to modify or reset DOSBox config variables from the GUI (dumb editing for the most part, but linking descriptions, documentation and "extras" like specifying a location to copy Roland ROMs from), and have them saved for future sessions.

• GUI: Ability to define a default keyboard layout other than default English (supported, but not straightforward).

• UX: Support for custom keyboard layouts/overlays as another option (next to keyboard, joystick, gamepad, etc). For apps and games which may have specific shortcuts that could be mapped to larger/renamed buttons.

• GUI: Support for custom overlay/skin (for example, to use iDOS in portrait with buttons on either side of the screen).

• UX: Support drag/drop in iPad/iPhone (offers to write path or to copy file to container directory).

• UX: Ability to "save" the current environment as a standalone .iDOS package (also, of editing and saving the settings while in an .iDOS package, including editing the screenshot).

• GUI: Visual shortcut to filesystem while in DOS mode to quickly see executables, texts, images, directories without dropping to DOS for simple "check and open" actions. Ability to flag some as "favorites" so they're featured at the top.

• UX: .iDOS package support for manuals (visible while in play), image gallery, text blurb

• UX: "Library"/"Launcher" mode able to list saved/loaded .iDOS packages (either historically opened or favorited).

• UX: Ability to create floppy and hard drive images from within iDOS

• UX: Apple Pencil support (direct touch may not be possible, but palm rejection and 100% pencil input replacing a mouse may be).

• QoL: Information labels on settings to explain what they do.

[litchie]

Thank you for taking the trouble to put everything together. They are very good suggestions. I shared with you a google doc since it's easier to respond that way.

[jorycz]

I would add - Saved States. If the game is opened from .idos package, settings should be aways the same.

[eduo]

I would add - Saved States. If the game is opened from .idos package, settings should be aways the same.

I think everyone agrees on this but.

Save States are not a trivial problem. Save States for DOSBox have not been resolved satisfactorily by any variant or custom modification. Some are included in front-ends (most famously retroarch's dosbox-pure and dosbox-x, both of which implement the same old hack) but are extremely buggy. In general it's not recommended and it's been shown to corrupt save files and break gameplay.

It's an easier problem on emulators that rely on disk images but much harder on the ones that rely on interaction with the local filesystem since assumptions on files locations, open state and metadata can't remain fixed inbetween runs. A Snapshot will always be unreliable in these cases.

[jorycz]

Could be available and always stored only in (and when used) .idos package. Because of static settings, it should work OK.

[eduo]

It's unrelated to being an .idos package. It an issue with emulating the platform itself and how the platform and the filesystem are not able to hold memory snapshots.

An .idos package is just a dedicated dosbox folder. The settings have no relation to the complexity of saving states.

This has been tried and it's known to be unreliable. Search for dosbox savestate bugs and you'll see the recommendation is always to not rely on savestates because they only work for the most basic of games (the ones 100% loaded into memory without any filesystem interaction)