Class Inheretance & KeyBoard

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

    • Class Inheretance & KeyBoard

      Hi Guys,

      After several weeks of research and design tweaking, I'm faced with several problems which I hope you guys can shed light on. First the inheritance question;

      I have "CWinApp" that deals with only windows functionality , and CMyEngine which deals with graphics functionality, (Credits, particles, GUI, etc.) I inherit "CWinApp" from CMyEngine" as "Has-A" (as apposed to "IS-A")

      Source Code

      1. #include "CWinApp.h"
      2. class CMyEngine
      3. {
      4. ...
      5. public:
      6. CWinApp WinApp; <<-- Inherete CWinApp as "Has-A"
      7. ...


      I have "LRESULT CALLBACK CWinApp::MsgProc( HWND hWnd, ...)" to handle keyboard messages (which is static) and in "CEngine" I have the same function. What I do is pass any and all messages from my CWinApp to the "MsgProc" in "CEngine" (none static). Once keyboard and mouse messages get to the "CEngine", I can split up the messages and route them to different functions. (Keyboard messages will get routed to Keyboard functions, mouse messages will get routed to mouse functions).

      Source Code

      1. // Handle input messages that come down the pipeline from CWinApp. Messages get split up here.
      2. ...
      3. void CEngine::OnMouseDragged( ... )
      4. {... }
      5. void CEngine::OnKeyRelease( ... )
      6. {... }
      7. void CEngine::OnKeyPress( ... )
      8. {..}
      9. ...
      Display All



      Heres the problem, in the "CWinApp::MsgProc(...) ", I have to do this:

      Source Code

      1. LRESULT CALLBACK CWinApp::MsgProc( HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam )
      2. {
      3. ...
      4. case WM_KEYUP:
      5. case WM_KEYDOWN:
      6. {
      7. MyEngine.MsgProc( hWnd, uMsg, wParam, lParam ); << -- NOTE: I'm supposed to be inhereting FROM CWinApp, not "looping back" and doing this!!!
      8. break;
      9. }
      10. ...

      Keeping in mind that I am inhereting CWinApp from CMyEngine, I have to "break some rules" by essentially doing this . By making CEngine assessable to all objects (global scope ?), I can get it to work, however this seems to be messy and sloppy. Is there a better way? Any thoughts or comments as to what I am doing?

      Follow-up:
      Since I am using the "Has-A" concept, how about "IS-A"? Any arguments, comments??



      S.
    • RE: Class Inheretance & KeyBoard

      To my way of thinking you model is backwards
      In my own homebrewed game engine my cApplication object contains references to my cRender (graphics) and cEventsHandler objects
      My cApplication contains WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) that handles messages coming from Windows. Windows itself wasn't designed with truely OO event processing so I've always found it based to have concerned classes have FilterMessage routines that are called before any other message handling. sort of like what your doing.

      One thing i wouldn't do is filter messages in in the application class WindowProc and call event handlers that way. There are a few messages that aren't strictly input or paint requests that can affect the engine sub-systems. Just as one example WM_ACTIVATEAPP,sent when an application activated or deactivated, can tell the input system to unlock a captured mouse or recapture it when the game application is activated again.
    • That's something that we've used before. The delegating static function.
      Feel you safe and secure in the protection of your pants . . . but one day, one day there shall be a No Pants Day and that shall be the harbinger of your undoing . . .
    • Somewhere I read something - or perhaps even wrote something about this!

      In fact - you can take a look at the GameCode Complete source code - version 2.2 - for how I like to solve this problem.

      Basically - The application object, in this humble authors opinion, should live as a singularity. The book describes an object called GameCodeApp - see it defined logically in Chapter 2 and actually in Chapter 5 (both in the 2nd edition).

      The application object should do things like you propose - grab operating system specific events and send them along to your non-operating specific game engine.

      I expect your game engine, CMyEngine, describes the game world - and therefore shouldn't be a part of the application object at all. It should be congruent to the BaseGame object I describe in Chapter 6 - and its purpose is to implement a very basic game simulation that is described by the following interface:

      Source Code

      1. class IGame
      2. {
      3. public:
      4. virtual shared_ptr<IActor> VGetActor(const ActorId id)=0;
      5. virtual void VAddActor(shared_ptr<IActor> actor, struct ActorParams *p)=0;
      6. virtual void VRemoveActor(ActorId id)=0;
      7. virtual bool VLoadGame(std::string gameName)=0;
      8. virtual void VOnUpdate(float time, float elapsedTime)=0;
      9. virtual void VChangeState(enum BaseGameState newState)=0;
      10. virtual void VMoveActor(const ActorId id, Mat4x4 const &mat)=0;
      11. };
      Display All


      I'm not sure if this helps much - but you asked one of those questions that can have a very big, and somewhat controversial answer.
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • RE: Class Inheretance & KeyBoard

      While this is an application/OS question, as you'll be writting different handling code on every platform you support, you should definately do something like the folks above have said and seperate this(and the rest of your application level code) from your engine. This also isn't a really good use of inheritance in my opinion as your application code "Is not A" offshoot of your game engine. You'll have a much better time if you seperate rendering/engine code from your win32 code. It makes each much more generic(in general, for what you'll need in win32 game development, it can be completely re-usable).

      The next step above this(sorry if I'm re-iterating someone else's post), is to actual abstract interaction between alot of your managing structures and event driven object by using a messaging API. These are pretty efficient if you keep them light, and will let you keep your code much cleaner.

      Hope this helps :)
    • RE: Class Inheretance & KeyBoard

      Hi guys,

      MyProject

      The file does not contain the entire project, but it does have the basics for making a demo. Heres what I'd like you guys to do, please. Offer your comments and suggestions. Do what ever you want with these files. This is not really a game, but I am hoping to make SOMETHING out of it, so I'm not sure if MrMike's code is helpful in some areas of this project.

      Here is what the demo will do;

      1) Show splash screen and wait for demo to load.
      2) Show dazzling introduction scene.
      3) Show some amazing background scene while the user waits to click some button to load/config the acutal demo. (User has access to a drop down console.)
      4) Sit back and watch heart pounding, eye popping effects!
      5 ) Show Credits with amazing graphics!
      6a) Goto #3 to exit or watch again.
      6b) Goto therapist to have horrific images of this demo erased from memory with meditation (or self-medicate with lots of beer!)

      Thanks guys.

      Me.

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