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.

Work in Progress / C17 Static Libraries.

Author
Message
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 11th Aug 2009 07:00 Edited at: 13th Aug 2009 06:36
After contacting Lee Bamber, to make sure it was ok to post about C17 static libraries. He gave me the following guidelines -- "Just stay clear of subjects like price, promises and licensing and focus on features, what works right now and what the current issues are."

EDIT: C17 is a Wrapper for any API, but is focused on game making. Currently it Wraps Direct X 9.0, Nvidia PhysX, basic windows, and XAudio2.

What I am trying to accomplish with this post is to see what other indie game makers think, and if there is interest for something like this.

What exactly are C17 Static Libraries? For those of you who may not know, a static library is simply a collection of "commands" contained in a .lib file. This is very similar to a .dll.

What C17 is attempting to do is create a different approach to game making. This is done by using a modular design. Each library can be used seperatly or together as a unit. No one library relies on another. The Object Oriented design also makes it very flexable. (I'm sure many of you will appreciate this.)

Which brings me to another key design feature of C17. We all know how technology changes, take for example, Direct X 9,10,11, OpenGL..ect. The basic idea is to develop the libraries to be easily interchanged between technologies. For example the command set from the Direct X 9 and 10 libraries will be very similar to ensure that compiling against either one will require minimal code changes. Functions that the user has created will be easily transferable between either(if they used functions included with C17). The basic idea is that there is a clear path to upgrade as technology changes. Users wont have to wait years to use a new api after it has been released. Once a library has been decided to be built, users can take advantage. I think what librarys to build should be based on what the actual end-users want.

So what exactly is done, and what technologies are already present?
1. Windows lib
2. Direct X 9 lib
3. Nvidia PhysX lib
4. XAudio2 lib

The Librarys are mostly done, but I haven't finished every aspect. I don't even know if I'm going to release them because I don't know if there is anyone who wants them.

I chose to start with Direct X 9 because its the most popular at the moment an probably will be for quite some time. I went with a heavily shader based approach and left out alot of FFP stuff that could be added in if thats what is wanted. I think the shader based approach is the best since, thats pretty much the wave of the future.

Current C17 command set.

Direct X 9


C17 windows lib


C17 PhysX library


C17 Sound library



Simple Sample project -- so you can get an idea how it works


In closing if you have anything constructive to say, please do so. Again I would like to state that I'm posting this to see if there is actually any community interest.

Thank you.

EDIT: I attached a sample Cubic Shadow Mapping program. (also the shadow shader is an edited shader I downloaded as an example.)

Attachments

Login to view attachments
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 11th Aug 2009 12:48
Probably a dumb question, but what does C17 mean?

(City 17?)



david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 11th Aug 2009 18:47
A C17 is a military cargo plane. A workhorse transportation, so C17 libs are also a workhorse transportation. It can reliably take you from point A to point B.
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 11th Aug 2009 21:11
@ david w
I see. :S - Personally I'd have said a car does that just as well xD

Car libraries...


tiresius
21
Years of Service
User Offline
Joined: 13th Nov 2002
Location: MA USA
Posted: 11th Aug 2009 21:30
Is this wrapping DarkGDK or DirectX ?

People in the C++ forums may have more to say on this...

I'm not a real programmer but I play one with DBPro!
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 11th Aug 2009 22:06
Its Wrapping Direct X. Nothing to do with GDK.
AndrewT
17
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 11th Aug 2009 22:20
You'd probably get much more constructive feedback if you posted this in the Programming Talk.

Anyways looks good.

i like orange
David R
20
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 12th Aug 2009 00:29
Suggestion: Attach textures to another object (like a manager of some form, so a dynamic array of IDirect3DTexture9* or even wrap them into a linked list) so it can take care of their lifespan (Releasing them). Manually releasing textures would quickly become tedious and error prone otherwise

09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0
Garion
16
Years of Service
User Offline
Joined: 7th Dec 2007
Location: Poland
Posted: 12th Aug 2009 09:55
Looks similar to darkgdk/dark basic pro... If it's faster, it's great though
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 13th Aug 2009 05:16
@David R. I understand what you are saying. I designed C17 not to have an automatic object handler. The reason being, is this provides much more flexibility for end-users. The end-user must come up with their own way to handle objects, be it textures, 3d meshes/models, or sounds.

The easiest way to do this is to put the classes into an array or linked list like you suggested. There is going to be a larger learning curve for C17 than for DarkGDK.

@Garion. I havent tested the speed vs DBP or GDK but I will. I can almost guarantee before even testing, that C17 will be much faster than either.

I will post a couple sample programs to confirm or deny this.
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 13th Aug 2009 05:59 Edited at: 13th Aug 2009 06:01
While trying to steer clear of things like price/licensing is this going to be free or commercial? As this seems to be in direct competition with GDK, and (at least currently) it appears to have nothing to do with TGC so I'm surprised they allowed it here.

Anyway it looks cool I guess, kind of like XNA but without being crap(managed). A few things strike me as odd and/or potential annoyances though:

1 - Nothing appears to be even close to const correct, this will be especially annoying with all the functions that take c-style strings(or maybe all these functions modify them?).

2 - I don't see the point in you wrapping about 4 methods from ID3DXBaseEffect when you could just have some function to find an effect by handle which returns a ptr to the effect like the LoadEffect function.

3 - Why add 'MatrixMultiply' when the user can already use all the D3D math functions? Or even just the * operator. The same is true for some of the other functions.

Anyway those are just the obvious things I see, anything more in depth would require a release.

david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 13th Aug 2009 06:54
@Dark Coder.

#1. I dont really see the problem with how I'm handling string data. You do one of two things. You either pass in a pointer to a c-string or you put the c-string in the function. Like LoadEffect( "myeffect.fx" ); or char* effectstring = "myeffect.fx"; LoadEffect( effectstring ); Maybe I'm totally missing something here, and you could elaborate a bit for me. I understand the difference between c-strings and c++strings, but I am wrong on alot of things.

#2. I wrapped it that way because I thought that it might be more user friendly like that. Plus there are things that go on in the functions that will allow you to pass data types besides just what the standard methods will allow.

#3. I thought about that before I wrote the functions, then decided that it wouldn't hurt anything. And you are right you could use them and also multiply like that.

Thank you for the input.
heyufool1
15
Years of Service
User Offline
Joined: 14th Feb 2009
Location: My quiet place
Posted: 13th Aug 2009 07:23
Wow, those libraries would be amazing to have! Especially the Physx library! I hope to see this finished!

Use Google first... it's not rocket surgery!
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 13th Aug 2009 08:12
#1 - All of your functions that take strings as arguments take char*, this is annoying because it's 99% likely that your routines don't actually modify the data pointed to, this means you can't directly pass std::string::c_str() without const_cast or a c-style cast to remove the constness. I.e. your functions should be more like: void DoSomething( const char* path ); that way you can pass both const char* and char* without warnings.

There's no actual difference between the two in terms of generated code(to my knowledge), but one signals to the user your routines may modify the data pointed to and the other tells you it won't get modified(or at least that it shouldn't), thus casting out the constness is rather ugly when your routine should have it.

david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 22nd Aug 2009 23:05
Well I was hoping for a bigger response, but seeing as how it is what it is. I really want to release this, but without enough support I can't justify it.

Let me be clear on this, C17 is ready to use now, the upgrade path is clear. Their isn't going to be much wait for new technologies. Just the time spent for me wrapping the commands into easy to use libs.

Also if anyone would like to test this please drop me a line.
heyufool1
15
Years of Service
User Offline
Joined: 14th Feb 2009
Location: My quiet place
Posted: 22nd Aug 2009 23:45 Edited at: 22nd Aug 2009 23:45
Well I'm not sure what you meant "by drop me a line" lol. But I would love to test them.

Games are like life, they should never stand still.
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 22nd Aug 2009 23:55
msn messenger.
tiresius
21
Years of Service
User Offline
Joined: 13th Nov 2002
Location: MA USA
Posted: 23rd Aug 2009 06:57
Quote: "Well I was hoping for a bigger response"

Have you posted these libraries on other non-TGC forums? What was the response there?
People here like TGC stuff, as they are more familiar with it. So people already using C++ here are probably here for DarkGDK. Just my $0.02

I'm not a real programmer but I play one with DBPro!
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 17th Sep 2009 03:00
If you want to tryout/test C17 please drop me a line so I can get you the libs.

My e-mail is dwestfall10070@hotmail.com
Master Xilo
17
Years of Service
User Offline
Joined: 8th Sep 2006
Location: Bern, Switzerland
Posted: 23rd Sep 2009 03:06
Just had a look at your function declarations in the first post.
For the physx one:

If you want to make use of the multi-threading physx features, you should rather create two functions, StartPhysXUpdate and EndPhysXUpdate for example.

Because the simulation is running between

and

so you could do the rendering (for example) WHILE the simulation is running...

Mista Wilson
15
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 23rd Sep 2009 04:15 Edited at: 23rd Sep 2009 04:21
What is the current featureset of the libararies ? I mean, how are you managing scenes, do you have some kind of scene graph/manager ? is there a resource manager, does it handle lost devices properly ?(look at DXUT if you want an example, its pretty easy to handle) Do you have any form of culling(other than DX CULL_MODE), frustrum cull, occlusion cull ? (a scene manager would make it easy to do this)

Your vertex decs functions, which is used in programmable pipelines, seems to be hardcoded to take certain values, is that deliberate or does it have defaults ? If i wanted to specify a decleration like this could I :
(obviously need the dx device)


(VertexPos would be a decl structure like so


Is the device(IDirect3DDevice9*)hidden ? I cant seem to find a reference to it or a function to return it to the user... thats something that will quickly make a DX lib useless. You need to have access to the device.

EDIT : Of course, I forgot to ask if you are planning on abstracting this away from the API, similar to ogre or irrlicht, platform independant... hiding the device would make sense in that case, as long as you had abstract methods to be able to get at it and set renderstates etc

Quote: "We all know how technology changes, take for example, Direct X 9,10,11, OpenGL..ect. The basic idea is to develop the libraries to be easily interchanged between technologies"


You will need to completely abandon the FFP is you want to do that, DX10+ has no fixed function pipeline, its all programmable although I do believe there is a DirectX9EX that can run on windows 7, im not sure if it still has an FFP or not.

If it ain't broke.... DONT FIX IT !!!
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 24th Sep 2009 03:04
I would first like to Thank you for your responses and suggestions.

@Master Zilo. Yes I can do what you ask and it would be fairly simple to implement. I will add commands, to make it so you can do it like you suggest.

@Mista Wilson. You first question is the scene graph/manager. I leave this open to the end user in the fact that, you would call the command MyObject.Render(); To actually render the final object. The system knows if you have a shader for that particular object, and the settings (you would tell it this when you create your objects)(default is FFP rendering, no lighting). I'm intentionaly leaving this open to the end user so that they may be able to create anything they wish without being forced into one way of doing it.

You second question is frustum and occlusion culling. When you call the MyObject.Render(); command the system automatically checks against the frustum and if its in it get render if its out it gets skipped. I did not add occlusion culling but could do so.

And your question about getting the device the anwser is no its not hidden. There is a command in place to do this --> IDirect3DDevice9* GetD3DDevice( ); So thats that.

Well if using DX9 I can still have support for the FFP, but thats only specific to the DX9.lib, the DX10.lib will obviously be different, while maintining most of the commands from the DX9.lib as possible. So the basic's will be the same with slight variations accross Librarys.

I hope that I have been clear and have anwsered your questions. If not please ask more as I really would like to see this project put to good use. Thank you.
Mista Wilson
15
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 24th Sep 2009 06:33
Quote: "And your question about getting the device the anwser is no its not hidden. There is a command in place to do this --> IDirect3DDevice9* GetD3DDevice( ); So thats that.
"


I see now, I missed that command im sorry. What about the vertex declerations ? They are an important part of the programmable pipeline, to the point that you cant use it without em lol, but as I see now you can get the device, setting your own declerations would be a snap, which brings another point...

I dont mean to criticise, but is there a reason that you havent got the whole lot encapsulated into namespaces and classes ? I have no objections to taking the procedural approach, dont get me wrong, but with a library like this, encapsulating and then abstracting the whole lot away from the API(directx9/10, opengl etc - not the physics) would be an approach that would enable you to keep the command set the same, and have different APIs available for rendering..

The best way to see how that is achieved is to look at a few different libraries that do a similar thing, some of the more complex ones would include :

Irrlicht3D
OGRE3D
Open Scene Graph

The above completely abstract the core of their libs away from the rendering API's so its not tied to any one. They interface it through sets of specific classes, with the idea that an application developed, should not have to have ANY code changes to port it between renderers.

For a more simple example I will refer you to a site I have learned a bit about the topic from, it has a framework that is API independent and quite simple, its much easier to get an idea of how to implement the ideas from this than somethnig like OGRE, which is much more complex. The site's author is called "Humus" and the framework is called simple "Framework3" - it gets updated regularly, the latest being a couple of months ago, plus the site has loads and loads of demos using it so you can see the techniques in action.

Humus3D(first couple of pages have some cool deferred rendering examples in directx10.1) :
http://www.humus.name/index.php?page=3D

Just as a last note, I think what you are doing is really cool, I dont mean to sound critical or judgemental at all, the above is all just ideas that im throwing at you, and you can feel free to completely ignore it if you like, I wont be offended.

Hope some of it helps anyway.

If it ain't broke.... DONT FIX IT !!!
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 28th Sep 2009 04:59 Edited at: 3rd Oct 2009 10:56
Thank you for the information and the link. What I am trying to go for here is similar to what you stated above. The reason I'm not totally "handling" every thing for the end-user is so that they have the control to manage the scene as they see fit. Also, the command sets are going to be slightly different between API's in the fact that they are different and alot of commands will be easier to implement. (besides DX9.lib is the only graphics API I have done and ready to use.) I think what I have is enough to make any game you wish. (there may be bugs and commands that need to be added/expanded, but its still in the early stages.)

I would like to state that regardless, if anyone actually uses what I have done or NOT. I still consider this project a success, because I will be using it myself, and Its been a great learing experience(LOTS OF FUN LOL - I did have a good time doing it).

I think I am not getting my idea here accross very well. So what I am going to do is make a simple FPS + PHYSX demo (Full Source + Heavily commented, so that anyone can check out how simple it really is to use).

NOTE: Would anyone be interested if I was to expand the windows lib to support multiple windows, menu functions(add item, delete, create), message boxes, and various dialouge boxes with misc. button creation?? (open, save, etc,)????

EDIT1: Also as it stands there is not any support for lost devices, but I can easily put the detection code in. Does anyone consider this must have also how important it AA to everyone?

EDIT2: I've added raycasting and collision detection with multiple feedbacks for the DX9.lib Also since working on the demo I have corrected a number of bugs and added a few commands so its easier to use.

EDIT3: After fighting barycentric coordinates and directx for a couple of days, I finally have raycast world position reporting done. The raycasting can be used independently from PHYSX.lib or in conjunction with the PHYSX.lib raycast commands. I felt the need to implement raycast and collision detection into the DX9.lib because, it is not always desirable to use PHYSX.lib for collision and raycasting purposes.
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 14th Oct 2009 04:37
Well as seeing that nobody here wants this. I'm going to stop posting about it here.

After all the complaints I've heard about DBP -- features, bugs, speed, etc. I figured this would have been well recieved. Well anyways, I'm done with it and will be using it for all my future development projects. See you on the other side.
David R
20
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 14th Oct 2009 15:30 Edited at: 14th Oct 2009 15:37
You've made it more flexible than GDK/DBP, but so flexible (i.e 'unmanaged') to the point where it isn't worth actually using versus just raw APIs. For example, the lack of object management etc. (auto release) is a pain - it may well give complete control, but it's annoying. That one thing alone my turn many off - once you get past a certain sized app, who on earth wants to keep a manual tabs on each and every texture, whether it's been lost etc.? The majority of users who want to make stuff to manage that themselves wouldn't bother using this library - and the users who don't want to make that stuff will be put off by this lib because it's "half way between" - it caters for no-one

What's the point of using this API on top of another API if it barely makes the code any easier to write or make sense of?

09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0
Bursar
15
Years of Service
User Offline
Joined: 17th Sep 2008
Location:
Posted: 14th Oct 2009 15:58
And I'm guessing it's for C++? People might complain about DBP, but it's so much easier to learn than C++ (or C#). From the sounds of what you've released, it won't help people who don't know C++ get to where they want to be any quicker.

I would suspect that in order for the DBP users to get onboard you would have to release it as a DBP compatible DLL like D3DFunc. That way people can get the benefits of your wrapper whislt staying withing the cosy walls of DBP coding.
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 14th Oct 2009 16:08 Edited at: 26th Nov 2009 00:07
C17 static library?


Attachments

Login to view attachments
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 15th Oct 2009 04:52
@ David R You are partialy correct. It is "unmanaged" in the fact that its currently set-up so the end-user has to manage their own textures, meshes, effects. When I was writing I thought that would be a good idea, perhaps not. Using the raw API, you have got to be kidding. What I have is far simpler and easier. The phsyx and direct x stuff I have included would require many long hours of programming and know-how just to get set-up properly. Animation, raycasting, dynamic cube maps, Phsyx itself, just to name a few.

I had thought that I made it very simple and easy to use. Slighty more involved than GDK, just more powerful. What is so hard about this:

IDirect3DTexture9* Texture0;
Texture0 = dx->LoadTexture( "mytexture.bmp" );
Model[0].LoadXObject( "cube 1x1.x" );
Model[0].BindTextureToStage( Texture0 , 0 );
dx->RenderBegin();
Model[0].Render();
dx->RenderEnd();

What I'm saying is I could make an automatic default obect handling function. Something like SetupGame(), that will initialize phsyx, directx, one camera, direct input and have dynamic storage for "objects" and "textures".

I thought this would create to much inflexability in the system, but it could be optional. No need to call it if you do not desire.

@bursar Yes I could make this into a dll, but there would be no point to make the DX9.lib into one. The others, yes they could be made into useful DBP DLL's.

@Cowbox LOL.
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 23rd Nov 2009 04:12
Well the plan is to release these libs for FREE. I wont make any money off them, I don't really want to. I would like to see this project turn into something useful for others to use. I haven't finished the help.chm yet, but I would rather release them with it finished vs no help for reference. If anyone would like them now without any help please just say so.

I really would like these libs to be put to good use by someone. Please dont underestimate the power and flexability that these libs offer.

#1 Clear upgrade path for future and current technologies.
#2 If you want a feature or command I will do my very best to add it.
#3 FREE.
#4 Relatively easy to use. If you can use DGDK you can use C17.
#5 Direct low level access that you may need.
Dar13
16
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 25th Nov 2009 16:37
I'd use them, david w. Using DirectX9 through Microsoft's API is a nightmare, and I want to be able to use something a bit more "lower level" than Irrlicht. These libraries seem to be the perfect compromise.

Note: By the way, those extra windows options would be a great addition.

Hayer
18
Years of Service
User Offline
Joined: 4th Nov 2005
Location: Norway
Posted: 25th Nov 2009 22:15
Release some source code then so maybe I end up rewriting some so its more OOP'ed.

and std::vector is sloooow D:

Keep it simple.
Questions? Mail me
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 26th Nov 2009 07:32
I'm going to be putting them on jegas.com, I have to give jason all the files so when they are up you can download as you like. Check after Thanksgiving, they should be up soon after that.
Dar13
16
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 8th Dec 2009 02:26
Hey david w, either the files aren't up or I just don't know where to look.

david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 8th Dec 2009 21:31 Edited at: 8th Dec 2009 21:32
They are not up yet. The reason they are not up yet is because I'm trying to get all the samples edited and with comments. I will upload just the libs and headers as soon as I get home.

(I'm trying to do a proper release. Samples and docs.)
Dar13
16
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 9th Dec 2009 02:39
Ok just wondering since you said they'd be up after Thanksgiving.

david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 9th Dec 2009 08:38
Ok they are up on www.forum.jegas.com
Dar13
16
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 12th Dec 2009 03:29
Thanks. After my wrestling tournament tomorrow, I'll mess around with it some.

Login to post a reply

Server time is: 2024-05-29 04:41:41
Your offset time is: 2024-05-29 04:41:41