I seem to be unable to create a dibsection using a handle from createfilemapping. My intent is to decompress a raw graphics file, directly draw a portion of it to a DC bitmap, and then display it. If I replace hMapBmap with 0, then it returns a handle but as I understand it, I would be unable to directly draw into the system allocated memory.

Any suggestions would be greatly appreciated thanks.

invoke CreateFileMapping,\

mov hMapBmap,eax
.if eax==0
Invoke MessageBox, NULL,ADDR szCreateBitMapFileMap_Error, Offset szAppName,MB_OK

invoke CreateCompatibleDC,0
mov hBmapDC,eax

invoke CreateDIBSection,\
OFFSET lplpBmpBits,\

mov hDIBSect,eax
.if eax==0
Invoke GetLastError
Invoke MessageBox, NULL,ADDR szCreateDIBSect_Error, Offset szAppName,MB_OK
Posted on 2004-03-26 20:38:32 by sceptor
No file mapping object is needed unless you have a reason to require one. You should be able to access the memory pointed to by lplpBmpBits. If the pointer is invalid, then something must have gone wrong.
Posted on 2004-03-27 06:33:47 by Sephiroth3
I have found that the return value from CreateDIBSection can be unreliable under some circumstances. At least TBPaint crashed alot before I stopped using the ppvBits value returned by it. You should get the pointer from GetObject, the file mapping is not necessary.



invoke GetObject, [hBmp], SIZEOF DIBSECTION, ADDR sbmp
mov eax, [sbmp.dsBm.bmBits]
mov [pDIBits], eax
Posted on 2004-03-28 15:06:26 by donkey
Hmm, ppvBits unreliable? I haven't had problems with 32bpp as long as I filled out the bitmap info header stuff correctly - but ok, I've only messed with 32bpp dib sections, and only 2k and 98.
Posted on 2004-03-28 15:16:57 by f0dder

Hmm, ppvBits unreliable? I haven't had problems with 32bpp as long as I filled out the bitmap info header stuff correctly - but ok, I've only messed with 32bpp dib sections, and only 2k and 98.

I can't remember the exact sequence of events that lead me to determine that my problems were with ppvBits, but I do know that there were circumstances where it crashed TBPaint and the value returned from GetObject was different than the one passed in ppvBits. I would have to dig out my notes to find out why I had to change the code but it definitely had to be changed for Get/SetPixelFast, FloodFillFast and LineToFast (direct to bitmap functions to replace the slow GDI ones). I especially remember this because I was a bit mad that I still had to make an API call in order to keep it from crashing. This is my DIB creation proc :

CreateIndependantBitmap proc hDC:DWORD,SizeX:DWORD,SizeY:DWORD,ppvBits:DWORD


mov bmi.bmiHeader.biSize,SIZEOF BITMAPINFOHEADER
mov eax,SizeX
mov bmi.bmiHeader.biWidth,eax
mov eax,SizeY
mov bmi.bmiHeader.biHeight,eax
mov bmi.bmiHeader.biPlanes,1
mov bmi.bmiHeader.biBitCount,32
mov bmi.bmiHeader.biCompression,BI_RGB
invoke CreateDIBSection,hDC,ADDR bmi,DIB_RGB_COLORS,ppvBits,NULL,NULL

push eax
; Ensure synchonization of access
invoke GdiFlush
pop eax

CreateIndependantBitmap endp
Posted on 2004-03-28 16:27:30 by donkey
I would be happy if you would care to dig out your notes, I'm starting to dabble a bit with GDI now, and it would be nice to know if it's a 100% necessary thing to do this, or if there's some other fix that can be applied.
Posted on 2004-03-29 00:28:16 by f0dder
I will look tomorrow after work.
Posted on 2004-03-29 00:36:40 by donkey
Thank you plenty, donkey :)
Posted on 2004-03-29 02:40:41 by f0dder
I will look tomorrow after work

I'll look forward too, because I'm using CreateDibSection for exactly your reasons and it works flawlessly on every system starting from Win95, ppvBits always have correct value 8-0
Posted on 2004-03-29 04:50:34 by masquer
Hi Guys,

