Chapter 7 - Init, Main Loop, and Shutdown

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

  • Chapter 7 - Init, Main Loop, and Shutdown

    Lots of great new code in here, and it all works too, unlike the first book.
    Mr.Mike
    Author, Programmer, Brewer, Patriot

  • RE: Chapter 7 - Init, Main Loop, and Shutdown

    • i love, love, love the approach you use in the first couple pages of this chapter (Initialization 101) where you show the reader the good and bad ways to do things and you make it even better by walking through the entire process! this is dynamite and your book will benefit wherever else you can apply it. (like in the screen/game/view material!)
    • The error reporting system is a key system in a game.. you leave it as an exercise to the reader, but couldn't something simple be put in place? perhaps even at the end of Chapter 3 in your "grab bag of useful stuff"?
    • pg.7 first paragraph: "After I get through all of the initialization tasks, Ill dig into the main loop." throughout the rest of this paragraph you are using "We're now ready" and "We'll create the class".. there is no "I" in team! :)
    • pg10: "// We don't need a mouse cursor by default, let the game turn it on" really? why? i can see in the Breakout game but when I started to make my game I had to figure out where the heck the mouse went when I started to play!
    • pg13: the stuff on checking hard drive space reminded me about the material you had in the 1st version (pg30/31) about storage required for various artwork etc. have we lost that? i liked that.
    • pg34: i don't wholly understand the call to VRenderDiagnostics() and how it's used..
    • pg36: what is PROC_INTERPOLATOR?
    • pg39: "// note - an explicit reset() of m_pNext is not necessary here...." why?
    • I think we could really benefit from more examples of how to inherit from CProcess. I mean CWaitProcess is cool, but it's kind of trivial given the importance of CProcess and we don't have any guts for the CKaboomProcess.


    I'm really sorry, that's all I have for now.. I've been rushing through these chapters trying to get some feedback up in a timely fashion, and part of my trouble is I haven't had time to digest and understand the new code so please bear with me.

    The post was edited 1 time, last by Carse ().

  • Carse, I think feedback is best done in layers. As with coding, you start with a top-down approach, and make that general pass over the chapter. Then later, yo might come back to the chapter and give feedback on the finer points that you might have missed on your first pass... at least this is how I do it. You and I seem to have the same feedback style. :)
    ____
    You might get some disagreement from Electonic Arts executives on this point.

    You mispelled Electronic... hahahahaha! Wait til the executives find out what you did!
    ___
    Speaking of top-down, I love the way this chapter adds layers of complexity to the topic, starting with a simple and naive game loop/init sample.
    ____

    Source Code

    1. // A useful macro
    2. #define SAFE_DELETE(p) { if (p) { delete (p); (p)=NULL; } }

    Maybe this might be the wrong place for my suggestion, but I think it might be good to mention that different compilers have different behaviors in DEBUG when it comes to uninitialized variables and those tend to be a pain to debug when it comes to bugs that only occur unpredictably in RELEASE mode. I guess this would go in chapter three, maybe?
    ___
    The problem with this message pump is that theres nothing in the code to change the game state if there are no messages in the queue. If you changed the game state only as a result of receiving messages, you would only see animations happen if you moved the mouse.

    In the project that I am currently working on at work, my main loop does almost exactly that, yet I am still getting updates even when the mouse is still and there are no messages generated. You think maybe this may have changed? I know for sure that I am not sending WM_TIMER to solve this problem. Why am I not having this issue you speak of?
    ___
    You do not mention Shutting down on consoles...
    We are painfully aware of certain console games that reboot the machine to load new levels. Bad coding, this is. How did it get this way? I notice that KOTOR and many other games did this as well. One defense of this... sort of a defense came from Donavon saying that rebooting the console was what you were expected to do in the old days because iterating through destructors consumed time, and for consoles a warm reboot took no time to just wipe memory clean and start over using some temp files as the queues for a startup sequence. Is this a valid argument? Pros and cons of warm reboots on consoles.... I think this would make a good mini-discussion within this chapter as well as add some more console flavor to this chapter.

    There just aren't enough books out there that discuss console programming topics, and so I figure the more console-specific input you can squeeze into the chapters, the merrier. I guess the danger of this would be that people might complain that your book is jumping all over the place like some kind of dimensional traveler in a Sci-Fi novel, but maybe not.

    The post was edited 1 time, last by Kain ().

  • RE: Chapter 7 - Init, Main Loop, and Shutdown

    Here's how I tried to explain the VRenderDiagnostics call:

    A good example of how I use this is drawing physics information, such as mesh wireframe of any objects moving on the screen. The physics system is purely a game logic object, and the renderer really belongs to the game view. If you wanted to religiously follow the separation of game logic and game view, you'd probably have to do something like have the game logic create special "line" objects and send messages to the game view that it needs to draw these lines. Well, that's just dumb, in my opinion. A game logic should be able to use the application layer - in this case DirectX's renderer - to draw debug data onto the screen. Yes it breaks the rules, but yes you should do it.

    How's that?
    Mr.Mike
    Author, Programmer, Brewer, Patriot

  • RE: Chapter 7 - Init, Main Loop, and Shutdown

    On the size of art, meshes, etc. I'm moving that to the resource cache chapter - it seems to make more sense there.
    Mr.Mike
    Author, Programmer, Brewer, Patriot

  • We're done with Chapter 7

    This chapter actually got so big we split it up - the init and shutdown is in one chapter, and the main loop follows it in a new chapter.

    Thanks for all the great comments!
    Mr.Mike
    Author, Programmer, Brewer, Patriot