It looks like you're new here. If you want to get involved, click one of these buttons!
orxOBJECT* TempObject;
for( // Grab the first object in our linked list, which is an orxOBJECT,
TempObject = orxOBJECT( orxStructure_GetFirst( orxSTRUCTURE_ID_OBJECT ) );
// Until we get one that's NULL,
TempObject != orxNULL;
// Continue onto the next object,
TempObject = orxOBJECT( orxStructure_GetNext( TempObject ) ) )
{
GameObject* GObj = (GameObject*) orxObject_GetUserData(TempObject);
if(GObj != orxNULL) GObj->Update(DT);
}
Comments
If you could send me your project I could have a look locally. However i'm leaving tomorrow for 3 weeks so if I don't get it before tonight PDT, not sure when I'll be able to check.
EDIT: I didn't see iarwain's post until just now; I was not talking about orx structures, just C/C++ variables. For optimization modes, it won't bother to set them to 0 (for speed's sake, I'm assuming).
I'll probably be too late dor that offer, iarwain, but i'll upload it for you when my computer is on and im out of bed.
Make sure you change the dir to the SVN dir, I've tried explicitly changing the pointer to a null pointer but no such luck.
As mentioned, Disable the optimization and it works fine, put it on the default Maximize Speed and it crashes.
With your current project, the first 2 objects of the list don't have a userdata but the third one has one (Player) and its value is correct.
However we do crash after updating the player gameobject, I'm going to have a look at that right now.
The stack pointer (ESP) doesn't get restored correctly at the end of your Player::Update() function and is 4 bytes off, which means exiting from this function sends us to an invalid position (if you trace in the asm window you'll see the call stack being correct till the ret 4 instruction is called and then all hell breaks loose).
Now understanding why we get 4 bytes off when restoring the stack pointer is the next step.
EDIT: Commenting out the call to GetMouseWorldPosition() and setting the vector to 0 will fix the ESP misbehavior and everything will run just fine.
It probably comes from the function returning an orxVECTOR by copy and a probably SSE/alignment issue, going to look more into it, but a probably (untested) work around would be to change your function to GetMouseWorldPosition(orxVECTOR &_rvPos) instead.
However it feels like it's a compiler optimization bug when trying to inline your GetMouseWorldPosition() helper function. The asm code results in an asymmetric number of stack push/pop, ending with the stacking pointer missing a pop (ie. 4 bytes).
A super simple work around is to not use your helper function at all.
This code works like a charm:
Otherwise, had a quick glance at your code, I have a couple of advices on how to use orx's features more efficiently if you're interested (like when creating Enemy and the current use of randoms, all this can be done completely in config).
One test you can do is change your GetMouseWorldPosition to take a orxS32 param (not a float as float are passed via the float stack to functions).
Don't do anything with that orxS32 inside your function, don't even read it. And when calling it do mousepos = GetMouseWorldPosition(5461);
Everything will work just fine, no extra pushes. -_-
It's like with no parameters the compiler, after inlining, is trying to call the orx functions (orxMouse_GetPosition/orxRender_GetWorldPosition) with a stdcall calling convention instead of the fastcall one they're using. The info might get lost at some point but not when the wrapping function (yours) is taking parameters.
Ah well, another microsoft oddity, I'll stop my investigation there. Have fun, 4AM here, time to get some rest!
Anyway, have a nice holiday or whatever you're going to do for 3 weeks, and see you after that ^_^
EDIT: Also, mad respect for your assembler knowledge. I'm supposed to know some about it (so your ramblings make sense to me) but the depth you're going through it is commendable.
EDIT2: Just thrown out the mousepos helper function, and now it works effortlessly. weird, but true.
A long time ago asm was my first programming language, back when it was the demoscene that got me into coding. I don't have the skills of doing asm coding anymore but there's enough left to help for this kind of cases.
As for Grey's version, I haven't tried it but it's possible that it might not be subject to the same optimization bug as his version is a method, albeit static, so the optimization path is C++ only whereas yours, being a plain function, could be a shared optim path with the C compiler. Worth a test, out of curiosity.
I'll have another stab at it, but i'm happy enough that it works now :P