• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
kovacsmarcell99

Game Engine using SDL 2

10 posts in this topic

Your math.h should have precomputed value :

const float DEG2RAD = 0.01745329251994329576923690768f;
const float RAD2DEG = 57.2957795130823208767981548141f;

inline float ToRadian( const float Degree )
{
  return ( Degree * DEG2RAD );
}

inline float ToDegree( const float Radian )
{
  return ( Radian * RAD2DEG );
}

You can clean your main.cpp, but it's personal comment, if you release, you have to clean, it's not a big code source so it's not a big effort.

You can optimize your vector2.h and vector3.h a lot using *= versus /= and avoiding return in CreateVector using reference as output.

I saw the same thing on different files who can be changed, output who has to be reference output and not returned.

This kind of optimization is important if the function is called each frame or often.

Now what I have to say about the all stuff is it's not a game engine for me but a framework actually.

But it can't be really used by other because you don't have any doc and it needs to be clean on different places.

Edited by Alundra
1

Share this post


Link to post
Share on other sites

Please, move the code out of the headers.  Every file that includes a header will include all the code as well.  That means you'll have multiple instances of the same code included over and over.

Just declare the classes and API's in the include files, and have the source code be available via a library, or at least separate .cpp source files.

2

Share this post


Link to post
Share on other sites

It's true, I didn't noticed that the first view. It's very bad coding style.

When you will move all the code, if you have function who is just "get" or "set", let them inline.

It's a hint for the compiler but you know these function will be inlined so it's ok to let them in .h inlined.

1

Share this post


Link to post
Share on other sites
If you use C++ go with SFML instead.

If he used SFML, the result would have been the same because it's a question of coding style more than API used.

Another point is SFML is more a game framework for OpenGL, SDL can be just used for windowing on D3D/OGL.

But after that, it's just a comment because SDL or SFML can be used for Unix version only if needed.

 

You're also not following the rule of three

I always like when Hodgman speaks about rule of three, because it's not always knew and should be.

Edited by Alundra
1

Share this post


Link to post
Share on other sites

Thanks everyone I almost finished all of them! I'm currently working on seperaing the code into .h and .cpp files, it's the last thing. I would like to hear further tips!

Edited by kovacsmarcell99
0

Share this post


Link to post
Share on other sites

Hey everyone! I've done some work on the engine in the last half year currently I am adding the .cpp files. Could you guys give some further tips? (Hint: I've redone the logging pls check it. Is it good?)

0

Share this post


Link to post
Share on other sites


Hey everyone! I've done some work on the engine in the last half year currently I am adding the .cpp files. Could you guys give some further tips? (Hint: I've redone the logging pls check it. Is it good?)

 

Sure, here's a few things I noticed:

	//TODO: This MAY cause problems!
	bool isOpen = (bool)(in);

See http://www.cplusplus.com/reference/fstream/ifstream/is_open/

	Logger() {};
	Logger(Logger const&){};
	Logger& operator=(Logger const&){};

If your compiler supports C++11, consider using = default; or = delete;  See http://en.wikipedia.org/wiki/C%2B%2B11#Explicitly_defaulted_and_deleted_special_member_functions

	static Logger* Instance();
	static void ResetInstance();

Consider making a templated Singleton class so you don't need to re-write this for every singleton you have.  Personally, I try to stay away from them but sometimes they're appropriate (ie. a Logger class is quite appropriate).

#define LOG(Message_) Logger::Instance()->LogLine(static_cast<std::ostringstream&>(std::ostringstream().flush() << Message_).str());

Using a preprocessor to wrap any debug/log statements is a great idea, as you can easily have the #define statement do nothing for certain builds.  However, consider utilizing the __FILE__ and __LINE__ macros to see where messages are popping up.  This will help in the long run.  (note that __LINE__ is an int).

inline std::string GetClockTime(void)

Consider making global functions as static functions in a class so you don't pollute the global namespace, and I don't seem to see any namespaces anywhere.  Also, I assume this is C++ since you're using C++ tools, so remove (void) as it does nothing in C++ and only clutters things.

if (logNumber > 500)

500 is a magic number to me.  Consider creating a constant that makes more sense to an external viewer.

	if (!instance)
		instance = new Logger();

