Jump to content
  • Advertisement
Sign in to follow this  
KruSuPhy

[MonoGame] Rendering graphics for a 2D top-down engine

This topic is 1025 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

Hi all, I'm working on building my first ever game from scratch. It's a 2D top-down RPG. I'd like to take a second to note that this game isn't intended to be sold or anything, I am purely making it for fun and learning, so yes, I am sure that I want to build it from scratch. Using other learning resources, I now have a working scrolling tilemap, and have written I/O Handling and Input Handling. My next concern is rendering all of the graphics for my game - I've seen somewhere that having a lot of SpriteBatches can be a big performance hit, so I'd like to avoid that. This means having a Rendering class that does it for all of my objects, rather than rendering each item separately in their own class methods(if i'm not mistaken). My question to you guys is, how do you structure this class and what is the "best" way to do it? should I just include four methods(Load/Unload/Update/Draw), or is there more to it that I need to know to do it?

 

EDIT: by the way, sorry if i sound clueless. I kinda am. I have a decent amount of experience writing game logic, but when it comes to the behind-the-scenes stuff, i can get kinda lost. I know how to program it so that everything loads and draws its images on its own, but creating a class to handle it all for me seems a bit different and I'm not sure how to go about it.

Edited by KruSuPhy

Share this post


Link to post
Share on other sites
Advertisement

I have used the website listed above my self and can say that it is a very nice tutorial for monogame/xna 

Share this post


Link to post
Share on other sites

I did a tutorial series on gamedev with monogame and this is the bit you should pay attention to.

 

Behind the scenes, Monogame ultimately uses OpenGL on most platforms, so you want to do the things that make OpenGL happy.  For the most part it has very little to do with how you structure or layout your code and everything to do with how you perform your draws.

 

You've touched on the biggies when it comes to performance.  Switching textures is a slow process in GL, so you want to organize your calls around the same texture as much as possible.  This means organizing your game data so the sprites that are most commonly used together are in the same spritesheet.  The next major thing is to use a sprite batch.   What a sprite batch does is essentially turn dozens, hundred or even thousands of draw calls into one single big call by "batching" them all together.  

 

 

Basically organize your sprites nicely, implement a solid loading scheme and use sprite batch and you shouldn't really have to worry about performance all that much.  That said, if you make the GPU make hundreds of different texture loads per frame, your gammmmmmemeeeeeee wwwwwwiiiiiiillllllllll cccccrrrrrraaaaawwwwwwlllllll.

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!