I think it’s better to focus on making the script do one thing only and as better as I can. If what you want is to manipulate the layout or cfg files, let’s say zip them, move them, then that part is currently out of the script on purpose. I’m not sure if I got your point entirely correct (pardon me but English is not my primary language). It would be a huge time saver and would allow me to also generate the precisely correct configurations for all my overlays without manual effort. It would also create the CFG files necessary for Retroarch and the proper directory structure for that as well. The script would then use the name from that PNG file to create a mame directory, the LAY file based on the dimensions of the transparent area of that PNG and then compress it into a zip file for distribution. My thinking is that I would like to create a script where I drop a PNG file into an image directory and then run “build” on that directory. If I had something as complex as the Space Invaders example I could just do that by hand. But this is also the assumption of the already existing overlay generation functions, that’s why you can specify a target size to resize the overlay image before calculation. This of couse assumes that the bezel size is equal (or at least fits without rescaling) to the monitor size. Where the “curly variables” would be filled in with the viewport values the scripts calculates form the bexel transparent area, and with set to the actual bezel size. The MAME layout files seem much more complex and versatile than I thought.Ĭonsidering just the basic layout sample that provided, I was thinking of converting it into a template like this for my purposes: Nothing in this folder will be menipulated or deleted (unless it's an output folder for some other command). Currently the "overlay_*" and "config_*" commands need to scan the directory containing the original overlays. PLEASE NOTE THAT ALL FILES EVENTUALLY EXISTING WILL BE DELETED.Įvery basic command that needs input files has it's own "input" keys in its related section. If you see the game running in a small box in RetroArch surrounded by black you probably put an incorrect path in this variable.Īll "output" directories will be created automatically if non existant. If it's incorrect RetroArch will not be able to locate and show the overlays. This is most important because it's the path that will be written into the configuration files. The "realoverlaybasedir" key MUST point to the path where RetroArch will look for overlay files. The file contains the basic paths for the utility to work. Rename the default configuration file to "config.ini". The program is then OS independent and should work fine on Linux, Mac or Windows. The program is written in Python3 so you'll need the Python language 3.* installed on your system. # Simple utility to manage RetroArch overlay images and related config filesĭownload the zip file and uncompress wherever you want. tarrasque73/RetroManager/blob/master/README.md # RetroManager It’s still very rough and I’d like to have feedback to fix and improve it. It’s a command line utility written in Python so it should easily running any system, provided you have Python 3.* installed. The resize operation can be based on the full size of the overlay or the viewport, thus maximizing the game playable area and cropping “excess” overlay. It can resize overlays to the desired size keeping the aspect ratio. It can detect the “viewport” area inside the overlay and generate RetroArch config files so that a game runs (almost) perfectly inside it. I developed a little utility to massively manage overlays and other config files for RetroArch.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |