mov hPlayerObject,$invoke (LinkedObjects_SetName,($invoke (AppendOrInsert ,NULL, sizeof Object)) ,CTXT("c:\masm32\directxex\xfile\Fighter.X") )
Posted on 2003-10-07 08:23:36 by Homer
Then you must love HLL also :P

Looks pretty much like "hide what is really happening" to me ...
Of course i looks like it will "ease" your typeing ...but wasnt that C/way of beeing?

Besides they say it is usefully ... :D
Posted on 2003-10-07 09:20:35 by BogdanOntanu
$invoke is simple .. it returns the result of whatever you are doing with it in EAX.
Aside from that, it simply passes the param(s) to regular invoke as a VARARG.

invoke Fun
invoke Fun, A
exitm <eax>

I also use a $mcall variant :tongue:

The point was that it can be nested, but its clearest use is thus:

mov hDC,$invoke (GetDC,hWnd)

so anywhere you would put EAX, you can put a full $invoke statement...
Posted on 2003-10-07 09:24:33 by Homer
mov OkToRender,FALSE
.if ($invoke (InitD3D, hWin)) != S_OK
Errr CTXT("Failed to Initialize D3D")
mov OkToRender,TRUE
Posted on 2003-10-07 09:44:08 by Homer
Errr is another of my silly macros.
It makes a messagebox and then returns from the current procedure , returning E_FAIL in EAX.
It makes no attempt to correct the Stack, but I wrote the macro, so I'm aware that I have to restore the Stack frame before I can use it (since it contains RET).
Silly, but quite useful, saves me heaps of typing, and it's still ASM to me.
I'm currently coding object oriented stuff as you can see, but it's all in asm, and theres no OOP framework, just chunks of allocated memory linked in lists and trees.
I do believe asm should evolve, but I don't think it should become cpp.
I actually can't program in cpp, I'm ok with that, I don't want to.
I like controlling the cpu registers and having the flow control that asm allows me.
I learned BASIC and then straight to machinecode, without realising asm existed.
For years I coded in memory monitors. Yuck !!
Do I think everyone should handcraft opcodes in a memory monitor? No !!
I have to say I want the best of both worlds, I want to have my cake and eat it too, and I can, and I do.
Posted on 2003-10-07 09:54:22 by Homer
Well, yes indeed it looks like cool, if you know exactly what you are doing
And it looks to me that you are.

So since i agree i am not very found of macro's and stuff...i was wondering if you could help me out with this
macro for define of tokens in HE parser:

i need a macro for defining tokens like this

tkn_u060 db 8
db "Big_Bird"

Where "8" is the length of the string "Big_Bird"

I was wondering if any simple macro (aka one that i could understand) could ease my typing
because curently i manually count the strings length and type them in the "db" :tongue:
Posted on 2003-10-07 09:59:05 by BogdanOntanu
Untested but nonetheless... should be ok
You get to supply the name of data variable as well as the string...
It will shove the length in front as you requested.

BogDacro MACRO variable:REQ,args:VARARG
LOCAL nExttOken , diffy
variable db 0,args
diffy equ nExttOken - variable - 1
mov variable[0], diffy


BogDacro Token32,"Hello World"

Result as follows:

Token32 db 11, "Hello World"
Posted on 2003-10-07 10:55:18 by Homer

Thank you very much man :)

Posted on 2003-10-07 12:59:10 by BogdanOntanu
Hi, EvilHomer2k and BogdanOntanu :)

@EvilHomer2k: Does the sample you posted first work well? I'm asking because I ran into some trouble when nesting $invoke too deeply... (although I haven't tested it with the latest MASM version, though).
Posted on 2003-10-07 17:10:36 by QvasiModo
Not to upstage anyone, but you dont need to have run-time code to fill out the size of the token. The following will evaluate your provided token strings at compile time:
TokenMacro MACRO variable:REQ, sz_arg:REQ


;; LOCAL sz1
LOCAL sz, cnt
sz = 0
FORC cnt,<sz_arg>
;; %echo cnt
sz = sz + 1
sz = sz - 2 ;; Subtract the (") 's
;; sz1 TEXTEQU %sz
;; %echo sz1
% variable BYTE sz, sz_arg, 0

I have tested this and provided my macro output routines for those who whant to learn and see what happens while compiling. Simply uncomment the double comments.

If you dont care, here it is lean and mean:
TokenMacro MACRO variable:REQ, sz_arg:REQ

LOCAL sz, cnt
sz = 0
FORC cnt,<sz_arg>
sz = sz + 1
sz = sz - 2
% variable BYTE sz, sz_arg, 0

As well, you might have noticed, I chose to align the start of the bye on DWORD boundries. You asked for a byte param, but i would personally change this to a dword in size, then the string array on the next dword alignment (just my preference tho). If you agree the change is simple, just change the "BYTE" to "DWORD" above.

The use is TokenMacro TOKEN_NAME, "La La La La La Sting..."

The generated output is:

TOKEN_NAME BYTE 24,"La La La La La String...",0

Posted on 2003-10-07 18:59:57 by NaN
By the way, your "token" is not to far from what COM uses for BSTR's:

The following code would produce a BSTR in the .data segment (one that would not require being freed by the SysFreeString API...):
DATA_BSTR MACRO variable:REQ, sz_arg:REQ

LOCAL sz, cnt, dummy
sz = 0
FORC cnt,<sz_arg>
sz = sz + 1
sz = sz - 2
% dummy DWORD sz
variable WORD sz_arg, 0

Posted on 2003-10-07 19:08:39 by NaN
Neat job, Nan.
It was late, and I couldn't remember how to evaluate expressions in macros.
Your method generates no code, only data. Good stuff !!

As far as nesting $invoke is concerned, I am aware that MASM has an absolute limit to the level of nesting in macros, but I haven't reached it because I don't try to get around the limit on line length, so a nested $invoke statement can only be as long as the namelengths of the procedures being called allows for - and I tend to use rather long and descriptive procedure names.

If I use $invoke in a nested fashion, it's only ever two or three calls deep, as BogdanOntaneu noted, it doesn't make for readable code to nest deeply anyway.

The only reason I use $invoke is because it can make for less typing and a shorter (and thus faster to debug) sourcecode.
The fact that it can be nested should not be abused.
$invoke can make your life easier or it can make it harder, its up to you to use it sensibly, like all macros, its a helper, but unlike many, it cannot bloat your executable because it simply generates the same code you would generate using the normal invoke method.
Posted on 2003-10-07 22:41:55 by Homer
Just a minor observation that NaN's version produces zeroterminators on the strings, which I deliberately avoided in mine as I thought that was a requirement.
Easy to fix.
Posted on 2003-10-07 22:56:06 by Homer