I Know it was said as a joke, but DarkGDK?

Miscellaneous Forums/General Discussion/I Know it was said as a joke, but DarkGDK?

It was mentioned a bit ago about DarkGDK being made into a mod/3d engine for BMax.

Well, is this actualy possible.

If it is could someone with the Know-how knockup a quick guide on the sort of thing that needs to be done to make this, (Or indeed any c++), code work.

What you get in DarkGDK is the Header files, and VC7 and VC8 lids. I read somewhere that the libs need to be turned into .a Is this true, how would that be done if possible.

If it is possible, Im willing to do the Grunt work, and if not A palabras necias, oidos sordos

I don't see any reason it wouldn't work.

Assuming that DarkGDK does not have an OO-syntax, then yes, it should work.

Heh. Why would it have that?

I don't see why it wouldn't work. The real question is why would you want to?

The real question is why would you want to?
Well, cos Ive already paid for the thing, (When it came out), and although I keep downloading all the updates, I never use it. And its definetly faster than MiniB3D, and is Dx9 and probably will be DX10 soon.

Basicaly Red shouted at me in another place, for not giving the thing a chance, but although I can just about get a "Hello World" demo going in C++, I am no where near the point that I would want to use it as my Lang.

And so, if its just a mundane question of copying/pasteing over and over again, with loads of mindless changes to make, Im willing to give it a go making a wrapper for it in Bmax. I just simply dont know how.

Oh and no its not oo in its frount end presintaion, (It just the DBPro commands in c++)

GSDK is pretty good, and fast too - shame you didn't come to the last Convention, where upon you would have seen various interesting things, including my Humans On A Planet game. However, you can get it on my website - may need MFC 70/80 for it.

It did have two problems (in my case), which I hoped are fixed in the update - ghosted objects are displayed and shows in the correct place.

I would have continued with it if they did an OS X version (but they dont, so I wont).

now its free

http://www.microsoft.com/express/samples/GameCreators/

look @ this and anyone make a wrapper ???

I am feeling like a stupid because I bought also Dark GDK (the shareware version) and now is free. I think this is not a honest policy from TGC

There is no shareware version. There was freeware and commercial version. Stop trolling around!

hi, Moraldi,

DarkGDK isn't actually free, it's $500 for profit use, since you have bought it before, you can pay old price $140 for commercial license if you think you need it.

