Cabrio and big list

[Fred B]

Hi,

With this hardware - AMD A4 5300 3,4GHz + 4go -, cabrio takes about 40 seconds to start
Has anyone had success using a full set (mame) with cabrio-fe ?

Regards
Fred

[Pieter Hulshoff]

Not really. It's one of the issues that will be fixed in 2.0. My computer needed several minutes to read in a complete MAME list. In 2.0, this will only take (part of) a second.

[Fred B]

Ok thanks

[Fred B]

For information the problem seems related with the artworks, not directly with the size of the list
A full set can works, a full set with artworks = 100% CPU

[Pieter Hulshoff]

I'll give it some thought; perhaps I'll have a look at the Cabrio 1.0 code, and do some updating there as well, though Steve would probably be able to fix this much quicker. I haven't heard from him in a while though.

[Fred B]

It would be great ! Like I said in topic "Saying thanks! (and a question too...)" it should be interesting to maintain a cabrio-fe 1.0 version, no deep change but some ameliorations.
Please, can you take a look at https://github.com/fredbcode/cabrio

Fred

[Fred B]

Merge here: https://github.com/SteveMaddison/cabrio/pull/18

Fred

[Fred B]

Hi Pieter, Hi Steve,

I'm thinking about this problem. Maybe a way to fix should be to remove the complete load of artworks and make a partial buffer.
Something like 10, 20 or maybe 50 artworks only, and loaded one by one at each move in front-end (right, or left)

For example: Cabrio at start -> 20 artworks are loaded, a move one step to the left and cabrio loads one new artwork and removes the first in memory.

About the jump to the next alphabetical letter, Cabrio should load 20 new artworks (I think with an old hardware this should be quick)

What do you think of this ? I guess the memory and CPU usage should be reduced and it's more simpler than a DB or something like that.

Fred

[Pieter Hulshoff]

Considering the plethora of themes and artwork, I think everything should be loaded on the spot. That's how practically every front-end I'm familiar with, including my own, handles it. Simply load your skin elements when needed, and free them up afterwards. Just for a few systems I'm already looking at 29 GB of art; that's not something that should be stored in RAM. I'd suggest removing the art loading from start-up, and add it to the display section for each element. For Cabrio 2.0 I'll provide some functions to return the path and file names of the desired files, but for 1.0 the defined names will do.

--
You received this message because you are subscribed to the Google Groups "Cabrio FE Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cabrio-fe-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Fred B]

Yes, but a minimum load is needed , for example https://www.youtube.com/watch?v=7yU7G-4fios , except video - just one -, there are seven artworks on the screen at start.
Thanks for your answer, what's your planning ? You will look soon ?

[Pieter Hulshoff]

I'm not too worried about loading 7 graphical elements on the spot. I'll have a look soon, and fork from your code. That's the one with the video fix?

[Fred B]

Yes right, and with some new features asked by users

[Pieter Hulshoff]

My apologies for the delays. I've forked and cloned your fork, and managed to get everything compiled and running. Next step is to analyse the code structure, and then I'll have a try and fixing this big list issue. I'll keep you posted.

[Fred B]

Le vendredi 23 janvier 2015 08:52:20 UTC+1, Pieter Hulshoff a écrit :

My apologies for the delays. I've forked and cloned your fork, and managed to get everything compiled and running. Next step is to analyse the code structure, and then I'll have a try and fixing this big list issue. I'll keep you posted.

Hi, Great !

[Pieter Hulshoff]

Ok, the cause is clear:

On my computer, about 7s of the delay when reading a full MAME list is caused by sorting the game list for each game that's inserted. That should be replaced by a sorting algorithm when the list is complete.

The rest (minutes) of the delay is caused by matching the game names to the corresponding art files. For each game, the directory in the specified path is read, and each file name is compared to the game name. With 30k games, 4.5k videos and 6.5k wheel images, that's a lot of matching. I'm considering replacing it with something simpler, and simply assume case sensitive correct naming, combined with a few acceptable file extensions. What are your thoughts to this?

[num...@free.fr]

