Hi all, I've been experimenting with directx in assembly and I keep comming up against the following problem:

If variables which are supplied to DIRECTX in function calls are declared as local then my program doesn't work. But when I change the locals to globals everything is "peachy keen"
Has anybody had this problem?
Posted on 2002-07-11 09:31:52 by MArtial_Code
Local data is on the stack and data there can only be used during execution time of that PROC. It is good to use for temporary objects that are released before return, but otherwise you must use globals (or pass pointers to stack space to child routines). Scronty's examples use all these methods - please take a look.

With DX8 you can loose the whole device to another application and have to restore the state prior to loss. So, most of my object pointers are global to allow access by everything.
Posted on 2002-07-11 11:24:38 by bitRAKE
I've noticed the same thing in non-dx programs I've coded,
and can CONFIRM this in my current work.
This seems only to occur when using the 586p instruction set.
Changing that, or as you said, moving the offending variables from local to global, are both solutions.
Furthermore, the error seems only to occur when a local variable is accessed indirectly, ie is being used to hold a Pointer which we access indirectly ie .
Posted on 2002-07-16 10:11:11 by Homer
hmm, I don't know why my DX app works even if I use locals to hold my pointers and use them to call the methods ... and still using 586p. ???

There's just probably some errors on the program logic that's why the local pointers didn't work. No biggie!!! ;)
Posted on 2002-07-16 11:02:51 by stryker
I'd love to believe that I had missed a bug in my coding, but I searched exhaustively, and can find no other possible explanation as to why changing the instructions set from .586p would solve it, if it was merely a coding issue.
I have come to the conclusion that there must be a case-specific bug, but that bug maybe so much isn't in the compiler, it could be in the very cpu version I run. I haven't tested my code on other machines to verify this as I generally try approaching my code differently , ASSUMING that I have an error and that I just am not seeing it no matter how long I stare... and I can stare a long while :)
The cpu on my asm box is an AMD K6-2 - maybe there's an opcode casing bug that just never turned up before? That too sounds unlikely - leading me again to believe, since changing the instructionset alone fixes the problem, that the compiler must have an opcode-casing bug somewhere in the .586p set.
Oh, I'm on the old ML.EXE still - anyone got the m$ ddk care to share the new one?
Posted on 2002-07-25 08:03:50 by Homer
Sounds rather weird... changing CPU directive shouldn't cause alternate
opcodes to be generated - it should only bitch if you try using instructions
that aren't included in the cpu you've specified. Other than that, the only
difference I know of when setting different processor style is that 486
and higher allow you to "align 16" (why the hell aren't you allowed to
do that with .386? Stupid masm ;)).
Posted on 2002-07-25 09:35:11 by f0dder
As per my original question:
I've since been using lea to pass the address of stack variables to directx functions, I'm still not happy as to why addr doesn't work! here's what i mean...

myproc proc
local var:dword
lea edx,var
DXINVOKE (pIDDS).SetColorKey,DDCKEY_SRCBLT,edx ;this works
myproc endp

myproc proc
local var:dword
DXINVOKE (pIDDS).SetColorKey,DDCKEY_SRCBLT,addr var;this fails
myproc endp

if I define a dummy function like ...

dummy proc arg:dword
mov edx,arg
dummy endp

then do this...

myproc proc
local var:dword
invoke dummy,addr var
DXINVOKE (pIDDS).SetColorKey,DDCKEY_SRCBLT,edx ;this works
myproc endp

It's clearly something to do with the directx call. I don't think it's the DXINVOKE macro
I'll have to dust off the old disassembler to check this out...

ps: there're no problems using addr with globals
Posted on 2002-08-14 11:22:06 by MArtial_Code
I just finished disassembling the ddraw examples and I 've found the problem.

masm's addr local_var
resolves to:

lea eax,
push eax

this was conflicting with the macro's use of eax.

by changing the macro to use edx instead the problem was resolved :cool:

UREKA!!...Now I know the reason why masm spits out the following error!
error A2133: register value overwritten by INVOKE

this happens when eax comes before an addr local_var in an invoke statement!
Well I definitely learned something today!
Posted on 2002-08-14 12:19:56 by MArtial_Code