Sorry your browser is not supported!

I have read a lot about both of these, and was wondering if anyone could tell me what makes DarkGDK/C++ a better choice over Panda3d. I would like to write a game for my friends and I to play, and do need a couple of thigns:

Ability to animate skeletons..ie be able to move a toons forearm by telling it where the two points, wrist & elbow are located.

Since its a network game I want to be able to track actions based on a timer..ie Trullion does action X at 1:33:33.343554 and use a timer to keep all the computers in sync with each other.
(Note:someone else might have a better idea.)

I have heard the games using DarkGDK require fairly high end systems....is this true?

Why dont use both?



It works different. But i think dark.net would be a great idea for that.

No the GDK does not necessarily require high systems. I ran the GDK very well on my old Dell that had 512 of RAM and a 2.1 GHz processor.

Dark gdk for sure. Because one I know 3d studio. Two because I use to use open gl tell recently. I like open gl gui better then Dark gdk non existant GUI, but loading objects in open gl vrs this is way faster. Of course were not talking Open GL. Basicly this Dark GDK will kill Open GL. Because it is a dieing language.

OK, so then here is another question on the same topic....let us say that I downloaded DarkGDK with VC++ Express and built my project. This way I could tell whether or not I like it. At this point, how difficult would it be to upgrade to the commercial version of DarkGDK?

unless you want to SELL your game for profit, you don't need to buy any commercial DGDK

DarkGDK free/commercial versions are the same, there is no difference in the software, the only difference is that you buy a license for one and not the other. You only need the commercial version if you intend to sell or make and profit from what you develop.

To answer the OP's question, it would not be right to say "One is better than the other". The product that you choose, should be the one that meets your needs the best.

Panda3D supports rendering through either OpenGL OR DirectX, it interfaces with those API's through it's scene graph. Panda3D is Open Source, you get the complete source and can alter it and rebuild it as you see fit. Panda3D is written in C++ but is designed to be used most easily through the Python scripting language interface rather than native c++ code(though its certainly possible to use native C++ its more involved) Panda3D has more advanced shader and effect support than DarkGDK, it has a built-in Physics engine(ODE), and handles basic FSM's. The drawcard of Panda is its OpenSource lisence and continual regular support, and all of its included extras(they are paid-for addons in GDK). The major drawbacks I can see with Panda3D would be it's complexity compared to GDK, the need to know both Python and C++ and to understand how they interface together(if you want to get into it at the code level) and what looks like a steep learning curve to get started with anything beyond "hello world" lol(even that looked alot more complex than the equiv in GDK), it has a very different system of operating than GDK, having its own exposed scene graph and task manager.


DarkGDK is closed source, you will NEVER be able to get the source code for it, you are stuck with the static libraries you are given and can only update it when the developer does. DarkGDK is ONLY DirectX, you cannot run it through OpenGL, so running anything you develop on other platforms becomes difficult. DarkGDK is SIMPLE. It is designed to be able to rapidly develop your application by simplifying tasks and making things easy. It is however a C++ only library(with a .NET version called DarkGDK.NET but thats a different product and only commercial, no free version, its also built on DarkGDK, so any bugs in GDK will also be in GDK.NET). The main drawcard of DarkGDK is its simplicity. The main turnaways(at least for me)are the bugs(or more accurately the lack of them being fixed regularly), the patchy support and lack of updated documentation, leaving users to figure out undocumented command usage on their own.

I know that seems alot of negative, but in reality GDK's simplicity really does offset all of that, at least for rapid development and ease of use.