How much use of Win32 [message loop] is generally acceptable in a robust game? I am doing a game with some friends from school, and the guy doing the GUI says he wants to rely on win32 messages like WM_CHAR, WM_LBUTTONDOWN, etc to drive his GUI, among other things. Also by his design, the framework also has MsgProc''s inherited all the way down, it''s proliferated in pretty much all the game code. Every game state gets win32 messages passed down to it... basically the win32 message proc is present all through the game code. Now I don''t have much experience in using win32 in actual games, but instinct (and the fact that win32 is not made for games) tells me it''s slow and not really suitable for the task. Is that a correct assumption? What are really the pros and cons? Thanks..

u could try to do the GUI with crappy windows messages and the game with DInput or GetKeyState() for the input.

i prefer using GetKeyState() for everythin although i when doing input (like getting a string form keyboard ) i have a harder job
also u have to translate key codes to key names (ex VK_UP - UP KEY)

and with GetKeyState() or DPlay u have to check urself for KeyDown (just key is down) or KeyPress (key was down but released) and it''s much harder to make input boxes and stuff.
key repeat delay and key repeat rate is another prob.

but i''d stick with GetKeyState()

I''m talking about in-game GUI for a fullscreen game. For example, the options screens in Unreal Tournament 2003. Not just some windowed "generic application"

The point of hesitation is Unicode. WM_CHAR apparently gives you info relating to unicode stuffs, whereas DirectInput doesn''t (not unless you do it yourself). Since we''re pressed for time, I rather work on other more important stuff than supporting Unicode... unless it''s completely trivial?

Question is, is Unicode support worth the performance hit of using win32 messages? How big of a hit is it compared to an efficient DirectInput wrapper?