I’m using the quick way of checking for key events inside the renderer thread:
if(Gdx.input.isKeyJustPressed(key));
But I can’t seem to find a key inside the Keys that maps out the greater than key on my keyboard.
Perhaps someone can point me in the right direction?
I’ve tried probably every key that says RIGHT something—as this seems as though something that might be it.
Moreover
It’s worth to notice that when using LibGDX’s InputProcessor, the greater than and less than signs don’t register at all as for certain keyboard layouts. In the Swedish QWERTY keyboard layout for example, the key for greater than and less that don’t register at all.
If you can use an InputProcessor, implement its keyTyped method to get a character from the pressed key, which is layout independent:
public boolean keyTyped(char character) {
switch (character) {
case '<':
// less than pressed
break;
case '>':
// greater than pressed
break;
default:
// whatever
break;
}
return false;
}
Keep in mind that there is no good way to poll a character instead of a key, and it's hard to emulate due to a lack of a keyTypedReleased event. As such, you might have to rethink your loop, since you can't check for char presses in the isCharPressed fashion that you have now.
Related
I keep seeing this in a lot of Flutter code but I have no idea what it does or what the point of it is:
TextField(
style: Theme.of(context).textTheme.display1,
key: _inputKey, // <-------------- what is this?
Using a Key, you can tell Flutter that a widget is the same (or not the same) after a rebuild. That's especially important when those widgets hold internal state (e.g. a running animation).
When you add or remove widgets from a list (Column or ListView) on a rebuild, Flutter does not know which widgets were added, which ones were moved and which ones were removed. Such a use case is described in the question linked by Rémi.
A GlobalKey is a special kind of key that allows you to access the State and RenderObject (and size) of the widget.
The AnimatedSwitcher which allows you to switch out a widget with an animation often requires keyed children to signalize if an animation should occur, or if the widget is the same after a rebuild.
http://pastebin.com/ap6hVRVb
I've fixed everything I can see, but maybe I've looked at it too much and I've grown used to what is wrong in the code, therefore I will have trouble seeing what is incorrect.
Basically I just need a symbol called player to move left and right when I press either A or D or left or right arrow keys.
I'm Still learning code I know I'm pathetic.
At first glance I see
rightDown=false instead of ==. What problems are you having with it exactly?
You should really end your statements with a semi-colon, man. It also doesn't hurt to use constant variables to store the key codes, so you don't accidentally mistype one.
In the updateSpeed function you have, you might want to change the 'if()' statements to 'else if()' conditionals? I'm not completely sure if that's the problem, but I don't think it'd hurt to try.
Also, as #VBCPP said, there's a line that says
if(rightDown=false && leftDown==false){
When it should be
if (rightDown == false && leftDown == false){
OR
if ( !rightDown && !leftDown ){
I have two alternatives to move a space ship movieclip.
First one is adding eventListener(keybordEvent) check which button is pressed and act according to it.
The second one is again,adding an eventListener(keyboardEvent) and using 4 boolean varaibles,leftArrow,rightArrow,upArrow and downArrow. keep track of pushed buttons and use eventListener(Event.ENTER_FRAME) and move movieClip in everyframe using these bool variables)
Which one is better or at least does any of them have an advantages ?
I suggest the second option because you want to handle movement in the game loop and not in the key event.
I would use the Boolean method as the other method (depending how you implement it) could react to the key repeat that happens when you press a key down - it triggers once, pauses, then continues to fire.
EDIT
..and, I agree, also for the best practices reason Nambew mentions!
I'm working on a game that uses four simultaneous key presses. It all works fine, except that when the keys are rapidly pressed, my framerate slows down significantly (if I hammer even just one of the keys, I can halve the framerate).
I initially just assumed that there was too much going on in the method that the key press triggers, but if I take the code out of the method completely, the slowdown still occurs.
Has anyone run into this before? The keypress is one where you hold the key down, so it's repeatedly firing a method call every frame, but this is pretty standard for many uses and I've never encountered this before.
EDIT: clarification.
Structurally, there's a KEY_DOWN and KEY_UP listener attached to the stage:
stage.addEventListener(KeyboardEvent.KEY_DOWN, menuKeyDown);
stage.addEventListener(KeyboardEvent.KEY_UP, menuKeyUp);
which then calls a method with a single switch statement in, that contains five lines like this:
case ONE: pressing1 = true; break;
There's an ENTER_FRAME event that checks to see if any of the boolean flags are true, and handles character movement. This calculation happens regardless of key presses (i.e. if you let go of the keys, gravity still has an effect). This holds 60fps easily.
The issue is literally at the exact moment the key is pressed or released, there's an almost imperceptible frame drop. Repeatedly pressing the keys causes the framedrop to get worse and worse. Holding a key down doesn't kill the framerate, apart from the single split second frame drop when the key is pressed down. After that the game carries on as normal. Letting go of the key causes another tiny hitch and then the framerate goes back to normal.
EDIT 2 - I added a framerate checker so I could see exactly what was happening to the framerate. Interestingly, I can't make it go any lower than EXACTLY 30fps even when I press keys very rapidly. Is there some sort of restriction in play here with Flash Player?
Turns out that the code was correct all along. Playing 60FPS content in the debug player or the standalone player causes any events (mouse and keyboard) to hitch the framerate. Viewing the same content in a browser, or exported to AIR, stops the issue entirely. The content is now running perfectly at 60fps without any slowdown.
Hope this helps someone, I was tearing my hair out!
Do you have multiple different listeners, or one listener that appropriately routes the keypress? I would suspect the former. The solution is to switch to the latter.
What I typically do is have one object that's responsible for listening to key presses and translating keyboard events into other, more meaningful events.
For example:
protected function handleKeyboardEvent(e:KeyboardEvent):void {
if (e.ctrlKey) {
switch (e.keyCode) {
case Keyboard.A:
eventBus.dispatchEvent(new Event(ViewEventKind.SELECT_ALL));
return;
case Keyboard.Y:
eventBus.dispatchEvent(new Event(ModelEventKind.REDO));
return;
case Keyboard.Z:
eventBus.dispatchEvent(new Event(ModelEventKind.UNDO));
return;
}
}
}
this works for me, but does it look correct in terms of as3 best practices. is it correct to return null if it fails?
override public function addChild(child:DisplayObject):DisplayObject {
if(child is Screen) {
super.addChild(child);
return child;
}
return null;
}
I don't see why not. I've never actually used a return value of addChild in practice. You'd need some way of knowing if the child had been added so you could then use:
if (!addChild(child))
{
//couldn't be added
}
instead of
if (child is Screen)
{
addChild(child);
}
else
{
// couldn't be added
}
Or you could instead throw an error in your override and catch that if it's not an instance of Screen.
I don't think it's a best practice issue at all if it works for you.
I see a couple of options and none feels completely "right".
The best solution, as I see it, is not possible in Actionscript (I think this is allowed in other languages). That is, declare that you will accept only instances of Screen:
override public function addChild(child:Screen):Screen {
return super.addChild(child);
}
Since that's not possible, the other options I can think of would be:
1) Throwing an Error.
I'm generally not very fond of throwing Errors, but a pro here is that it matches the behaviour of the extended class. If you pass a non valid display object to addChild, it will throw. On the other hand, this is valid given that the method signature tells you that you have to pass a DisplayObject. In this case, your method is "lying", in a way, because it says it accepts DisplayObjects but it really only accepts instances of Screen. So you are relying in documentation (hopefully) rather on the type system to tell the user code how it's supposed to use your function.
2) Adding an addScreen method that calls addChild.
public function addScreen(child:Screen):Screen {
return super.addChild(child) as Screen;
}
This is somewhat more typesafe, but you lose some of the advatanges of polymorphism (and perhaps it's not possible / feasible in your code). Maybe if we had method overloading... but we don't so, again, I guess it's a tradeoff.
3) Runtime type checking and returning null on failure.
This is what your code does. It could be just fine. What I don't like about it is what I mentioned above: that your method is kind of "lying". I don't expect a method that takes a DisplayObject to fail because I passed a DisplayObject. But well, sometimes, this is not a big deal.
I'm afraid I can't really give a definite answer on this. If possible, I think I'd probably go with option 2), but all these options seem equally valid. At some point you have to settle for the one that makes more sense for you and your project, I guess.
There is no good way to do, what you want to. If you want the desired behaviour, you are to use composition instead of inheritance. What you're trying to do is violating the Liskov substitution principle.