Hi Everyone, It is my pleasure to announce that I have released my small library (with source code) for developing 2D games. Though, it is small, but it is easier to use and provide easy interface to Direct X; It is for beginners who are just wanna be game programmers. It could be a good start to use and and understand how it works. For source code, documentation, and other details: http://age.aleshas.com Keep your comments and feedback on at this thread or on the website. Cheers

Quote:Original post by Mybowlcut
A few things I noticed in your code:

1. <You don't use initialiser lists. Take a look at this link for reasons why you should - especially since this engine is aimed at beginners who are picking up habits.


2. You've got using namespace declarations in every source file. Doesn't this defeat the purpose of a namespace?


3. Any reason you created a class only to define some constants in AgeExtraGlobals.h?


4. You should consider performing self-assignment checks in your operator== functions. If the address is the same it saves all the extra comparisons.


5. What is the point of this:*** Source Snippet Removed ***Objects created on the stack don't need to be manually destroyed unless they use dynamic memory internally... in fact I get a warning in Visual Studio if I try something similar: warning C4552: '~' : operator has no effect; expected operator with side-effect


6. Having not used DirectX in development before, I'm a bit confused that I'm getting errors telling me dsound.h, dinput.h, d3d9.h and d3dx9.h do not exist when I try to compile the code. Where would a newbie like me go to resolve this? Perhaps you should mention that people wanting to use your libraries will need these files.


7. Have you considered allowing for the documentation to be downloaded? That would be quite handy.

It's good to see someone releasing their work into the public for all to use. I hope to contribute something once I make something worth it. :)

Thanks for your valuable comments and suggestions. Let me come to one by one:
1. AGREED, I should have used initializer lists and that is now in my task list. I will update the code soon and will let everybody know.

2. AGREED, I will also update this.

3. Reason for making it a class is just to have everything fit in OO model. I admit it might not prove a faster and efficient approach, but sticking to OOD make design smooth. For OOD sake, we sometime do such things, that look stub in other way. Class is also there for the sake of code readability.

4. AGREED, added to my task list.

5. It looks like your compiler is leading you to incorrect direction. This operator is 'bit-wise NOT' operator. Like ~ of 0011 would be 1100. I am using VS2005 (It would be useful if you can let us know what compiler you are using?) and I never got that warning. Actually there is no destruction involved in this, rather it is a simple 'un-ary bit-wise NOT operator overload'.

6. AGREED, I am thinking of including a tutorial to get AGE set-up for first time.

7. AGREED, I will upload it now.

Yes, everybody is welcome to contribute to it. I will definitely host it with your name on the site if you provide any thing helping to it.

As I promised to upload documentation for download. You can visit Downloads page to download the documentation.

http://age.aleshas.com/node/3

Quote:Original post by DLight
3. Reason for making it a class is just to have everything fit in OO model. I admit it might not prove a faster and efficient approach, but sticking to OOD make design smooth. For OOD sake, we sometime do such things, that look stub in other way. Class is also there for the sake of code readability.

That doesn't have anything to do with OO. Why not put your constants into their own namespace instead of abusing a class as, well a namespace?

Edit: Some more comments after actually looking through your code:
1. Whats CMaterial supposed to do? Whats with all that bit flag magic? When I read material I whould expect it to have something to do with colors/textures and the like or if somithing is solid or water or whatever.
2. Why don't you put your objects initialization into the constructor but instead add an Initialization method everywere? And have to check for m_bIsInitialized in every other method? Something more to look into here: RAII.
3. Opinions may vary on this, but would you expect a ^ b to perform a vector cross product if you hadn't written the vector class yourself? Why not use a static method or free function and name it after what it really does: CrossProduct (or just Cross if thats to long)?
4. Opinions also vary on the use of naming conventions like hungarian notation. But at least with starting every class name with a C. What benefit does that have other than making class names less readable?

[Edited by - sebbit on April 29, 2009 12:56:32 PM]

While I haven't played a lot with the code here are few things I noticed in your code:

1. The naming convention. I think that in 2009 ( with IDEs we have ) there is no need to prefix your variable names like CRenderer, bIsInitialized, sTitle, nColorKey etc. as it only makes code harder to read. Good exceptions would be the g_, m_ to provide scope information. Also i think the variables in functions and methods would be better named without using capital letter ( const Vector& screenSizeBox instead of const Vector& ScreenSizeBox ) to differentiate between variables and types ( classes and structures mostly ).

2. The overuse of singletons. While singletons are useful in some cases you clearly are overusing them. If you need the access to your subsystems like Audio, Renderer, Logger etc. why not store them in Engine class and return a pointer/reference to them and making the Engine the only singleton? I think it's more logical way of doing it and also gives a better control of initialization and destruction of subsystems.

3. Returning a const value. I have no idea why you are returning a const value. The const here doesn't add any protection/constness over the returning value and just is misleading for the people who read the code.

4. The already mentioned AgeExtraGlobals. I don't think wrapping a bunch of globals in a class make the design more OO because in the first place you should avoid exposing globals in API. Probably the MAXIMUM_SOUNDS should be stored within your audio subsystem and not in a globals class wrapper.

5. The design of input handling. I don't find a reason why Mouse class should know anything about Keyboard class. I think that it would be better if you merged the two of them into an Input class that would provide the input handling. You already have classes like Logger, Renderer and Audio then why not have Input class for input handling ( seems logical to me ;) ).

Well those are few things that I noticed when browsing through your code. I hope that any of them are useful to you ;). I'll add more thoughts as I become more familiar with your engine ( don't have much time right now :/ ).

Cheers.

Thank you sebbit & MtrXPL.

That's great to see such a supportive response. I end up learning things from you guys around.
I will definitely cover the suggested areas one by one and will update the engine. (Due to job and other responsibilities it might take some time for me to come up with all improvements suggested, but I will keep updating as I get chance, one by one)
I appreciate the comments and have added these to task list.

Quote:Original post by sebbit
1. Whats CMaterial supposed to do? Whats with all that bit flag magic? When I read material I whould expect it to have something to do with colors/textures and the like or if somithing is solid or water or whatever.

CMaterial is supposed to provide unique identities to different objects like a car material is 0000 0001 and a floor material is 0001 0000. This is then used in collision detection (CModel class) where we can specify soft collision material and hard collision materials for an object.

Quote:Original post by DLight
CMaterial is supposed to provide unique identities to different objects like a car material is 0000 0001 and a floor material is 0001 0000. This is then used in collision detection (CModel class) where we can specify soft collision material and hard collision materials for an object.

If I get you right here (and interpret your code correctly) you use CMaterial as a large bit field where each unique bit combination is supposed to identify a material. And you do all that bit compare magic just to tell, that a CModels softcols or hardcols bit fields contain that specified bit pattern?
I don't know why you did it like that, maybe there is something I missed but wouldn't it make more sense to just make CMaterial a class that actually holds MATERIAL properties?
That way the material would define if it's soft or hard, not the model. Or maybe you could give it a softness property and select the kind of collision depending on the materials of the colliding objects.