Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Welcome to the new platform of Programmer's Heaven! We apologize for the inconvenience caused, if you visited us from a broken link of the previous version. The main reason to move to a new platform is to provide more effective and collaborative experience to you all. Please feel free to experience the new platform and use its exciting features. Contact us for any issue that you need to get clarified. We are more than happy to help you.

Skeleton Window's event handler function for games.

I've seen plenty of questions about what the Window's main loop for a game should look like, but never any on what the event-handler function looks like. What does the basic skeleton event handler need to have in it (for games).


I have WM_ACTIVATEAPP to determine when the game is minimized/restored, and WM_DESTROY.

I added a section for WM_PAINT just to shut Windows up so it wouldn't keep sending them. I just used a BeginPaint()/EndPaint() pair, but is there a more efficient way? (I don't care about WM_PAINT, I just don't want to keep getting it sent).

I also added a case for WM_SYSKEYDOWN/UP and WM_SYSCHAR because I was having big trouble when trying to use the ALT button in my game. Evidently Windows stops my program because it thinks it should activate the program's menu, even though I don't have a Window's menu (stupid Win). I was hoping DirectInput would stop that stuff, but evidently it doesn't.

The only other thing I thought of is to maybe catch the WM_CHAR event just so Windows won't have to go and process it.


That's what I have. Is there anything else i should have. Are there other msgs that I should catch just so windows won't have to process them?


Rock




Comments

  • : I've seen plenty of questions about what the Window's main loop for a game should look like, but never any on what the event-handler function looks like. What does the basic skeleton event handler need to have in it (for games).


    : I have WM_ACTIVATEAPP to determine when the game is minimized/restored, and WM_DESTROY.

    : I added a section for WM_PAINT just to shut Windows up so it wouldn't keep sending them. I just used a BeginPaint()/EndPaint() pair, but is there a more efficient way? (I don't care about WM_PAINT, I just don't want to keep getting it sent).

    : I also added a case for WM_SYSKEYDOWN/UP and WM_SYSCHAR because I was having big trouble when trying to use the ALT button in my game. Evidently Windows stops my program because it thinks it should activate the program's menu, even though I don't have a Window's menu (stupid Win). I was hoping DirectInput would stop that stuff, but evidently it doesn't.

    : The only other thing I thought of is to maybe catch the WM_CHAR event just so Windows won't have to go and process it.


    : That's what I have. Is there anything else i should have. Are there other msgs that I should catch just so windows won't have to process them?


    : Rock


    Why don't you just skip the entire Win programming (that method), and switch to WinAllegro. It handles the DirectX stuff (DirectInput, etc.) and it's free. It's also easy to use and produces nice graphics.


    Goto http://members.xoom.com/onestone/allegro.htm and download a copy. Soon Allegro will be version 4.0 which will be able to be used multi-platform.


    -Xotor-


  • : Why don't you just skip the entire Win programming (that method), and switch to WinAllegro. It handles the DirectX stuff (DirectInput, etc.) and it's free. It's also easy to use and produces nice graphics.


    Someday I'd like to look into Allegro, especially if it goes Linux (or does it now?), but I don't have the time now, and I'm not generally a fan of high level APIs. DirectX isn't the problem though, its the one Windows function that is the problem.

    But if it doesn't use this Window's method, then I assume your talking about a console app? I don't really want to go that route.


    Rock


  • : : Why don't you just skip the entire Win programming (that method), and switch to WinAllegro. It handles the DirectX stuff (DirectInput, etc.) and it's free. It's also easy to use and produces nice graphics.


    : Someday I'd like to look into Allegro, especially if it goes Linux (or does it now?), but I don't have the time now, and I'm not generally a fan of high level APIs. DirectX isn't the problem though, its the one Windows function that is the problem.

    : But if it doesn't use this Window's method, then I assume your talking about a console app? I don't really want to go that route.


    : Rock


    I think that there is a Linux port of Allegro. Also they're making the version 4.0 which will support nearly any and all major OSes on the market.


    I'm not talking about a Console app either. WinAllegro (you can also try the WIP version) uses Direct X for graphics but uses the Allegro functions for the programming. It makes programming graphical games/apps on any platform a breeze. It's nice because Allegro will soon become platform independant (or rather it just supports a lot of platforms).


    Allegro (the WIP version), supports UniEncoded (I think that's the term) text. That means that it supports huge ASCII character sets (like ones that would be used in Japan or China).


    -Xotor-


Sign In or Register to comment.