Jump to content
  • Advertisement
Sign in to follow this  
calvin940

Game Design Question: Where to Render() ?

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

For my 2D sidescrolling platformer, I am trying to figure out where a Render() member function be located in my object classes or should it be in the main code? TO be more specific, I have say moveable objects like rocks. I have other objects called character (which I use to govern movements, interactions etc for my hero main character) and which I extend into a baddie class to use for enemies and extend/customize with AI for chasing/attacking my character. THe Question is, should I be putting in Render member functions in my object classes or should I be designing them in such a way as to create member functions to provide render details back to the main program loop/engine/(whatever you want to call it) and have it render the scene. I have no experience with this and while trying to figure out what to do, I am unsure of what things to consider and what the best design is. Any thoughts from you folks would be greatly appreciated. Cheers Calvin

Share this post


Link to post
Share on other sites
Advertisement
Model-View-Controller. An object has a model, which describes its state (where it is, how it moves, and so on), a view, which describes its aspect (how it can be rendered) and a controller (synchronize the model and view, allow external access to the entire object).

I would have the game provide the controller at construction time with a "graphics" object, which is then passed to the view, which registers some kind of avatar (a sprite, a model) within that graphics object. The avatar is then rendered until the view disappears and unregisters it.

Share this post


Link to post
Share on other sites
Thanks for your reply. I am aware of the MVC approach, but do not understand it fully as of yet. I believe though that my character class does somewhat conform to that (I will have to do some reading), but from a practical term where you talk about the controller, would I pass the device over to the character class and let it have it's way (ie character creates the sprite, actually draws the object a la m_pSprite->Begin/End m_pSprite->Draw etc or should it be handing back the information to the main program to perform this.

Sorry if my question still shows my lack of understanding. Trying to wrap my head around it. Thanks very much for your input.

Calvin

Share this post


Link to post
Share on other sites
Ideally, you'd want to work with a 'describe once' approach: instead of drawing a sprite every frame, the view specifies once that a sprite is to be drawn every frame at a given position, and merely updates the position. This way, you can let the device know the entire set of sprites to be drawn, and decide based on that perfect knowledge which can be drawn, which can be culled, and which LOD can be used for each.

Share this post


Link to post
Share on other sites
Hmm...

I may be misunderstanding, but isn't this the usual approach?

Update:
pre-process...
insert into renderlist.
...

Render:
Get visible
Sort
Render

Is this MVC?

Share this post


Link to post
Share on other sites
Quote:
Original post by Rasmadrak
I may be misunderstanding, but isn't this the usual approach?


I don't know what you mean by 'usual', but it doesn't reflect what you described:

Quote:
Update:
pre-process...
insert into renderlist.
...

Render:
Get visible
Sort
Render


For a given object, it would look like:

Init: insert into renderlist
Update: move around
Die: remove from renderlist

So that the actual update doesn't add stuff to the renderlist (or care about rendering at all).

Quote:
Is this MVC?


This is independent of MVC (you may use this with or without MVC, and you may use MVC with or without this).

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!