Sign in to follow this  
DLight

AGE Released - A Free 2D Game Library

Recommended Posts

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

Share this post


Link to post
Share on other sites
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:
    const CMaterial CMaterial::operator~() const
    {
    return CMaterial(~this->slot1, ~this->slot2, ~this->slot3, ~this->slot4);
    }

    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. :)

[Edited by - Mybowlcut on April 29, 2009 8:42:43 AM]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by DLight5. 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'.

[...]

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.
Oops! Sorry. I should have taken better notice of what function that was hahaha. I thought it was the destructor!

This project should go well seeing as it's open source. Good luck!

Share this post


Link to post
Share on other sites
I noticed something you are not using index buffers and vertex buffers.
you could do something like in hge library.

Also it will be nice to draw filled quads, lined quads, and symple lines.

There are still messing many features compare to hge.



But the overall is a good starting library.

Share this post


Link to post
Share on other sites
Quote:

Original post by sebbit
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.


The reason to do that is to handle softcols and hardcols. But first I should explain what softcols and hardcols.
Matrerials specified in softcols just 'ENABLE' reporting about that matrial has been touched (like an object is touching another and objects are allowed to overlap).
Materials specified in hardcols are hard collisions like when a car in game collide with a wall (wall won't allow car to pass through it) that is what hardcols are for.

Having it in CModel had purpose that: for some objects a material (i.e. another object) is overlap-able but for some others its not. Like in a game where enemy plane touches with player's plane and player plane health bar start to decrease. In other games it wont be the case, and just a touch of enemy plane will make player's plane crash.
I meant to say flexibility in collision detection.

I strongly feel that lack of proper documentation (other than API reference) is causing even more confusion to AGE users. I shall prioritize this so that users of AGE get to know what is purpose of that they are using.

Yes becoolnike, AGE is a baby in front of HGE. I know about HGE it is quite good. I will try to add primitive drawing in AGE.

Thanks to all of you and suggessions are all the way helping.

Share this post


Link to post
Share on other sites
What I wanted to say is that it just seems very confusing to me to call a class Material if what it does is just producing some numeric identifiers. What if you want to extend that later on (i.e. not only define Material by it's collision properties)?
But well, thats just my opinion on that. Don't want to force anything to you there.

Share this post


Link to post
Share on other sites
Animation:

Your engine makes it difficult to reuse animations. What if I want to have 50 objects play the same animation but each one of them started that animation at a different time, so it would need to show a different frame? I would have to duplicate Animations in each object. You should make it so that animations can be shared between multiple objects, while making it possible for each one of those objects to play the same animation with different speed, different current frame and different options (forward/reverse, etc). Also, I don't see support for pausing and resuming animation.

Input:

I would suggest using WM_CHAR for getting textual input data for entry into text fields. That's what it was made for, anyway - DirectInput is a bad way to go about this as proven by your huge code fragment that has to check for uppercase/lowercase on many characters.

Some specific stuff:

Line 166 and 167 of Model.cpp:
It looks like you are swapping two variables based on their value, yet the very next line compares them again and chooses one based on value. The swap seems to be unnecessary. Just use min() or max() macros for stuff like this.

Misc Notes:

* I don't have a problem with Hungarian notation, however you are misusing it in several cases (such as prefixing Vector variables with "n" which is used for integers). Better not use it than to use it mistakengly.
* Why is CMaterial not in any namespace?

Share this post


Link to post
Share on other sites
Sign in to follow this