I should add iso-ification to gdishrink.On my card I have all US games, all PAL exclusives, about 50 japanese titles, and a bunch of unreleased games
I don't know what terminology you guys are using for 'shrink' since there's a few different things that can be done to reduce filesize, but all of my games are converted from GDI+BIN (2352) to GDI+ISO (2048). This only saves about 10% per image but makes 100% fully compliant images that should never be at fault for an error.
The only one of all of those that crashes for me upon highlight is Sega Worldwide Soccer Euro Edition.
On that disc the 0GDTEX.PVR file is a smaller resolution than the 0GDTEX.PVR on all other discs.
Rather than rebuild the disc or try to find/make a better 0GDTEX.PVR for a game I frankly couldn't care less about, I just hex-edited the ISO file and changed the filename in the file table from 0GDTEX.PVR to 1GDTEX.PVR.
Now GDEMU doesn't try to load the artwork, doesn't crash, and the game loads fine
I honestly wish we had a full set of the 2019 TOSEC DC release, with all GDI's run through GDI Shrink with edited PVR textures to show the proper box art covers instead of disc art images.
When I get some free time (in probably well over six months, so don't hold your breath anyone) I plan on investigating what makes gdishrinked images not work with gdemu and fix it. There's a reason why I don't make it convenient yet to shrink images; it's still experimental and comes with no warranty or support for the foreseen future.I've thought about doing so in the past and DATing the set on Dumpcast (since the set would probably need updates and bugfixes) but there were some big cons to doing this:
- I already have the entire scene, redump, trurip, and tosec sets stored on my fileserver, I don't need to store and update yet another damn set...
- I would really hate for yet another set to be floating around, people already ask for GDIs, CDIs, and SDISOs as Dreamcast standards, we don't need another...
- I am not really a fan of shrinking the games (using truncated files) because it can create problems and 400GB SD cards that hold everything are only $55 now, so this is a lot of headache for people to save $20 and put the fullset on a 256gb card instead of a 400gb, esp when memory costs will only continue to drop in price where soon this isn't even remotely a concern. So I would personally desire for my own use yet another set of DC images that aren't shrunken but have new 0GDTEX.PVR images
So, IMO, there might be better ways to accomplish this because I agree the ODE UI experience on Dreamcast is lacking (I want something that looks more professional and "official" for my frontend... I have been working on some themes for my DC, like this one below that I use on my black Dreamcast:
View attachment 5402
That being said... injecting new 0GDTEX.PVR files in GDIs should not be difficult to automate so that people can just apply the textures to their images. A theoretical utility can just look up the 0GDTEX.PVR entry in the filesystem and replace the LBA with the earliest possible useable LBA in the dummy data area of track03 and then plop the 0GDTEX.PVR data in that area. gdishrink's sanity check should prevent it from being stripped out and it won't modify or move around any of the existing game data in a way that would set off copy protection.
For the games that don't have a 0GDTEX.PVR at all though, it would have to insert a new file record
A new version (or outright replacement) for GDEMU SD Card Maker could be created with options to insert artwork from packs (so different region artwork could be used based on user preference) in addition to shrinking or bin2iso'ing GDI files as they are transferred. It could even support theming the GDMenu entirely
But also, yet again, I think there's an even better way to accomplish this, and that is to support and help @neo on his OpenMenu replacement for GDMenu, which if done right could natively support all of the above features without hackery plus include stuff like a patching engine for cheats, widescreen/60hz fixes, etc...
When I get some free time (in probably well over six months, so don't hold your breath anyone) I plan on investigating what makes gdishrinked images not work with gdemu and fix it. There's a reason why I don't make it convenient yet to shrink images; it's still experimental and comes with no warranty or support for the foreseen future.
I think in the end, what I should do is to add a "strip" and "dress" function in GDITools to respectively remove or add EDC/ECC. I experimented with lidedc in the past and I should be able to make some python bindings relatively easily.
On the GDIShrink side, I think the final design should be reversible. I plan on not removing the content of the low density area and the new sanity check should make it 100% reversible, worst-case I can generate a small json file to add some infos for the "GDIExpand" function. A GDIShrink—GDIExpand loop should leave checksums unchanged.
I could also add a GDITools option to patch/replace a file in a "stripped" GDI, as long as the final file has the same size as the original. It'd be a pain to mess with the files record safely in general, but I could maybe add an option to add a file in the padding area. Although it might not be a good investment in terms of effort/usefulness if there's a more flexible menu on the way.
In the end, I would like to provide a utility to add to the tosec package that'd allow users to patch and shrink/strip/dress/expand their GDI dumps. Would that sound good @darcagn?
Main missing resource right now is time.
The only one of all of those that crashes for me upon highlight is Sega Worldwide Soccer Euro Edition.
i'm check Sega Worldwide Soccer 2000 - Euro Edition v1.030 (2000)(Sega)(PAL)(M4) TOSEC
this image don't contain 0GDTEX
Which version of the game are you using?
- I am not really a fan of shrinking the games (using truncated files) because it can create problems and 400GB SD cards that hold everything are only $55 now...
A theoretical utility can just look up the 0GDTEX.PVR entry in the filesystem and replace the LBA with the earliest possible useable LBA in the dummy data area of track03 and then plop the 0GDTEX.PVR data in that area. gdishrink's sanity check should prevent it from being stripped out and it won't modify or move around any of the existing game data in a way that would set off copy protection.
For the games that don't have a 0GDTEX.PVR at all though, it would have to insert a new file record
It doesn't have a fixed size, but it can really be a pain to add a file to it in some cases. ISO9660 wasn't designed with edition in mind at all.@FamilyGuy the file table have fixed size? would be possible to add a new file to the table and append the file to the end of the iso image without having to rewrite the entire iso?
That's highly unlikely as the Menu Software is basically only a game with custom commands to control the GDEMU in a very basic way, like swapping GD-Rom or returning firmware version. It can't read the GDEMU SD-Card, unless that feature is added to GDEMU in the future (unlikely).I for one am hoping we'll eventually get an alternative menu implementation, where you can simply put a pvr file alongside the disc image instead of having to deal with all the injecting bs. But maybe that's just me.
what? for usb-gdrom just put tosec isos on a usb and thats it. no trouble at allI'm simply hoping somebody comes up with a new device so I can get rid of GDEMU and USB-GD. They're both way too much trouble.
I checked and it is Sega Worldwide Soccer 2000
what? for usb-gdrom just put tosec isos on a usb and thats it. no trouble at all