I looked through my notes and the problem for me was actually fairly benign. The value returned when I created the bitmap was fine but not necessarily the value that was there when I actually drew to the image. There was a possiblity that the image I was editing could be different from the main image, for example it could have been swapped out for any number of reasons. It could also be a temporary DDB bitmap as in the text paste function, where the bitmap is created solely to paste the text then destroyed. So I needed to get the actual image in the DC and then find the ppvBits from that. Sorry about that, my comments weren't clear and my memory was cloudy on it.
Posted on 2004-03-29 08:41:09 by donkey
No problem donkey, glad stuff is resolved and that it sounds like there's no worries wrt. using ppvBits :)
Posted on 2004-03-29 08:44:33 by f0dder
Oh, but you have to use GdiFlush after you call drawing functions. Otherwise the changes might not show up right away.
Posted on 2004-03-29 11:55:22 by Sephiroth3
Well, I never did get the mapped version of createdib working so I tossed the towell on it.

The regular createdibsection works fine with one thing to note. When you fill out the bmapinfoheader structure, take note that the sign of the height affects the bitmapbits pointer returned to you.

If you use a negative height, the bitmapbits pointer is returned pointing to the beginning of the dibsection. If you use a positive height, the bitmapbits pointer is returned pointing to the end of the dibsection. After a few nervewrcking gpf's I realized I was moving my bitmap into unallocated memory because I had used a positive height. I assumed the bitmapbits pointer always pointed to the beginning of the section.

So now once I get it tweaked in fully, I will port it to directx. The graphic file decompresses to 250Mbytes, and bitblt is a slow boat to china.
Posted on 2004-04-01 12:22:03 by sceptor
Hrm, "points to the end" with a non-negative height? I thought it was a bottom-up bitmap, but that the pointer returned was still to the start of the buffer?!

250MB uncompressed? Christ, you shouldn't use regular bitmap structures or API calls for this, then :) - especially not if you want to run on 9x.
Posted on 2004-04-01 12:27:30 by f0dder
I guess they assumed everyone would know to decrement the pointer as they do for "bottom-up" bmaps. I didnt though.

Actually I am not using true bitmaps. I am decompressing a 4 bit/pixel run length encoded file into an 24bit/ pixel RGB array, and displaying it. However I only show a 800x600 view of it at a time. Most of the time I will be just panning around in it. I suspect I will have to port it over to directx to get it to run faster though.
Posted on 2004-04-01 16:03:47 by sceptor
A negative height changes the origin of the bitmap. A bitmap is normally drawn from the bottom left pixel instead of the top left, normal bitmaps are bottom-up, a negative height will produce a top-down bitmap. The memory still follows the same format but you are reversing the scan lines (not the pixels). The major difference is that you cannot use any compression (ie RLL) on a top-down bitmap.
Posted on 2004-04-01 16:10:17 by donkey

I guess they assumed everyone would know to decrement the pointer as they do for "bottom-up" bmaps. I didnt though.

Sounds pretty weird - I could've sworn it wasn't like that, but my memory sucks. Guess I'll have to play around a bit again :)

You approach doesn't sound too bad since you're not decompressing directly to BITMAP stuff, although there's probably an amount of ways to optimize it. Especially if you have control of the file format, so you can design it in a way that doesn't have to be 100% decompressed at once :)
Posted on 2004-04-01 16:15:25 by f0dder
here's how I found the pointer was pointed at the end of the dibsection.

Make a window at 1024x800, then create a dibsection at 640 x 480, select it and all that.

Draw about 30 or so lines of image in the section, and increase the pointer as you draw. Then blit it to the windows hDC, you will see it starting at 480 and extending below from there.

make a new dibsection of 640 x -480, and do the same thing. (increasing the pointer as you fill it). It will start at the top of the window and extend down.

It sure stumped me until I made the window larger than the dibsection so I could see where it was blitting to.
Posted on 2004-04-01 16:33:19 by sceptor