Sorry your browser is not supported!

I experienced this too with DBP and transitioned to DGDK. But, I also transitioned from Blitz3D to DBP. From A7 to Blitz. From RAD to A7, and it keeps going on and on. I've been transitioning for two decades now.

But, for some strange reason don't feel the same limitations. I'm finally using C++. The same language the pros have used for years. The option to write a DX wrapper or use another is readily available.

Matty, I'm curious as to what triggered your curiosity about wrapping DX. I honestly don't have a problem with working DirectX directly (I use the D3DVECTOR struct heavily in MAUI). But writing a full-power wrapper looks like a lot of additional work.

Also, once we introduce a new rendering wrapper library, DOSP will no longer require DGDK. It wouldn't be a DGDK Open Source Project any longer. I was on a mission to prove what DGDK can do. Maybe the TGC team will release the DGDK source so the community can fully take advantage of it.

I tried it once before and it just gives you a sense of complete freedom, but it is really time consuming, I would not advise anyone to try and completely wrap it if their objective is to just make a game, I might give it another go one day just as a learning experience.



You are, of course, correct. If DOSP is to work, we need to stick with it, otherwise we may never finish anything. I just get the feeling that we may be doing too much, trying to make an engine with a complete feature set, I think certain things would work better if we did work with directX, MECS for instance, and I know the physics would run faster if it was developed along side the rendering engine. It seems we are trying to make a professional API but at its heart is a DX wrapper that was written for the sole intention to provide an easy to use interface for novice programmers or quick simple games.

That does not mean I'm going off the project, I will complete the physics and then look at where we are and what I want to do next.
I am still hopeful that we can complete something really special for the DGDK community, I do think we need more help though, I hope marlou returns to do the AI

I'm not trying to get you to actually check out my static libs. But I have all of directx graphics api already wrapped into easy to use classes, with physx, and Xaudio2. I will be starting the C17 DirectX 11 static lib in about a month. It will be identical commands to my dx9 static lib.

The speed differences between C17 static libs and gdk/w-physx are not even comparable. I have a demo with over 10,000 trees running at over 60fps. Not to mention all the direct control you have if you want it.

@david w - I've had a quick look through it and I'm itching to give it a good run, are there any limitations on what it can be used for? In other words, can anyone develop and completely own an engine/game built with it?

Oh yeah, anyone can develop whatever they want. Obviously I'll maintain the source code, otherwise it doesn't really matter.

Hi david w. I too had a quick look through your C17_Documentation.chm. The command labels are easy enough to understand (I get headaches looking at DirectX's). Perhaps I overlooked commands for managing DX Lights, Sprites, 3D Soundfields/Listener, Bone/keyframe animation, and Geometry Hierarchies. Are these features better handled directly by DX?

I really like the way Blitz3D wrapped up DX with its entity system. In Blitz3D, all 3D Elements: cameras, lights, meshes, soundfields, and pivots are all considered to be entities in which the same commands can be used to manipulate them. For example, the TurnEntity command can be used to turn a camera, a light, a mesh, or even a massive terrain!

If I were to pursue a DX wrapper I would draw on inspirations from Blitz3D's entity system. It would also be convenient for the wrapper to provide methods the simplifying building and editing for 3D entities, texturing, and animation ie: entity relationships, connections, texture layering/channelizing, geometry editing{weld, split, subract, adding vertices/faces/shapes}.

I will admit the more I think about it, the more appetizing writing a DX wrapper appears. Within the past 3 months I've tackled writing wrappers for LUA & Box2D. I like power and freedom, but, I'm lazy and a DX Wrapper looks like massive amount of work when you start considering whats all involved, 2D, 3D, Animation, Sound, Input.

Perhaps this week, I'll take a break from MAUI and write up a fictional feature and wrapper command set.

Well the C17 help is far from complete. I released it only because I thought I should have "something" that people can refer to for help, instead of nothing. Unfortuantly I haven't had time to finish the help as I've been busy working on C17's core DX9 features, fixing any problems and expanding the commands set to make things much easier to work. (If you really want a good overview of what is available "out of the box" then have a look at the header files for each lib.) (basically it can do everything DBP and Blitz3D do and more.)

As it stands however, C17 can be used to make a full game. I have been busy working on new demo's and in the process, optimizing the code, and fixing any bugs that may have slipped by me on the first release. So I will be putting out a new version soon.

I will be honest, it took me over a year to make C17. I have to admit that at times I was very frustrated. However, now that its finished, I can use it to make games, without the limitations that other systems have. If you want to make your own system, then that great. Good luck.