mouse input without windows messages ?

Eek.

You don't want to do this.

You may think that your program should have full control over everything, and that it shouldn't have to play nice with other apps, but I can assure you that a large proportion of your potential users don't share this thought. They're going to want to switch away, run other processes, etc; that's a pretty basic expectation and if you can't play nice with that expectation then they will be annoyed at you.

Taking full control of everything in the manner you describe also quite spectacularly fails the Raymond Chen "what if two programs tried to do this?" test - "When two programs duke it out like this, you can't predict which one will win, but you can predict with 100% certainty who will lose: The user."

So no, sorry to have to be blunt about it, but your program is not so awesome that the user will gladly let it take over everything in the way you want.

Yeah, maybe I'm just being lazy...

I know that OnLostDevice() _CAN_ be done correctly if one is careful about it.

I just wish the HP support software installed on my PC didn't force a full screen refresh on launch. It loads in the background and causes a lost device about 2-3 minutes after logon. Just enough time to logon, fire up a game, and then lose focus, usually resulting in a crash. Oblivion can usually handle it if it completes loading the savegame and the current level first. Other games, not so well.

It _would_ be nice to be able to switch away from the game and back again. due to the design, there's actually very little (codewise) to restore. timewise is another issue though, as everything is loaded once at program start and almost all into vidram.

Windows supports raw input http://msdn.microsoft.com/en-us/library/windows/desktop/ms645543(v=vs.85).aspx which allows you to read the mouse, keyboard, joysticks, ect... You still use the windows message queue, but you have alot more control over what/when you get data.

that meant you could use AsyncGetKeyState for keyboard, INT 31h for mouse, and didn't need a windows message processor at all.

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. The user will have pressed a button and you game will have missed it. If you listen the the message queue, you'll correctly receive the press and release messages, no matter how frequently/infrequently you poll the queue. You also get some other useful stuff, like the ability for keys to be converted into characters according to the user's locale for text input, as well as keypress inputs...

What's wrong with using the message queue? It's there for a reason -- to separate applications from the hardware so that device drivers can correctly exist in the middle. This way, the device driver can be responsible for knowing how to handle the many different types of hardware out there and translating their inputs into a common structure. As above, it also ensures that your application doesn't miss out on any messages (unless you receive a LOT of messages and poll the queue VERY infrequently).

the nice thing about this was that Alt-Tab messages no longer got processed

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.

However, if you're going to do this, you should really make it an option that the user can enable in your menu, because it's a standard convention when doing anything on Windows that the alt+tab combo will work at any time. Breaking conventions like that is really unfriendly to your users; giving them the option to disable alt+tab if they choose to is much nicer. You can also give them the option to disable the windows key if you like.

right now, instead of attempting to recover a lost device, i simply exit with a message saying a background process took vidcard access away from the game, and recommend closing any interfering processes and restarting the game.

That's really bad. It's my PC. If I need to quickly alt+tab to reply to an email or order a pizza, and your game quits as a result, then your game is at fault. It would have to be pretty amazing for me to keep playing If I want to be restricted to only running one program at once, I would still be running DOS instead of Windows.

It's not hard to manage a lost device -- whenever you create any of the resources that need to be recreated, store a pointer to them in some kind of "manager". When you handle the lost device, you've then got a list of resources to recreate in the one spot.

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.

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.

By the way, and this is a very important point, lost device handling is not only for Alt-Tabbing. See http://msdn.microsoft.com/en-us/library/windows/desktop/bb174714%28v=vs.85%29.aspx

By design, the full set of scenarios that can cause a device to become lost is not specified

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.

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.

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!

That's why D3DPOOL_MANAGED exists; so that you don't need to worry about this. The driver will handle it for you, and believe me, the driver knows more about what's best for it's own internal architecture than you do. As a general rule - unless the docs explicitly say that you need to use D3DPOOL_DEFAULT (e.g. depending on your D3DUSAGE) you should be using D3DPOOL_MANAGED. Task switching is not a 10-second job with this; it goes down to well under a second (and any video mode changes required if using a fullscreen mode will likely take longer than resource recreation) - don't assume before you have actual facts and measurements to back things up.

You're falling into a few traps here. First off you're worrying about memory fragmentation before you've even determined that memory fragmentation is even a problem for you. There's a name for that - pre-emptive optimization. Secondly, you're basing your performance assumptions only on factors you can directly measure in your own code, whereas in reality there are a whole heap of factors outside of your code and that you can't directly measure that also come into play.

You're also still equating dynamic creation and destruction of resources during gameplay with the destruction and creation required during lost device recovery, and that's a huge mistake because they're not the same kind of thing. Lost device recovery is a response to an abnormal operational state, not something you do on a regular basis. When a lost device happens everything that was in video RAM gets chucked out; you're starting from a clean slate again and fragmentation is not a concern. Let me re-emphasise - this is not a normal operational state, this is not something that you do every frame. The warning against dynamic creation/destruction applies if you're doing it every frame, lost devices are a special case.