I downloaded the Free Version, the .sln/vcproj are VC2008 ready, but I made a project with VC2005, it did compile and work(the lib didn't change much). Didn't test on VC2003 and I didn't find a MinGW port, or anyone else is doing that.

I stick to gman's Irrlicht for Max because I've used it for a while tho.

you are right videogamer my fault ...

It is of no meaning the terminology. The most important: I payed for a product that know is free. I bought it because I wanted to test it (and then proceed to the upgrade). Now everybody can test without any payment

PS (for the thevideogamer):
Can you tell me what makes you think to believe you are able to tell me what I will post?

Hey, 3D World Studio is on Microsoft.com!

yap i see congrats

Direct Link please ?

http://www.microsoft.com/express/samples/GameCreators/

And its definetly faster than MiniB3D, and is Dx9 and probably will be DX10 soon.


Now Darkbasic is supported by MS.
If what H&K said is true, does Blitz has any special weapons to compete with Darkbasic? or just let it win?

@H&K: How do you come to this conclusion? Do you do any tests? Does Blitz have Blitz SDK?

Free...but for personal use. If you want to sell anything made with it, you have to buy a $499 commercial license!

http://gdk.thegamecreators.com/?f=order

>And its definetly faster than MiniB3D

It's not the factor of rendering pipe, but the code optimization issue especially tested a few test like massive particle/cone/cube etc with MinGW/VCTK2003/VCExp2005/VCExp2008.

Technically, thanks to the Optimization of VC2008, the code optimization is notably better than 2003/2005. 2008 outperforms 2005 about 15% speed, that means you can do more thing you want, MinGW is reasonably usable but the code optimazation is ...hmmm.

hmm the examples in the installer are not really fast imho

As to "just let it win?", face it, as you know Mark/Skid/Simon are not talented on sales.

Mark made the great work on the quality and reliability on Blitz series, but that's only it, maybe current the Blitz sale is stable enough to support the site so Mark didn't make further steps, or they are just too busyto handles this?


It's not the factor of rendering pipe, but the code optimization issue especially tested a few test like massive particle/cone/cube etc with MinGW/VCTK2003/VCExp2005/VCExp2008.

Very few games are CPU bound, let alone simple graphic demos. I think it's highly unlikely that you'd notice any difference in simple graphics demos based on the compiler you use. If MiniB3D actually is slower ( I have no idea if it is ) then it almost certainly *is* because of the rendering, and quite possibly the choice of API.

If what H&K said is true, does Blitz has any special weapons to compete with Darkbasic? or just let it win?


MiniB3D isn't even a Blitz product, so why should BRL have to bring out any specials weapons?

If MiniB3D actually is slower ( I have no idea if it is ) then it almost certainly *is* because of the rendering, and quite possibly the choice of API.


Sounds totally untrue to me. The code needs to be very, very fast and efficient to sort all textures, surfaces etc, factor in culling and other cpu intensive calculations.

Then finally get down to your game AI and so forth. The CPU can and is stressed by the graphics engine.

Thats a real-world game with levels. If you're going to do 1 room of graphics then sure, the CPU isn't going to be the limiting factor.

The code needs to be very, very fast and efficient to sort all textures, surfaces etc, factor in culling and other cpu intensive calculations.

Well that's certainly true if you had to compile Dark GDK from source. I wasn't aware that was the case though. Of course, if you *do* have to compile it all from source than you probably don't actually have a choice of compiler.


Thats a real-world game with levels. If you're going to do 1 room of graphics then sure, the CPU isn't going to be the limiting factor.

Well on the face of it, it seemed improbable that H&K had actually written a real-world game with levels, AI, etc just to compare the relative speed of two 3d engines. But if you know different..

Sounds totally untrue to me. The code needs to be very, very fast and efficient to sort all textures, surfaces etc, factor in culling and other cpu intensive calculations.

It depends, but what Gabriel said is pretty much correct.

When comparing two engines with purely graphical demos, the performance usually represents how well the engine handles the rendering of the scene, not how well optimized the CPU code is. You're correct that certain types of occlusion can eat a lot of CPU, but as far as I know neither DarkGDK nor MiniB3D support any type of occlusion, so that's not a factor here.

The main exception to this argument would be if you have a really fast video card, and both demos run really really fast (maybe over 200 FPS). In this case it's likely that the CPU will become the bottleneck and comparing demos this way can show which uses more CPU, but practically this info is absolutely worthless. In fact, if a spinning cube in Engine X runs at 500 FPS and a spinning cube in Engine Y runs at 1000 FPS, Engine X may very well be significantly faster in rendering an actual game environment simply because it does use more CPU to optimize the GPU's work.

Then finally get down to your game AI and so forth. The CPU can and is stressed by the graphics engine.

Thats a real-world game with levels. If you're going to do 1 room of graphics then sure, the CPU isn't going to be the limiting factor.

Actually, the graphics engine should be the least of your CPU optimization worries. It's things like physics and AI that really consume CPU usage, not the rendering engine.

I'm not saying that a rendering engine shouldn't be optimized though, just that there's a lot more to rendering engines than CPU usage.

On the topic of DarkGDK / DBPro, I'm surprised to hear that it's faster than MiniB3D. I haven't used MiniB3D myself, but I have made some games with DBPro in the past, and found it to be extremely slow compared to most other engines. I haven't used it a while though, so they must have really improved.

hmm the examples in the installer are not really fast imho

I believe the sync speed is fixed - and isn't set to go as fast as possible. Its easy enough to change and re-compile.

but I have made some games with DBPro in the past, and found it to be extremely slow compared to most other engines. I haven't used it a while though, so they must have really improved.

DBPro is slow - GSDK isn't, because it's just the 3D engine, and none of the other stuff (code for while/for/repeat loops etc), that just isn't needed. When the GSDK first came out, I worked out that there was a approximately a 175% speed increase between DBPro code and C code with the GSDK...

Now Darkbasic is supported by MS.
No it isn't. It's still supported by TGC.

DBPro is slow - GSDK isn't, because it's just the 3D engine, and none of the other stuff (code for while/for/repeat loops etc), that just isn't needed. When the GSDK first came out, I worked out that there was a approximately a 175% speed increase between DBPro code and C code with the GSDK...

I don't mean code execution speed - of course C/C++ is faster than DBPro in that respect. I meant that DBPro's actual ability to render complex scenes, even with the most basic render loop, was very slow.

Now Darkbasic is supported by MS.

It's not supported by MS, it's promoted by MS (basically as a freebie addon to Visual C++, though it's not free for commercial products as you know).

its not bad for a freebie but i still wouldnt use it

@H&K: How do you come to this conclusion? Do you do any tests? Does Blitz have Blitz SDK?

Jeez, Nine mths ago, when I made that statment No, there wasnt a Blitz SDK.
And MiniB3D WAS ALSO, 9 Mths younger than it is now, and yes, on all the comparitve demos DarkSDK was faster. AS too if it was really faster, I cannot tell, cos I couldnt get it to work with Bmax, and MiniB3D doesnt work with C++