Yet another DDraw Question

[Agathron]

Alright so here's the problem...

I am trying to plot some pixels (and i'm completely new at this) using direct draw. I create the surface, have locked it and have the pitch and pointer to the surface. I defined a function plotPixel32 in a separate file uColor.cpp, with header uColor.h and have the uColor as an include in my main.cpp. When I try to call plotPixel32, i get the following error

main.obj : error LNK2001: unresolved external symbol "void __cdecl PlotPixel32(int,int,unsigned int,unsigned int *,int)" (?PlotPixel32@@YAXHHIPAIH@Z)


I figured that there was something wrong with the way i'm including it or anything. Any ideas?

[!shira!]

tr getting rid of the header file and declaring the function as an extern ...(rest of definition)

It might work

[DarkAvenger]

That's a familiar error whenever I inline my pixel plotting functions, so are you declaring the functions as inline? If so, make sure you are using the correct technique (it gets a little confusing when using multiple files).

[!shira!]

Originally posted by DarkAvenger
That's a familiar error whenever I inline my pixel plotting functions, so are you declaring the functions as inline? If so, make sure you are using the correct technique (it gets a little confusing when using multiple files).

read about inline a while ago and sorta forgot about it
what is the point of inline and how do you do it correctly (so I don't make this mistake)

[DarkAvenger]

Well, 'inline' basically tells the compiler to substitute the function call with the function code in order to reduce overhead. Pixel plotting functions are usually one line functions, so they are inlined so that when they are used, there is no overhead of the function call, especially considering that arguments are used. The downside is larger code size (though not that much larger).

As for using inline, try this MSDN link.

[!shira!]

thank you much

you are a big help around here

[Agathron]

Awesome thanks. The function was inline. Is it worth putting such functions in different files or should i just stick 'em in the main and be done with it?

[DarkAvenger]

Well, it is good to break up your project into multiple files, especially in large projects, because it becomes easy to manage and compile. Just put the function prototypes in 'graphics.h' and type out their declarations in 'graphics.cpp' (or whatever filename).

Think of it this way: you change one line in a function, and the function is in the main file. That means you'll have to recompile the *whole* main file, which contains all your other functions as well. Do this a few times and you'll get irritated. But if you've got it in a separate file, then your compiler will recompile only that file, and leave the other files alone; naturally, this is quite a timesaver.

Granted, in such a case it wouldn't be *that* bad to have the pixel plotting functions in the main file, assuming that's all the program has, but I think it's good to get into the habit of splitting up your files.

[Agathron]

Thanks again. If breaking it up, is it worth putting it all the direct draw coding and stuff into it's own class? I've programmed in java and am trying to make the jump to visual c++ so i am somewhat familiar with classes. Would having it within a class make it easier?

Oh and out of curiosity, what happens if one names a file say windows.h and windows.cpp. Would it include the real windows.h or the one I edited. (note: while i am definitely capable of doing something like this, fear not, i wouldn't do it with windows.h

[DarkAvenger]

Yes, making a DirectDraw class is a good idea. You can later make this class into a library and then use it in all your other programs. Very useful!

As for the windows.h/cpp thing, if you say '#include <windows.h>'
the compiler will only search in the include directories for the header, so it will find the actual header.

If you type '#include "windows.h"'then it will look in the current directory and therefore use the 'fake' header.

And if you were to include your directory in the include directories list, and then type '#include <windows.h>', then it would use the header located in the first matching directory in the list.

And I too doubt you'll do it for windows.h .

[Agathron]

Thanks again man. Hey, just noticed you were in india. You indian or just visiting? I'm indian but am in china atm.

[DarkAvenger]

Yes, I'm Indian also .

[Agathron]

coolness. Well bhayia i have yet another question for you. What's the overhead on a switch command? I figure instead of writing three different methods to draw on each of the surfaces to just write one and have it switch on a param that would let it know which surface to write to. Is this going to cause huge slowdowns and would it be worth my while writing a separate function for each surface? Also when working with a DC one has to initialise it, do whatever and release it each time right? thanks again, sorry to keep picking your brain.

[DarkAvenger]

If I understood your question right, I think the easiest method is just to pass the surface which you want to use as an argument (by reference). So it would be something like this:

void LoadBitmap (LPDIRECTDRAWSURFACE7 &lpddSurface)
{
// Replace 'lpddsBack', 'lpddsPrimary' with lpddSurface
// e.g. lpddSurface->GetDC(hDC);
}

LoadBitmap (lpddsBack); // Loads bitmap in the back buffer
LoadBitmap (lpddsPrimary); // Loads bitmap in the primary surface

I rather like this method, it's quite clean.

As for the DC, AFAIK you need only get it once, do whatever you want, and then release it at the end of your program, not each time you use it.

[Agathron]

so you can do your flipping and all that good stuff with a DC still active? Also, when you flip, does what's on the primary surface get flipped to the back buffer? ie. can i pop up a screen from the back buffer and then return to where i was on the primary? Thanks for that code, makes life a lot easier!