As a general rule - unless the docs explicitly say that you need to use D3DPOOL_DEFAULT (e.g. depending on your D3DUSAGE) you should be using D3DPOOL_MANAGED.

I could have sworn that default was the recommended usage, and managed was for special cases (maybe like stuff you reload on lost device? ). guess i'd better look it up again. as i recall, with managed, the driver handled restoring vidram as needed, but it ran slower (perhaps because of a need to confirm sync between the two copies?). there was some downside i recall. I'll look it up again. maybe i misinterpreted it.

First off you're worrying about memory fragmentation before you've even determined that memory fragmentation is even a problem for you.

to tell you the truth, i'm not really worried about that, i've always been very good at making sure my mallocs and frees (so to speak) match up.

my only concern is load time. i can see how having the assets in managed would be faster than reloading to default from disk.

I found it interesting to note that Oblivion doesn't support Alt-Tab.

I found it interesting to note that Oblivion doesn't support Alt-Tab.

I'm just curious why you want to "take over" someone's PC? What is it about Alt-Tabbing that you just hate so much that you feel you have to take over complete control? What if someone is playing your game at work, and the boss comes in, and they can't emergency Alt-Tab out of your game? Boom, they get fired, their kids starve to death, they end up on the street in 30-below weather with snow blowing up their ragged pants leg, a dog comes out of an alley and steals their moldy old hot dog bun that they were going to have for dinner. That's what happens. All because you just had to "take over" their PC.

I mean, just sound it out. "Take over your PC." That just sounds like a hostile, unfriendly act to me. Let the users Alt-Tab, for Pete's sake. Do it for the children.

Boom, they get fired, their kids starve to death, they end up on the street in 30-below weather with snow blowing up their ragged pants leg, a dog comes out of an alley and steals their moldy old hot dog bun that they were going to have for dinner. That's what happens. All because you just had to "take over" their PC.

LOL! Oh I love that one!

but seriously, in the beginning, a lot of PC game building was about getting the operating system out of your way. Finally MS got a clue and made ways for gamedevs to cut thru the OS and get to the low level stuff needed for performance. that's where the "take over the PC" concept comes from. like i said, i'm really just being lazy. lost device wouldn't be an issue if i didn't have to use windows to talk to the vidcard. but then i wouldn't get the benefits of using windows to talk to the vidcard. and yes, back in the day, my games had boss keys!

now, for the other side of the coin:

while being a well behaved PE executable is all fine and good, there are some windows hotkeys that can get in the way of a game. I have problems with the windows key and Oblivion for example. Alt-tab might interfere with gameplay in Oblivion too. tab is your inventory, and you use it a LOT! even in the middle of combat to drink healing potions and select spells. I don't know if alt-tab is a problem as Bethesda disabled it.

...and just because Oblivion doesn't support it doesn't mean that not supporting it is the right thing to do. That's (in the absence of personal knowledge of the decisions made for Oblivion on my part) most likely to be a bug in Oblivion, and - yes - a quick Google for "oblivion alt tab" shows it to be something that users are complaining about in their droves.

Also consider that Alt-Tab is just one of the potential Lost Device scenarios. There are many others, which Microsoft don't document because they can't document them all. A Lost Device can happen for any of these reasons, and it's still hugely rude to not support them - just picture the scene: player has whittled the Boss down to 1 hp, ready to land the killing blow, then - YANK! Device lost. If you were the player how would you like the program to behave? especially considering that this is something for which there is a documented recovery process which just requires a small amount of extra work on the part of the programmer?

As a general rule - unless the docs explicitly say that you need to use D3DPOOL_DEFAULT (e.g. depending on your D3DUSAGE) you should be using D3DPOOL_MANAGED.

"Use the D3DPOOL_DEFAULT flag at creation time to specify that a resource

are placed in the memory pool most appropriate for the set of usages requested
for the given resource. This is usually video memory, including both local video
memory and accelerated graphics port (AGP) memory."

the "most appropriate" part led me to believe this would be the optimal method.

D3DPOOL_MANAGED has the added convenience that static meshes and textures are not lost on lost device.

both run at the same speed, obviously (just tested it). whether there's a backup copy of the static meshes and textures in system memory has no effect on the speed of the vidcard. as long as nothing tries to take control of the vidcard away from directx, its happy.

however, unless the "restore" from system mem to vidram is triggered explicitly by the developer (and i believe its automatic), that would seem to require a check before using a resource in vidram, to make sure it was in sync with the system mem copy first. and a check is overhead. apparently negligible in this case. so from a clock cycle point of view, it may be slower.

i know, don't even start! who cares about a clock cycle or two?

well, until directx can do fixed function real time ray tracing, and still leave 30 milliseconds per frame at 30 fps for simulation, we probably all should.

i do. but then, i'm ambitious! .

put a Cray on every user's desk, and i'll build you a REAL game!

until then, my life is an exercise in trying to shoehorn too much game into not enough computer.

Seriously - and I'll start being blunt now - this is not a problem.

