Search

[moviecouple]

I keep hearing that the R4/M3 Simply rom trimming tool over trims it's stuff. What about trim.exe 0.2, DStimmer, or the DS-X trimmer? Should we be using one of those instead?

Here was the thread that talked about the overtrim on R4:
http://gbatemp.net/index.php?showtopic=41527

DStrimmer
http://gbatemp.net/index.php?showtopic=41816

DS-X trimmer
http://forums.ds-xtreme.com/showthread.php?t=1050

[jbullfrog]

I don't think it overtrims. How do I know this?  I trimmed my rom file, and my sav file still worked fine with the trimmed rom.

If it overtrimmed, the sav file probably wouldn't work.

[deviations]

I keep hearing that the R4/M3 Simply rom trimming tool over trims it's stuff. What about trim.exe 0.2, DStimmer, or the DS-X trimmer? Should we be using one of those instead?

Here was the thread that talked about the overtrim on R4:
http://gbatemp.net/index.php?showtopic=41527

DStrimmer
http://gbatemp.net/index.php?showtopic=41816

DS-X trimmer
http://forums.ds-xtreme.com/showthread.php?t=1050

DStrimmer uses the same trimming code as the r4ds trimmer i think. i trimmed a few games in both and they came out to the same size.

[moviecouple]

Saw that too. Although trim.exe 0.2 produces slightly different sizes than R4M3S and DSTrimmer.

DSTrimmer allowes you to do roms in batches.

[Koji]

I'm not sure how a trimming program could overtrim. It's a fairly simple procedure. It checks the end of the ROM to see when FF starts repeating indefinitely then removes them. As far as I know, no real DS game does any sort of check outside of a simple checksum which is probably thrown out/ignored/given falsely as passing to the DS.

If you're really worried, you can always do it manually yourself as well with a simple hex editor.

[ratx]

There are 2 ways of trimming a nds rom; the "classic" method as Koji describes is to simply scan and remove the blank/nulls in the file starting from the end of the entire rom inwards - this is how trim-0.2 works.  Most other NDS trimmers use a different method; the address of the "end" of the file is stored at a location in the actual NDS header so they just read that "Offset" and delete everything after that.  This explains the different results... I've read  that using the "offset" method doesn't account for wfc data so maybe this accounts for the problems people have been reporting.

[moviecouple]

So you are recommending trim 0.2 over the others?

[Koji]

There are 2 ways of trimming a nds rom; the "classic" method as Koji describes is to simply scan and remove the blank/nulls in the file starting from the end of the entire rom inwards - this is how trim-0.2 works.  Most other NDS trimmers use a different method; the address of the "end" of the file is stored at a location in the actual NDS header so they just read that "Offset" and delete everything after that.  This explains the different results... I've read  that using the "offset" method doesn't account for wfc data so maybe this accounts for the problems people have been reporting.

Ahhh I see, I didn't realize their was anything in the header that listed the ending address. I'd say of the two, it'd be far simpler/safer just to remove the null bytes. The difference between the two can't be anything too great, and it's the safer method imo.

[ratx]

So you are recommending trim 0.2 over the others?

Ha ha maybe, but then I could be bias. Seriously like Koji says there isn't much in it, and an easy fix to any bad offset related problem is just to add a few k to the figure so I'm sure any "broken" trimmers can easily be fixed. Use what works for you unless it breaks stuff