Fun Facts Splashscreens

meleu

@hiulit well done sir!!

hiulit

Good news everyone! Fun Facts! Splashscreens v1.1.0 is here! :D

Added

--apply-splash to use the generated Fun Facts! splashscreen.
--update to check if the Fun Facts! script needs updates.

Deprecated

~~--splash~~ is now --splash-path.

Now it's possible to apply/set/use the Fun Facts! splashscreen right within the script, with the command --apply-splash.
This will append the generated Fun Facts! splashscreen to /etc/splashscreen.list. This file is the one responsible to tell the system which splashscreen to show at boot.

Also, I've added the --update command, to stay up to date with the latest changes ;)

It would be awesome if you guys could try this script :)
Let me know if it's working (or not), if you find some functionality is lacking, etc.

Thanks!

hiulit

We are now at Fun Facts! Splashscreens v1.4.1! :D

You can check the CHANGELOG to see the latest changes, but the main ones are:

More Fun Facts!, thanks to Thunderforge.
"Set the text color" is now split into 2 subsections, basic colors and full list of colors.
Check if there are updates to download.

You can use the Update script option from within the script to get the latest version.

If you are using the script via the RetroPie-Setup (if you installed it via the Retropie-Extra repository), go to:

Manage packages
Manage experimental packages
fun-facts-splashscreens
Update from source

fnkngrv

This is definitely pretty cool however why are you saying that it is only able to be used on the Raspberry Pi boards?

hiulit

@fnkngrv I guess you are referring to other boards like Odroid, Orangepi, Tinker boards, etc, right? Maybe I should change that. What I meant is that Splashscreens are NOT available on these systems !x86 !osmc !xbian !mali !kms.

fnkngrv

@hiulit said in Fun Facts Splashscreens:

@fnkngrv I guess you are referring to other boards like Odroid, Orangepi, Tinker boards, etc, right? Maybe I should change that. What I meant is that Splashscreens are NOT available on these systems !x86 !osmc !xbian !mali !kms.

Correct.

Is this specific capability 100% dependent on OMX player? I ask because as an example the Odroid XU4 has a mali GPU and we (Odroid Retro Arena) do have splashscreens working albeit they are the video ones. I have not tested static images as of yet because quite frankly most people I know prefer video over static.

To provide further background my dev team that I put together a few months ago have been working to provide a base RetroPie image for the Odroid XU4 that rivals the experience on the Raspberry boards and in many cases surpasses it. My goal when I started was to work toward assisting to have more robust support for the board and eventually providing our results to the RetroPie devs to incorporate those results and make the experience for the XU4 users more seemless from the start like with the RPi boards.

hiulit

@fnkngrv I really don't know what makes splashscreens work, I actually just copied the flags that RetroPie is using, assuming they would know :P
That being said, those flags are only used in the scriptmodule, if you use the "standalone" fun facts script https://github.com/hiulit/RetroPie-Fun-Facts-Splashscreens/blob/master/fun-facts-splashscreens.sh it should work. It doesn't check any of those flags.

hiulit

@fnkngrv said in Fun Facts Splashscreens:

!x86 !osmc !xbian !mali !kms

Maybe @herb_fargus or @BuZz could tell usa bit more about these flags !x86 !osmc !xbian !mali !kms in splashscreen.shhttps://github.com/RetroPie/RetroPie-Setup/blob/f482904f8e2fd0edb02057805b7ed813e3265f9b/scriptmodules/supplementary/splashscreen.sh and when do splashscreens work and when they don't.

hiulit

New Fun Facts! Splashscreens version v1.5.0.

Changelog

Fixed

Fixed issue in create_fun_fact() which was not getting proper values and therefore making the function not to work.
Fixed issue in Set splashscreen path option which was setting the path incorrectly.

Added

Merged #16 - More Fun Facts! thanks to Thunderforge.
Added documentation for --version.
Added a style guide for adding new Fun Facts!.

Changed

Applied the style guide to Fun Facts!.
Updated help for the scriptmodule.
Cleaned up code and comments.
Changed some outputs that were too much verbose.

I guess there aren't many people using the script because there were a couple of big bugs and nobody noticed :P

Anyway, I keep working on improving it :D

fnkngrv

@hiulit said in Fun Facts Splashscreens:

@fnkngrv I really don't know what makes splashscreens work, I actually just copied the flags that RetroPie is using, assuming they would know :P
That being said, those flags are only used in the scriptmodule, if you use the "standalone" fun facts script https://github.com/hiulit/RetroPie-Fun-Facts-Splashscreens/blob/master/fun-facts-splashscreens.sh it should work. It doesn't check any of those flags.

