BOOL DIB::BltFast(LPDIRECTDRAWSURFACE lpsurface, int desx, int desy,
int sourcex, int sourcey, int wdth, int hght,
short Colorkey)
{
LPDIRECTDRAWSURFACE lpddSurface = CreateSurface(Colorkey);
if ( !lpddSurface )
{
OutputDebugString("Failed to create dd surface");
gapp.error = TRUE;
return FALSE;
}
RECT source = {sourcex, sourcey, sourcex+wdth, sourcey+hght};
HRESULT hr = lpsurface->BltFast(desx, desy, lpddSurface, &source,
DDBLT_WAIT |
DDBLTFAST_SRCCOLORKEY);
lpddSurface->Release();
if ( hr != DD_OK )
{
OutputDebugString("Unable to bltfast to surface");
gapp.error = TRUE;
DDBltFastDebug(hr);
return FALSE;
}
return TRUE;
}
The code was modified from the Blt version I had for the DIB class. The Blt
version works, so I am using the Blt version for now. But I had tips or
perhapes suggestions that BltFast is recommended over Blt. This BltFast
function is called by the overloaded function
BOOL DIB::BltFast(LPDIRECTDRAWSURFACE lpsurface, int desx, int desy, short
Colorkey)
{
return BltFast(lpsurface, desx, desy, 0, 0, width, height, Colorkey);
}
and the overloaded function is called within the game/program by this line
finger->BltFast(lpddSurface, 272-finger->GetWidth(), 190, 1);
In case you wonder why I have an overloaded function, it's because at times
I want to blt the whole bitmap, instead of perhapes a portion, and it looks
cleaner this way.
So does anyone know which is the Invalid Parameter?
Ooh, and by the way, besides the error, I am also seeking to improve
myself. So any advices, or comments on my programming style? Or whatever,
tell me too. Thanks.
Kent
----------------------------------------------------------------------------
----------
Email me at amar...@hotmail.com
Visit my homepage at :
http://www.geocities.com/SiliconValley/Peaks/9680
i just took a quick look at your code, but try using DBLTFAST_WAIT instead of
DDBLT_WAIT when you use BltFast.
As the other poster pointed out, this needs to be DDBLTFAST_WAIT
instead of DDBLT_WAIT. Also note that Blt can clip if a clipper is
attached to the surface, while BltFast cannot. If you have a clipper
attached to the surface lpsurface, the BltFast call will fail with the
error DDERR_UNSUPPORTED.
Matt Setzer
mse...@ix.netcom.com
Kent <amar...@hotmail.com> wrote in article
<01bd1dc1$afa8a280$a27874cb@acer>...
[snip-snip]
> Ooh, and by the way, besides the error, I am also seeking to improve
> myself. So any advices, or comments on my programming style? Or whatever,
> tell me too. Thanks.
>
Don't abbreviate variables unnecessarily, and un-standardly (I think I made
that word up :-)). Don't use one global structure for your "global app"
variables -- you're still using global variables, you're just hiding that
fact, and global variables are generally very bad. You should read the
book "Code Complete," by Steve McConnell (published by Microsoft Press).
It has helped me VERY much improve my programming. The book "Writing Solid
Code," by Steve Maguire, (same publisher) is also excellent, and has helped
me very much; I highly recommend you read both books -- maybe even more
than once (seriously!).
Another related book is "Debugging the Development Process," by Steve
Maguire. This is not so much about actual coding as -- you guessed it --
the development process, and is also *very* good. (Same publisher.)
I have some DirectDraw specific advice: write a loop for your BltFast
call, and handle DDERR_SURFACELOST. This 'error' is supposed to and does
happen, so you must handle it. (You might try writing a routine which does
a DD call for you, handling errors that can be handled, so you don't get
very similar code in Blt, Lock, GetDC, etc. etc. wrapper-methods.)
Also, I recommend not using a DirectDrawSurface wrapper class; I have
written many of these wrapper classes, and I have finally decided on a
better way:
Write a graphics subsystem (don't call it the DirectDraw subsystem -- this
goes against information hiding, and abstraction).
Have this subsystem do blts, etc. instead of a wrapper class, and have this
subsystem manage images, and have it only give the caller a *handle* to an
image, (make a type HIMAGE, for example), instead of giving the caller a
pointer to an object. (I'm not sure what you're doing, on a broader scale;
you may have your DirectDraw code in your main program -- I advise against
this.... by the time you write DirectSound, DirectInput and DirectPlay
code, there'll be no room left for the actual program!)
This, for one thing, makes it easier (and just seems better to me) to have
image caching. I have found that having objects that must communicate
between each other just generally seems wrong. OOP and OOD aren't easy to
do well, in my experience, and modular programming has worked very well for
me. I use it, and I still use classes, but not "one-instance" classes,
such as for a graphics subsystem. That applies itself better to a module
than an object, IMO.
So, most of all, I recommend *every* programmer read those three books, no
matter how accomplished or experienced. (If you're wondering what I meant
by abstraction, information hiding, and why global variables suck, Code
Complete will enlighten you. =))
--
Adam
b i k k o AT i x DOT n e t c o m DOT c o m