I think you are right, perhaps a solution should be to search/load the artworks only when it appears on screen (a little more artworks I guess, I mean a kind of buffer for security and avoid little freeze) ?
Like this there is no limit, on screen we have 10 artworks maybe 20 at most, this should be quick even with an old hardware.

If an artwork is missing nothing appear, no need to control before.

[Pieter Hulshoff]

Ok, it's working now. A full MAME list loading in a fraction of a second supporting .mp4 and .png files. I'll add more extensions and a proper sorting function in a few days, test it, and then check in the code. Let me know which extensions should be supported. I'll admit that the code's not a thing of beauty, but at least it works until we've got 2.0 up and running. :) It's unfortunate that Cabrio 1 does not support clone indications; the graphics and video files I have are generally only for the original, and not for the clones.

In the mean time: is it just me, or is video playback not entirely smooth still? The sound is ok, but many of the videos are stuttering (briefly halted), and some have some static at the bottom. They also don't seem to loop around at the end.

[num...@free.fr]

Excellent !
For me no problem (Ubuntu 14.04) with videos, about loop the new option <video-loop>false/true</video-loop> is needed

Like you are more than quick, do you have an idea about a request from users, how put a different theme for each list, eg list Genesis = genesis theme ?
1 - A general theme for All games 2 - An individual theme for each list
In my fork there is already an option to switch quickly to the list https://github.com/fredbcode/cabrio/blob/master/README

I can't see your fork in github ?

[Pieter Hulshoff]

My fork is at https://github.com/phulshof/cabrio but is currently still the same as yours of course.

I'm running Kubuntu myself. Videoloop is working now, but I'm still having video stutters, e.g. with Vulcan Venture. The audio of that video plays just fine.

I'll think about your other requests; I don't want to take away too much of the little time I have to work on Cabrio 2.

[num...@free.fr]

| My fork is at https://github.com/phulshof/cabrio but is currently still the same as yours of course.

Ok thanks, let me known when your code is ready, I will release a new version of Livemamecab

| I'm running Kubuntu myself. Videoloop is working now, but I'm still having video stutters, e.g. with Vulcan Venture. The audio of that video plays just fine.

Maybe a problem with some video formats ?

| I'll think about your other requests; I don't want to take away too much of the little time I have to work on Cabrio 2.

Ok Yes, I understand, I promise this is the last for cabrio 1.0 :)

Thanks again

[Pieter Hulshoff]

I've added a sorting algorithm, and some additional extensions (.jpg, .mp3, .flv). I hope that covers what we need.

I did run into a small issue: after returning from a game, the resume_all function is called. This contains the game_list_resume function call, which tries to load the texture for each game... I removed it from the resume_all for now; it doesn't seem to serve any purpose.

[Numsys]

Tell me if you need some help for testing

[Pieter Hulshoff]

I could upload the code so you can have a look. Should I remove the old code (currently commented out) or shall I leave it in so you can see what was taken out?

[Fred B]

Le samedi 24 janvier 2015 20:36:30 UTC+1, Pieter Hulshoff a écrit :

I could upload the code so you can have a look. Should I remove the old code (currently commented out) or shall I leave it in so you can see what was taken out?

Yes remove please, I will send a binary to some users for test

[Pieter Hulshoff]

I've committed my changes; please have a look, and let me know if you encounter any problems. I'll try to fix them as soon as possible. :)

[num...@free.fr]

Thanks, maybe there is something wrong, but I'm seeing nothing here ? https://github.com/phulshof/cabrio

[Pieter Hulshoff]

That is odd indeed; my git said it was up to date after my check in, so I assumed it was uploaded correctly. I will have a look this evening to see what went wrong.

[Pieter Hulshoff]

Ah, I forgot the push after the commit. Give it another try?

[num...@free.fr]

Ok good, I will compile and try, thank

[Numsys]

Ok merged, tested, and approved :)
Works great

https://github.com/fredbcode/cabrio/blob/master/README

Thank you, this is really helpful

[Numsys]

Pull request here https://github.com/SteveMaddison/cabrio/pull/23

