Jump to content
  • Advertisement
Sign in to follow this  
Josheir

2nd Code Review, Please - Asteroids

This topic is 394 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone, this is my project up for it's second code review.  It's Asteroids and it's on GitHub.  If you can, please help me with your criticism.  I really appreciate it!

 

https://github.com/Joshei/asteroid-project

 

Thank you,

Josheir

 

@Joshei

 

 

Edited by Josheir

Share this post


Link to post
Share on other sites
Advertisement

Various comments typed in your code, so if you apply the patch, make a branch first so it doesn't mess up the code

Despite being called ".diff", it's a plain text-file you can open it with any text editor.

 

In all, it looks nice!

comments.diff

 

Edit: Link to another post with references to the timestep solution

 

Edited by Alberth
Added link to "fix-your-timestep" post

Share this post


Link to post
Share on other sites

Alberth already caught most of the things I saw, but I want to give some more general advice. If you look at the movableObject class, you'll see that it only has some member variables and some setters and getters for them, but no functions that have any behavior that's unique to that class. I would expect this class to have a move() function that then updates the position using the direction (deltaX, deltaY?). Right now this is spread out and duplicated all over the place, in asteroid::moveAsteroid and the various move*** function in main.cpp. 

SFML also has the sf::Vector2f type that you could use instead of splitting every position in an X and Y variable. (If it needs to be integers you can also use sf::Vector2i)

Also regarding the Sleep(10), what I recommand doing right now is enabling vsync (SFML uses OpenGL by default right?) It's more reliable than the Sleep function and has the added benefit of preventing screen-tearing. Later on you can decouple the render-loop from the simulation-loop by following the fix-your-timestep article.
 

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!