   FIghting Game input system?
  IM having some trouble figuring out stuff about handling input for a fighting gameconsider the following scenario:A punch attack can be canceled into a special attack, in order for this to happen the command of the special attack needs to finish exactly at the attacking frames of the punch attackSo if the punch attacking frames only last 3 frames and the startup of the attack is 2 frames (just an example) it means that I have a 5 frame window to input the command, but if the command to execute the special attack is a complex command say like BACK, BD, DOWN, DF, FORWARD, BACK, BD, DOWN, DF, FORWARD + PUNCH BUTTONthis means that the input manager needs to grab input commands faster than the render timeprobably im messing things up here but I dont see how this will work or actually the I/O works at a much faster rate than the render loop? do i need a separate thread for I/O handling? and maybe for fighting games the human player can actually clog the input system by pressing buttons at a faster rate than the hardware can handle?thanks   
Quote:BACK, BD, DOWN, DF, FORWARD, BACK, BD, DOWN, DF, FORWARD + PUNCH BUTTONthis means that the input manager needs to grab input commands faster than the render time No. You just buffer the input as it comes in, and act on all of it as it comes in as well.The character will act out all the directional inputs, but when you hit the attack button, you'll look through the buffered input to see if there is a special move pattern there, and then play the specific attack.Someone wrote a great post about this not to long ago. Try searching for fighting game threads. There has been a few in the last 2 months.   ;  so you mean that the controller is able to send a directional keypress faster than one per frame?   ;Quote:so you mean that the controller is able to send a directional keypress faster than one per frame?First, the "directional" part doesn't matter. All that matters is keypress and release events.In most implementations, either the device itself will buffer input events and send it to the OS when asked for it, or it will generate a CPU interrupt each and every time an input event happens (button triggered/released, joystick twisted etc); allowing the OS to buffer up the data.To explain it from another side, the OS doesn't check each frame (whereby frame is purely an abstraction: the OS doesn't care for VSYNC or whatever else when its checking input) "is this button pressed", which would indeed allow for input events get lost (and this will happen to you if you don't work on key events, but on key states). It just sends the buffered events to your application, one event after the other.   ;  Never done it, but....... uh.... heres how I think it would be done.variable inputsequence (a string)check for input.if input exist  add input to inputsequence  check inputsequence backwards  if input is equal to predetermined string    perform move  else    perform inputsequence (last item/char/etc)else  clear inputsequenceprobably a good idea to separate the time outside of that to determine when to rid yourself of the sequence. Could be a good idea to add a if button is still pressed down.   