Hi all,
I've been experimenting with Ddraw in windowed mode and so far heres what I've come up with...
It's a simple program which creates a window with a 640x480 client area. It uses the desktop color depth.
The functions of most interest are probably the Bitmapdrawwindowed and Bitmapfileload2 functions... I'm especially proud of Bitmapfileload2 it uses windows functions to load the bitmap and in doing so saves me from having to convert the 24bit bmp to either 16 or 32 bits...alot less work==a lot less bugs!
I've not implemented the 8bit section so don't use it with 8 bit or less bitmaps...

Since windows does the conversion of the bitmap the 16 bit mode should work for 565 or 555 video cards, both my computers are 565 so I'm not able to verify this...
If you try it, test it in both 32 and 16 bit modes and let me know the result..
there's still some issues to be covered but i think this will serve it's perpous...

the attachment is a rar archive so just remove the .zip extension.

{edit}
replace the section which does transparent drawing with this, it will remove the "mysterious" line under the eagle...
also to compile the code I've attached another file in a post below


;copy one pixel at a time checking for transparency
sub _nBytes,4
next_line:;can unroll
mov ecx,_nBytes
next_dword:
mov eax,dword ptr [esi+ecx]
cmp eax,_TransColor
je @f
mov dword ptr[edi+ecx],eax
@@:
sub ecx,4
jge next_dword
add esi,_dwWidth
add edi,_dwLPitch
dec ebx ;<-can restructure to eliminate this
jg next_line
Posted on 2002-09-14 18:15:48 by MArtial_Code
Here is a picture of what it looks like on windows XP. Doesn't appear to fit in the window correctly?
Posted on 2002-09-15 01:06:56 by bitRAKE
Thanks. My first Win32asm project was The same thing. But that code is old now, and I kinda broke it, don't have the time to fix it again(better to rewrite it less messy).

I'll be interested in looking at your added funtionality.
Posted on 2002-09-15 02:27:14 by ThoughtCriminal
I have a question about stuff like this:


DXINVOKE (pIDDC[lpDDClipper]).Release


I can't find where the DXINVOKE macro is defined.

Are you just using the basic interface or DX5 or DX7? I have not been able to figure out the DX inerface stuff yet.

Thanks.
Posted on 2002-09-15 06:35:16 by ThoughtCriminal
Here's an attachment which has everything you need to compile/link the example.
Note the DXINVOKE macro modifies edx before the parameters are pushed on the stack so you won't be able to send paramemters via edx with DXINVOKE. Originally it was eax but that interfered with masm's addr directive.

Also in the code there are PT PD PH PSBA macro calls...these are simply equates for vKims debug macros
Printtext,PrintDec,PrintHex,PrintStringByAddr...powerful tools inconjunction with RadASM.

BitRake thganks for testing...it does look as if the title bar is been over drawn...that's strange because the starting coords for the blitting is 0,0 in the client area...is there a way to make the window look like a W2k window...if so can you try it and see if the problem persists? cheers...
Posted on 2002-09-15 07:16:23 by MArtial_Code

...it does look as if the title bar is been over drawn...that's strange because the starting coords for the blitting is 0,0 in the client area...is there a way to make the window look like a W2k window...if so can you try it and see if the problem persists? cheers...


Hi, I tested it as well.
While my Windows XP looks like normal Windows, your programs looks fine (except for that mysterious line under the eagle). However, when activating Teletubby XP (the "fancy" design) you see the effect, bitrake has just shown with his snapshot.

Greets YaWNS
Posted on 2002-09-15 07:43:17 by YaWNS
Hey Martial Code, the program crashes on my machine (Win2K/NoSP) DX 8.1
--------------------------------------------------------

The instruction at "0x00401957" referenced memory at "0x001430A0". The memory could not be "read"
----------------------------------------------------------------------------

Heres the code MSVC++ debugger gives me:



shl dword ptr [ebp-18h],1
0040193B jmp 0040194E
0040193D cmp dword ptr ds:[4051B0h],20h
00401944 jne 0040194E
00401946 shl dword ptr [ebp-14h],2
0040194A shl dword ptr [ebp-18h],2
0040194E cmp dword ptr [ebp+14h],0
00401952 je 00401975
00401954 mov ecx,dword ptr [ebp-18h]
00401957 mov eax,dword ptr [ecx+esi]
0040195A cmp eax,dword ptr [ebp-1Ch]
0040195D je 00401962
0040195F mov dword ptr [ecx+edi],eax
00401962 sub ecx,4


May I have permission to debug the program and investigate further?
Posted on 2002-09-15 13:05:37 by x86asm
My system is win2k sp2 dx8.1 and it runs fine...
by all means debug away....It looks like the part which does the transparency...here's the routine...I've fixed it so it drawsa the transparent bit properly...clipping to the left doesnt work though...
BitmapDrawWindowed proc uses ebx esi edi,_lpSrcBitmap:dword,_lpDstBuffer:dword,_dwLPitch:dword,_dwTransparent:dword,_dwWrap:dword

;this function draws the bitmap onto the destination memory surface
;if transparent is 1 then color 0 will be transparent
;This function is for static elements
;Bitmaps are always clipped at the surface extents.

LOCAL _lpDst:dword ;starting address of bitmap in destination
LOCAL _lpSrc:dword ;starting adddress of bitmap data in source
LOCAL _Pixel:byte ;used to hold pixel value
LOCAL _Index:dword ;looping vars
LOCAL _dwWidth:dword
LOCAL _dwHeight:dword
LOCAL _nBytes:dword
LOCAL _TransColor:dword
;test if this bitmap is loaded
mov ebx,_lpSrcBitmap
mov eax,(BITMAPIMAGE ptr[ebx]).Attr

.if (eax & BITMAPATTRLOADED)
mov esi,(BITMAPIMAGE ptr[ebx]).lpImage
mov eax,dword ptr [esi]
mov _TransColor,eax ;get the transparent color

mov edi,(BITMAPIMAGE ptr[ebx]).X
;test if clipping needed in X direction
mov eax,(BITMAPIMAGE ptr[ebx]).dwWidth
mov _dwWidth,eax
mov ecx,eax
add ecx,edi ;ecx==width + Xposition

.if _dwWrap&CLIPX
.if sdword ptr ecx >ClientRect.right ;clip on the right side
sub ecx,ClientRect.right ;
dec ecx ;really mean ClientRect.right+1
sub eax,ecx ;set number pixels
.elseif sdword ptr edi<0 ;clip on the left side
mov ecx,edi
neg ecx
sub eax,ecx ;eax==width - Xposition
mov edi,eax ;
.if ScreenBPP ==16
shl ecx,1
.elseif ScreenBPP==32
shl ecx,2
.endif
add esi,ecx
.endif
.endif

mov _nBytes,eax
mov eax,(BITMAPIMAGE ptr[ebx]).Y
mul _dwLPitch

mov ecx,ScreenBPP
shr ecx,4
shl edi,cl
add eax,edi

add eax,_lpDstBuffer
mov edi,eax;

mov eax,(BITMAPIMAGE ptr[ebx]).Y
mov ecx,eax
mov ebx,(BITMAPIMAGE ptr[ebx]).dwHeight
mov _dwHeight,ebx
add ecx,ebx

.if ecx >ClientRect.bottom ;clip at the bottom
sub ecx,ClientRect.bottom
sub ebx,ecx ;clip in Y direcion
.endif ;end of clip test in Y direction

.if ScreenBPP ==16
shl _dwWidth,1
shl _nBytes,1 ;convert number of pixels to bytes
.elseif ScreenBPP==32
shl _dwWidth,2
shl _nBytes,2 ;convert number of pixels to bytes
.endif

