Author Topic: MSVC runtime problem  (Read 16392 times)

0 Members and 1 Guest are viewing this topic.

Offline AnimalMother

  • btst #6,$bfe001
  • Atari ST
  • ***
  • Posts: 113
  • Karma: 7
    • View Profile
Re: MSVC runtime problem
« Reply #20 on: July 08, 2008 »
For passing the parameters you should read the Win32 Programmer's Reference. I uploaded it on my webspace http://zeros.ath.cx/Downloads/Tools/win32.zip

Offline Jim

  • Founder Member
  • DBF Aficionado
  • ********
  • Posts: 5301
  • Karma: 402
    • View Profile
Re: MSVC runtime problem
« Reply #21 on: July 08, 2008 »
You push the params on the stack in reverse order in Win32
Code: [Select]
mov eax,size
push eax
push 0  ; GMEM_FIXED = 0
call GlobalAlloc

Jim
Challenge Trophies Won:

Offline Naptha

  • C= 64
  • **
  • Posts: 53
  • Karma: 3
    • View Profile
Re: MSVC runtime problem
« Reply #22 on: July 10, 2008 »
You push the params on the stack in reverse order in Win32
Code: [Select]
mov eax,size
push eax
push 0  ; GMEM_FIXED = 0
call GlobalAlloc

Jim

Just what I was looking for, thanks. :)

Crinkler ran quite happily with the above, but the program crashed with 'memory could not be read' error.  A couple of false starts and visits to MSDN (could their docs be more ambiguous?) and I guessed that maybe a call to GlobalLock was needed, even if GlobalAlloc specifies a fixed memory block; GlobalAlloc apparently doesn't return a pointer like HeapAlloc does, but a handle... if you specify GMEM_FIXED, then GlobalLock does nothing but return a pointer to the first address in the block referred to by the handle.  ??? ::)

Code: [Select]
; Dynamic memory allocation
alloc:
; EAX: how many bytes to allocate
push eax
push 0x0040 ; GPTR
call GlobalAlloc
push eax
call GlobalLock
test eax,eax
jnz alloc_R
pop edx ; EIP
pop ebx
leave
alloc_R:
ret

I am really happy that this is working, I've dabbled with assembly before but never really understood it, this has helped a lot.  O0

Having checked the uFMOD site there doesn't appear to be any restriction on modifying or distributing it, so I've attached the modified object file here, along with a spinny cube. :)  Haven't got around to thinking about embedding the image and music in the exe yet, and it's still a bit large for what it is, but I'm not that worried about size on my first effort.

I think I've already credited most people, but anyway:
Frank D. Luna's "Introduction to 3D Game Programming"
directxtutorial.com
Unknown Author of the song (one that was lying around on my hd, believe it is titled "Rose")
Asterix and Quantum for uFMOD
Everyone here for all their help. :D

Oh, and this ufmod is for win32 using winmm.
« Last Edit: July 10, 2008 by Naptha »

Offline Jim

  • Founder Member
  • DBF Aficionado
  • ********
  • Posts: 5301
  • Karma: 402
    • View Profile
Re: MSVC runtime problem
« Reply #23 on: July 10, 2008 »
If you use GMEM_FIXED it returns a pointer directly, not a handle, so I'm a bit confused as to why you had to use GlobalLock.  ???
If you're size coding, you can remove the null (test/jnz) check too :)

Good job getting it working!

Jim
Challenge Trophies Won:

Offline Clyde

  • A Little Fuzzy Wuzzy
  • DBF Aficionado
  • ******
  • Posts: 7271
  • Karma: 71
    • View Profile
Re: MSVC runtime problem
« Reply #24 on: July 10, 2008 »
Welldone on your efforts dude, looks cool too.
Still Putting The IT Into Gravy
If Only I Knew Then What I Know Now.

Challenge Trophies Won:

Offline Naptha

  • C= 64
  • **
  • Posts: 53
  • Karma: 3
    • View Profile
Re: MSVC runtime problem
« Reply #25 on: July 11, 2008 »
If you use GMEM_FIXED it returns a pointer directly, not a handle, so I'm a bit confused as to why you had to use GlobalLock.  ???


Me too.  :D  MSDN says:

Quote
GMEM_FIXED : Allocates fixed memory. The return value is a pointer.

However, it didn't work, while getting a pointer from GlobalLock did. ???

Welldone on your efforts dude, looks cool too.

Thanks, I will be expanding it further, tidying it up, and generally trying to learn more as I go, however I will refrain from bugging you all further (for the time being). ;)