Still no advance on this graphics corruption and crash; I spent all of last night looking through code and playing with Minus4 to try and replicate the bug there, all with no luck. I still think it's to do with the new sprite cache initialisation code because if I run it once only, it seems to be fine. Problem is, the code looks okay to me, which means I'll have to step through all 137 sprite slots being initialised.
You know in a way, this restores my faith in development. When I started this, I had come to the conclusion that either I'd just gotten way better than when I was doing this stuff profesionally, or things were just not that hard now. But this shows that really nasty bugs can still rear their ugly heads, and are still a fag to track down. Thats not to say that its not easier over all - if I hadn't improved in the 18 years I've been doing this for a living, I'd be really worried!
2 comments:
I would try it with 8 cache entries first, if it still fails then there's much less to debug.
When I've encountered seemingly random bugs I've first found out the result - memory corrution, out of range values in table etc. - and then added some sanity checks all over the place. This usually locates the corrupting code quite fast. If the bug is in the code, great, if not then it was some bad data fed into the code so I repeat the above until I get to the source (pun unintended).
--
TNT
I've already tried with 9, and it alters what goes on. with 137, its predictable....
Its no fun being me :)
Post a Comment