keydownstate[] "bug"

[Michael_J]

I'm not sure if this constitutes a bug, or is expected behavior (already discussed with Josh, just adding a post for a reminder)

 

I do not do any KeyDown or KeyHit checks in my app::loop. Rather, I have a controller class that handles everything (joysticks, keyboard, mouse, etc) that I call once per frame. For the keyboard functionality I use Window::keydownstate[] which works well.

 

However, without any calls to KeyDown or KeyHit this causes Windows to think that the program has become unresponsive, even though you can see the program is still running (mouse control still works, engine still updates, etc).

 

To correct this "bug" there has to be at least ONE call somewhere, per frame, to either KeyDown or KeyHit.

 

Here's test c++ code so you can see the behavior. Note: if you don't un-comment the first line in the App::Loop you WILL have to shut down the prog with Task Manager...

 

#include "App.h"
using namespace Leadwerks;

class keyGRABBER
{
public:
bool Shutdown(Window*);
};
bool keyGRABBER::Shutdown(Window* window)
{
if (window->keydownstate[27]) return true;
return false;
}

keyGRABBER getKeys;

App::App() : window(NULL), context(NULL), world(NULL), camera(NULL) {}
App::~App() { delete world; delete window; }
bool App::Start()
{
window = Window::Create("test", 0,0,1024,768,Window::Titlebar + Window::Center);
context = Context::Create(window);
world = World::Create();
camera = Camera::Create();
camera->SetRange(0.05, 5000);
return true;
}
bool App::Loop()
{
//if (window->KeyDown(Key::Escape)){}; //uncomment this to fix the bug
if (getKeys.Shutdown(window))
{
//End program
return false;
}
else
{
//Continue
Time::Update();
world->Update();
world->Render();
context->Sync(true);
return true;
}
}

 

Excuse the code--I just threw the example together quickly so I can get back to work Anyway, keydownstate may not poll for windows activity on its own, in which case this isn't a bug per say. But I wanted to at least make a post about it so no one else trips over this. I spent 4 hours tracking this down

[Rick]

I don't think keydownstate is a supported thing to work with. It's not in the docs at all. Josh pretty much made everything public but that doesn't mean it's supported to be used by us. I think he's incorrect by doing this for reasons like this, but that's the way it's setup.

[Michael_J]

True, but it's the cleanest way to get states for all the keys each frame. I fully expect, seeing as RogSys is a sim, that people will use as many keys as possible for different systems control, and I have a LUA table that allows user-defined keys and buttons.

 

I couldn't imagine having to do an independent "if" for all those key states separately I mean, functionally it's the same thing as putting one "if" inside a loop, but code-wise it's just seems a bit... ugly...

 

Edit: I think in many cases (and Josh, correct me if I'm wrong here), there just hasn't been time to document everything yet. If so I would believe this to be one of those cases, as a loop-able downstate for keys and buttons is pretty common. That said, if I can see it and it will save me coding time you can bet I'll try it. If it's not supported and doesn't work THEN I'll code around it

[Rick]

True, but it's the cleanest way to get states for all the keys each frame

 

It would be the cleanest way if it was officially supported

 

I agree with you btw, but it's hard to call it a bug if it's not documented and isn't wrapped around a function.

[Michael_J]

[/size]

I agree with you btw, but it's hard to call it a bug if it's not documented and isn't wrapped around a function.

 

Again, that's understood, which is why I'm not sure it can be classified as a bug. If not then I think it at least warrants a mention somewhere for reference. In hindsight, the "programming" section probably should have been the first stop for this. My bad there

[Rick]

There would need to be a lot of references to a lot of different things since most everything is public in the API but most of it isn't supported to be used by us. If anything I think you'd be better off making a post in the suggestion forum for this specific thing about what you are after because I think it's valid and you might get some support behind you to have Josh do something about it.

[Michael_J]

Yeah, that's a fair comment. I'll do that from here out for the "unsupported" issues as they arise...

[Josh]

Internally, KeyHit and Down call an Update() function that updates the window event queue. Not sure how you're even getting key events if there's no event polling.

 

All programs should call Window::Closed() each frame. This will also update the window and keep it "alive" to the OS.

 

The internal members like keydownstate might not exist an all operating systems, so you are potentially breaking compatibility.