Games have been using the managed pool since the managed pool first existed. That's - oooh I dunno - a clear case of production software covering thousands (or tens of thousands) of titles across millions of users.

The managed pool works. It's proven to work in the field. So it's decision time - (a) use something that's been proven to work time and time again, versus (b) adopt some user-hostile wacked-out scheme to explicitly avoid having to use the solution that works. Which do you choose?

there are some windows hotkeys that can get in the way of a game. I have problems with the windows key and Oblivion for example. Alt-tab might interfere with gameplay in Oblivion too. tab is your inventory, and you use it a LOT! even in the middle of combat to drink healing potions and select spells.

So add an option to your configuration screen where people can opt-in to disabling these keys.

however, unless the "restore" from system mem to vidram is triggered explicitly by the developer (and i believe its automatic), that would seem to require a check before using a resource in vidram, to make sure it was in sync with the system mem copy first.

No, it can use the same mechanism that you'd use on the application side to deal with vidram losses -- only when the lost device flag is raised (checked once per frame upon present), then iterate the list of managed resources and restore them using the sysram copy.

lost device wouldn't be an issue if i didn't have to use windows to talk to the vidcard. but then i wouldn't get the benefits of using windows to talk to the vidcard.

Exactly. On the PS3 I had the luxury of not having to go through the OS to talk to the GPU... and it was a nightmare. I had the option of using higher level APIs, but I was writing an engine, so I may as well go as close to the metal as I could, right?

* Packing bits and bytes manually into structures in order to construct command packets, instead of just calling SetBlahState() -- not fun. Yeah, slightly less clock cycles, but not enough to matter. Profiling the code shows it wasn't a hot-spot, so time-consuming micro-optimisations are a waste. I'm talking about boosting the framerate from 30FPS up to 30.09FPS, by a huge development cost. I could've spent that time optimising an actual bottleneck. Also, any malformed command packets would simply crash the GPU, without any nice OS notification of the device failure, or device restarts, or debug logs... The amount of time required to debug these systems was phenomenal, which again, means less time that I could use to optimize parts that actually mattered.

* Dealing with vidram resource management myself -- not fun. Did you know that any of your GPU resources, such as textures, may exist as multiple allocations? In order to achieve a good level of parallelism without stalls, the driver programmer (or poor console programmer) often intentionally introduces a large amount of latency between the CPU and GPU. When you ask the GPU to draw something, the driver puts this command into a queue that might not be read for upwards of 30ms. This means that if you want to CPU-update a resource that's in use by the GPU, you can either stall for 30ms (no thanks), or allocate a 2nd block of memory for it. Then you need to do all of the juggling that makes n-different vidram objects appear to be a single object to the application developer. The guys that write drivers for your PC are really good at this stuff and know how to do it efficiently. There's also lots of sub-optimal strategies that seem like a good idea to everyone else (i.e. your GPU driver probably solves these issues more efficiently than you would anyway).

* Then there's porting. Repeat the above work for every single GPU that you want to support...

Giving up a few clock cycles to the API has turned out to be a necessary evil. The alternative just isn't feasible any more.

Profile your code and optimize the bits that matter. Also, your obsession with clock cycles as a measure of performance is a bit out-dated. Fetching a variable from RAM into a register can stall the CPU for hundreds of clock cycles if your memory organization and access patterns aren't optimized -- on a CPU that I used recently, reading a variable from RAM could potentially be as costly as 800 float multiplications, if you had sub-optimal memory access patterns!

The number one optimisation target these days is memory bandwidth, not ALU operations.

put a Cray on every user's desk, and i'll build you a REAL game!

I think the point of "real" game development is to figure out how to build a game...without a Cray.

i know, don't even start! who cares about a clock cycle or two?

This guy does:

like most things in game development, there's the easy way and the fast way to do it. if you code each line with clock cycles in mind form the get go, you'll have very little optimization to do at the end.

Also, your obsession with clock cycles as a measure of performance is a bit out-dated. Fetching a variable from RAM into a register can stall the CPU for hundreds of clock cycles if your memory organization and access patterns aren't optimized -- on a CPU that I used recently, reading a variable from RAM could potentially be as costly as 800 float multiplications, if you had sub-optimal memory access patterns!
The number one optimisation target these days is memory bandwidth, not ALU operations.

This.
1000x this.

A fixation on clock cycles when coding on a highly pipelined out of order cpu and a massive latency to main memory is the sign of an 'old skool' programmer who has failed to keep up with the realities of a modern development environment.

Seriously - and I'll start being blunt now - this [sync overhead] is not a problem.

yes, I know. Just being technical, from a theoretical point of view.

The managed pool works

at the moment, i only have 20 dynamic meshes that would have to be restored. they're actually 20 copies of the same ground quad.

loading a copy into system mem and then restoring from there would avoid a disk hit on restore. but then again, its only 20 quads. try it the easy way, go for the fast way if needed. I was hoping to pull this title off with no paging, but its just too big and complex.