Versatile C++ game scraper: Skyscraper

jura

Hi @muldjord , I used your software for the scraping the images for roms and I loved it.

Seems to work almost OK, sometimes when game names are closely the same e.g. gameName 1 and gameName 2 it messes the description for these games. There's might be a chance that these descriptions are messed up in the location where it get it from at the first place, dunno.

When I checked the Lakka which is another Retro gaming fontend seems that they get images and thimbnails from the libretro. Dunno is it only based on the name of the game.

Any chance to use also this location which is used in Lakka for the images to the games? :)

https://github.com/libretro/libretro-thumbnails/tree/master/

muldjord

@jura It doesn't mess them up, rather it sometimes gets faulty results from the sources, which is a side-effect of the highly automated way Skyscraper works. For instance, if you have a relatively unknown game called "Star Blob" and a game called "Star Fox", it will quite likely get a correct hit for "Star Fox" since it's a well-known game. BUT, it will probably also return the data for "Star Fox" when it searches for "Star Blob" since that's how the source search engines work. So it doesn't mess them up, it just, sometimes, gets faulty results where it seems like the previous game has "spilled over" into the next entry, when in fact it only does so because the names are closely related. In this example by the "Star" in the name.

You can force it to not accept these by changing the minimum match percentage with the '-m' flag on command line. :) It defaults to 50%, which means that "Star Blob" and "Star Fox" gives a positive result.

I can't use a github repository for scraping, simply because I do not have the permission from github to do so. Github is not meant to be used for game media scraping and I highly doubt they would allow it if they knew people used it for that purpose.

EDIT: On a sidenote, I plan on completely rewriting the way matches are achieved, so matches will improve in a future version. No ETA though.

muldjord

A huge thank you to @chipsnblip for spreading the word about Skyscraper on reddit. I notice these things, and I appreciate it a lot! :)

chipsnblip

@muldjord it's my pleasure to help! i've been lurking in this thread since day one, and to tell the truth haven't even used skyscraper yet (but plan on it very soon-- life keeps getting in the way). i was just so impressed watching one person's hard work and dedication to a project of this nature. seeing people pour their heart into the retro gaming community is truly inspiring.

muldjord

On a related note: If any of you good people feel Skyscraper is a project you want to support, then a good way to do so is simply to spread the word about it. :) I'm not exactly a PR guru myself, so I'll concentrate on the coding part of it. When people do lend a hand it means quite a lot, and is quite motivating.

