• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Norman Barrows

mouse input without windows messages ?

23 posts in this topic

Is it still possible to get mouse input without using the windows message queue?

 

I know that as of Windows Vista or so, it was still possible to use DOS interrupts.

 

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

 

the nice thing about this was that Alt-Tab messages no longer got processed. you had full control of the PC, no lost devices. The only thing that still worked was ctrl-alt-del.

 

right now i'm using windows messages to get mouse input. but that's the only message i process.

 

if you take a careful look at the directx docs, it says the best way to do things is to load everything up into memory at program start, then go for it.

 

so all this reload / restore on lost device is a bad thing.

 

while a number of games attempt to support it (as a well behaved windows app should), few seem to succeed in all cases. many warn that it can introduce instability and recommend restarting the game (Oblivion for example).

 

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.

 

But it would be nice to trap out alt-tab etc.

 

I want full control of the pc, that way my games don't have to play well with others.

 

-2

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

 


if you take a careful look at the directx docs, it says the best way to do things is to load everything up into memory at program start, then go for it. so all this reload / restore on lost device is a bad thing.

 

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.

0

Share this post


Link to post
Share on other sites

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!

0

Share this post


Link to post
Share on other sites

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? <g>). 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.

0

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

...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?

2

Share this post


Link to post
Share on other sites

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! <g>.

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.

0

Share this post


Link to post
Share on other sites

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. 

0

Share this post


Link to post
Share on other sites

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.
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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

 

I'd say the idea is to build a cool game.

 

figuring out how to do it without a Cray is the "glory coding" part of it.

0

Share this post


Link to post
Share on other sites

well, alt-tab and lost device is in the game now.  took a while to find everything in D3DPOOL_DEFAULT, but once I did, it worked fine.

 

Now it Alt-tab's with the best of 'em!   I'd like to thank everyone here for convincing me not to be lazy and to go for the quality implementation.

Edited by Norman Barrows
2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0