U look like him, a little bit.
edited 8:26 PM EDT October 4, 2005
Regarding making a usflib set, might the problem be that you're using a version of recon that assumes a ROM smaller than the one you ripped from? This was a problem for me for a while... Run recon with no parameters to see what it uses.
Other than that there shouldn't be any reason for usflib reduction failing, each miniusf should contain replacements for any data at the same address that another song is using.
Yes, last night i remembered something that recon "assumes" a 32Mb rom, and once i changed this it was running fine.
Other than that there shouldn't be any reason for usflib reduction failing, each miniusf should contain replacements for any data at the same address that another song is using.
You obviously haven't tried to USFLib my original DK64 set. But a few of my own routines seemed to do the job just fine, but this might be caused (highly unlikely, but likely) by the fact that i didn't have a single pj, but 174 pj's (about 1.4GB worth). Also i think i have found out why dk64 uses so much cpu time. I got it reduced from about 25% to less that 5%. Conker uses 0%?
Anyway i with this out of the way and started making a set of Conker and MAN HOW LONG DOES IT TAKE!!!
I started it at about 9:30 last night and started watching tv, and i saw a good anime movie - it was Laputa: The Castle in the Sky. So when that was finished at about 12:10 i turned the screen back on and it was not even half done. So i just went to bed.
Well here is what i got of the rip so far.
I might get it finished today, or tommorrow.
Nice pic.
Also, disk_free_space() reports lots of space left on the server.
edited 7:56 PM EDT October 5, 2005
I tested the sample and it was kewl.
Hooray for Robin Beanland!
I'd love to know why recon isn't working... to each miniUSF the data is supposed to look exactly the same. Could you put up a minimal example, or tell me what you changed in your own routines? And are you sure you weren't using a version of recon assuming something smaller than DK64's 32 MB?
Glad CBFD is working now, anyway. And regarding the CPU usage, have you taken a look at how the old set performs in beta 17? You may have fixed on the USF side what I avoided on the player side.
If disk_free_space reports anything more than 20 MB it's counting the space actually left on the server, not the portion of my 500 MB quota that's free.
edited 9:24 PM EDT October 5, 2005
edited 9:26 PM EDT October 5, 2005
Anyway i had several programs made to rip it. The first one was to strip an empty .PJ created that played nothing to get rid of the savestate header. the second was to compare that file to all the rest of the PJs to keep which bytes were common to them all. The third was to remove a whole shitload of data that i found wasn't nessecary and what was already in the base PJ that i created before. The fourth was made to remove a huge 1Mb chunk of rom that wasn't being read by any of the tracks.
Then i used recon to make the minirams and they worked.
I suspect you won't be able to play the second verse of the poo boss song without it. it.
Hmmm, i don't think it does play, but i will check it out...which music index is the poo boss song? I've never played CBFD.
If you generated sparse RAMs with anything but PJ64USF (excluding anything you wrote that might leave 0s in) this might become an issue.
and I think the index is 0x42, though I haven't checked your test rip for that yet
edited 11:31 PM EDT October 5, 2005
No, not 0x42, though that is a cool track. I listened to it on infinite play for 1.5 hours last night while working on a lab report. According to the code on this page it's 0x41, but your 0x41 isn't what I had been working with (which had lyrics and was in fact a completely different song, though it had the same instrumentation). So maybe you're using a different section of the same thing already.
edited 9:48 PM EDT October 6, 2005