As you can see, I have narrowed it down to a single function call, but it is called across hundreds of different objects and only one of them may be corrupting the heap. The heap in question in the stack of memory which holds all the data for the engine, and while applying a shader to one of the light mapped imported objects, the vertex data copy operation is overwriting neighboring blocks of memory and causing a heap crash.
Finding it was a complete mare, but fixing it might be just as torturous. The good news is that I am tracking it down now and with a little luck I can solve it once and for all.
Fortunately this was not my only small win today, as I have also solved the issue of the light map image files saves from crashing by moving the DirectX copy texture and save code from the threaded process to the main one. A rival solution was to activate the DirectX multi-thread mutex feature but that would have incurred a very small performance hit which I am no longer willing to compromise.
It's about nine thirty PM now and still no joy in figuring out which object is messing up my heap so will do my usual back-ups and resume Wednesday with better eyes. As un-glamorous as this type of code fixing is, it may solve several issues in one go as the unpredictable outcomes of silent heap corruption can be far and wide. Thirty objects down, several hundred to go...
You may want to investigate some of the trees sooner rather than later. Tree05 in the official media certainly seems to cause me much slowdown for no apparent reason. Probably not related, but worth a look.
ReplyDeletePerhaps as part of your investigations to solve this you could release a version to your testers to test out baking and report objects that fail? In the long run it may prove to be a faster way to find any potential model issues, including custom ones. That way you could go back to other things and avoid much testing yourself.
Oh I forgot to ask.
ReplyDeleteint lee=42
What on earth is that beyond a Hitch Hiker reference? ;)
Well duh. Lee is the answer to the ultimate question of life, the universe and everything. :P
DeleteI simply use it as an anchor code line to place my break-point. I may be the answer, but figuring out the actual question is usually the hard part...
DeleteAh, heap corruptions. What fun!
ReplyDeleteOH. I just remembered. Something I've been meaning to ask you for years: Are you the Lee Bamber who created the Zeb game example in The Games Factory 1?
yes he is clunker
DeleteIndeedy. I coded it, and Nolan Worthington design the game and created the art. It was lots of fun!!
DeleteAwesome! My brother and I spent many, many hours pulling that game apart and trying to work out how it was coded, only to mostly give up and just create new levels from the old parts ;) That was pretty much the first time we'd ever encountered game creation, and it was very exciting.
DeleteAnd this my friend is why I let you handle the coding. I hate debugging code. I would rather spend my time with the actual game creation. You definitely have my respect because I know what it takes to write all those lines of code and have to search back through for that one troublemaker.
ReplyDeleteProgramming is a lot like sex. One mistake and you're providing support for a lifetime.
An interesting parallel...although I would not want my software hanging around for 16 years before leaving home - it could get crowded!!
ReplyDelete