Hey guys, I have been working on a fork of Dolphin called “KawaiiDolphin” (pun on Qt and Dolphin). Please note that none of this is official but I will try my best to get it all integrated in to the master branch. Here is the basic goal of KawaiiDolphin:
- Create a “console” like experience when launching Dolphin. This is akin to the “Big Picture” when launching Steam or using any modern console.
- Nicely animated and “flashy” UI. This is why QML is used.
- Be able to do just about everything using just a gamepad
- Act more of a complement, rather than a complete replacement of DolphinWX or DolphinQt2
- If possible, use QML touchareas to make it mobile friendly (replacing the Android and iOS UIs).
I just finished my proof of concept! Here is what I got accomplished:
- Joystick/gamepad controls in QML! This is huge since Qt/QML has no native way to handle any kind of joystick input. Better yet, since it uses the InputCommon backend, whatever Dolphin supports, KawaiiDolphin will support as well.
- As implied with the previous bullet, I got a fair amount of QML to work with C++ from the core classes. This includes getting a list of games and their banners to show up in QML
- Be able to launch the game. Special thanks to rukai and degasus for the Qt code to get that working.
- Picks up whatever settings you put for DolphinWX for launching / playing the game. Therefore, if there is ever any setting that can’t be set using QML, DolphinWX or DolphinQt2 can be used as a fallback.
- Particles and all that cool jazz. A few simple stress tests to ensure that the UI can work on low end machines.
Source code is on
github. This fork will be abandoned and replaced with a much better design. I have only tested it on Linux, but it should work on all OSs as long as you have Qt 5.5 or better and you have all the QML pulg-ins including ParticleEffects.
Check out a
simple video I made here (everything was controlled using an Xbox360 controller).
Obviously I didn’t add many features for something that is just a proof of concept. As a matter of fact, moving on, I will have to start the UI again to make something much better. At this point, I know a full proper UI can be done using QML. Anybody who is interested in helping me out is more than welcome. I will need help mostly on Art and Design. People who have ideas and concepts that you want me to try out or any artists who want to submit icons or other artwork are welcome. Please note that
THIS IS NOT AN OFFICIAL FORK! I will do my best to get this mainstream but I can’t promise this will be part of the default download/executable.
Thoughts? Comments? Concerns? Complements or hate mail? Let me know. Thanks.
I like the idea and was hoping for something like this to come along so I'll keep an eye on it. This may be outside of the scope of what you want to accomplish but if you can make it play game banners, it would be the killer front-end for Dolphin.
So "Big Picture Mode" is an idea which has been tossed around for ages, but nobody is actively working on it at the moment.
One of the major concerns is adding "yet another gui" to dolphin, we already have way too many.
Over Christmas, I actually wrote a design document to try and solve this problem, instead of creating a separate "Big Picture Interface", it advocates creating a single unifying "Little Picture Interface" that works and adapts to whatever control scheme the user is using, including mouse, controller, touchscreen, controller or even a wiimote. It also scales from a small phone screen all the way upto a massive projector screen as well as working well on a desktop too.
Then all the rest of our GUIs can be phased out.
You can read this document here:
https://docs.google.com/document/d/1yNQiny2wowtiTVJXzggSxHfM9IuPW5IsduHQ0vBmWWc/edit?usp=sharing
The other discussion point is: Is QML a good idea?
I mean, it's better than many alternatives, but I didn't really like it the last time I tried it, and it requires linking a massive library into dolphin. In my plans I've always envisioned creating a light-weight widget toolkit over both directx and opengl and then creating the "big picture" GUI inside that.
(07-06-2016, 10:42 AM)phire Wrote: [ -> ]So "Big Picture Mode" is an idea which has been tossed around for ages, but nobody is actively working on it at the moment.
One of the major concerns is adding "yet another gui" to dolphin, we already have way too many.
Over Christmas, I actually wrote a design document to try and solve this problem, instead of creating a separate "Big Picture Interface", it advocates creating a single unifying "Little Picture Interface" that works and adapts to whatever control scheme the user is using, including mouse, controller, touchscreen, controller or even a wiimote. It also scales from a small phone screen all the way upto a massive projector screen as well as working well on a desktop too.
Then all the rest of our GUIs can be phased out.
You can read this document here: https://docs.google.com/document/d/1yNQiny2wowtiTVJXzggSxHfM9IuPW5IsduHQ0vBmWWc/edit?usp=sharing
The other discussion point is: Is QML a good idea?
I mean, it's better than many alternatives, but I didn't really like it the last time I tried it, and it requires linking a massive library into dolphin. In my plans I've always envisioned creating a light-weight widget toolkit over both directx and opengl and then creating the "big picture" GUI inside that.
QML could be "The Interface To Rule Them All". At the end of the day, it is really just C++ combined with a simple scripting language. Whatever QML lacks, you can always write it using C++.
Here are some pros and cons of making QML
the interface:
Pros:
- It works with mouse, keyboard, touch, and (with this proof of concept) joystick
- Things like animation and even GLSL shaders are first class citizens in the UI
- Once it starts, it is fairly optimized. The GPU/CPU requirements are lower than Dolphin itself
- Works on all platforms including Android and iOS
- Because it is a runtime language, the end user can do something like add new UIs or themes just by pointing to a different QML file without having to download and run an entire SDK
Cons:
- Stability in complexity. When I worked on MeeGo, we noticed that once an application got to a particular size, the "cost" of maintenance became much higher. Any kind of heavy logic should stick to C++ and only simple code should stay in QML. We learned that unless you really design the QML well, the start time could take forever and the code can easily become messy.
- QML was supposed to be designed for people who can't program well. However, in reality, its the programmers that end up writing the QML code. The only nice thing is that it become easier/faster to prototype using QML compared to most other languages/frameworks and artists can tweek a few things here and there (but don't expect them to write much QML code).
- Combining C++ and QML is not 100% trivial. It took some work in order for me to get this proof of concept going and handling the joystick input and using the Core classes.
- Adds a good 16-20 MB to the download on Windows (and 40MB unzipped). Almost 50 MB in Mac. It adds about 9MB to Android. I would expect the same for iOS.
- Not everybody know QML. It is still a niche language and framework compared to C++ itself
Originally, I wanted to make something that would complement rather than replace a mouse/keyboard interface (the same way "Big Picture" doesn't replace the regular UI). Making it THE interface would require a fair amount of work and I don't know if other people are willing to help out.
(07-06-2016, 11:17 AM)DesiOtaku Wrote: [ -> ]QML could be "The Interface To Rule Them All". At the end of the day, it is really just C++ combined with a simple scripting language. Whatever QML lacks, you can always write it using C++.
Quote:Originally, I wanted to make something that would complement rather than replace a mouse/keyboard interface (the same way "Big Picture" doesn't replace the regular UI). Making it THE interface would require a fair amount of work and I don't know if other people are willing to help out.
Yeah, consider this as me just floating the idea. Fortunately the first few steps are identical; A gamepad/mouse/touch controlled full screen interface that can launch games and do various things while paused.
A complementary interface would ideally integrate into our new Qt GUI, launchable by a menu, button press, from the command line or an auto-start option.
I would be very weary about adding configuration menus to such an complementary interface, users can exit to the desktop interface to change settings.
Quote:
- QML was supposed to be designed for people who can't program well. However, in reality, its the programmers that end up writing the QML code. The only nice thing is that it become easier/faster to prototype using QML compared to most other languages/frameworks and artists can tweek a few things here and there (but don't expect them to write much QML code).
Everyone just keeps making that mistake. I'm moving to the theory that it's not possible to make language that's easy for non-programmers, because as soon as a non-programmer detects something is a programming language they shut down and refuse to learn it.
Quote:
- Adds a good 16-20 MB to the download on Windows (and 40MB unzipped). Almost 50 MB in Mac. It adds about 9MB to Android. I would expect the same for iOS.
Yeah, one of the larger, more contentious issues. And more complexity in our code base makes programming harder.
Quote:
- Not everybody know QML. It is still a niche language and framework compared to C++ itself
I wouldn't worry about that, programmers are good at adapting to new languages.
Quote:
- Things like animation and even GLSL shaders are first class citizens in the UI
- Once it starts, it is fairly optimized. The GPU/CPU requirements are lower than Dolphin itself
Actually this brings up further questions, How well does QML interact with our non-opengl backends like DirectX and Vulcan?
I would really like to see a prototype of an overlaid pause-screen interface (with transparency) working on all our backends before deciding if QML is a good idea. I can help get it running on windows if you want.
Great work with the demo, and an interesting discussion. My personal recommendation is qt widgets > rolling our own gui toolkit > qml > everything else. If you think you can make something awesome with QML then go for it. It certainly seems like you have a great start here
You'll need some way of moving from in-game to dolphin menu with a gamecube controller. That'll have to be configurable, since lots of games use strange button combos.
(07-06-2016, 12:40 PM)phire Wrote: [ -> ]Actually this brings up further questions, How well does QML interact with our non-opengl backends like DirectX and Vulcan?
I would really like to see a prototype of an overlaid pause-screen interface (with transparency) working on all our backends before deciding if QML is a good idea. I can help get it running on windows if you want.
Right now, with his proof of concept, it actually brings up a new window with an OpenGL context (just like the WX and Qt2 versions do). For working in a Direct3D context, it may not be as simple since the normal QML engine uses either OpenGL or OpenGL ES. Vulcan support is quite minimal at this point but the Qt guys appear to want to port the QML engine to Vulcan at some point.
It appears there is a lot of interest in a "Pause/Suspend" menu. Perhaps I should make that my next proof of concept before anybody spends more time on QML.
(07-08-2016, 08:12 AM)DesiOtaku Wrote: [ -> ]Right now, with his proof of concept, it actually brings up a new window with an OpenGL context (just like the WX and Qt2 versions do). For working in a Direct3D context, it may not be as simple since the normal QML engine uses either OpenGL or OpenGL ES.
Yeah. I think this is the key requirement for any big picture GUI, seamless integration into the current context. I don't to see anything which involves dolphin running both an opengl and directx context at the same time. Maybe one of those OpenGL ES compatibility layers for directx (and vulkan too?) is an option, but that's yet more dependencies to include in dolphin.
I guess rendering a GUI on the CPU and then uploading it as a texture to be overlaid is another option. But I said earlier, my theoretical plans involve creating (or finding) somewhat a minimalistic widget toolkit that is easily abstracted to OpenGL/OpenGL ES/DirectX 11/DirectX 12/Vulkan/Metal or whatever new and wacky graphics apis the future might have in store for us.
PPSSPP already has an example of such a widget toolkit (abstracted to OpenGL/OpenGL ES/DirectX 9) but it doesn't do curves and I think font rendering can be improved. I also think it's important to have a damage system, so we don't have to redraw the whole GUI at 60hz when nothing changes, or just a background image changes.
It's probably a good idea to prototype the pause/suspend overlay style screen, that will prove our use case. Doesn't need to look pretty (or even be controllable), but I'd like to see examples of alpha blending over blurred/saturated/filtered version of dolphin's output,l like you see in the screenshot from my design document.
If it works for our use case, I have no fundamental arguments against using QML.
(07-10-2016, 11:46 AM)phire Wrote: [ -> ]Yeah. I think this is the key requirement for any big picture GUI, seamless integration into the current context. I don't to see anything which involves dolphin running both an opengl and directx context at the same time. Maybe one of those OpenGL ES compatibility layers for directx (and vulkan too?) is an option, but that's yet more dependencies to include in dolphin.
I guess rendering a GUI on the CPU and then uploading it as a texture to be overlaid is another option. But I said earlier, my theoretical plans involve creating (or finding) somewhat a minimalistic widget toolkit that is easily abstracted to OpenGL/OpenGL ES/DirectX 11/DirectX 12/Vulkan/Metal or whatever new and wacky graphics apis the future might have in store for us.
PPSSPP already has an example of such a widget toolkit (abstracted to OpenGL/OpenGL ES/DirectX 9) but it doesn't do curves and I think font rendering can be improved. I also think it's important to have a damage system, so we don't have to redraw the whole GUI at 60hz when nothing changes, or just a background image changes.
It's probably a good idea to prototype the pause/suspend overlay style screen, that will prove our use case. Doesn't need to look pretty (or even be controllable), but I'd like to see examples of alpha blending over blurred/saturated/filtered version of dolphin's output,l like you see in the screenshot from my design document.
If it works for our use case, I have no fundamental arguments against using QML.
OK, so after realizing how hard it would be to force a QML engine to any arbitrary context, I realized there is one "hack" I can do:
Pretty much, on whichever button (which we will have to figure out later), it will actually pop up a new window. However, I take a quick screen shot of the current game screen, give it a nice blur and then add the menu items on top. As long as I implement moving the window around and when the user switches between fullscreen/windowed mode, I should be OK.
I got a proof of concept of this working over here.
This solution can not work if you have a tiling window manager or for window managers that forces a long animation for popping up windows (well, it will still work, but the illusion of a fake overlay will be dispelled). It least this solution will work no matter what kind of window context (OpenGL, D3D, Vulkan, etc.) is made for the game. It would also keep the game render separate from the UI renderer. What are your thoughts on this?
(07-18-2016, 10:28 AM)DesiOtaku Wrote: [ -> ]What are your thoughts on this?
I'm going to have to say: No
Not only will there be GUI elements that we might want to put on outside of pausing (fps counter, messages, GBA windows and many other things that we haven't considered yet) but this is a complete hack and will never work in fullscreen.