muldjord / skyscraper

Powerful and versatile game scraper written in c++
GNU General Public License v3.0
481 stars 127 forks source link

Support overlays/bezels (or generic assets) as additional resources #127

Open jueank opened 5 years ago

jueank commented 5 years ago

First of all: Skyscraper is great! Many thanks!

The feature: Users should be able to import additional custom asset types into skyscrapers cache on a per-game basis (besides the standardized screenshot, wheel, marquee) and be able to use them in artwork.xml. Intention is to be able to have more degrees of freedom when generating game artwork.

My use-case: I have a collection of ~24 overlay png files for my vertical arcade games. Their usage while playing is fairly standard: covering the left- and right side of the unused space on my monitor for vertical games. Skyscraper comes into play, because i also want to have the overlay images being part of the game screenshot in Emulationstation generated by skyscraper.

In order to do this, i have to use a workaround, because skyscraper can only use additional image files by 'statically' referencing them in .skyscraper/resources. That leads to an awkward workflow:

  1. Per game, delete it from gamelist.xml in roms/arcade, so that i can run skyscraper on a per game basis. Here a feature to 'force' artwork creation for individual games while preserving content of the gamelist.xml for the other games would be great too.
  2. Create an artworkvertical[game-name].xml file, which combines a screenshot (automatically retrieved by skyscraper from the cache) with the statically referenced overlay file for the game whose overlay file name you have to type into the artwork file.
  3. Run skyscraper with "-s localdb --unattendskip -a "/home/pi/.skyscraper/artwork_vertical[game-name].xml"

If skyscraper would support having a resourectype 'overlay' (or any other user-definable types) that you can populate with images by using "-s import" in the commandline, then you could reference this in your artwork.xml file and skyscraper could retrieve the concrete image resource per game dynamically. By doing so, you only need to maintain one artwork file and you could run the artwork generation for all of your (vertical) games at once.

muldjord commented 5 years ago

This is a big change, but I like the idea of having all artwork being custom. I could just add a custom type or something like that to the existing types, but it's not the right way to go. Instead I would need to completely rewrite the artwork type code so no types are hardcoded and all types are custom. This would allow the user to create any type they wanted with the import function. You could create a type called cabinet or cabinet_layer1 or whatever. And the sources would of course create the usual types such as cover and wheel.

But yeah, this is a big change, and I'm not sure when I will get the time to do this. I've added it to the roadmap.

EDIT: Btw, a workaround is to just use one of the existing artwork types for the images you need. I do this myself for the spines of covers. I simply import them as the marquee type and use that in my artwork.xml for the platforms that I have them for. But this only gives you 1 extra type of course, and requires that you don't already use the marquees.

jueank commented 5 years ago

Thanks for mentioning the workaround. The 'spines' files are another case where extendable resource types would be good to have.

I have a proposal which might require much less code changes: Specifically for overlay files, you don't need to import them into skyscrapers cache at all since most probably you have them organized nicely in your local filesystem anyhow (e.g. in one single folder below .skyscraper/resources/). You just need a way to access them properly. Assuming you have overlay files named like your game files- if skyscraper would support wild-cards (for example [game_filename]) you could turn this example of a game specific artwork file

<frame file="arcade-overlays/centiped.zip.png" x="0" y="0" width="640" height="480"/>

into a generic artwork file for all vertical games

<frame file="arcade-overlays/[game_filename].png" x="0" y="0" width="640" height="480"/>

The above would already be sufficient for overlay files. In general it would be nice to be able to define which artwork file to use for which games. Could be some extra 'metadata' you have to import per game (artworkfile=xyz) or you could do it the other way around and evaluate metadata which is already present in skyscraper (e.g. tags like 'vertical-scrolling').

For completeness: If you ever plan to really 'scrape' overlay data from 3rd party sources and write this into skyscrapers cache, then skyscraper could become a Retropie (Retroarch) overlay manager.Using them for artwork creation would only be a by-product then (IMHO).

jueank commented 5 years ago

I have another idea for a workaround feature. it's quite a hack to be honest.

Let's assume your true marquees are coming from a scrape source (arcadedb, thegamesdb, ...) and not from manually importing it. If you could force a source in your artwork.xml, you could import your overlay files as marquees and use resource="marquee:import" instead of resource="marquee" where you want the overlay images to appear. Example would look like this then:

<frame resource="marquee:import" x="0" y="0" width="640" height="480"/>
muldjord commented 5 years ago

In general it would be nice to be able to define which artwork file to use for which games.

You can already do this for platforms. Simply create a [<PLATFORM>] section in config.ini and set the artworkXml=<FILENAME> option to point to different xml files per platform. This is very useful for handling different artwork configs, specifically for arcade platforms where users often desire a different look. But I understand you want it to go deeper, detecting the tags and using a different artwork.xml for certain tags. I'm not sure I want to go down this road, but I like the idea.

I do think your first workaround could make sense (the file="arcade-overlays/[game_filename].png" concept). It's quite easily achieved I think and would be quite useful. Gonna add that to the roadmap aswell.

spilinek commented 4 years ago

I ran into this issue with Attract Mode. I have a layout that is looking for artwork like boxart and cartart. I tried adding output type boxart to my artwork.xml, but boxart wasn't getting generated. Took quite a while to figure out you cannot add custom boxart. Would be nice if ARTWORK.md mentioned that the ouptut types are hard coded and you can't add custom ones.

muldjord commented 4 years ago

I can add a note about them being hardcoded.