Windows supports raw input
If i decide to "take over the PC", looks like that's the way to get my mouse input. But i'm having second thoughts on not supporting recovery of lost devices.
Implementing a keyboard handler via AsyncGetKeyState rather than the windows message queue is a really bad idea. If the user presses and releases a key for a short period of time that doesn't overlap with the point in time where you poll for that key, then you won't detect that keypress.
i poll at a rate of 15 times per second. never had any issues. been using this method since XP, when BIOS interrupt driven keyboard support went away. I've been building games for a long time. Since before DirectX, even since before Windows itself. When windows came along, you saw what still worked, what they (microsoft) broke, and what would have to be done differently. You used windows where you had to and then got back to the real business of building games once you got the operating system out of the way again. I used to capture the entire keyboard state 15 times a second, and then test the results as needed. now I simply do GetAsyncKeyState on individual keys as needed (at a poll rate 15 times per second).
You could just, listen for that message in the message queue, and return the return-code that indicates that you handled the message, so that the OS won't pass it on to the default message handler.
This sounds like a nice elegant way to handle things.
But i'm already pretty much convinced i should "play well" with others and implement on_lost_device().
You can also give them the option to disable the windows key if you like.
Haven't tried that one, but yes, that's another focus buster there: "Focus, focus, lost my focus, where's that confounded device?"
If you want to reduce the chances of a lost device occurring in the first place, you can use a "fullscreen window" instead of actual fullscreen mode. You can run your game in windowed mode, but create a window that fill the entire screen, has no border or title bar, and is on top of everything else. This makes it as stable as regular windowed apps (which means it plays nicely with alt+tabbing) but looks like a fullscreen app.
No lost devices? Any other changes required other than going windowed vs fullscreen at startup? What window style is used in CreateWindowEx? I currently use WS_POPUP, with CS_HREDRAW | CS_VREDRAW for the window class.
The way I deal with lost devices is by having each module register up to 4 "handlers" - OnCreate, OnRelease, OnLost, OnReset - which then get called in the appropriate places.
Yes, this seems to be the architecture used in the Directx demos. Its probably as straight-forward an implementation as is possible.
If you were handling lost devices from WM_ACTIVATE messages then you were doing it wrong; you need to be checking for D3DERR_DEVICELOST from your Present calls instead.
Thats what I do. I added a check for 3d3_ok and d3d_device_lost after I present() a frame. but then i just display a lamo error message and exit - I know, LAZY!
That's a misinterpretation of the docs; the intention is to warn against a common beginners mistake (which may be seen when porting from e.g. OpenGL's immediate mode) which is to create and destroy e.g. a vertex buffer each frame during normal operation.
so its performance related, and not about memory fragmentation? I can't remember off hand where i saw it, maybe a Chuck Walburn (sp?) post on MSDN? It was definitely from Microsoft. They seemed to be advising against dynamic loading during gameplay, due to fragmentation issues and the hazards of getting your reference counts screwed up and therefore memory leaks.However i do understand that paging of level data (meshes, textures, etc) is done everyday in games like FPS's.
Now what about the load times? Right now i load everything at program start. everything goes into D3DPOOL_DEFAULT, plus there are 20 D3DXMESH_DYNAMIC meshes (probably in managed pool). load times are about 10 seconds. pretty much everything would have to be reloaded into vidram on lost device. So 10 seconds load time every time i task switch back to the game, right? Yuk!
"DirectX is like a belt fed machine gun, where every texture change is like hand loading in a new belt of ammo. worse, every mesh (vb) is a new belt of ammo, and a texture is like breaking the gun down, and setting it up again elsewhere, then loading it, then spraying triangles again. so you want to setup the gun once, string all your belts together, load it once, then just spray."
Rockland Software Productions
"Building PC games since 1988"