So I added some spiffy features that I thought most people could benefit from, such as a notification bubble, a game counter, and increased stability. Here’s a new video link.
I will have some windows binaries available in the next few days.
Looking better and better! I like that link to the emu-general wiki 
Thanks hunter! Okay everybody, I’ve created a windows build for the project and should include everything that you need to run the frontend. Just read the README.txt I included in the compressed file. Some features that I’m going to edit/remove are still present in the project. This is meant to be just a quick preview for those interested in what I’ve been up to. http://www.mediafire.com/download/79wg9 … -v0.7a.exe
Currently the frontend does not support loading .zip files. I will rectify this issue soon.
To end the week I have created a system settings dialog. It currently has options to configure most of the settings that RetroArch uses. The settings are very trivial to add and so I will add all of the settings that RetroArch uses in the a day or two. Even though the binary I posted is only a few days old, I have added so many settings that it is now extremely outdated. I will post an updated one soon.
Once all of the data is added to the system dialog, I will work on adding the ability to choose your own cores per system.
Here’s a link to a video demonstration. link
So for a little update as to what I’ve been able to accomplish, I have added .zip support and currently every rom that you import, gets scanned against the no-intro crc code entry in order to clean up titles you. So even if a rom is named “amdkakmd.zip” or “helloworld.n64” the frontend will try and turn the title into it’s actual name, as long as the name is in the no-intro list. What this also means is that importing your games is a slower process now. For me to scan about 10 folders with 40 games in it takes about 2 - 3 seconds, this is recursive scanning, so the import time is still good.
Most if not all of the RetroArch options will work, for example, there’s a mute audio checkbox, fullscreen, rotation, xscale, yscale, adding paths etc. There’s also a table that shows every code available for RetroArch with all of the authors and permissions information on it.
I currently broke shader support again, so i am fixing that. Everything else seems to work great though.
Also loading your cores is now handled as soon as you specify the path to your roms, and the cores are dynamically added to your menu and you can choose which cores to use.
I told myself that as soon as I finish with the shaders, adding zip support, and adding an advanced settings menu, and having core selection, that I would release it as a first version so I am going to do that probably this weekend; since I have class work to get done. I could use some people to test it out. Thanks!
No Intro database checking sounds fantastic. Are you planning to build in artwork/description fetching from that?
Yes I do. Lately I’ve been putting those features on the back burner though, since I wanted to add more features first. As soon as the first version is out, I’ll start work on artwork scraping and info fetching. Then comes adding the ability to configure controls from within the frontend, instead of just running retroarch-joyconfig in a sub-process.
So, as promised here is an almost finished build of the frontend for version 1.0. I will put shaders back into the frontend before I release it as a 1.0, currently selecting shaders doesn’t do anything. Also I am aware that when changing your cores, the settings will not look saved when the frontend is reloaded. They are saved, it’s just that the image doesn’t reflect it. Also, with recent additions the theme looks a little patchy. I will address these in the next day or two and so they are not bugs.
The things that I want to see that work are changing video, audio, and path settings, proper loading of games, and making sure that the new rom scanner works, games work just as well in the grid mode as they do in the table mode.
I also want to see if cores are displayed correctly with proper names, and so a core named say “mupen64plus_libretro.dll” should be displayed as “Mupen64Plus” in the core selection.
Try and crash it and please report it to me. Thanks! Also the source code in included in the src folder and it is needed for the emulator to load so do not delete it. Some of the source code may be a little hard to follow and so I am formatting it correctly and putting files into their own folders.
crashes on startup for me, but that’s most likely because I’m running windows xp (my current laptop can’t run much newer setups sadly) EDIT: It’s an open gl thing, essentially my graphics only supports opengl 1.4 and qt builds with a much newer version.
That is why. I believe that there is a work around though. I’ll look for it.
That is why. I believe that there is a work around though. I’ll look for it.[/quote] I updated my post actually. It’s a graphics issues. Mainly my gpu in this junker laptop is too shit old
That is why. I believe that there is a work around though. I’ll look for it.[/quote] I updated my post actually. It’s a graphics issues. Mainly my gpu in this junker laptop is too shit old[/quote]
Ahhh that makes sense then. Thanks for trying it out though.
Another quick update, I ran the executable through msys2 shell , you seem to be missing a module too
TheCanadianBacon@thecanad-ab8293 ~/release $ ./Phoenix.exe QQmlApplicationEngine failed to load component file:///C:/msys32/home/TheCanadianBacon/release/src/qml/main.qml:8 plugin cannot be loaded for module “io.thp.pyotherside”: Cannot load library C:/msys32/home/TheCanadianBacon/release/io/thp/pyotherside/pyothersideplugin1.dll: The specified module could not be found.
Segmentation fault
EDIT: Never mind, it’s there but it’s still having a difficult time reading the file
Interesting. It may have something to do with pyotherside not being an officially supported library, I’m not entirely sure, but with the tests that I’ve ran it seems to run correctly. This is good to be aware of though. So I will look into it. Thanks!
Not a problem, I believe I’m under way to working again and when I do I’ll be building a proper dev box so I can help out. One Idea I had was creating something alternative to how you are doing it but targeting the libretro api directly. At least eventually. But I love what look you achieved. It’s pretty damn close to openemu 
Hey that’s great to hear. I’m right there with you, I was planning on removing retroarch altogether and targeting the api. It’ll be a good learning experience. I was also thinking about either converting the api into a Python wrapper, or just strictly using C++ with Qt, or even possibly writing it in the Go language. Do you have any preference as to what language?
I’m generally a c++ person, I don’t have much experience using qt though, mainly wxwidgets, however as for python. There are some python bindings for libsnes which was the original library before libretro was forked from that and It was pretty slow on the display side. But would make a great starting point I think if you were going to try that. Though I never tried go before. I may want to try that.
This fine person made Qml bindings for golang. https://github.com/go-qml/qml
I wouldn’t mind c++, however I think that golang would make life easier for things like artwork scrapping.
I’ll go with go
Cool cool. Also QML is a markup language that separates the frontend code from the backend.