Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK .NET / How to get around keyboard input limitations in DGDK.Net

Author
Message
code master
20
Years of Service
User Offline
Joined: 4th Dec 2003
Location: Illinois
Posted: 6th Feb 2009 23:50 Edited at: 7th Feb 2009 17:10
Alright, so I've seen a LOT of posts about this...

Basically, because of the way DirecInput retrieves data, it dosn't work very well with a form based UI. The form actually gets all the key data and we're left with no input.

But there is hope.

The simplest way I've found to do it is this:



1.) Declare a public variable in your main class for each Key. I.E "Dim KeyUp as Integer"

2.) Go to your form's KeyUp and KeyDown events.

3.) Get the value of the key that triggered the event, and update it's variable in turn.
"Dim KeyEvent as Integer = E.KeyValue
Application.KeyUp = (KeyEvent = Keys.Up)"


4.) Make sure to do the same in your Form's KeyDown event... and your set!

I really wanted to just write sample code... but I don't have access to my laptop ATM, and I'd rather not do it wrong, So that's gonna have to wait bit.




Enjoy!

Nicoust
18
Years of Service
User Offline
Joined: 3rd Jul 2005
Location: Manchester, England
Posted: 7th Feb 2009 10:53
If you're not using a form you could use XNA, which offers a great selection of input.

You need to, obviously, have installed xna.

Then add references to xna, and include(using) the following:

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Input;



at its simplest.

Its easy to add a previous method so you can keep track of key presses and releases. Much preferable, imo, to Forms input. It is possible to use it when a form is included, but I cant find the notesI had for that. If you need 'em let me know I'll try again.
Hayer
18
Years of Service
User Offline
Joined: 4th Nov 2005
Location: Norway
Posted: 7th Feb 2009 16:17
Great! Thanks code master.



btw;

4.) Make sure to do the same in your Forum's KeyDown event... and your set!

.. Im using Forms dont know about u.

code master
20
Years of Service
User Offline
Joined: 4th Dec 2003
Location: Illinois
Posted: 7th Feb 2009 17:09
Nicoust: Sounds like a good method too... But I'd prefer not to install anything beyond what I'm using ATM.

I'm sure some people will find it useful though.

Hayer: Glad to help.

haha. Touche.

RanQor
16
Years of Service
User Offline
Joined: 8th Jun 2007
Location:
Posted: 28th Feb 2009 21:36 Edited at: 28th Feb 2009 21:36
I cant figure this out. The form (fMain) is not calling the keydown or keyup events, and darkGDK isn't receiving them either.



MessageBox should popup no mater what key I press, but I get nothing.
RanQor
16
Years of Service
User Offline
Joined: 8th Jun 2007
Location:
Posted: 28th Feb 2009 21:39
Nevermind, I needed to assign the keyup/down events from the viewport instead of the form.
RanQor
16
Years of Service
User Offline
Joined: 8th Jun 2007
Location:
Posted: 28th Feb 2009 21:44 Edited at: 28th Feb 2009 22:35
no I take that back, it works fine until I click with the mouse and make the viewport active.


Mouse Position isnt working either, how am I suppose to get input?
MoomanFL
18
Years of Service
User Offline
Joined: 12th Nov 2005
Location:
Posted: 1st Mar 2009 03:20 Edited at: 1st Mar 2009 03:40
One other possible way, that I am getting ready to explore is to run the viewport in a separate thread and use delegates to access functions between threads.

If this is done, there shouldn't be a problem of DGDK.Net monopolizing the input. One of the reasons why it does, is because of the way .NET and events work. Every time an event is called, the call gets placed in a stack, and then the calls are handled in order. If a sub or function is running when the call is made, then it executes the callback function for the event when the current function or sub is done. However if you are running in a game loop, that current function or sub is NEVER done so the events never get acted on. However if this was all, just adding an Application.DoEvents() in the game loop would fix it, so it is a combination of that and DGDK taking over the input.

Operating the game loop in a separate thread might fix this, but you will have to attach the viewport from within the same thread as the game loop or it will just make a new viewport window instead.

As I said, I don't have an example of this yet.... but I will be working on it since I need it for my current project. One other possibility is running the viewport in another appdomain, but that gets a little trickier.

Design documents?!? What design documents??? I thought we were just going to wing it!!!
RanQor
16
Years of Service
User Offline
Joined: 8th Jun 2007
Location:
Posted: 1st Mar 2009 04:18
I wonder if there will be any official fix for this.
MoomanFL
18
Years of Service
User Offline
Joined: 12th Nov 2005
Location:
Posted: 1st Mar 2009 04:37
RanQor,

If I am not mistaken, the problem with this is that DGDK.Net is built on top of DGDK. In C++ you aren't dealing with events. That is a construct of higher languages. I suppose there could be a fix, but it wouldn't be an easy one. Apex would basically have to write his own event raising code.

Design documents?!? What design documents??? I thought we were just going to wing it!!!
MoomanFL
18
Years of Service
User Offline
Joined: 12th Nov 2005
Location:
Posted: 1st Mar 2009 23:49
Ok... tried running the viewport in a separate thread and there was no change with the input. An appdomain MIGHT work better, but it is trickier to get info passed between the main form and the appdomain with the viewport. I just don't have the energy at the moment to work on it.

Design documents?!? What design documents??? I thought we were just going to wing it!!!
APEXnow
Retired Moderator
20
Years of Service
User Offline
Joined: 15th Apr 2003
Location: On a park bench
Posted: 11th Mar 2009 04:10
There needs to be a fix for this, and it stems from capturing events from DirectX. Windows message events are handled differently to normal windows Input events, and hence why the problem only occurs in non fullscreen mode applications. This problem is being looked into.

Paul.

MoomanFL
18
Years of Service
User Offline
Joined: 12th Nov 2005
Location:
Posted: 11th Mar 2009 05:29
For my version of the problem (e.g. form events not firing correctly when the gameloop is running), I found an ugly fix for it. It will work temporarily, but it is only really good for the one project.

I put a timer control on the viewport's form, then put the game loop in the Timer1_Tick event handler. I then set the Interval property for the Timer to 10. This keeps simple stuff working at a fast enough frame rate, but still allows time in between to handle other form events. Since the viewport will just be there to view images, models, etc. this fix works great. For a game though it probably wouldn't be a good idea.

Design documents?!? What design documents??? I thought we were just going to wing it!!!
APEXnow
Retired Moderator
20
Years of Service
User Offline
Joined: 15th Apr 2003
Location: On a park bench
Posted: 12th Mar 2009 13:59
The other way to force form events to be processed, is to delete the timer code altogether and put this in your game loop:

System.Windows.Forms.Application.DoEvents()

This forces message pump processing.

Paul.

MoomanFL
18
Years of Service
User Offline
Joined: 12th Nov 2005
Location:
Posted: 12th Mar 2009 22:15
Tried that before using the timer. In my case it still didn't handle the events. I thought that odd at the time, but worked around it.

The problem I was having was in using the open source Dockpanel Suite by Weifen Luo: http://sourceforge.net/projects/dockpanelsuite/

I put the viewport on a control and added some toolwindows to the dockpanel. I then added the control with the viewport to one of the toolwindows. As soon as it was initialized, sliding the panel resizer no longer worked and it became impossible to move floating toolwindows.

Adding Application.DoEvents() to the gameloop didn't solve the issue, but putting the loop in a Timer_Tick event did. Odd, but solvable.

Design documents?!? What design documents??? I thought we were just going to wing it!!!

Login to post a reply

Server time is: 2024-03-29 05:34:12
Your offset time is: 2024-03-29 05:34:12