Mick is Stumped

Members
  • Content count

    57
  • Joined

  • Last visited

Community Reputation

113 Neutral

About Mick is Stumped

  • Rank
    Member

Personal Information

  1. keyboard GetDeviceData (buffered) never releases keys?

    Ok faithful readers and anyone in the same boat.... Over in the xna forums (http://xboxforums.create.msdn.com/forums/p/108722/642144.aspx#642144) we discovered this behavior is caused by calling Unacquire in your event processing loop. Funnily enough only the keyboard seems to be affected. Now if I could just figure out what the hell Acquire and Unacquire really do. Sorry about the cross posting btw. Just doubles the odds of some one int a pinch finding this I guess [img]http://public.gamedev.net//public/style_emoticons/default/laugh.png[/img] Microsoft's sites are notoriously impermanent after all [img]http://public.gamedev.net//public/style_emoticons/default/dry.png[/img]
  2. keyboard GetDeviceData (buffered) never releases keys?

    ^Hi, actually that's not my code. But if you do the experiment you will find that the condition in it is never false. I think the comment is just announcing the expected behavior. I could be wrong but the down events also appear to repeat. Which seems really counter to how DirectInput should work as there is nothing "direct" about translated input. It seems like the person (lets give MS the benefit of doubt) who programmed the buffered side of the system keyboard device was just a world class twit and MS in its supreme irresponsibility never fixed it. At any rate I describe a fix here ([url="http://xboxforums.create.msdn.com/forums/t/108722.aspx"]http://xboxforums.cr...s/t/108722.aspx[/url]) that basically just fills a buffer with the downed keys and calls GetAsyncKeyState until the key is lifted. In theory a down event could get timestamped before a previous up event (especially with the repeating behavior; though you could overwrite the timestamps too) but other than that its not so awful for buffered keyboard input. And its the only non-trivial specialization I had to do with for a system that exposes controllers as completely abstract beasts. In theory I could finish Super Mario Bros. with the nobs and mute button on a little speaker I have that for some reason shows up as a Direct Input controller. It was really annoying having to setup a DIK to VK translation table though. If you are implementing input handlers on a subsystem basis you really don't have to pick a subsystem. It's probably the best that can be done for Direct Input and probably should work without a hitch if the buffer readback loop is of sufficient resolution. In other words there are plans to offer end users more than one keyboard option in my case.
  3. ^Thanks MikeBMcL. I think what I really wanted was windowless Direct Input which is not documented. But I know some win32 APIs treat 0 as a desktop window. I wonder about side effects. But I also wonder if it would be legit to pass the desktop to Direct3D if what you want is just a windowless but nonetheless windowed device instance (you can pass windows directly to Present) for instance when the renderer is inside a DLL and doesn't care about the Present targets. Ontopic: For anyone looking for info on this matter here (http://xboxforums.create.msdn.com/forums/p/108720/641925.aspx#641925) is a detailed explanation, but because microsoft.com links tend to go stale in short order what I found was Sleep indeed causes a deadlock but assuming you are using SetEventNotification and [Msg]WaitForMultipleObjects what seems to work is manipulating the timeout parameter of MsgWaitForMultipleObjects. The examples in the documentation are pretty confusing as they seem to make a number of assumptions that are not explained and in and of themselves appear to be slapped together as there are contradictions right there in the code/explanations if you look for them. Tip: if you are trying to be nice setting the timeout to even 1ms will take your thread's CPU usage down from ~50% to ~3-1% or less. The docs imply that 0 is a good timeout but that is probably assuming that your loop has something to do during on timeout (eg. draw a frame) that will by Direct Input enough time to not deadlock itself. I would say more but there is the above link which pretty much covers the bases.
  4. keyboard GetDeviceData (buffered) never releases keys?

    I found this (http://www.flipcode.com/archives/DirectInput_Example.shtml) with a comment that suggests releases are not buffered: [code]if ((key_pressed[0].dwData & 0x80) ? 1 : 0) // only key-down events are reported { keyevent[key_pressed[0].dwOfs] = true; }[/code] Which seems to be directly contradicted by this (http://msdn.microsoft.com/en-us/library/windows/desktop/ee416238%28v=vs.85%29.aspx) quoted below because microsoft.com links have a very short shelf life... [quote=Buffered Keyboard Data]o retrieve buffered data from the keyboard, you must first set the buffer size (see Device Properties). This step is essential because the default size of the buffer is 0. You must also declare an array of DIDEVICEOBJECTDATA structures. This array can have up to the same number of elements as the buffer size. You do not have to retrieve the entire contents of the buffer with a single call. You can have just one element in the array and retrieve events one at a time until the buffer is empty. After acquiring the keyboard device, you can examine and flush the buffer at any time by using the IDirectInputDevice8::GetDeviceData method. (See Buffered and Immediate Data.) Each element in the DIDEVICEOBJECTDATA array represents a change in state for a single key-that is, a press or release. Because Microsoft DirectInput gets the data directly from the keyboard, any settings for character repeat in Control Panel are ignored. This means that a keystroke is counted only once, no matter how long the key is held down. You can determine which key an element in the array refers to by checking the dwOfs member of the DIDEVICEOBJECTDATA structure against the DirectInput Keyboard Device. (See also Interpreting Keyboard Data.) [b]The data for the change of state of the key is located in the dwData member of the DIDEVICEOBJECTDATA structure. Only the low byte of dwData is significant. The high bit of this byte is set if the key was pressed, and it is clear if it was released. In other words, the key was pressed if (dwData & 0x80) is nonzero.[/b][/quote] I don't know why the world puts up with such a ghetto corporation. Oh yeah all of the others make the MS look like a saint nowadays and non-corporations don't have an advertising budget Any ideas?
  5. Bottom line using the buffered methods GetDeviceData buffers presses but not releases!? Same with the laptop keyboard and a USB keyboard. What could be going on here? Edit controls etc work just fine. Disclaimer: the keyboard is part of a generic controller framework, and it is used for gamey inputs so I am not sure why Direct Input is unsuitable for that (as is often proclaimed; read: so please spare everyone the lecture) though raw input will probably be looked into as an alternative if it can distinguish between multiple keyboards. Not sure what to do if this won't work [img]http://public.gamedev.net//public/style_emoticons/default/sad.png[/img] I remember having issues with buffered keyboard for "ghosting" in the past but nothing this dramatic.
  6. FYI: I found passing a 0 for the window handle to SetCooperativeLevel seems to be less sticky (or rather may actually work) than when using a hidden window. The docs say a valid window handle is required, but I think it's possible that 0 is interpreted as the desktop or something??? Otherwise this is undocumented and therefore unreliable behavior. I was using a hidden window because I've found that one is required for Direct3D9 to function on windows XP and under different circumstances. It may be Direct3D needs a window for messaging purposes but it seems like bad design either way. Post XP a 0 window seems to work with Direct3D. Not that it matters.
  7. Last night just as I was readying to demo a controller subsystem Direct Input 8 begins having a tendency to never come back from Acquire... Anyway dinput8d.dll is no longer in any of the DX SDKs and seems to have even been backwards removed from the download links of SDKs from years past. I am not convertible downloading it from a .dll repository website as they all look like the seediest things on earth. But I am wondering if some of my usage patterns might be error prone and would feel better if I had a debug build either way. Background: I have at this point a single thread that manages multiple devices all self contained. The outer framework is very asynchronous but the DirectInputDevice stuff is all self contained within the single thread itself. So I just don't see any excuse for the method to deadlock. The coop mode is background nonexclusive. The controls seem to work in the control panel even when the thread is waiting for Acquire to return. Not sure if that would work if it was a driver bug. Thanks.
  8. For the record I am not sure now that you guys run ads in the first post or not, but it is a common practice so I may have assumed. Also I am pretty sure this is in all threads more or less; but sometimes with shorter posts its not so obvious, and it doesn't seem to affect things like code blocks. And like I say its been this way for more than a year probably possibly considerably longer. I am surprised anyway that I am the first to have mentioned it. Good luck!
  9. New Firefox Windows 7. I've been noticing this for years. Pretty much all of the topics have the 180 day necro posting warning, but they list in the search engines so.... Pretty much every time I've come across a gamedev.net thread while websearching it has been this way. It's just hard to believe that many people would post a page of text without any spaces ([url="http://www.gamedev.net/topic/477414-design-of-direct3d-vs-opengl/"]http://www.gamedev.n...ct3d-vs-opengl/[/url]) The bottom of this (http://www.gamedev.net/topic/388392-right-hand-perspective-matrix/) one is pretty suspect.
  10. DirectInput debug runtime

    I realize this is old. But I've been looking for a copy of dinput8d.dll for a long time, but it's not in the (August 2005) SDK as of now, nor in any of the SDKs I have, 2010, 2008. This is the only link I've ever come across mentioning it. To make matters worse (for me) DirectInput8 has started deadlocking on Acquire tonight and I can't make a lick of sense out of it. Could even just be a random event
  11. I occasionally end up reading a forum thread here after a websearch. At first I thought for a while that only crazy people post questions to this forum (hey it's not unusual) but I've begun to notice a theme... Basically all of the whitespace is stripped out of the opening posts of many threads here. Possibly archived threads only. Probably all of them. It's pretty much impossible to read the opening post because it looks like one huge stream of conscious block of text without any paragraphs. Just being a good citizen and letting the staff know. I assume it has something to do with the embedded advertisements throwing off the formatting and its not as severe as the formatting no longer being in the database.
  12. PS: Would like to edit the subject to be "SOLVED" and provide a solution... wish I could think of a title that made sense. But the "Full Editor" link isn't working right now in two different browsers (one with no cache for this site) so no clue. Will try again later.
  13. Sweet success! A week worth of work down the drain, but nonetheless feels good to not have been totally for naught. Long story short, the global solution plan went off without a hitch. I think I learned some stuff though. I just wish I could remember what order to multiply matrices etc in.... it's just too easy to try one way, and then the other if that does not take All these years programming graphics, I still don't know.
  14. The link for the above quote is (http://www.euclideanspace.com/maths/algebra/realNormedAlgebra/quaternions/transforms/index.htm) ... did not appear in the quote citation. For the record, this morning, I devised a solution that worked with 3 diagrams. The approach I ended up taking was canceling out the translation due to rotation, and then the remaining translation is pretty straightforward ... but what I found was the results were identical to having the second rotation+position pair drive the product of the two (basically q2*q1 from the quote above) ... which I found counter intuitive, and would not have suspected, but it works. I am pretty comfortable with the dynamics, but it is still not working out. So rather than trying to prove that solving for the spaces between the reference frames (the relative frames) does or doesn't introduce the error, I reckon I will go ahead and slap together a global solution (one that computes the sum of the transform chains, combines the results, then chops up/portions out the results in relative terms) ASAP and just see.
  15. I don't seem to be one to be able to let an open problem lie. I've found sketching things out on paper to be of some help (I draw pictures rather than crunch numbers for the most part) I am "pretty" confident the rotation component should always be correct in my thinking; though I am a little confused about the order thanks this to this find: [quote=http://www.euclideanspace.com/maths/algebra/realNormedAlgebra/quaternions/transforms/index.htm] The order worked out above assumes that each rotation, q1 and then q2 is done in the absolute frame of reference so we get q2*q1. When we are working in the frame of reference of a moving object such as an aircraft or spacecraft then the order is not reversed so the combined rotation is q1*q2. absolute frame of reference q2*q1 frame of reference of rotating object q1*q2 [/quote] I find it odd that the order should matter in different contexts myself. But I can't tell if by absolute he (assuming) means within the same reference frame (vs. across frames) or in some magical outer most frame. I discovered that most if not all of the oddness in picture #3 above is actually built into this model, and can be observed if translation is taken out of the model. So a picture like #3 will happen naturally whenever there is not enough translation (the position component) correcting things. I will most likely anyway, keep trying to work this out, on paper, another day. If it is true that only the position component must be solved for then it should not be too unwieldy a problem (let's hope)