Eventually (2 days of brain bashing) I figured this out:
0xC0000005 errors are normal; But they're a good hint into memory over-walking.
Turns out, you can;t do this anymore (used to be able to; I'll figure out the fix):
struct myvec{ float x,y,z; } //Nicely packed struct takes up 12 byts, 3 floats in order.
float myfloats[9] = { 0, 0, 0, 10, 15, 10, -5, -10, 0 }; //Nicely packed float coordinates.
myvec somevecs[3]; //Make some vectors
memcpy( &somevecs[0].x, &myfloats[0], sizeof(float) * 9 ); //Copy them in!
Before you scream at this; Note that this works perfectly lots of times. Apparently, there are some rare cases you can cause this to break and GDB is helpless in figuring out you just walked passed the save/writable zone in an array. It's really hard to get this kind of thing detected, especially when using pointer casts.
Basically, if you run into a situation in which you find yourself doing this; Please stop and redesign your code so you do not have to do this. Unfortunately, there is no "fast" solution without redesigning some kickass wrappers and C-style code; but if you OOP this, you run into massive overhead and ultra slowdown from all these specialized copy operations; So, what can you do.
In my testing, caching blocks of floats seems to work best, then just forcing your user to slowly copy them into their structures. Although, I don't do that, because I redesign my structure to WORK with a float * internally so this can be as fast as possible and still lexically coherent.
What a $(#@^& problem.
-Z
Here's a picture. .TED files contain a lot of information; Once I clean up this stupid problem I'll post more goodies. By the way, these are models from the PC game "I of the Dragon" because I don;t want to show my models until they look somewhat decent. Obviously, again, I'll never use these; They're only good test sets to play with.
No comments:
Post a Comment