As you know Skyscraper is completely open source and free to use (I'm a huge advocate of openness in general). I do this work entirely in my spare time simply because I enjoy working on it. Part of that is watching the community actually make use of the project. So a thank you to all of you for simply using it is in order aswell. :)

Clyde

@muldjord said in Versatile C++ game scraper: Skyscraper:

As you know Skyscraper is completely open source and free to use (I'm a huge advocate of openness in general).

Let's drink to that. o/ᵁ

muldjord

@clyde *clink* ᵁ\o

AnalogHero

I really think skyscraper should included in Retropie-Setup. Im sure i mentioned this in a different topic.

AnalogHero

@muldjord Could it be that version 2.2.5 is a lot slower than previous versions? Just added a few whdload games and rescraped my amiga folder. I thought it crashed because the first output took sol long. Scraping with localdb takes the same amount of time. Over 10 minutes for 61 .uae files...

muldjord

@analoghero It is slower yes, which is caused by the new compositor rendering the shadow. I've optimized it a bit, but it could probably be optimized even further in future releases. I've basically implemented my own custom shadow renderer based on gauss kernel, which takes a bit of time to render... If you want to speed it up, try disabling the drop shadow in artwork.xml (chech the documentation for that).

The first results sometimes (not always) take a long time, that's normal (also for pre-2.2.5 versions), there's nothing I can do to change that since it is caused by the Qt frameworks network manager.

EDIT: 10 minutes for 61 uae files means something is wrong on your end. Can't tell you what exactly. It's a lot faster on my Pi 3 (not overclocked).

AnalogHero

@muldjord Cant say whats wrong... just tested it with psx as platform (18 games here). Took 4:06 :( This was faster in the past for sure.

(ES is closed, nothing is overclocked or running too hot)

Shame that i dont have a older version, would test it.

Edit: When --pretend ist set, its fast. When it dont find any matches (using wrong scraper) its also fast.

AnalogHero

@muldjord Ok tested it. Compiled old version 2.2.1 and scraped my psx system with 18 games in it. Result: Took 12 seconds

---- Scraping run completed! YAY! ----
Writing 366 resources to local database, please wait... Success!
Now writing '/home/pi/RetroPie/roms/psx/gamelist.xml'... Success!!!

---- And here are some neat stats :) ----
Total completion time: 00:00:12

Average search match: 93%
Average entry completeness: 83%

Total number of games: 18
Successfully scraped games: 17
Skipped games: 1 (Filenames saved to 'skipped-localdb.txt')

With 2.2.5:

---- Scraping run completed! YAY! ----
Writing 366 resources to local database, please wait... Success!
Now writing '/home/pi/RetroPie/roms/psx/gamelist.xml'... Success!!!

---- And here are some neat stats :) ----
Total completion time: 00:03:58

Average search match: 93%
Average entry completeness: 83%

Total number of games: 18
Successfully scraped games: 17
Skipped games: 1 (Filenames saved to 'skipped-localdb.txt')

muldjord

I will do some testing on this when I get the time. In the meantime, please post your artwork.xml file.

muldjord

Just scraped 11 files on scummvm platform. Took 18 seconds on 2.2.6 with localdb on my Pi3 model B with RetroPie 4.3.
Scraped 21 files on psx platform with 2.2.6. Took 30 seconds.

Here's my artwork.xml. Try using that:

<?xml version="1.0" encoding="UTF-8"?>
<artwork>
  <output type="screenshot" width="640" height="400">
    <layer resource="cover" valign="bottom" y="-15" height="200">
      <shadow distance="10" softness="5" opacity="50"/>
    </layer>
    <layer resource="screenshot" align="right" width="520" height="390"/>
  </output>
</artwork>

EDIT: Just cleared out my localdb and rescraped which is the same as starting over. Still only takes 30 seconds for 21 psx games. I can't reproduce your problem, sorry.

AnalogHero

@muldjord Ok its much faster now. Here is my (slow) artwork.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- This is the default 'artwork.xml' file that exports a screenshot composited from the cover and screenshot artwork and the wheel file. Please check 'artwork.xml.example' for a more thorough example of the possibilites. Also be sure to check the full artwork documentation at https://github.com/muldjord/skyscraper/blob/master/ARTWORK.md -->
<artwork>
  <output type="screenshot" width="640" height="400">
    <layer resource="cover" valign="bottom" y="-15" height="200">
      <shadow distance="10" softness="10" opacity="75"/>
    </layer>
    <layer resource="screenshot" align="right" valign="top" width="520" height="390"/>
  </output>
  <!-- delete the next line to disable 'wheel entirely -->
  <output type="wheel" width="350"/>
  <!-- delete the next line to disable 'cover' entirely -->
  <output type="cover" height="390"/>
  <!-- delete the next line to disable 'marquee' entirely -->
  <output type="marquee" width="350"/>
</artwork>

muldjord

@analoghero I'm pretty sure it's the "softness=10" that causes the huge slowdown, which is probably what I made the default value was for 2.2.5, sorry bout that.
Rendering a shadow using a gauss kernel is quite taxing on the cpu, and the higher the softness, the bigger the gauss kernel is, which results in a lot more work for the cpu. So that's the short explanation.

So, basically there isn't an issue, it's just because the shadow rendering is so taxing on the cpu and therefore it becomes slow.

EDIT: I will look into optimizing the shadow rendering in the future. If/when I do, it will be a bullet point on the release note.

AnalogHero

@muldjord Thanks for looking into it. I changed the xml a few times, so i wasnt sure if it was the default. No time to test atm, is there any difference visible between softness 5 and 10?

muldjord

Yes, it's the softness/blur of the shadow. But I personally prefer a softness of 5, so just keep it at that (I might put a max of 5 on it in future releases).

muldjord

I am currently looking into an optimized algorithm for the shadow renderer. If all goes well, it should provide the same result with a huuuuuge speed improvement. So "softness=10" would become usable.

EDIT: New algorithm is almost implemented and will be in 2.2.7. The speed improvement is insane! Thousands of times faster, literally.

muldjord

The new optimized gauss shadow rendering is now fully implemented and the results are in! For 21 roms, rendering 1 shadow with a softness of 10 for each:

Old unoptimized version 2.2.6: 3 minutes and 26 seconds
New optimized version 2.2.7(still in testing): 4 SECONDS!

Now, THAT's what I call a proper optimization! :D HAHA, I love this.

Keep in mind that this is for 1 shadow with a softness of 10. The more shadows you have, the more time is saved. And also, a softness of 10 is ridiculous, so most often you'd use a softness of 2-5, which is even faster!

2.2.7 will be released as soon as I've done some testing. :)