🔒 Locked

Having a "renderer" object?

Started by TFS_Waldo Mar 25, 2006 at 5:22 PM 3 replies 600+ views

Original Post

Mar 25, 2006 at 5:22 PM

Okay, so I started working on a simple game using SDL today. It's aimed to be 2D, and I don't plan on making it very big. I just want my very first WHOLE game. LoL. =P Anyhow, I was thinking about different ways about handling rendering the scene, input, etc. Right now, I'm working on rendering. I currently have a window class, 'CAppWindow', and a basic sprite class, 'CSprite', and a 'CRenderer' class. Now, I was wondering if having a "renderer" class was a good idea. Instead of drawing each object in the "Render()" function, I just call "g_Renderer.Render()". In the "CRenderer" class, just for sprites right now, I have a vector, "std::vector m_pSprites", that holds sprites. There are also two other functions, "AddSprite(CSprite *pSprite)" and "RemoveSprite(std::string sName)", add a sprite to the vector object, and remove a sprite from the vector object. When I call "CRenderer::Render()", it draws each sprite object in the vector to the screen. Is this a good idea? Or should I take another approach. I've never really REALLY tried to make a game. So I'm trying to get others' opinions on this. I hope this is enough information. I figured a renderer class would be alright, since I don't have more than intermediate experience in game development. If you need anymore information please let me know. Thanks in advance, Matt U.

supagu

Mar 25, 2006 at 8:04 PM

This is effectively what i do in my 3d engine,
Once you create a mesh you can add it to as many renders as you like. This works really well, and allows me do do special effects easily.
Eg. I have main renderer, then a reflection and refraction renderer.

This also allows me to sort my objects, they are sorted when inserted, by material/shader etc.

Bob Janova

Mar 26, 2006 at 6:11 AM

In a general sense, having a separate renderer is a good idea, because it can keep track of information that might make rendering easier or faster. (For example, if many objects use the same sprite it could draw them all at once.)

TFS_Waldo

Mar 26, 2006 at 7:38 AM

Alright, I did something useful on my own. LoL. =P J.K. But thank you both for the comments. =) I'll be back if I need anything.

matches81

Mar 26, 2006 at 7:46 AM

I have a seperate Renderer, too. When rendering a frame, I add the visible meshes (sprites in your case) to the Renderer into a list. The meshes contain all information needed to know how to render them (textures, shader, bones and so on. In your case this would probably come down to texture, position, rotation and size).
The list of visible meshes then gets sorted by shader and texture (again this would be the sprite texture in your case) and finally gets rendered. This way I can rather easily do batching (rendering as many meshes / sprites with one call as possible for greater performance). So the job of my Renderer class is to render all meshes I throw in there in the most efficient way (well, at least in theory).

However I have a second class called Scene which contains all the meshes that make up the level (and other stuff like lights and cameras). I store these seperately because not all of the level will be rendered every frame and the Renderer should only contain the meshes I want it to render in the current frame.
So, the Scene does the visibility determination for a given camera and sends the visible objects over to the Renderer, which does its job afterwards only using the meshes that are visible.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.