• Advertisement
Sign in to follow this  

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

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