I would figure if it included the headers and the .lib files it would be the full SDK? I think I''m gonna give Interprise a gingle and ask what the shmuck is up with their distribution of Direct X.

a.h{text-decoration:none;color:blue;};a.h:hover{text-decoration:underline;background:red;};-=CF=-

You can also #define INITGUID (make sure this is only done once) and this should cause you compiler to generate the GUIDs for you.

-Liquid

#define INITGUID didn''t work, I still get "unresolved external error on ''DirectDrawCreateEx''" from my .obj file named after my project. Also, I cut back from ''directdraw7'' to ''directdraw'' as far as my object and surfaces go and I get an access violation, but it is when I try to create the back buffer. So I guess it would be progress.


This would be the line giving the error

dval=lpddsprimary->GetAttachedSurface(&ddsCaps,&lpddsback);
Remember that I''m now using a ''directdraw'' instead of a ''directdraw7'' object ''n'' surfaces now!

a.h{text-decoration:none;color:blue;};a.h:hover{text-decoration:underline;background:red;};-=CF=-

JwayneT,

Deanmat here...and most definitly a HE!

dxguid.lib is distributed with the DirectX 7 SDK. It is there...it is located in the \DirectX\lib\Borland sub-directory. Same goes for dinput.lib and so on. You MUST use the Borland lib files.

Next thing to check is the order of the include directory search paths...

Make sure that...

\DirectX\include is included BEFORE ANYTHING! I think Builder comes with some of the (older) DX header files. If you get the lib file specified along with the correct order of the include directories, you should get this to work.

Don't worry what SeanHowe said. While it is good advice to use DirectInputCreateEx, for some reason it doesn't work with Builder. I'm using DirectInput just fine in the manner I descirbed previously...and I'm using Builder 4.0.

If the above directions still don't help you out, let me know.

Dean M.


Edited by - deanmat on May 25, 2000 12:15:00 AM

Ok, I''ve been using Visual C++ 6 for Direct X development for just over one year now, and have long since understood all of the reasons behind ordering your search directories, adding the libs to the project, etc. BUT I have not yet got a working DirectX program in Borland C++ Builder (3,4 OR 5). I know for a fact that this is simply because I do not really understand the Borland enviroment and setup very well, I only recently found out how to make normal Windows programs (not console, not RAD) in the enviroment, but here''s the deal: I would very much like someone to give a step by step account of how to configure Borland C++ Builder 5 (or 4) to create and run a simple DirectX program, assuming that both Builder and the DirectX SDK have been installed correctly and to the default locations (to make life easier for everyone who reads it ... we can translate the paths to our own setups). Thanks in advance.

BTW i didn''t mean you need to give an actual DirectX program either ... just assume the user (me in this case) has the simplest possible DirectX program ... in a file called say "MyProgram.cpp" with perhaps a file "MyProgram.h" and that this program uses only C++ that is the same to both Visual C++ and BCB. The only reason I would expect you to delve into discussing the program itself is for issues such as that stated earlier ... like "you cannot use DirectInputCreate() with BCB ..." OR also if there is some sort of pragma, #include or anything that BCB will need to be set. Anything that is the same as what''d documented by MS, can be assumed to already be correct. Thanks again.

Well, I don''t know anything about Borland compilers/IDEs, but DirectDrawCreateEx() and DirectDrawCreate() are just "shortcut" functions that call CoCreateInstance(), because a lot of people don''t like to deal with COM (even 3 COM function calls in a typical setup). You can get the DX 7 interfaces of DirectDraw and Direct3D properly by using CoCreateInstance(). Think of Direct3D as "part" of the DirectDraw object, and QueryInterface() like a fancy method of casting pointers. (Note that isn''t technically correct, but it''s a good starting point.)

DirectDrawCreate() vs. DirectDrawCreateEx() represents a change in the "shortcut" function, not a change in the way CoCreateInstance() is called. CoCreateInstance() is a COM function, and DX is just made up of COM objects. If IDirectDraw7 is compliant to the COM standard, you should be able to use COM methods to create an object of it.

quote: Excerpt from the DX docs

You can create a DirectDraw object by using the CoCreateInstance function and the IDirectDraw7::Initialize method rather than the DirectDrawCreate function. The following steps describe how to create the DirectDraw object:

Initialize COM at the start of your application by calling CoInitialize and specifying NULL.

if (FAILED(CoInitialize(NULL)))
return FALSE;

Create the DirectDraw object by using CoCreateInstance and the IDirectDraw7::Initialize method.

ddrval = CoCreateInstance(&CLSID_DirectDraw,
NULL, CLSCTX_ALL, &IID_IDirectDraw7, &lpdd);
if(!FAILED(ddrval))
ddrval = IDirectDraw7_Initialize(lpdd, NULL);

In this call to CoCreateInstance, the first parameter, CLSID_DirectDraw, is the class identifier of the DirectDraw driver object class, the IID_IDirectDraw7 parameter identifies the particular DirectDraw interface to be created, and the lpdd parameter points to the DirectDraw object that is retrieved. If the call is successful, this function returns an uninitialized object.

Before you use the DirectDraw object, you must call IDirectDraw7::Initialize. This method takes the driver GUID parameter that the DirectDrawCreate function typically uses (NULL in this case). After the DirectDraw object is initialized, you can use and release it as if it had been created by using the DirectDrawCreate function. If you do not call the Initialize method before using one of the methods associated with the DirectDraw object, a DDERR_NOTINITIALIZED error will occur.
Before you close the application, close the COM library by using the CoUninitialize function.

CoUninitialize();

To bring up another point, I have no idea why DX was made in COM.



- null_pointer
Sabre Multimedia

DX was made in COM because Microsoft apparently believes that COM is the greatest thing since sliced bread. They''ve even stated that they plan to eventually base their entire API on COM. I''ve been learning COM lately and it''s really not bad at all.

-fel

hmm...sliced bread...I''ll have to try that...

BTW, I don''t like COM but haven''t studied it...extensively, so it''s probably newbie-dislike. I''ll think about it some more.



- null_pointer
Sabre Multimedia

Okay, this is really odd then.

I dropped to just directdraw from directdraw7 and I got DirectDrawCreate to work. Now the method to get a backbuffer(GetAttachedSurface) gave me access violations, but to me this was an improvement.

Also deanmat, I had searched all of my drives and I didn''t find dxguid.lib anywhere. That''s why I got it from Visual Studio from my college. I also found a utility that came with Borland which converts MS .lib files to Borland. It''s in the \bin directory called COFF2OMF. I ran that on the one from school and it dosn''t give me trouble anymore, but I still get that persistant linker error on DirectDrawCreateEx. I checked all of my include paths and my .lib paths, searched the Borland site for nessesary #pragma calls, and put my Direct X includes above all other ones.

It seems that Xai and null_pointer back you on CoCreateInstance. But what confuses me is I get farther down my code when I use ''DirectDrawCreate'' instead of ''CoCreateInstance'' when I am only using DirectDraw(the one where GetAttachedSurface dosn''t work).

Or possibly I''m a real jerk because I''m using the "SDK" that came with my compiler, I didn''t get one directly from Microsoft.

a.h{text-decoration:none;color:blue;};a.h:hover{text-decoration:underline;background:red;};-=CF=-