ZSNES board

I usually try to keep out of off-topic discussions, but I feel obliged to mention two things: * UPX does not add to the "alphabet soup of compression formats" because it is self-extracting. The decompressor comes with the executable, no additional user software required. * The very concept...

I thought the objective was to make a fake that looks like a real, not a fake that looks like another fake. The objective was to show that MD5 plus CRC32 is not any more secure than MD5. And I hate to quote myself, but: As soon as an MD5 preimage attack becomes known (and I have little doubt that w...

DataPath wrote: Am I doing something wrong?

You are comparing one of the modified versions (cannot tell which one) with the original, not with the other modified ROM.

Here is a practical example: I uploaded patches one and two . Apply them to the US localization of Super Mario World. The resulting ROMs have the following properties: - Both have the same MD5 hash. - Both have the same CRC32 checksum. - Both have good internal checksum. - Both are fully functional....

All you really need is two existing checksum methods. Fraud and collision is next to impossible with CRC+MD5 documentation. If by some miracle someone had the motivation and skill to brute force both, the file would be so butchered that it would never propagate in distribution channels. Because it ...

This actually caused a loss of 2-3 fps >_< Strange. Would you mind sharing the WIP, so that I can take a look at the produced binary code? I know it's not because it's slower, more likely some sort of alignment issue with the generated code. I moved a variable inside a class below a two-entry struc...

Took a ~1% speed hit or so by using functors for the callback and using the signed math trick to avoid the need for a normalize() function. Replace return x - y < (std::numeric_limits<unsigned>::max() >> 1); with return x - y <= (std::numeric_limits<unsigned>::max() >> 1); to reverse the speed hit ...

CRC32 and filesize alone would probably be sufficient, your worries are unfounded. CRC is a transmission error detecting code (and a good and simple one for that), but was never intended to protect against malicious alteration of data. Tell you what, take a common bad checksum, spoof it to match th...

What's ugly about it? "Premature optimization is the root of all evil." If the function is called once a second on an array that never has more than 10 elements, I'd be surprised if it consumed more than 0.001% CPU time. I was not speaking of speed but rather of conceptual elegancy ... bu...

Bah, screw that. I'll just use a normalize function instead. Call it once a second or so. void normalize() { for(unsigned i = 0; i < heapsize; i++) heap[i].counter -= counter; counter = 0; } Wait, do not be so unidealistic! That normalizing is just plainly ugly. Why not inline the function blargg p...

Just a quick note on the priority queue (actually, there is nothing left of any deltas) implementation (I know this is anything but final): You need to use the sliding compare not just in the tick function, but everywhere you compare absolute cycle counts ("heap[child].counter >= heap[parent].c...

blargg, good job in elegantly implementing a delta queue (and also in providing commentary on standards-compliant C/C++ implementation of "sliding" compares). Note that you can get rid of the subtractions in "*p -= time;" and "time -= *p++", and also the "last"...

2) exact cycle count timestamps that grow forever will eventually overflow, unless you subtract them all by the smallest value in the list periodically. Do you do something like that after each frame or so? No need there. When comparing time stamps, instead of a < b always do (signed) a - b < 0. On...