tokumaru wrote:
My advice is, by all means, cover your ass by clearing whatever you can as much and as often as it takes for you to feel comfortable, but save such safety measures for the end of development, because while having bugs manifest themselves in the final product is a BAD thing, having them manifesting themselves during development is a GOOD thing.
Sorry that I've tread back on
our old argument, but no, I would definitely not want to suddenly add in extra safety code at the END of development. That has far too much potential to add NEW bugs, and invalidates all of the testing you were doing up until that point. I think doing this would be worse than no safeties at all. If you've gone without them up until that point, just stay the course and ship that way.
Like I said in the other thread, I think "safeties off" tests are a
great thing to do, just not as something you alter so late in the project. E.g. every sunday night turn off all the redunant checks (helps if you put 'em in a .define) and do some smoke testing, then after this testing session
turn them back on and get back to normal. Spend as much time as is practical testing the way you will deploy. That by itself is much more important than having a redundant safety feature.
tokumaru wrote:
how will you detect these bugs if you're clearing the latch left and right?
I would once again suggest the debugger can do a much better job than working safeties-off. The game failing is neither the only way, nor the best way to detect a bug. Using appropriate debug tools you can detect this with complete reliability
without even removing the safety code.
If you wrote a LUA script to catch any $2002 reads where the latch isn't already at 0, you would catch a mismatch error whether or not it resulted in crashing the game or gave any easy visual indications, and wouldn't require any modification of the game's code. Setup breakpoints on unexpected reads/writes, fabricate some sort of assert mechanism, use thefox's nintendulator that automatically catches uninitialized memory use, etc. there's lots of very good tools for this kind of thing!
tokumaru wrote:
situations where every cycle matters...the 4 cycles taken by a BIT $2002 were preventing me from fitting those 2 updates together
Of course, yes. If you need 4 cycles or 3 bytes, it's something you can cut.
There's also a compromise between "never do it" and "always do it", like nobody is advocating clearing $2002 more than once during an NMI handler (pointless), but even if you only put a redundant $2002 read between screens or levels (i.e. timing not an issue, rendering off), that by itself is still a recovery point. Maybe the game goes visually haywire for whatever reason, but if they can just make it to the next screen... they're back in business!
Even if your code is perfect (it
isn't) there is such a thing as hardware failures, bad catridge connector, vibrations in the room, crummy power supply, etc. You could write these cases off as "well it should crash and I don't care what happens", but if someone's been playing your game for an hour they'd probably really appreciate being able to recover if it's possible. Such a miracle has happened to me a lot of times while playing NES and it's always been a moment of extreme relief.
Overall I don't think $2002 latch mismatch in particular is a case with high potential for error, really. It's just one of many things I think usually worth doing redundantly as a matter of practice.