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.

DarkBASIC Discussion / DarkGDK + DBC integration

Author
Message
BN2 Productions
15
Years of Service
User Offline
Joined: 22nd Jan 2004
Location:
Posted: 23rd Dec 2012 03:48
I figured I'd ask here first, since anyone with GDK probably hasn't done much with DBC.

Since dll's can be written in C++ and DarkGDK is basically a DarkBASIC library for C++, I was wondering if you could write a dll in C++ using DarkGDK and perform function calls via DBC's in place dll commands.

The idea here would be that expansions could be made in DarkGDK for DBC (such as making a GUI toolkit and other things). Of course, this is only a viable option if DarkGDK can interact with DBC programs (so if I were to have a GDK function that moved a sprite, would I be able to call that function from a dll call and have it move a sprite in my DBC program?).

Does anyone know if the two can be linked like this? Or would the dll essentially be in its own world?

Great Quote:
"Time...LINE??? Time isn't made out of lines...it is made out of circles. That is why clocks are round!" -Caboose
Fluffy Rabbit
User Banned
Posted: 23rd Dec 2012 06:23
@BN2-

There is absolutely no reason why this can't be done, although you have to understand that DarkBASIC's built-in rendering functionality is half of the appeal of the language. If you were to use a DLL that essentially wraps DGDK's functionality, you would have to throw out whatever functionality of DarkBASIC's it's replacing. For example, if you want to use DGDK's shaders, you couldn't use DarkBASIC's built-in 3D commands. If you were to use DGDK's sprite commands, you probably couldn't use DarkBASIC's sprite commands either. This is because DirectX and OpenGL require a rendering context (a window, fullscreen or otherwise). Sure, you could point DGDK to the DarkBASIC window, but then you couldn't use DarkBASIC's built-in 3D rendering at the same time in the same view. You might be able to do it splitscreen, but bottom line, you couldn't fancy up DarkBASIC's 3D by using a DGDK library. You'd be better off using that functionality in a language that doesn't already have it, like FreeBASIC or just plain C.

Disclaimer: I don't 100% know any of this for sure.
BN2 Productions
15
Years of Service
User Offline
Joined: 22nd Jan 2004
Location:
Posted: 23rd Dec 2012 07:39
Quote: "because DirectX and OpenGL require a rendering context "


Does GDK use OpenGL? The website seemed to imply that it used DirectX.

Regardless, I was mostly looking into taking advantage of dynamic memory capabilities. Perhaps look into either a GUI toolset or whatever else might come in handy. I figure it'll be a nice trick to hold in my back pocket.

Great Quote:
"Time...LINE??? Time isn't made out of lines...it is made out of circles. That is why clocks are round!" -Caboose
Fluffy Rabbit
User Banned
Posted: 23rd Dec 2012 09:10
@BN2-

Yeah, I think DGDK uses DirectX, but OpenGL works in the same way so it was worth a mention.

I don't know what kind of dynamic memory capabilities you're talking about. Integrating a Windows GUI with DarkBASIC might work (it has been proven to work with DB Pro), but you don't need DGDK for that.

Now, don't get me started on nice tricks to hold in my back pocket. DarkGDK has some awesome rendering capabilities that I would want to fully take advantage of. If there is any reason to integrate DGDK with DBC, that is the reason.
BN2 Productions
15
Years of Service
User Offline
Joined: 22nd Jan 2004
Location:
Posted: 23rd Dec 2012 09:17
Quote: "I don't know what kind of dynamic memory capabilities you're talking about. Integrating a Windows GUI with DarkBASIC might work (it has been proven to work with DB Pro), but you don't need DGDK for that.
"


More of dynamic memory command subset that's available from c++, via the "new" command, lists, vectors, etc. Basically, you have a lot more power.

On top of that, you get access to classes and subclasses. This is what I was thinking would allow you to create a GUI toolkit. Not necessarily using a native Windows GUI, but more of a custom GUI system for use within programs (calling up windows, message boxes, button support, etc). As it stands, it can be done, but it's incredibly tedious to do. This would allow for a more general solution, rather than always making specific cases.

I was working on one for DBC, though after a while it started to get to be more trouble than it was worth.

I haven't looked into GDK's rendering capabilities though. I assume it has the features that DBPro has, though they may have expanded on it.