At first, I was a believer of the "no braces for a single statement if statement" but unfortunately, it can be error prone (an error may only come up 1 in 1000 of these situations, but even that small chance is worth the coding style change), so consider always wrapping statements in { } braces.

	instance = NULL;

Consider using nullptr. See http://en.wikipedia.org/wiki/C%2B%2B11#Null_pointer_constant

Logger* Logger::Instance()
{
	if (!instance)
		instance = new Logger();

	return instance;
}

Consider returning a reference for a function if it's guaranteed that the item it returns will always exist.  Only use a raw pointer if you cannot guarantee that the returned item will exist.

 

I also implemented my log/debug functions as functions that take a std::string as a parameter, but I probably should have just overloaded the << operator instead, so you may want to try that out as well.

 

I was just looking in TextureManager as well, and for your sanity, use typedefs or using = SomeC++11Type or using = SomePreC++11Type.  I'm referring to this:


#ifdef CPP11_SUPPORT
	std::unordered_map<std::string, SDL_Texture*> textures;

	std::unordered_map<std::string, bool> errorShown;
#else
	std::map<std::string, SDL_Texture*> textures;

	std::map<std::string, bool> errorShown;
#endif

I hope this helps.

2

Share this post


Link to post
Share on other sites

 



Hey everyone! I've done some work on the engine in the last half year currently I am adding the .cpp files. Could you guys give some further tips? (Hint: I've redone the logging pls check it. Is it good?)

 

Sure, here's a few things I noticed:

	//TODO: This MAY cause problems!
	bool isOpen = (bool)(in);

See http://www.cplusplus.com/reference/fstream/ifstream/is_open/

	Logger() {};
	Logger(Logger const&){};
	Logger& operator=(Logger const&){};

If your compiler supports C++11, consider using = default; or = delete;  See http://en.wikipedia.org/wiki/C%2B%2B11#Explicitly_defaulted_and_deleted_special_member_functions

	static Logger* Instance();
	static void ResetInstance();

Consider making a templated Singleton class so you don't need to re-write this for every singleton you have.  Personally, I try to stay away from them but sometimes they're appropriate (ie. a Logger class is quite appropriate).

#define LOG(Message_) Logger::Instance()->LogLine(static_cast<std::ostringstream&>(std::ostringstream().flush() << Message_).str());

Using a preprocessor to wrap any debug/log statements is a great idea, as you can easily have the #define statement do nothing for certain builds.  However, consider utilizing the __FILE__ and __LINE__ macros to see where messages are popping up.  This will help in the long run.  (note that __LINE__ is an int).

inline std::string GetClockTime(void)

Consider making global functions as static functions in a class so you don't pollute the global namespace, and I don't seem to see any namespaces anywhere.  Also, I assume this is C++ since you're using C++ tools, so remove (void) as it does nothing in C++ and only clutters things.

if (logNumber > 500)

500 is a magic number to me.  Consider creating a constant that makes more sense to an external viewer.

	if (!instance)
		instance = new Logger();

At first, I was a believer of the "no braces for a single statement if statement" but unfortunately, it can be error prone (an error may only come up 1 in 1000 of these situations, but even that small chance is worth the coding style change), so consider always wrapping statements in { } braces.

	instance = NULL;

Consider using nullptr. See http://en.wikipedia.org/wiki/C%2B%2B11#Null_pointer_constant

Logger* Logger::Instance()
{
	if (!instance)
		instance = new Logger();

	return instance;
}

Consider returning a reference for a function if it's guaranteed that the item it returns will always exist.  Only use a raw pointer if you cannot guarantee that the returned item will exist.

 

I also implemented my log/debug functions as functions that take a std::string as a parameter, but I probably should have just overloaded the << operator instead, so you may want to try that out as well.

 

I was just looking in TextureManager as well, and for your sanity, use typedefs or using = SomeC++11Type or using = SomePreC++11Type.  I'm referring to this:


#ifdef CPP11_SUPPORT
	std::unordered_map<std::string, SDL_Texture*> textures;

	std::unordered_map<std::string, bool> errorShown;
#else
	std::map<std::string, SDL_Texture*> textures;

	std::map<std::string, bool> errorShown;
#endif

I hope this helps.

 

Thank you very much!

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0