Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Embedding DarkSDK

Author
Message
MACRO
21
Years of Service
User Offline
Joined: 10th Jun 2003
Location:
Posted: 30th May 2008 15:02 Edited at: 30th May 2008 15:06
Hey,

Just a quick question...

Is it possible to embed the render output from DarkSDK into a form component in c++?

I would like to implement some tools for my game dev and would love it if I could make a wxWidgets app with a DarkSDK render window component. Does anybody know if this is possible or is the standalone render window hardcoded into the library?

I can think of two possible ways to do this easily assuming it is possible with the sdk...

1 - Supress the engine standalone window and get a handle on the render buffer then draw it to a specialised panel component.

2 - Supress the engine standalone window and render to texture every frame then draw it to a specialised panel component.

Is it possible to do either of the above?

Cheers

MACRO
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 30th May 2008 18:06
Quote: "Is it possible to embed the render output from DarkSDK into a form component in c++?"


I would think yes.

Quote: "Does anybody know if this is possible or is the standalone render window hardcoded into the library?"
Yeah its this too. I would think you'd need to get creative, or make life easier and have it in windowed mode, and ,make your "tools" external floating windows.


Quote: "1 - Supress the engine standalone window and get a handle on the render buffer then draw it to a specialised panel component."
Sounds right but I don't how easy that will be, especially if they are changing the render target based on the window's metrics.

Quote: "2 - Supress the engine standalone window and render to texture every frame then draw it to a specialised panel component.
"
You know... if you minimized the main window, and rendered to texture and used the directx style image pointer - or better the device directx surface pointer... you might be able to get to your end.

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 30th May 2008 18:21
I'm not sure what I can offer here but I'll give you what I've got so far. There's an undocumented command in the header for the image component of Dark GDK called

LPDIRECT3DTEXTURE9 dbGetImagePointer(iID);

that returns a pointer to the image data. You have to extract from there but you can get the device information from

LPDIRECT3DTEXTURE9 textData = dbGetImagePointer(iID);

IDirect3DDevice9 *device;
textData->GetDevice (&device);

which essentially loads device with a pointer to the device. From there you might be able to leverage the device into your own component. But with Dark GDK taking over winmain() you might have difficulties there. Just using the LPDIRECT3DTEXTURE value I've been able to write directly to the image surface.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Sephnroth
21
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 31st May 2008 18:27
alternitively you can use the command: dbGetDirect3DDevice() which all my d3dx extensions for the darkgdk use

further more, #include "globstruct.h" and inside there you can find the hwnd for the dgdk window inside the externed struct "g_pGlob"

specifically: g_pGlob->hWnd;

in DGDK .NET our method to throw the dgdk "screen" onto a form was to place a component on the form (img box, tab, whatever) and to override the dgdk hwnd with the hwnd of the component we want to draw to. Then simply hide the old dgdk window. This might work for you through cpp too, though i've never done it that way in cpp! Though, close

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 31st May 2008 18:41
Quote: "alternitively you can use the command: dbGetDirect3DDevice() which all my d3dx extensions for the darkgdk use"


Guess I need to look at a few other header files. What I came across derived only from what I saw in the image header.

While I have you on the line, so to speak, can you tell me if the device so derived is directly related to the device context used in the Windows API? That's always been my stumbling block when it comes to trying to draw my own controls. All references to DC have assumed that you knew the premise.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Sephnroth
21
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 31st May 2008 19:26
a little confused ;; the device the function returns is the directx device. the hWnd in the glob struct is a handle to the actual window. If you want to get a device context for that window to draw on it then:

http://msdn.microsoft.com/en-us/library/ms533241(VS.85).aspx

You can actually attach certain components, like menus, directly to the window using just the hwnd, ie:



which is an snippet from an old VC6 project. VC6 had a forms designer as standard though - the express version of vc++2k5 and 2k8 dont appear to :/

Just for curiosity, incase you havnt seen it, i've attached to this post my old tutorial for intergrating DGDK with winapi functions, your own event loop, etc. Thing is, its old and obsolete - assumes VC6 and access to the forms designer. It might be good for people with standard/pro versions of visual studio though if that has a designer that works the same way.

Attachments

Login to view attachments
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 31st May 2008 19:41
I appreciate it. I've tried to study the Win API but, not working in a programming environment, I don't have as much time as I'd like to concentrate on the learning aspect of the job and I don't have anyone to bounce questions off for immediate feedback. Forums are okay for brief interchanges but not for a detailed give and take learning experience. I've started to read and re-read books on the API but something else more immediate keeps me from plowing through it from beginning to end.

And I do have VC6 in addition to VS 2005. I'm not certain that I'm going to grab 2008 in the near future.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 31st May 2008 19:52
Quote: "the device the function returns is the directx device. the hWnd in the glob struct is a handle to the actual window"


Okay, one more thing to, hopefully, clear up my confusion. In each window, does each control have it's own device with its own surface(s ) or is the window the thing that holds the device and the control is given the position and area on the device surface in which to draw? Everything I've read provides drawing functions to draw within the device context. But I'm more inclined to use my own routines to do my own drawing directly to the pixels once I have a pointer to them and know the parameters of my drawing surface.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Sephnroth
21
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 31st May 2008 20:34
My own winapi study has always been "what i need" - i was never taught properly by anyone, just looked at what i found interesting Its also rusty - for a couple o years now i've used c# for applications and utilities (keeping c++ for engines) and in c# it doesnt matter xD

So excuse if this information isnt completely accurate but:

Each control has its own surface. Each control also has its own handle (im pretty certain on this) and so, by finding the handle (hWnd, etc) for a control you could get its device contex using GETDC I *think* and then any GDI drawing etc you do to that contex should appear on the component you are drawing on. That is something i'm *assuming* based purely off the fact that in c# each component has a "Handle" property and overwriting the dgdk hWnd with that handle causes dgdk to draw only on that component (which is funny when its a small button )

But, in contrast, controls (components) are attached to a window which is itself ANOTHER service with another potential device context. Ie, the dgdk window has a hwnd, you could create a device context from that and drawing to that DC would draw on the window itself. But the window could have a menu attached, the menu has its own handle, you could create a DC from that and then draw to that DC to restrict drawing to the menu.

I dunno if any of this information is useful to you because i'm not sure what exactally you intend to do It sounds like you want to create buttons etc and then draw on them - possiably some sort of theming engine?

Anyway, thats about all i know xD

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 31st May 2008 21:37
Quote: "I dunno if any of this information is useful to you because i'm not sure what exactally you intend to do It sounds like you want to create buttons etc and then draw on them - possibly some sort of theming engine?
"


Something like that. Without direct access to the pixel data I'm pretty limited in what I can do because all I have are the drawing tools that the API provides. I've already developed direct access to the image in DGDK (but I can't print to it with fonts) so I've got the skills for that. It's just that relating that to the Windows DC hasn't been clear up to this point.

Thanks for your input. It has help quite a bit.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 31st May 2008 23:34 Edited at: 31st May 2008 23:56
Folks, I've been doing some directx dabbling and the solution to getting directx to render on a window in DarkGDK as was described as possible "maybe" because something was done similiar with .net (did I read that right LOL) anyways...

I was just experimenting merging a DirectX demo with a plain-jane Win32 app made with a wizard, and it kept crashing... util I connected the dots. The Directx code was all about the "d3d device" and once I sent it the hwnd I was able to render perfectly.

Therefore I THINK its possible to render DarkGDK to any windows window you want with some work.

Login to post a reply

Server time is: 2024-09-29 21:26:08
Your offset time is: 2024-09-29 21:26:08