For each found folder in /games/ :
1) First, it checks the titleID and the game's tile from the folder's name (same functions as the Wii games, so not the problem I guess)
if no ID found, set titleID to 000000 (why? it should already be zero. unneeded commands, sources might need to be verified) it would remove few CPU cycles.
2) Then looking at the differences with wii games, gamecube has to get the game's filename.
On Wii, it's mandatory to be TitleID6.xxx but on gamecube, it can be :
titleID6 or "game", with extension "iso" or "gcm" (and "ciso" not supported yet)
so, the difference is it's checking for file existence 4 times, with "game.iso" first.
game.iso <-- you should have this, so it's checking and stopping on the first try. it shouldn't take too long, but maybe single cycle of "check if file exists" can be long if there are too much games?
TitleID.iso
game.gcm
TitleID.gcm
(possible bug, if no ID found previously, it'll search for 000000.xxxx 4 times, need to be fixed)
3) If none is found, it verify if you don't have only "disc2.iso", using the same method. This could probably be simplified. but it's only in case you have ONLY disc2, no disc1.
4) If still no game iso/gcm are found, it then checks whether the game is in extracted format (fst).
5) If no titleID has been found on first step 1, it opens the first found ISO file to read the titleID from the header. at the same time, store "game's Title" for later.
Apparently, there's no way to get the TitleID of an extracted game format if it's not found on previous steps! TitleID in folder is mandatory here!
6) get the Game's Title from gamestdb, or from the "Title cache" file, based on the titleID.
I now see there is a bug, there's no way to enforce "title from disc" (step 5) if TitleID is found (step1)
7) if title not found in gamestdb or not in use, or ID not found, and "force title from disc header" is disabled by the user, set the game's title from the title found in the path in step 1
8) If we have both an ID and a Title, add that game to the gamelist and skip to process next game.
9) unsure when this step is reached...or what it's supposed to do.
looking randomly at the sources 2 years later is not easy. comments are not very good.
Apparently, it's only reached if the user selected "Force Title from disc".
so, when using that option, it feels like the ISO is opened multiple times in the process.
It seems it opens the ISO header and store the entire raw header into the game list without really checking and storing the ID/Title/Disc number/etc. to be used by the loader (resulting in empty games listed on the interface?)
Finally it saves the game's ID/Title (from the unverified RAW header?) association to the "Game title cache" file to speed up next launch of the loader.
it should never reach that step anyway as it should already have both ID and title from previous steps, unless it failed to find ID or title. but then, I'm not sure why it's trying to open the ISO again.
So, if you see all these steps, it should do :
Step 1 (get the TitleID from folder) [like wii games]
step 2 (get the filename, stop at the very first try : game.iso)
step 7 get title from gametdb [like wii games]
step 8 add game to game list [like wii games]
Skip to next found game in /games/ folder [like wii games]
only "verify the filename" is added, and it's a single check if you use "game.iso".
it's using a loop to check all names.
maybe using 4 conditions would be faster?
maybe using stat() is slower than using "check if file exists" ? though, "FileExists()" might use stat() itself. (to be verified)
Of maybe the condition-ception is not working and never return true?
if((found = (stat(fpath, &st) == 0)) == true)
if it's never true, then it ends loading ID from the iso header.
https://sourceforge.net/p/usbloadergx/code/HEAD/tree/trunk/source/GameCube/GCGames.cpp
PS: I don't have that many GC games to do speed tests.
maybe I could add a timer or cycle checker to compare different methods/commands?