Game Design Question: Where to Render() ?
Author
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
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.
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.
Author
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
Sorry if my question still shows my lack of understanding. Trying to wrap my head around it. Thanks very much for your input.
Calvin
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.
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?
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?
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).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
