Controls classes and sound

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

    • Controls classes and sound

      Hi guys. First and foremost, read the book, and absolutely loved it! Gave me insight that other books just don't do. I've got LaMothe's Tricks and Tips of windows game programming gurus, also a few others, but none go into depth on anything aside from DirectX.

      Anyway, I just need a bit of help with my User Interface code. I've created a graphic button class as follows:

      class GraphicButton : public BitmapSprite
      {
      protected:
      bool focus;
      ...etc
      public:
      virtual VOnMsgProc(AppMsg msg);
      virtual VOnUpdate(const int deltaMilliseconds);
      ...etc
      void OnMouseOver();
      void OnMouseOut();
      void OnClick();
      }

      Most of my GUI classes/components have been implemented this way.

      Anyway this seems to work fine, the bitmap series loops when Mouse is Over it, goes back to frame 0 on mouse out, and clicking it will pass a result stating this button has been clicked to the calling code (i've used my own Screen classes to receive this msg to do something useful).

      I know the problem might seem basic, but what I want to do is actually to add sound. I can do it when I add a smart pointer and launch the CSoundProcess, but because the button is declared in a seperate header file. UserInterface.h, it needs a public access to a ProcessManager.

      I considered implementing another ProcessManager in my ScreenManager class. Or would I have to actually send an event to the sound sub system???
      If you put your mind to it, you can accomplish anything.
    • Note that I am a complete noob, however, that does "sound" to me like a perfect example of when to send an event.

      When a GUI button is clicked it probably doesnt do anything "itself", it just sends a message/event to any game systems that should do something in response to it... or more likely, it enqueues the event in the eventmanager, which then sends it to all registered game systems.

      So if you register your sound system with the eventmanager to receive any "button click" events, then when it handles that event have it play whatever soundfx you want.
    • That's not a bad way to do it - but there are a ton of ways to skin this cat.

      You could argue that since UI sound effects are really contained completely with the Human View of the game, and shouldn't burden the event system with calls to make button click sounds.

      You could have a process manager in the HumanView to manage sound effects, animations that don't affect the game state, and things like that. When you consider what it would be like for a HumanView to be remote (like in a network game) this makes even more sense - why send a network event to play a sound effect for the GUI?
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • now i'm curious...

      If you process input in a separate process, wouldn't you still need to send messages to this "UI" process? How do you suggest avoiding that?

      Maybe... you could first check in your input process if it was a mouse interaction with a UI event, then do the manipulations there by keeping a reference to your UI system inside your Input Process, then only sending messages to do other game events if this is NOT the case... well that would avoid sending messages but I doubt that was what you had in mind Mr.Mike.

      If your UI system also manages time-based animations you would need a process (i think) but if the animations you were refering to are all button related then would you even need a separate UI process? What I'm invisioning would be a UI system that is referenced by the input process.

      For a button that DOES affect game status, i guess you would have to send events to other systems, but why did you single out UI buttons/animations that do not affect gameplay?

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

    • RE: now i'm curious...

      I like the way Mr Mike has suggested, as then the button class is completely encapsulated with its own sound effects and animations. This will also save you having to send round more events that I believe aren't really necessary. However, in TeapotWars the ProcessManager in the HumanView is declared protected. Would I need to then either declare the Button class as a friend of the HumanView, or make the the ProcessManager a public member??

      The way I was thinking it about before was to actually move the ProcessManager from the HumanView into my ScreenManager class, because if you think about it, the TeapotWarsScene is just another screen, and hence sound effects can still be launched with this method. Would this be a good way of doing things? As i do want my ScreenManager to be a top level system, to handle all the different interactions between screens.
      If you put your mind to it, you can accomplish anything.
    • Perhaps thats the only caveat. What I'm actually using is the Polygon structure and the PolyHitTest Mr Mike mentions in the book, whenever this function returns true within the VOnMsgProc function its registered as MouseOver if its a mousemove event, or button clicked if its a LeftBtn down event.
      If you put your mind to it, you can accomplish anything.
    • RE: now i'm curious...

      I'd say that the HumanView is a container for a few things that could certainly include a ProcessManager and a ScreenManager.

      This ProcessManager might handle generic processes that don't need visibility to the game state - like anything UI.

      You should try it your way as an experiment, and let us know hiw it turns out!
      Mr.Mike
      Author, Programmer, Brewer, Patriot