question about class function

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • question about class function

      There is a class function in the book that i don't understand. On page 501, there is a VOnUpdate function, what is that doing? As far as I can see, it just make recursive calls VOnUpdate throughout the entire scene graph hierarcy, and nothing else, isn't that true?

      If that is the case, it doesn't really update anything. It isn't even using elapsedMs, just passing it on...

      Shouldn't the function do something before calling all childrens? the image i have of update in this class is for example, updating position, rotation, animations, etc...

      Am I totaly out of the structure?

      Also, to the author, here's a comment on the book; it's really great, but I thought it was hard to understand the structure. I had to look through the entire book's source-code to understand how to understand the interaction between application layer, game logic and game views.

      I think it would been much better if you would have described the architecture a little more in the beginning.

      For example, where should I put the entire virtual "world"? like all objects, so that the game view can access the positions ( matrix transformations, chapter 13 is especially awesome, I really like it :D ) and the logic can check collisions, where to put it?

      The scenario I has, is that the world should be in Logic, but how is the views going to get the positions? Through the event-system or what?

      Sorry if this has been asked before, I'm new at this site, and thank you, Mr. Mike, for the greatest game-coding book ever written... :D
      "There are of course many problems connected with life, of which some of the most popular are: Why are people born? Why do they die? Why do they want to spend so much of the intervening time wearing digital watches?"
      -Douglas Adams
    • RE: question about class function

      The call to VOnUpdate() throughout the scene graph heirarchy is meant to touch every node in the scene graph so that node data can change from one frame to the next. You might do this to create an animation, for example, by changing the rotation of something a few degrees every second.

      To do this you'd create a custom class, overload VOnUpdate() and do your extra updating work. The function SceneNode::VOnUpdate() just makes sure that children nodes get the call too.

      The explantion of game architecture is actually at the beginning of the book in Chapter 2. My goal was to show the high level, and then explain each component in later chapters. Maybe the 3rd edition should contain a poster or something you could refer to as you are reading later! Until then, maybe give Chapter 2 another read and see if that helps.

      The positions of things are actually in both the view and the logic. This might seem redundant but it's not as bad as all that. Let's say you have a game object, like a teapot, at position (1,2,3) in your world. The game view will have all of the data it needs to draw it, such as the list of polygons in model space and the textures. The game logic will have the physical representation of the game object - such as the collision hull and any important "logic-ish" properties such as the weight, and maybe how many cannon balls it has.

      It does seem like there's a lot of redundant data - especially if the collision hull of something IS the exact same as the geometry. But, consider for a moment WHERE the visual representation is likely stored: completely in video memory. For those platforms where this makes a big difference, like the PC, its ok for the copy to exist because you get a huge boost in performance.

      It is also likely that the data for the visual representation and the physical representation will need to be formatted completely differently for the special needs of the system using it. For example, a physics system will likely sort (x,y,z) vectors of polygons completely differently than a renderer would.

      So - even though it looks like you are storing something more than once, you are really converting source data into special forms that can be processed by systems that will use it.

      Does that help?
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • That was very helpful, thank you. I have been scratching my head for some time now, especially about the connection between logic and views. :)

      I have read the book pretty much, and everytime I read the book and threads here at the website, I discover clever things about the structure.

      I have recently begun to code my first 3D game engine (after very much planning and structuring), so the book has been, and is going to be a great help. :)
      "There are of course many problems connected with life, of which some of the most popular are: Why are people born? Why do they die? Why do they want to spend so much of the intervening time wearing digital watches?"
      -Douglas Adams
    • That's an interesting idea - I wonder if I couldn't put an appendix in the 3rd edition that shows all the relationships.....

      Does anyone know of a coolio automated dooddad or Visio plug in that does this?????
      Mr.Mike
      Author, Programmer, Brewer, Patriot