go-emu-launcher

[johannesbehr]

I started a fork and added GIF-Support for the box-art

As the storage limits are quite high with microsd but the ram is low, wouldnt it be better to use uncompressed box art image formats instead of gif?

That was there's less data interpretation to be done?

The decompression of the gif is pretty fast. In comparison to the CRC-Calculation the go-emu-launcher does now, it is nearly zero-time.
Actually my change works in this way, that if there is an gif in the same Folder with the same name as the rom-file, it is loaded immediatetly,
E.g. 'Alien vs Predator.gif' for 'Alien vs Predator.lnx'.
The normal Art-Folder with CRC still works in the same way as before.
I do only load the first Frame of the gif file, so Animation is out of focus (but would be possible by loading further frames from the file).
The ram consumption is moderate and the files have the big advantage that the can be created with any grafic tool.

I also converted the header and logo files in the metadata-folder, this works well, too (I'll attach the files...).
So with a gif format here, custom theming could be easily done...

[johannesbehr]

Just in case anyone likes to test the gif-feature, I created a release:
https://github.com/johannesbehr/odroid- ... op/release
Please keep in mind that this is just a test version, so no guarantees


Edit: Switched to develop branch to be uptodate.
@pelle7: I suggest that you also set the develop branch as Default in order to avoid confusion.

[ducalex]

I like the idea of cover art in a more accessible format and there's more than enough RAM to do it.

But have you run any kind of analysis on existing cover art to see how many colors they use? I'm worried that GIF's 256 colors limit might be a (small) problem and PNG would have been a better choice.

[johannesbehr]

I like the idea of cover art in a more accessible format and there's more than enough RAM to do it.

But have you run any kind of analysis on existing cover art to see how many colors they use? I'm worried that GIF's 256 colors limit might be a (small) problem and PNG would have been a better choice.

I understand your Point, but I think at a size of 176 Pixel (max for height) and this type of display, there is nearly no visible difference.
For a quick test I calculated the difference between a example gif and a png, can you tell which is the gif ?

Rampage (USA, Europe)_small.png (65.21 KiB) Viewed 397 times

Rampage (USA, Europe)_small.gif (21.19 KiB) Viewed 397 times

Rampage (USA, Europe)_small_delta.png (46.65 KiB) Viewed 397 times

But yes, I think png and jpg would also be possible, I still plan to test the following libs: https://github.com/elanthis/upng and https://github.com/MakotoKurauchi/JPEGDecoder

[lordhardware]

Id like to see the render speed of a .tif or uncompressed .png vs a .gif

Not saying its not quick but that means no overhead or artifacting just straight screen draw (providing the pixel size is set)

[ducalex]

I understand your Point, but I think at a size of 176 Pixel (max for height) and this type of display, there is nearly no visible difference.
For a quick test I calculated the difference between a example gif and a png, can you tell which is the gif ?

I think I worded my question poorly. I wasn't worried that it would look worse in real life, really. I was just curious why you picked GIF over PNG it is (on the surface) better suited.

But after taking a look at the code I can see that gifdec is much simpler than even the simplest png decoder I'm familiar with, which is nice. Plus GIF has the advantage that eventually we could have cool animated headers!

[johannesbehr]

Hi Folks,
I just changed the style of the file list a bit to cut the names, do paging and use a different font
For me this is more comfortable, but I think it is a question of gusto.

https://github.com/johannesbehr/odroid- ... op/release

if more people like it, maybe this style could be a menu option?

(But keep in mind that this is only a tweaked test version and not official Version!)

[Nemo1984]

Does this firmware have the Triforce/Super Go Play improvements?

[ducalex]

Does this firmware have the Triforce/Super Go Play improvements?

Yes he incorporated the changes! See here viewtopic.php?f=159&t=35234#p260327.

[ripper121]

Coolest would be to have a MP3 player and SD-File Wifi Browser on board:
--> viewtopic.php?f=162&t=35893
--> viewtopic.php?f=162&t=35893

[Paspartout]

Very nice project, the ingame menu in the emulators is quite an improvement over the old way of interacting.

I also found a bug that occurs when an emulator with no roms is chosen that when you then press right or left on dpad the menu freezes and I have to restart the odroid-go.
Also one suggestion I would have is that when you press menu on the launcher that it would reboot into the firmware,
so users could switch/reflash applications without turning the odroid go off and on again.
I might address these myself and submit a pull request.

Coolest would be to have a MP3 player and SD-File Wifi Browser on board:
--> viewtopic.php?f=162&t=35893
--> viewtopic.php?f=162&t=35893

I agree, having a emulator launcher or even firmware with all that functionality built-in would be awesome.
But the firmware switcher from ducalex is making switching between these applications already quite convenient.