good to know....It would be interesting to see this also get implemented in the launching images via runcommand.

hiulit

@fnkngrv Yeah, that's something we talked about with some people here in the early stages of the Fun Facts! Splashscreens development but I decided to start with the boot splashscreens as it was easier to do. I've never work with the runcommand but I wanted to, so I guess now it's a good time to take a look at it ;)
Also, there was some talking about the possibility that launching the script via the runcommamd could take too much time to create the splashscreen and therefore the user would have to wait too much to start the game.
I'll open an issue in the GitHub repo so I don't forget!

cyperghost

@hiulit said in Fun Facts Splashscreens:

Also, there was some talking about the possibility that launching the script via the runcommamd could take too much time to create the splashscreen and therefore the user would have to wait too much to start the game.

I'm here!
Well the runcommand-onstart.sh is the key for this and afaik runcommand itself starts the emulators AFTER the onstart-script gots completly excuted and closed.
Why do I say that? Because if you add a sleeptimer of a few seconds. The runcommand call is delayed for a few seconds. So I think it doesn't matter at which point a splashscreen is created.

I would suggest to use /dev/shm because that's a RAM-drive (fast) and will cleanup itself after powerdown ;)

meleu

@hiulit @cyperghost my 2 cents, call the script via runcommand-onend.sh. When an user launches a game he is eager to play, and even a short delay can be frustrating. When he leaves the game he is already satisfied and a small delay to go back to emulationstation won't hurt that much. ;-)

cyperghost

@meleu I don't know how much it lasts to generate a picture and I think the RAM-drive should speed this up. But I'm not the developer of this. So with your suggestion we would create a screen on every boot and after a game is finished. Also a possibility - nevertheless I would prefer the runcommand-onstart.sh ;)

meleu

@cyperghost said in Fun Facts Splashscreens:

@meleu I don't know how much it lasts to generate a picture and I think the RAM-drive should speed this up.

I think you're saying this based on what we discussed about my script to generate launching images. If I recall correctly you suggested using /dev/shm because in my script I create some temporary images to build the final one.

But the fun-facts script creates the final image in only one step. Add the fun-fact text and done!

So with your suggestion we would create a screen on every boot and after a game is finished.

With that sentece I'm not sure if you are confused about what the fun-fact script does. Then here are some words, just trying to clarify:

The boot splashscreen image file is different from launching images.

When the fun-fact feature is enabled to run at boot it generates, in a background process, a new splashscreen for the next boot. The splashcreen that is being shown was previously generated and the code responsible for showing it is the official splashscreen RetroPie scriptmodule. It has nothing to do with launching images.

I would prefer the runcommand-onstart.sh ;)

My suggestion to call it from -onend script is just an approach taking into consideration the user experience, but the code would be exactly the same, regardless of it being called from -onstart or -onend scripts.

And now, at a second thought, I think that calling it from -onstart and making it runs in background, while the current launching image is being shown, can work better.

@hiulit

The feature @fnkngrv requested does not demand any change on the fun-fact script.

We made the fun-fact script allow the user choose what image you want to use to add the fun-fact on. Then it's just a matter of runcommand-onstart/onend tweaking. ;-)

fnkngrv

@meleu said in Fun Facts Splashscreens:

@hiulit @cyperghost my 2 cents, call the script via runcommand-onend.sh. When an user launches a game he is eager to play, and even a short delay can be frustrating. When he leaves the game he is already satisfied and a small delay to go back to emulationstation won't hurt that much. ;-)

that is a cool idea actually!

cyperghost

@meleu said in Fun Facts Splashscreens:

So with your suggestion we would create a screen on every boot and after a game is finished.

With that sentece I'm not sure if you are confused about what the fun-fact script does. Then here are some words, just trying to clarify:
The boot splashscreen image file is different from launching images.

Sorry bro for being unclear.
My suggestion was to create a funfact screen during boot (not a splashscreen!) to have one generated picture ready to show if you start a ROM. Then the runcommand-onend creates the next...

Hope that I was clear now ;)

meleu

@cyperghost

My suggestion was to create a funfact screen during boot (not a splashscreen!) to have one generated picture ready to show if you start a ROM.

Generate launching images at boot? For what system? All of them? 😱

I think the delay would be unbearable.

hiulit

@meleu @cyperghost maybe what we could do is have a function in fun facts to create all those launching images (it would take a long time) and then we could either use onend or onstart to generate the new one, per rom/system

meleu

@hiulit I wouldn't bother to code something to be used only one time to do the exactly same thing that would be done on demand later (except for learning purposes, of course).

Summing up: let's focus on runcommand-onstart/-onend scripts! ;-)