A graphical front-end for command line emulators that hides the underlying operating system and is intended to be controlled with a joystick or gamepad.
Would it be possible to treat "text assets" in a similar way to artworks? Or create an instance of Text class which is similar to what artwork is to images? Right now artwork provide a lot of ease of use, like we can create any number of artworks in emulator.cfg, mention paths and easily call upon them in layouts i.e. "fe.add_artwork (art-class dimesnions)". No such function is available for text assets, other then Magic Tokens where other hardcaps apply. Some instances where it can helpful are:
Right now all "overviews" are being kept at a specific location "AM\scrpaer\emulator-name". This has a few drawbacks, for one The number of files can increase greatly. Then lack of portability, if we can specify the location for overviews (e.g. in relation to roms or in emulator.cfg) the whole rom-package can be kept portable with all image/ text assets in a single place. Current location also complicates automated backups as either one has to backup in bulk (/scraper) or create as many sync instances as number of emulated systems.
Emulating systems like Commodore and PC-98 has many instances where specific keyboard input is required, or in case of PC-98 switch Floppy disk images in a certain way. Such information is far better suited for an easily accessible text field (e.g. "notes"). Something which would not require to switch out of AM.
Currently we can't use triggers like "Trigger.EndNavigation" with Text, this can have an impact on browsing speed if there are huge text files.
Magic Tokens can be useful for this but AFAIK only functions defined within the layout can be called via MT, plus paths can't be specified. Adding this in romlist (under different header) will create a mess because of length of text. If we can create a Text class instance like artwork it would solve most of the issues:
a- any number of text assets so all relevant data at one place
b- custom paths so portability and better organization
c- easy accessibility in layouts
d- working triggers
Would it be possible to treat "text assets" in a similar way to artworks? Or create an instance of Text class which is similar to what artwork is to images? Right now artwork provide a lot of ease of use, like we can create any number of artworks in emulator.cfg, mention paths and easily call upon them in layouts i.e. "fe.add_artwork (art-class dimesnions)". No such function is available for text assets, other then Magic Tokens where other hardcaps apply. Some instances where it can helpful are:
Right now all "overviews" are being kept at a specific location "AM\scrpaer\emulator-name". This has a few drawbacks, for one The number of files can increase greatly. Then lack of portability, if we can specify the location for overviews (e.g. in relation to roms or in emulator.cfg) the whole rom-package can be kept portable with all image/ text assets in a single place. Current location also complicates automated backups as either one has to backup in bulk (/scraper) or create as many sync instances as number of emulated systems.
Emulating systems like Commodore and PC-98 has many instances where specific keyboard input is required, or in case of PC-98 switch Floppy disk images in a certain way. Such information is far better suited for an easily accessible text field (e.g. "notes"). Something which would not require to switch out of AM.
Currently we can't use triggers like "Trigger.EndNavigation" with Text, this can have an impact on browsing speed if there are huge text files.
Magic Tokens can be useful for this but AFAIK only functions defined within the layout can be called via MT, plus paths can't be specified. Adding this in romlist (under different header) will create a mess because of length of text. If we can create a Text class instance like artwork it would solve most of the issues:
a- any number of text assets so all relevant data at one place b- custom paths so portability and better organization c- easy accessibility in layouts d- working triggers