Oh! I gotcha! I was having thoughts on that, re: text colour. Initially, if I kept it the same as the dark theme, the text would have been blue/green, and almost unreadable against the white. That’s why I changed it. It’s particularly painful, when trying to navigate the menus in the settings, and file names etc.
Haha a random thought. Make a UI based on the Pokemon UI. Seems like a lot of people are using their Gameshells for Pokemon.
If it’s of any interest, I started some work on getting PokeMMO working on the Gameshell. I haven’t looked at it in a while, but hey! If you’re interested, the instructions are there.
on windows, sure it will be !
release two version must not be really hard and could be automated, one with only os partition for update, other with full image
This would however fragment a lot of the tutorials reference things. Although just making everything use symbolic links would make most things work. However that would just be for things that I define in the image.
a good solution will be to set other partition as /home,
but menu is in /home and near all what is setup more are also in home folder,
in a way this is perfect, only update core os and let all user settings & additional binary in place
but if menu contain additional programs who are setup in the real classic way (/usr/bin /usr/local/bin …) the menu will get fucked up entry
in this case not follow good method is a valuable point %)
also, with fstab (like for /boot), mounting /home could be automatic, just transparent for users and all existing tutorials
in arch i follow an only package way, letting all update to the classic system way, not needing new os release
got an only os partition release is more or less an in the middle solution
each modification you done you release a new revision, you made a fantastic work,
but users cannot follow you as fast, in fact they may reformat only if real issue is get out or if they fucked up their system,
also you provide as you can information to update without formatting but as release advance it cannot be followed step by step, for users and also for you
I fear I will need to be here forever
that’s the point ^^
you made an awesome job but cannot be forever the full support
re standardising things that will be prevalent from now on.
So perhaps setting a new standard starts here with us, the users.
that’s i was originally try to set up long time ago, full white page with community choice before all extend too much ^^
externalize data partition with fstab mount could be transparent, easy to setup without major changes, just create the 3rd partition, and tell extend script to work on this one instead
one issue would be it will limit in size the system partition, needing let sufficient free space into for the future
Hey I just updated D. E. O. T. And tried to play one of my roms but it isn’t showing up I am not sure I put it in the right folder or not. However, I did read your post set up notes and checked the files for roms under the directory games and placed them in the appropriate folders (gbc With gbc etc.) But none show up did I skip a step or something?
Hey, which rom are you trying to play, and with which emulator?
If it’s not showing up, possibly it hasn’t been sent properly. Have a look at this post. (Note it’s from the previous DEOT thread; don’t get mixed up with info!
Each emulator has an action.config file that recognised a set of extension. To the best of my knowledge, I’ve added all of the missing extensions, along with .zip and .7z, frequently found in rom sets. I mainly use Nintendo emulators however, and am less familiar with say, Sega, lynx, colecovision etc. If the game you’re trying to run is in a format that’s not listed, it won’t be detected.
Another thing. If you’ve got your gameshell on, and transfer the files over, they won’t appear unless you go into the list and push the X button to refresh the list. Refreshing the launcher by running a program and then exiting can also work. That and restarting.
This image should run exactly the same as a stock 0.5 image, just with better support. Did the game you are trying to run work on a vanilla 0.5 image? If it did, then I am super curious to know which one it is you’re trying to run. My guess is that it’s in a compressed archive such as a .rar and isn’t recognised. Either that, or the game could be corrupted.
Partitions would definitely be the most logical approach, but I figure, if a user has trouble following the incremental steps I’ve written to perform small updates themselves, I’m going to assume that they would find it even harder to follow instructions on writing an individual partition.
It would be a tech support nightmare, worse than the initial official 0.4 -> 0.5 upgrade patch. It was an amazing concept in theory, just not the most “regular” user friendly.
You’ve probably noticed that I’m also primarily using the classic /usr/local/bin and /usr/bin file locations. Most of the config information ends up in ~/.config, which would no doubt need to reside on the system partition. This would make overwriting the partitions wipe any custom settings.
On top of that, most apps that are in ~/apps/emulators also store their config files, save states, screenshots and save files in this directory, and would also be in the system partition. Essentially, I’d also need to make a custom script to back up all of these files, taking into account every file extension that could possibly exist, and then returning them to the correct place.
Just backing up the entire ~/apps/emulators directory would be an easy approach, however that’s where the majority of my updates end up going. Essentially the process would involve a lot of user manual intervention, which would result in “regular” users making mistakes - something I’d need to personally spend even more time trying to answer people getting frustrated.
It’s funny! I actually wanted to do this back in my DEOT v1+ image!
So you’re definitely right on the money for what I want. It’s just a matter of delivering it in the easiest way for a non Linux user to be able to execute. I was going to go the two release path, ie one image with a partition and one without, but doing upkeep on that would be a lot of work. It’s already enough using my current workflow setup.
I’d need to multiply that by two, which is going to be a lot of work. Ideally it would be good to have a team who could work on things together. That would actually be an interesting proposition, although if that were to be a thing, it would probably be better to use an image such as your archlinux as a base and make it an entirely community driven collaboration from scratch.
As much as I would love to have it based on the official image, I simply don’t know how to get in contact with the official devs who are in charge of official releases. Guu has been extremely helpful, but it does sound like he needs to answer to powers above him, following guidelines that they have in place.
Back on topic, another thought I had was to have ALL of the contents of non user contents tarballed up, and have users transfer a massive file over to their gameshell, and run a script to essentially manually replace the contents of ~/apps, ~/launcher and /usr. They’d lose the config files and customisation etc I mentioned above, but would keep all of the contents of ~/games and ~/music.
It would also take a ridiculously long time to do, and would be plagued with user errors breaking the system. The amount of trouble and time it takes would make if worthwhile to just have users backup their files. Unless they’ve got a Linux system, this takes an eternity over Ethernet or wifi.
Likewise if I have everything in a .deb file, I need to be able to trust that a user can follow instructions perfectly. Another thought I had was to simply make my own warehouse repository, with scripts people can run to incrementally build up their stock OS to include whatever features exist on the forum. Think a Debian/Ubuntu style GUI installer.
I’ll be honest. I get scared of commitment, and thrive on instant gratification of user happiness. I just feel that the amount of work to do any of this would be so much, for so little reward. I am 100% on board with what you’re saying and suggesting. I just don’t want to be reinventing the wheel, and fragmenting the community more than it already is.
If anything, I’m hoping this thread will bring people together, and get the attention of the official devs. If that means they release an official image with partition support, I would be on board. Of course if we do a good job of implementing it here, it could do exactly that, and they could use what we have done as a base. Eg, look at how Lima was fixed up in the DEOT v1 thread. My fear is that I’d spend the time doing it, then officially they release something that effectively does the same thing, but does it using a different method/file structure.
I’d also realty want to work with you, using your arch Linux OS as a base, and making it much more of a user friendly experience. It is so powerful and clean, that it would be easy to work with. The clockwork OS is kinda all over the place, almost held together with sticky tape. It’s hard for users to know how to easily edit things.
So! In short. I want to have a separate data partition SO badly! But I have many fears.
Great. Can you tell me the exact name of the Roms, including the extension, exactly where you’re putting them, and exactly which emulator you’re using? Eg, mgba in my build is specifically there to play GB and GBC and doesn’t search for GBA Roms. GPSP is what I have designated as the GBA player. Likewise, GPSP is not currently set up to to play GB/GBC.
Oh also. Try pushing left and/or right while in the menu. You may have navigates away from the main list to the favourites list, which if you just wrote your image, would currently be empty.
Okay so the directory is as followed /home/CPI/games/GBA
And let’s just take for example The legend of Zelda the minish Cap.zip when I unzip the file all it registers is GBA file under type even on name it doesn’t classify the it as anything different
Okay! So is it specifically GBA or gba - capitalisation makes a difference! If it’s not lower case, it won’t even see it. Try changing it to zelda.gba instead of zelda.GBA. I’ll possibly update the file associations to include upper and lower cases of everything, if this continues to be a problem.
speaking of GBA, from yesterday, I had some (2 or 3 times) of random freezed then reboot when playing with RetroArch.
It happened on several ROMs, with both mGBA and gpSP core.
I don’t remember exactly but I was not overclocking.
Now I’m enabling logging for RetroArch to see if it happen again
OH?? Which kernel were you using? I’ve pretty much switched to using 5.5.9, and have had smooth sailing. I used to have freezes on earlier kernels. But like we discovered earlier, some people have a screen flicker issue with anything other than stock 5.3.6.
On top of that, the 5.5.9 has also got a modification to allow you to push the power button to force a proper safe shut down, even when the system is unresponsive.
I use this a lot when troubleshooting. Saves having to hold the power for 10 seconds, and hope the system is being shut down properly.
If you’re one of the lucky few who can use a newer kernel, give that a try and see if that improves your stability in retroarch.
Also, regarding overclocking, I haven’t found that it affects stability at all. The only thing I really notice is a higher temperature, but that’s only when I’m using all 4 cores to compile code. For gaming, I haven’t noticed a real difference; but then again, I haven’t exactly been methodically monitoring. The main thing is, there hasn’t been any thermal throttling noticed, or sudden drops in frame rates. That should mean that it’s running cool and within specs.
I wonder if we can properly overclock it, removing the thermal throttling. This is a terrible idea I know, since if it is getting that hot, you’re probably going to melt plastic haha! The fact that it doesn’t means that stability shouldn’t be compromised by an overclock. I think people just get scared of the word “Overclock” and associate with the word “Void warranty”. Of course I can’t guarantee anything, but that’s just my experience. I don’t have it on all the time, since honestly, most things don’t need it. It’s when I know I need it I will crank it up.
Another thing - Try a general core update within retroarch via the online updater. There was a pretty big overhaul of cores recently. I deliberately avoided doing it, in case it would break something, but hey! If you’re having stability issues as it is, give updating them a shot. What’s the worst that can happen? (famous last words)
Oh god, um, don’t restart! You can’t have two 30_NAME files. Make the numbers change, otherwise the order will get messed up!! Do that before restarting, otherwise it possibly won’t start! Also, you will need to make a duplicated icon in the skin file.
So maybe something like,
And hope that the next numbers aren’t occupied. That is how the ordering of the icons is done, via numbers. And clashes with numbers/names is how launcher hangs happen.
Okay. So depending on if you’re in the full DEOT mode, or in the mode that lets you change skins, you can find the skin files in different places.
DEOT Full mode: /home/cpi/launcher/skin/DEOT
Skin mode: /home/cpi/skins/DEOT
Once you’re in the skin folder, go into DEOT/Menu/GameShell/20_Retro Games/ and duplicate the file MGBA.png, and rename it MGBAgbc.png. (there’s also an alternative MGBAalt.png file that you could use/rename)
Basically, just make the .png mirror the naming structure of your new action files.
Do the same with the OhboyCBC+. Note: you don’t need to have the number prefacing the file name for it to recognise which icon needs to be skinned.
TITLE=Gameboy Color Roms
Under EXT, I changed the extensions list to only contain gb and gbc extensions. If you don’t use zip or 7z files, you can get rid of those too. As it initially was, it was able to read all gameboy, gameboy color and gameboy advance roms, in case someone decided to say, put all the pokemon games in one directory.
Under TITLE, you can change it to whatever you want. I had it initially as the name of the emulator.
Now the question is, was there any reason for choosing to use MGBA over gpsp for GBA games? From my experience, gpsp ran faster for GBA in every way, whereas MGBA ran better for GBC and Super Gameboy, integrating better colour palettes and borders. I switch to the gpsp+ standalone for games that need a bit more grunt to play faster. The downside is that it uses more power.
Ohboy was included mainly for old school gameboy games, and better palette selection. It also has nicer borders to simulate physical gameboy consoles. The downside compared to mgba is that it doesn’t support retroarch achievements, and other features.
I haven’t made as many individual iterations to keep the menu from being too cluttered.
The reason I’m asking is I haven’t tried every possible game, and emulator combination. If there are specific scenarios where one emulator works better than another, I may consider removing superfluous emulators in future. For example, it doesn’t seem like you’re using any of the gpsp emulators.
Haha phew! Yeah, that’s exactly my thinking re: having them all!
But yeah, definitely is good to be flexible to be able to use any and all of them as you see fit.
I shall definitely keep them all! I was getting worried that perhaps no one was using gpsp and/or ohboy.