.if(_dwTransparent)
;copy one pixel at a time checking for transparency
sub _nBytes,4
next_line:;can unroll
mov ecx,_nBytes
next_dword:
mov eax,dword ptr [esi+ecx]
cmp eax,_TransColor
je @f
mov dword ptr[edi+ecx],eax
@@:
sub ecx,4
jge next_dword
add esi,_dwWidth
add edi,_dwLPitch
dec ebx ;<-can restructure to eliminate this
jg next_line
.else
;copy each line of bitmap into destination without transparency
copy_line:
invoke MemCopy,esi,edi,_nBytes
add esi,_dwWidth
add edi,_dwLPitch
dec ebx
jg copy_line
.endif
.endif
ret
BitmapDrawWindowed endp
Posted on 2002-09-15 13:13:56 by MArtial_Code
Hi! Martial:)
The frame of the window appears then disappears.
No error message
Win95 PII266 DirectX8.a
Friendly........Gges
Posted on 2002-09-15 13:16:41 by Asmgges
Here is the last/latest version of this project. Once I've finished convering the other functions I'll post some real windowed mode games.

I've rewritten/cleaned up the functions. The 16/32 bit version of the functions have been replaced by one generic function by using a simple method of correcting for color depth.

I suspect the WinXP problem is still present. There must be another system constant to GetSystemMetrics for when XP is in "Teletubby" mode...does anyone know what it is... Bitrake /Yawns perhaps

Asmgges: I haven't got win95 but feel free to mess with the code and see if you find the problem
x86asm:get atleast SP2:tongue: have you found the problem!
ThoughtCriminal: did you get the code to compile?

Thanks all...
Posted on 2002-09-17 11:56:58 by MArtial_Code
You know whats weird, your program works when I step thru initialization with OllyDB and then press "F9" to enable the processor to go at it full speed. I think I will get SP2! hehe :D
Posted on 2002-09-17 15:01:23 by x86asm
here it how it looks on WinNT4 SP6
Posted on 2002-09-18 01:00:35 by TBD
Do i have to create BackBuffer separatelly while windowed mode like you did in your prog. ???? Or can i do it as an attached backbuffer to primary surface ??
Posted on 2003-09-03 13:49:11 by AceEmbler
You HAVE to create it separated while using windowed mode because you can not use ::Flip method here just the ::Blt. and in 2D attached surfaces are used just for flip chains

And TBD that really looks like an pitch standard problem :) maybe combined with a 5:6:5 / 5:5:5 16 bits problem
Posted on 2003-09-03 16:07:12 by BogdanOntanu
Thx BogdanO.... How can i know such a things ?? You have learnt DirectX from books or using internet only ??


BTW. Look this conversation started almos after a year since TBD last post here ;)
Posted on 2003-09-03 16:39:29 by AceEmbler
A little information on the mysterious crashes in D3D and why they don't occur under Olly:
Firstly, there may not be anything wrong with your code or the way you do things.
The problem may be what you are NOT doing, ie, checking that the device is ready before rending to it. The reason that it works under Olly is that the crash is causing a minor exception which Olly is handling and your program has only the very basic exception handler that always gets generated in your binaries by default.
This minor exception is MEANT to be caught and handled by debuggers, and I'd wager you are using d3dx8d.dll which is the debug version of the dll.
Nonetheless these exceptions are generated if you do silly things with the retail version of the dll as well, and learning to code a simplistic exception handler that at least catches the crash and gives you feedback (or at most totally handles the crash and resumes execution from a safe point) would be well worth your time.
Likewise would a study of something like Donuts3D.cpp which shows how to detect when you lose your device or when it's simply not ready for rending, and how to handle these conditions (ya meant to reload ALL DX RESOURCES which stinks imho)

I'm thinking about writing a tutorial on not the math but the practical use of matrix transforms including hierarchical transforms if there's enough interest in the topic.
Posted on 2003-09-04 01:47:55 by Homer