OK, I got some sleep now ^^'

So, as Synfire said, COORD made of 2 words. And they're supposed to be passed by value, not by pointer. I gues they're supposed to be pushed as 2 dwords (like 2 parameters), and that's probably why masm defines them as 2 dwords.

So try pushing 2 dword values instead of 1 COORD value.
Posted on 2008-04-14 02:55:08 by ti_mo_n
cHome should be a dword value - low word x, high word y.

    include \masm32\include\masm32rt.inc
   
    .data?
    hStdOut dd ?
    nConsoleSize dd ?
    nCharsWritten dd ?

    .data
    cHome COORD <0,0>
   
    .code
start:
    ;the next line gets the error
    invoke FillConsoleOutputCharacter,hStdOut,' ',nConsoleSize,cHome,offset nCharsWritten
    ;the next line works OK
    invoke FillConsoleOutputCharacter,hStdOut,' ',nConsoleSize,DWORD PTR cHome,offset nCharsWritten
    exit
end start

cHome sounds like (cursor 0,0) so you can replace "DWORD PTR cHome" with "0"
Posted on 2008-04-14 04:29:39 by sinsi
The default definition for the COORD structure in windows.inc is:

COORD STRUCT
  x  WORD      ?
  y  WORD      ?
COORD ENDS

I sorta assume it would push this as a DWORD, so I don't get why it's complaining. If you passed the struct as a single DWORD value, you'd have the whole thing without any extra padding or anything. all the documentation I've seen would seem to suggest that (since passing each word as a DWORD is kinda stupid).

I tried using the invoke statement with simply replacing cHome with eax,ebx (each holding cHome.x and cHome.y respectively), and got a "Too many arguments" error.

Tried manually calling, and it looked good, except I got an exception when I called the first function. The exception was ERROR_INVALID_ACCESS (0000000C).

Part of my problem is that I have to multiply the X and Y values to find out how big the console buffer is, so I can tell it how many characters to write to the screen, and somewhere in my code (I'm not sure yet, I haven't completely traced down the problem) it's multiplying 2 values I don't think it should be, and going to a piece of code that I don't think it should be. I don't think the buffer is big enough to cause my multiplication to have overflow in EDX (it's multiplying EAX and EBX, which contain the screen size information as X and Y coordinate values), but it is. I'm gonna have to spend some more time debugging this.

Anyway, I think that manually calling them and pushing the X and Y coords as individual DWORDs seemed to work, I've just got that pesky unintentional overflow to deal with. (which caused that exception later, because it skipped over some essential code for the next call to work properly.)

FAKE_EDIT:

Well, pushing it as 2 DWORDS seemed to work fine when I run through it in OllyDBG (that exception seems to have nothing to do with this issue, lol).

I can always try that DWORD PTR syntax if I find out later that it doesn't work after all, and this exception is masking the true problem.
Posted on 2008-04-14 05:11:33 by Bobbias
Winapi functions are STDCALL. You should be able to tell how many parameters are required by watching how the function adjusts the ESP register. Push, like, 15 NULL dwords and make a call to this function. The function will most probably return with some error (due to the parameters being all 0s), but it WILL adjust the stack the way it thinks it's supposed to be adjusted. If you know how many parameters are required (every parameter is a 32-bit dword, after all), then it'll be obvious whether the call requires 1 or 2 dwords to pass the COORD structure by value.
Posted on 2008-04-14 17:33:16 by ti_mo_n
The correct struct translation is :
COORD	struct 
X SWORD ?
Y SWORD ?
COORD ends

Notice the uppercase members and SIGNED WORDS.

I'm using japheth includes which are better than masm32 (see : http://www.japheth.de/win32inc.html  for the correct sdk translated headers)

here are my functions for use with win32inc
ConsoleGoto proc stdcall coordX:sdword,coordY:sdword
LOCAL hStdOut:DWORD, co:COORD
invoke GetStdHandle,STD_OUTPUT_HANDLE
mov hStdOut,eax
mov eax,coordX
mov edx,coordY
mov co.X,ax;; change to "x" if using masm32
mov co.Y,dx;; change to "y" if using masm32
;; change to "dword ptr co" if using masm32
invoke SetConsoleCursorPosition,hStdOut,co
ret
ConsoleGoto endp

ConsoleClear proc stdcall
LOCAL nbrw:DWORD,hStdOut:DWORD,csbi:CONSOLE_SCREEN_BUFFER_INFO, co:COORD
invoke GetStdHandle,STD_OUTPUT_HANDLE
mov hStdOut,eax
invoke GetConsoleScreenBufferInfo,hStdOut,addr csbi
movzx eax,csbi.dwSize.X
movzx ecx,csbi.dwSize.Y
imul eax,ecx
lea edx,nbrw
push eax
xor ecx,ecx
mov dword ptr co,ecx
invoke FillConsoleOutputCharacter,hStdOut,' ',eax,co,edx
movzx edx,csbi.wAttributes
pop ecx
;; change to "dword ptr co" if using masm32
invoke FillConsoleOutputAttribute,hStdOut,dx,ecx,co,addr nbrw
invoke ConsoleGoto,0,0
ret
ConsoleClear endp


ps: did you guys know that japheth is making masm compatible assembler? yay  :D
http://www.japheth.de/JWasm.html
Posted on 2008-04-15 04:00:06 by drizz

ps: did you guys know that japheth is making masm compatible assembler? yay  :D
http://www.japheth.de/JWasm.html


Can't think of anyone more qualified to do that. :thumbsup:
Posted on 2008-04-15 07:40:22 by JimmyClif
Hope he fixes all the bugs and shortcomings then :P - and perhaps spices the stuff up a bit.
Posted on 2008-04-15 07:59:36 by f0dder
Lol, I think I can say that this thread has been officially derailed.

In any case, I'll post an update whenever I get around to fixing my code and figuring out what's going on.

I'm just coding a couple hours every now and again when I feel like it, so this is going to be a rather slow moving project for now. I think I have more stuff typed about what I'm planning on doing with this game than I have lines of code written, lol.

It doesn't help that for the 2 years or so I've been away, I haven't touched ASM at all (or pretty much any other language for that matter.)
Posted on 2008-04-15 12:05:30 by Bobbias