C++ 3D DirectX Tutorial [Window Framework] 6

The Partridge Family were neither partridges nor a family. Discuss.
Post Reply
BouncyKnight
Posts: 4
Joined: May 18th, 2019, 1:56 am

C++ 3D DirectX Tutorial [Window Framework] 6

Post by BouncyKnight » May 18th, 2019, 2:04 am

Can someone tell me if I am on the right track of thinking in the episode mentioned in the subject?

Do we use the singleton to avoid creating another class to handle the switch statements for checking msg?

Thank you!

User avatar
chili
Site Admin
Posts: 3825
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Re: C++ 3D DirectX Tutorial [Window Framework] 6

Post by chili » May 18th, 2019, 4:31 pm

Nah, I just create the singleton because there should only be one class for the WinAPI Wndclass data.
Chili

BouncyKnight
Posts: 4
Joined: May 18th, 2019, 1:56 am

Re: C++ 3D DirectX Tutorial [Window Framework] 6

Post by BouncyKnight » May 20th, 2019, 4:18 pm

Thank you! for the quick response! I understand that now.

Why all the "hanky panky" for handling messages in the window class, I mean why does HandleMsg need to be a member function? (Future reasons/experience?)

albinopapa
Posts: 3785
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: C++ 3D DirectX Tutorial [Window Framework] 6

Post by albinopapa » May 20th, 2019, 5:02 pm

The Win32 API is written in C and C has no concept of classes, so there is no requirement for HandleMsg to be a member function. However, since C++ has classes and classes are used to group similar data and behavior together, it makes sense to put stuff handled by the main window in MainWindow. For the chili framework it probably doesn't matter as much since there is only one window, but what if you had multiple windows? You can organize your message handlers by keeping them in the class that handles those messages instead of having multiple global functions.

Another good reason is in the chili framework, mouse and keyboard are stored as members of MainWindow and if you just had a global function, how would those members be accessed? You'd either have to make them static members, create accessor functions like GetMouse()/GetKeyboard() or just make them public and access them using a MainWindow* object within the message handler. So having the HandleMsg function as a member function, it now has direct access to members of MainWindow without any extra hoops.

NOTE: I don't remember the exact layout of the HW3D classes as it's slightly different than the chili_framework 2016 and the 3D fundamentals frameworks, but I think the reasons are the same. The Mouse and Keyboard objects are already public, but you still need an instance of the Window class to access them.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

BouncyKnight
Posts: 4
Joined: May 18th, 2019, 1:56 am

Re: C++ 3D DirectX Tutorial [Window Framework] 6

Post by BouncyKnight » May 21st, 2019, 6:01 pm

Thank you for the elaborate yet concise explanation!

I have a question though, is it a bad idea to make the keyboard and mouse static?

I did what you theorised in your second paragraph "You'd either have to make them static members" and made a static member function. Even if I had multiple windows now wouldn't that mean that each one just sends its changes through the static function to the static keyboard and mouse variables(and not their own individual copies)?

Also, I did not quite catch the problem that would arise if the HandleMsg function is not a member function if I had multiple windows. Can I not just get a handle to the currently focused window and then proceed with asking that window to respond to the input?

albinopapa
Posts: 3785
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: C++ 3D DirectX Tutorial [Window Framework] 6

Post by albinopapa » May 21st, 2019, 10:49 pm

The mouse and keyboard objects could in fact be static. Combine that with the singleton pattern and you get single instance global access to the mouse and keyboard from anywhere Mouse.h and Keyboard.h are #include'd. This I think would actually be fine for those two controllers. You definitely wouldn't want that for gamepads though.

My point about HandleMsg better off being a non-static member is the ability to access non-public members of MainWindow and for organization by way of keeping associated code with the MainWindow class.

As stated before, the chili framework being more game oriented has a single window and isn't really "event driven", isn't a good example of how having those functions as member functions is helpful.

Yes, as I alluded to before, these handlers for each window would be global functions or child windows would just get the messages processed with the same parent handler like buttons and menu items. Yes, those handler functions do get a copy of the HWND handle, so that can be used directly with the Windows API. You don't have to use object oriented programming paradigms with C++, you can just use functions and publicly accessible structs like C does and get all the benefits and features of C++ except classes. I think the point was with Object Oriented programming, you get data encapsulation and code organization which is arguably better in my opinion.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

BouncyKnight
Posts: 4
Joined: May 18th, 2019, 1:56 am

Re: C++ 3D DirectX Tutorial [Window Framework] 6

Post by BouncyKnight » May 22nd, 2019, 4:43 pm

Oh!!! I see.

Yep, I understand it now, thank you so much for taking your time to explain this to me!!

I also realised that the events were not really necessary for a game engine and hence wrote my class without any events, instead I use functions to check the current state of any key/mouse button.

Also, I do not know anything about gamepads so I will take your word for it and try to dig in deeper to understand them.

Once again thank you so much!

Post Reply