directional button problem
Blitz3D Forums/Blitz3D Programming/directional button problem
| ||
| the following code is for climbing around on a Mario World like fence ladder. The problem? If the player is pressing the left button and then at the same time presses the right button then the directional values causes the player to move right. But it doesnt work like that in opposite (pressing right button and then at the same time pressing left) same with vertical buttons, if the player is holding the down button and then at the same time holds down the up button then the player movement switches from down to up but doesnt do it when the button values are reversed. I would like to be able to switch the directional values regardless of the order of button pressing. So what must I do to fix this? |
| ||
| hi you are testing in a sequence so the "climb_dir" only stores the last tested. you have to decide what about pressing both key's. the expression: KeyDown(205) - KeyDown(203) gives 3 posible results: 0 if both keys are pressed 1 if only key 205 is down -1 if only key 203 is down the following code moves left/right if only one is pressed and do nothing if both are pressed if ClimbDirLeftRight is translated to: if ClimbDirLeftRight<>0 you can make an Else part in this statment to evaluate what would you like to do in case both are pressed: if ClimbDirLeftRight then ;1 if rigth only, -1 if left only else ;if both are pressed end if Graphics3D 800,600,0,2 SetBuffer BackBuffer() Cam=CreateCamera() Light = CreateLight() Cube=CreateCube() PositionEntity cube,0,0,10 While Not KeyHit(1) ClimbDirLeftRight = KeyDown(205) - KeyDown(203) ClimbDirUpDown = KeyDown(200) - KeyDown(208) If ClimbDirLeftRight Then MoveEntity Cube, ClimbDirLeftRight*0.1, 0, 0 End If If ClimbDirUpDown Then MoveEntity Cube, 0, ClimbDirUpDown*0.1, 0 End If RenderWorld Flip Wend Juan |
| ||
| Hey, thanks! :D I'll toy with this code and see what I can get out of it! |
| ||
| While technically speaking Charrua's way is sometimes faster, personally I don't bother with the extra If structure and just have it "MoveEntity e, Right - Left, Up - Down, Fwd - Back" once every loop. I just find less stuff onscreen to be visually cleaner; it's a MoveEntity where you could have avoided it, but since the game has to be able to absorb the speed cost (which is really not high) anyway, or it would slow down when you move, it's effectively no different (also because premature optimization is the root of all evil). Why point this out? Uh... well it'll help you recognise that same structure when you see it phrased like I just did. It's quite a common space-saving idiom; if your character moves in more than one dimension at a time, you can roll the movements into a single call to MoveEntity or whatever it is you use. |
| ||
I'm actually using 2D commands (the only 3D I'm using is in the background behind the 2D playing field) so I'm actually using:drawimage img_player,player_x,player_y Same difference I guess. :P I'm switching to BMax today anyway. Wish me luck in transferring my entire game into that coding language! Should be a fun little adventure! |
| ||
| If the player is pressing the left button and then at the same time presses the right button then the directional values causes the player to move right. But it doesnt work like that in opposite I dont know how many there are but some old KB drivers do this. |
| ||
| I dont know how many there are but some old KB drivers do this. Nah, it's nothing to do with his keyboard drivers, H&K, it's purely the order in which he has his IFs arranged. I am pretty sure that, with regards to what you suggested, it's also true that the hierarchy for the UDLR keys is Left > Up > Right > Down, respectively, or at least used to be. Come to think of it though, that was something I "learned" from a very old program of mine, so it may have been the same issue for me there; IFs in an odd order. |
| ||
| Wish me luck in transferring my entire game into that coding language! Should be a fun little adventure! Good luck transferring your game into that coding language! It should be a fun little adventure! ...sorry, couldn't resist. Here's a tip though: don't bother with the Import BB option. Doesn't work unless your code conforms to some very specific requirements (not just having to be valid BB), e.g. you can't have comments in certain places, and you'd better hope you didn't name anything a BlitzMax keyword. You'll learn the language faster if you do the port yourself by hand - aside from the fact that it's more likely to compile and work correctly, you can also spot little places where BlitzMax features will help with something you didn't have in Blitz3D (e.g. Continue from loops as well as Exit, roll helper functions in as nested ones, exception handling), which will help you learn the new feature set bit by bit rather than being faced with a monstrous wall of new things. |
   |