This is something I’m thinking of including in a future release - and even having as potentially a default launcher, if people just want to have the gameshell as an emulation only device.
I’ve found that a few standalone emulators assume they’re in the same directory as emulationstation, that by default is installed in /usr/local/bin
This means that some expected configs/bioses can’t be found. Eg, PCSX.
I’ve experimented with fixing that, making a symbolic link in the /apps/emulators directory, running this after running the script above:
I tried commenting out the double up consoles, but it seems to ignore that. Eh, just delete the attempted comment outs if you want. They’re mostly the emulators that don’t work as well.
Keep in mind, I put in the file types to allow for zip and 7z files. The problem with this is, whenever an emulator opens one, it decompresses the rom, and leaves it in the origin file’s directory. Problematic only if you use compressed archives for roms.
In fact, it might be worthwhile to include this to launch games within Emulationstation:
I’m debating whether to do this, seeing as some emulators just flat out don’t run as well, and I should just remove them.
Arguably I could also just update the stock awesome launcher, removing all the double up console directories and using this script instead; however, if I want to have the launcher updatable like a stock 0.5 clockwork OS, this would break the moment you update it. Sure you could make exceptions, holding files or making a script to return things to normal, but at that stage it’s not really going to be at all like what a stock launcher is like.
I haven’t included the ScummVM, or the ID software games in the Emulationstation system config/setup.
I may make a custom “console” to be used as a toggle to change back and forth between the awesome launcher and the emulationstation launcher. Not exactly eloquent and I’m sure someone else could do something better.
Just in case, here are the contents of es_settings.cfg
I can’t remember if there was anything else special I really needed to do, but looking back over the old thread, it looked like some people had trouble having things look viewable. I may have needed to have manually installed a theme as well. I’ll put in something to script a download of a theme.
I’ve tested most of the consoles. I can’t seem to get drastic running via Emulationstation which is weird. I’ll keep working on it, and hopefully find a solution.
Oh sweet!! I wasn’t sure if it was something you forgot! Haha I was about to DM you about it too!
Good thing you did, I was just about to write in stand-alone support myself. Ha! Save me the effort!
Oh and also, I solved that problem re: which directory ES is executed from. Simple symbolic link. It all works now. Well. Except for Drastic, which I’m guessing I’m going to also need to do something for. Probably will need to completely move the contents of the drastic emulator from its own directory to the same ~/app/emulator directory. It’s gonna get messy! Hopefully there’s another way.
I don’t know if anyone has issue with some GBA games on gPSP standalone emulator (I don’t like RetroArch because of its battery and CPU consumption). I had a blank white screen when starting some Pokemon games (FireRed, Ruby).
Googling around and found that gPSP requires special configurations for some specific games to run correctly.
Copying game_config.txt file from Github repo in gpSP for gameshell alone build to /home/cpi/apps/emulators will resolve this.
Oh damn, thanks for finding that! I had no idea about that, having not tried that combo! I will definitely include this in the next release! Thanks so much!
Also, do you actually find that retroarch uses more battery/cpu cycles? Is this a feel thing, or actually by SSHing and viewing the process/number of threads etc.
I think by default, the 5.3.6 uses the performance governor, so it would probably be running full speed all the time, without any throttling. I haven’t looked into this much more, re: retroarch specifically, but that is definitely something good to potentially know!
Jav, I just wanted to say thank you so much for this build. You fot me completely re-excited aboit the CPI again with this. I absolutely hated the cluttered file structure that I just couldn’t wrap my head around and the bland UI was completely off putting to me when I got mine a year ago.
This build has fixed so many things I hated and has made me understand so much more whats going on behind the hood.
Thanks so much, bud. I really appreciate all the hard work. This thing rules!
Hullo! Welcome to the forums. I’m afraid it doesn’t seem as though you can really change the DPI, short of plugging it into an external screen via HDMI.
Most of the functions can be edited via the config.
The fact it has a GUI is a step up from mupen64plus and mednafen.
If anything we’d need to use some kind of GUI or front end.
I’ve tried emailing the author of the emulator for the source code. According to his FAQ, if you seem to be genuine, he will provide it. I linked this forum, the community and the thread to show where our genuine intentions and ambitions lie. I haven’t heard back; I’m assuming possibly because he now focuses more on his android apps, which are paid for content.
I could be wrong, but if we want to change the DPI of the GUI, we would need to have the source code.
@Cha0 Thank you so much for your kind words! What you said was exactly what I was hoping to achieve, ie show the entire process of modifying the OS, step by step as I’m thinking things out. I’m not a coder or software engineer by trade, and just a regular “user” like everyone else. If I can even just show people where to find information, then my job is done!
I agree! The directory structure was indeed in a confusing state, with a strange naming directory structure for rom placement.
Re: bland UI, I’m wanting to eventually make a new UI from scratch, having contiguity throughout. Ie all of the consoles/items having the same feel. I’m wondering how far we can actually push the Awesome™ UI.
It really means a lot to hear that people are getting enjoyment and rekindled love for the console! I will continue to make things exciting for as long as I can! Let me know if any suggestions you’d like, and I’ll see what I can do! Keep me busy.
Could I ask if anyone is willing to do a Retroarch core update via the online update within Retroarch, and test as many games as possible for any changes; be it improvements or incompatibilities. Ive only really tested the consoles that I use (which is most but not all) and am nowhere near close to testing EVERY game on each console.
Of course, I have it always updated on my day to machine, but I only play the games that I play.
Keep in mind, this will only update Retroarch cores, and not standalone emulators.
Also can I get a confirmation on whether the colecovision emulator actually works? Another thread had a user report it not working. Likewise with Fuse, UAE and Lynx. I have never used any of these emulators, or have Roms to test them with.
@javelinface Just want to let you know that I changed mednafen.cfg for the virtual boy. Now it is in mono scope mode (black & white), bilinear interpolation is turned on, the picture quality is much better, buttons layout is in SNES mode, and I made new keyboard shortcuts for shoulder buttons (L1- decrease save slot, R1 - increase, L2 - save, R2 - load).
But my shoulder buttons is modded into the standard shell so it is reversed upside down, so if you using standard layout you need to reverse key inputs values in the config file (just search in the file strings “save_state” and “load_state”, “state_slot_dec” and “state_slot_inc” and reverse key values)
You absolute champion! I was hoping to find a way to make it look less over layed. That said I wonder if we can use old school red/blue style cellophane 3d glasses to achieve a 3d effect. Or if it’s even worth it haha.
Thanks for this! Is it okay if I provide it in the next release?
Also, have you tried your hand at configuring mednafen for any of the other consoles?
Sure you can use it
I haven’t tried to tweak other cores because I only needed VB and I don’t see any point because of other alternatives. Do you think it is worth of trying?
Anyway, it is easy to do, just edit mednafen.cfg file in any text editor using this documentation: https://mednafen.github.io/documentation/
The annoying part is specifying where each bios is, and praying that you don’t change too much at once, and accidentally break something else!
I started doing a batch remap of controls, and stupidly did all of them at once. Result: I broke the config, and felt too distraught to bother debugging it to find out exactly what went wrong hahah!
From what I’ve heard, mednafen particularly excels at virtual boy, wonder swan and Dreamcast; Although I haven’t tested dreamcast yet. I’m not holding my breath! Maybe a tonight job!
Edit: Oops! Nope, it doesn’t support Dreamcast!
I’d consider using solely mednafen if I was to say, have a setup using emulationstation. Mednafen runs enough things fairly well, that I might consider emulationstation as a similar kind of launcher as Retroarch.
As it stands, my emulationstation is using a bit of a frankensteined mix of Retroarch and standalones. It would be nice to have everything standardised.
@podmaz - Just looked at the config. The Bi-Linear filtering although pretty is possibly hitting the frame rate pretty hard. Going to test things a bit more! Otherwise, it’s looking very nice!
Edit: Turning Bi linear interpolation barely makes any change to the frame rate. The fact that the emulation looks way better means I’d be happy to take the 1 - 2 frame hit. Good call!
I see you’ve done a pretty similar thing to what I did re: Control mapping. I thought it was the opposite at first, but that’s because I was comparing my “GM” console, and not my day to day one where I made the changes ;). SNES layout for life.
Before I knew about the SDL can mode re: key mapping, I made a little conversion chart. Might be helpful for others wanting to modify their mednafen scripts.
I’ve configured the majority of the mednafen console key binds.
That’s not to say that everything necessarily runs, or runs well. Eg. SNES runs awfully!
Probably the most noteworthy consoles emulated are Virtual boy; which was the reason for embarking on this journey, Wonderswan; something that may be a bit niche and NES; which is possibly a replacement candidate for FCEUX, which now runs terribly.
Here it is. https://pastebin.com/wvkPtp6x
I never grew up with a sega console, so can’t really vouch for how it “feels” configuration wise for games, given sega has a (3x2)+2 vs a [(2x2)+(2+2)]+2 config. I mapped it as close as I could.
I haven’t done any turbo keys, since I don’t feel that they’re necessary. There will be some overlap of controls for state save toggle/load/save, using @podmaz’s config above. If you ever decided to actually emulate something that uses trigger buttons, you’ll need to disable them.
The question is, would anyone actually want that in the default DEOT Launcher? It’s now deviating away from what the original DEOT OS looked like, but hopefully still keeping it spiritually in the same realm of what it would have looked like, had this page.py mod existed when DEOT was first made.