[Pieter Hulshoff]

I had a quick look at that memory leak problem, and I understand what the problem is and how to solve it, but is it worth it? Basically every call to e.g. xmlNodeGetContent provides you with a pointer to e.g. char, and that memory is never freed. Fixing it requires something like:

replace
config_read_boolean( (char*)node->name, (char*)xmlNodeGetContent(node), &config.iface.full_screen );

with
char *content = (char*)xmlNodeGetContent(node);
config_read_boolean( (char*)node->name, content, &config.iface.full_screen );
free( content );

and that for every call to these functions. If we want to read the XML files many times it should certainly be done, but is it a problem if they're called only once?

I should probably consider this well, since we're using a similar structure in Cabrio2 (but then with std::string conversion added for C++ string handling).

[Pieter Hulshoff]

Nevermind; once I figured out the code structure it was a simple find/replace action. The code is checked in; let me know if it works for you too or if you encounter any bugs I should fix.

[num...@free.fr]

Ok, I will try this weekend

[Iro Nik]

Hello,
Thanks Pieter for the update. Now cabrio is usable with big lists.
I had some crash (2 in fact, return to the desktop) but nothing critical.
It's missing some ergonomic things with big lists (such as the rom name or description to differentiate the many versions of the same game, "Jump letter into letter" (In S,  jump to Sa , Sb ,Sc ...) and this version of cabrio will be a good alternative to Cabrio2

Thanks all for your job :)

[Pieter Hulshoff]

You're welcome. :) I'm still considering integrating my menu plans into Cabrio 1 as well. It will give me a chance to test its features while we wait for Cabrio 2.

[num...@free.fr]

About the return to desktop, there are some changes from Pieter very recently (memory leak)

[Pieter Hulshoff]

I don't actively use Cabrio at the moment, but once I've done my next upgrades I'll do some more testing, and check the debug info should it crash. It needs a few more changes before I'm willing to dump Mamess for it. :)

[Fred B]

Yes I agree, maybe a quick fix should be add a jump 5 by 5 after a moment ? Eg,  after 2 or 3 seconds to the right position the games jump to the next fifth game   

| "Jump letter into letter" (In S,  jump to Sa , Sb ,Sc ...)

How implement this without break the usual behavior ? a dedicated button ?
 

[Pieter Hulshoff]

I did away with letter jumping in MAMESS, and simply had a jump 1, 10, 100, and 1000 using 2 buttons in combination with up/down. Left/right was used for switching emulated platforms.

[Fred B]

Le vendredi 13 février 2015 14:37:22 UTC+1, Pieter Hulshoff a écrit :

I did away with letter jumping in MAMESS, and simply had a jump 1, 10, 100, and 1000 using 2 buttons in combination with up/down. Left/right was used for switching emulated platforms.

In cabrio up/down jump to the next letter (a,b,c) and right/left rom by rom (can be changed in conf file)
Maybe we can take a look at a combination like yours, something like a button + right/left = 1,10,100 etc
 

[Pieter Hulshoff]

I'm having a bit of a dilemma here. I notice applying changes in C takes a lot more effort than programming in C++, but Cabrio1 will not compile using g++. I might be more effective creating a transition version of Cabrio while Steve figures out the OpenGL code for 2.0. This transition would combine my plans for menu structures, and platform/game based theming with some of the Cabrio1 code.

[Fred B]

I'm having a bit of a dilemma here. I notice applying changes in C takes a lot more effort than programming in C++, but Cabrio1 will not compile using g++. I might be more effective creating a transition version of Cabrio while Steve figures out the OpenGL code for 2.0. This transition would combine my plans for menu structures, and platform/game based theming with some of the Cabrio1 code.

I'm not a code master, (In reality, I'm not Developer at all), and my knowledges about C++ are not huge...
But If you think it's more easy for you I agree

Maybe a good way, should be just fix or thing or two and let cabrio1 like this ?

I known just two requests from users

1 - A way to select easily the games with a big list
2 - And a theme linked with a list, eg when you select the list genesis a dedicated theme appear