Update - RetroArch OpenEmu-style

Cool cool. Also QML is a markup language that separates the frontend code from the backend.[/quote]

That much I do know lol, I may not program with qt but I do know what each toolkit does and their components. I followed close enough for qt because of their support for wayland on linux. :slight_smile:

looking forward to the future of this program. iā€™d really love to see artwork scraping integrated.

Itā€™ll be in there very soon.

Alright everyone! I have finally added artwork scrapping, along with game descriptions, genres, and all that jazz. Hereā€™s a new video update. This video also has me providing an audio walk-through as to be more engaging, instead of being so static. video link. I also added artwork for the tableview. I also added some other neat features, so check it out! Hereā€™s a screenshot if you prefer them.

itā€™s actually looking pretty good man, I have a newā€¦ish setup I can compile with it nicely now which is a start.

itā€™s actually looking pretty good man, I have a newā€¦ish setup I can compile with it nicely now which is a start.[/quote]

Hey as long as it has a new enough graphics card to run qml itā€™s all good.

itā€™s actually looking pretty good man, I have a newā€¦ish setup I can compile with it nicely now which is a start.[/quote]

Hey as long as it has a new enough graphics card to run qml itā€™s all good.[/quote]

Looking good man

So, for this week I havenā€™t added much yet. Iā€™ve been busy with school. I did however change from using xml files to store your library to a json file. This json file plays better with javascript and allows me to edit the data quickly and from within the GUI.

What you will see is that adding game artwork and saving game artwork is now much much quicker. Itā€™s virtually instantaneous, the other method slowed down on older systems and would take up to 2-3 seconds for the changes to take place.

This move to json also gives me the ability to add games to the library from inside of the GUI, without having to call python or c++. This means that there I reverted game importing, back to having only one option to import games, a recursive scanner. This is all that is needed now though, since games that currently exist inside of the library will not be added and no data will be overridden by future scans.

What I plan on doing tomorrow is simplifying the other config files that I use into one file, this will cut down on some load times. I also am changing how the crc scanner and the online artwork scrapper works.

I found that QML doesnā€™t like resizable images that load web urls. When games in the grid mode would get resized, it would produce a horrible system slowdown, dropping the GUI from 60 fps, to what felt like 20-25; this would affect even high-end systems. This issue does not exist on artwork that is stored locally and so, I highly suggest that you just do that to add artwork. I will still add the ability to get images from the web, however, you may find the experience sub-par.

Also crc scanning will now be a frontend option, and will run in the background. What I did before was I did everything at once. I would calculate the crc file of every file that was supposed to be imported. This worked okay on nes through snes games, however, playstation isos and n64 roms would take longer than expected to produce the crc code. As an example it turned importing 60 games, from 2 seconds, to 15 - 25 seconds, so this feature will now be used if you choose to select it. Iā€™ll also rework it to rename the actual game files, instead of just how they are displayed in the GUI.

Once these things are completed, it will be done.

Does it support fetching from the web and then caching/storing locally? That seems like what many/most people would prefer.

Does it support fetching from the web and then caching/storing locally? That seems like what many/most people would prefer.[/quote]

It does, but it is more involved and itā€™ll take me a little bit to implement. Iā€™m still going to add it though. Itā€™s just I feel like I donā€™t do much when I spend hours trying to solve these kind of issues and so Iā€™ll finish the other features, which should be accomplished this week and then iā€™ll work on caching the images.

Sounds good. It never feels very rewarding banging your head against a stupid problem for hours :slight_smile:

Right. Iā€™ve tried it before, along with adding video support. Itā€™s all perfectly possible, and itā€™s also all cumbersome.

Alrighty. What do you think about this idea for providing artwork descriptions and file information? http://i.imgur.com/DZyuqEv.png

The plan is that the grid will expand vertically and then it will close once you are finished.

I think that looks nice

Wow that looks awesome, what toolkit is that again?

Wow that looks awesome, what toolkit is that again?[/quote]

Well the UI work is all done in QML. That specific image was just something I cropped up in gimp.

In case someone is wondering what iā€™m up to this week, Iā€™m rewriting the game scanner in C++, the speed increase from Python is unreal, along with doing some UI work.

One month later ā€¦ Any chance for a new build? =D

Good things comes to those who wait :wink: Myself Druage and another person have actually evolved Phoenix into a new project where itā€™s own libretro frontend instead of being a gui for retroarch. This way we learn a lot more of the libretro api and on top of that we help contribute to libretro by helping it get it recognized as a standard.

As TheCanadianBacon said, weā€™re working differently now. Weā€™re shooting for a release date of the end of the summer, however things may work out in our favor and weā€™ll be able to have a build out much earlier. Itā€™s going to be awesome though. If you have any suggestions, or wish to contribute, please shoot me an email.