It is trivialy easy to get rid of WinMain and start windows app from "standard" main instead. But is there any way to get rid of windows procedure as well and do your own poll of input devices? In case when we run in fullscreen there are not many window related messages to process but input. I am just interested if there is some way to call nt services directly and go around win proc entirely to do keyb/mouse/joystick polling instead or one is dooemed to go through winproc? Creating windows class with window proc sett to 0 of course crashes app directly after initialisation :-), but if one create empty winproc, windows will obvioulsy generate all messages as usually, it is just that we are not handling them, but overhead is still there. Actually even if we don't register a winproc, windows will probably generate all messages anyway, it just crashes when it tryes to pass them to the app. So I wonder if there is some way to entirely bypass win32 layer, and do windowing through the kernel itself. I know it is not a trivial thing, just wonder if anyone has tryed (and succeeded) with that?

Quote:
But is there any way to get rid of windows procedure as well and do your own poll of input devices?

Not really.

Quote:
In case when we run in fullscreen there are not many window related messages to process but input.

False assumption; there are many messages that a well-behaved application should process beyond simply input.

This isn't really feasible to do in userspace, and it's not really any kind of "overhead" at all. If you're running under the OS, you're going to play by the OS's rules. It's going to send you those messages whether you like it or not, and just because you don't have a procedure to handle them, doesn't mean they will not get handled. You'll just spend your time doing the default processing. Even if you took the appropriate drastic steps to go around it, you'd just end up reinventing half of it since you won't get those messages you think are important anymore -- you won't get anything.

You should not be concerned about it whatsoever in terms of overhead. Calling main() consumes 100% of your applications time anyway. Do you want to remove that? Removing the window message pump procedure is only slightly less drastic.

If you don't like dealing with it, just wrap it. But it doesn't cost you anything.

DI hooks the window procedure, though. Sure, you may be able to "look like" you're avoiding the procedure, but it's still there -- it doesn't address the OPs misplaced concerns about the 'overhead' of the procedure, which are basically unavoidable if you're going to be running under the OS.

What you have to give up to get rid of the procedure completely is essentially every OS service you're used to having. It's 100% not worth the effort.

Quote:Original post by rip-off
In any case, Microsoft have deprecated DirectInput (unless you are using joysticks), so I'm guessing no.

Has DirectInput been depreciated? Man, I am gonna have to re-write all of my input classes.

What has it been superceeded by?

Quote:Original post by rip-off
In any case, Microsoft have deprecated DirectInput (unless you are using joysticks), so I'm guessing no.

Has DirectInput been depreciated? Man, I am gonna have to re-write all of my input classes.

What has it been superceeded by?

Quote:Original post by lonewolff
Has DirectInput been depreciated? Man, I am gonna have to re-write all of my input classes.

What has it been superceeded by?

XInput, which works for Windows and XBox360

Quote:Original post by Rattenhirn

Quote:Original post by lonewolff
Has DirectInput been depreciated? Man, I am gonna have to re-write all of my input classes.

What has it been superceeded by?

XInput, which works for Windows and XBox360

Plain WinAPI messages (WM_KEYDOWN, WM_MOUSEMOVE et al) were also recommended for some time (DirectInput being a wrapping layer over those), although it might not be the case anymore now that XInput exists.

List of reasons not to use DirectInput for any sort of keyboard or mouse input