However, LZMA has a more significant impact typically on CPU, mostly because it usually uses larger lookbehind buffers and lots more memory and memory searching. If your device has a Mhz higher than 1000, it's probably going to make almost no difference in speed (for decompression.) And CSO compresses better.
A CFW implemented it, so I tried experimenting with it, but it really didn't seem all that worthwhile for desktop. The performance difference for ZSO only really matters on the 222Mhz CPU of the PSP. Guess I'll change the title as PPSSPP is not related to RA it looks like posted in wrong place.
#PPSSPP FILE PSP#
Using The Leecherman's "ISO~PBP converter" for PBP and maxcso for other formats, maybe I just don't understand the settings which I should use for ZSO, but from my testing it was the fastest while leaving the biggest file.Īnyway if few mb's is a big deal PBP format seems the best for me, it's also supported on PSP and doesn't modify the file in any way, commonly overlooked with some myths caused by Sony's using it for non-PSP games as well, but PPSSPP supports it just fine.ĬHD did had a sligly better compression even than PBP, but I don't think it's worth storing PSP games in that format, it's not native to the platform and doesn't have anything which would make it worth using while coming with all MAME stuff that we don't care about.
PBP -> CSO2 with bigger block size -> CSO -> ZSO Is ZSO even ment for the biggest compression?įrom my test with available formats from best compression to worst: This may change thou, since they seem proud of the CHD support. I'm more pessimistic, complicated features are the first to be handwaved away.Īnyway, CHD is bad for now for retroarch anyway because the metadata database and their scanner is not ready to accept CHD checksums, internal or external (even the internal checksums are different from the raw cue/bin because they're of a 'sum' of the involved files, not only the 'first track' or whatever hack RA is using - they previously used cues and gdi and of course this failed alot since many gdi are indistinguishable due to dumping group bad idea, so i'd actually prefer the CHD approach). The devs thought that since the format specifies that the format should support parent/clone relationships this wasn't needed. Emulators still need to implement reading chd, but that's much easier.
#PPSSPP FILE PATCH#
and they nixed my proposal on their chdman issue report page to add 'reversible hardpatch' to their format (basically, do the boring work of integrating a 'patch update' tool that takes a binary patcher, patches the underlying bytes, and creates a reversal patch to add as header for the next 'patch update' and recompress that again).īig advantage of such schemes is that they don't depend on lazy/dead emulators implementing softpatching to work (reimplementing the wheel every time), while still being easy to update. Pity it doesn't work anywhere else (including retroarch, except, ofc, the MAME core). One 'advantage' of CHD is that chdman and mame are supposed to have support for a form softpatching (parent-clones relationships, where clones store different files/sectors).
0 kommentar(er)