Great Quote:
"Time...LINE??? Time isn't made out of lines...it is made out of circles. That is why clocks are round!" -Caboose
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 23rd Dec 2012 20:28
I just wrote a real long description of an approach and I hit some button and everything vanished! I'm now mad! So I'll summarize:

I wouldn't use GDK with DBC because each is complete in itself and I don't see the advantage of not just using GDK. I would use straight C (because I'm a dinosaur) but you could easily use straight C++.

If you want to use windows gui, you can subclass the "DBG" class window (that's the name of the class of window that DBC creates) to use things like menus and such.

I you want a custom GUI, you'll have to create it no matter what you do. I've done work with writing drawing commands directly to DBC's back buffer through a DLL. It's very fast. I've even tried drawing custom 3D (just outlines and such) to the back buffer and it works fast as well.

The challenges:

1. Reading from the back buffer is too slow
2. Most memory handling has to be through memblocks.

No. 2 is a challenge because caling memblock commands in DBC isn't the fastest thing in the world and you also have to be clever how you set them up.

As far as data types: vectors, quaternions, matrices, etc. you generally create the types you want in your DLL. You then allocate sufficient memory in a memblock of the data size for N number of items.

If you look at the DBC challenges, the last challenge I entered with a smooth moving snake over a waving matrix, uses vector data types to communicate to the d3drm DLL.

You aren't limited to only using memblocks for memory management, however. I've created a collision DLL that manages all of the objects inside the DLL. ColDet does the same thing, and so does sparky's. ColDet was written in C++ and manages instances of collision objects classes. This is hidden from DBC through the DBC functions and the "in between" dll I made to talk to the coldet library.

Caleb on the DBC forums created a DLL in C++ for dynamic memory management. You should look aroudn for that.

Quote: "...On top of that, you get access to classes and subclasses. This is what I was thinking would allow you to create a GUI toolkit. Not necessarily using a native Windows GUI, but more of a custom GUI system for use within programs (calling up windows, message boxes, button support, etc). As it stands, it can be done, but it's incredibly tedious to do. This would allow for a more general solution, rather than always making specific cases.
"

No matter how you look at it, the GUI would still have to be created. It's a tedious task. But once it's in place, it is done. But it still doesn't eleviate the problem of a thousand new commands to use in the form of a library to use the GUI with a program. You still have to position dialog boxes, create menus, setup windows,etc. Even with windows, managing the GUI is not simple.

If you created the DLL, you might also want a GUI designer that spits out the function code for use in the program.

Enjoy your day.
Brendy boy
14
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 27th Dec 2012 07:50
you can't use dark gdk to write plugins for db classic. Dark gdk uses directx 9 and db classic (i believe) dx7. They can't be combined. For any 3d functions you would have to delve into pure directx

Fluffy Rabbit
User Banned
Posted: 2nd Jan 2013 14:38
@Brendy-

Well, you could discard DarkBASIC's 3D functionality and instead manage everything using DGDK code.
Brendy boy
14
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 3rd Jan 2013 05:22
Quote: "Well, you could discard DarkBASIC's 3D functionality and instead manage everything using DGDK code. "

yes, but what would be the purpose of a such plugin, wouldn't be simpler to just do everything in DarkGDK then?

Fluffy Rabbit
User Banned
Posted: 4th Jan 2013 04:47
@Brendy-

You don't need to play dumb. DarkGDK has limitations on commercial use if you don't pay for it. Making a plugin that abstracts a lot of its core functionality would be like a big middle finger to TGC. It would be about the same as making some kind of interpreter or game engine in DarkBASIC which essentially provides a DarkBASIC scripting language.

Also, most people don't like C++. To be able to use DarkGDK from the convenient syntax of DarkBASIC would be a breath of fresh air to a lot of people.
Kevin Picone
16
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 5th Jan 2013 14:21
Quote: "To be able to use DarkGDK from the convenient syntax of DarkBASIC would be a breath of fresh air to a lot of people"


Dbpro is exactly this.

Fluffy Rabbit
User Banned
Posted: 5th Jan 2013 18:35 Edited at: 5th Jan 2013 18:35
@Kevin-

Yeah, but I thought DGDK had better lower level graphics stuff due to being in C++ or whatever. I don't know.

Login to post a reply

Server time is: 2019-08-24 23:08:21
Your offset time is: 2019-08-24 23:08:21