[Your help needed!] Test bugfix for key input processing when key is continuously pressed

Discussion in 'RPG Maker 2000/2003' started by Cherry, Oct 5, 2016.

  1. Cherry

    Cherry RM2k(3) Developer (English Version) Developer

    Messages:
    105
    Likes Received:
    57
    Location:
    Austria
    First Language:
    German
    Dear community,


    RPG Maker 2000 and 2003 always had the problem that when a key was continuously held down and you were polling the key states using "Key Input Processing", you would falsely get zero (no keys held down) every few checks, so it would look as if the user were pressing and releasing the key over and over again. (Those of you who encountered this problem before probably built a workaround by "debouncing" the key input and accepting key release only if it persisted longer than a few frames.)


    I now looked into this problem and I think I was able to fix it. However, this changes a few technical details in how the key input is processed and synchronized with the rest of the game. Because of that, I would kindly ask you to assist me here and test the bugfix in a few scenarios.


    I implemented the fix for RPG Maker 2000 only at the moment. If it works fine, it will be implemented in RPG Maker 2003 as well and later released.


    I have created a special RPG_RT.exe version for RPG Maker 2000 based on Version 1.61 which includes this bugfix. It is meant to be used for testing only and displays a nag window and an overlay to prevent production use. You can download the file here: https://www.dropbox.com/s/336wzchszcx2tst/RPG_RT_keyfix_beta.exe?dl=0 - To test it, copy it into a project's folder and use it instead of the normal RPG_RT.exe.


    Please test the following:


    - Does the fix work you in general? I.e., are there no more errornous key releases detected using "Key Input Processing" when a key is kept held down for some time?


    - Does the key input otherwise still work as usually?


    - Can you feel any performance impact compared to the normal version 1.61? (You can test it in some performance-hungry v1.61-based game, for example.)


    Thank you for your help!


    Cherry
     
    #1
    muramasa, Ally, Millefeuille and 2 others like this.
  2. Mephisto_jpn

    Mephisto_jpn Warper Member

    Messages:
    1
    Likes Received:
    0
    First Language:
    Japanese
    Hi!


    I tested this performance impact using the attached file project.


    - Does the fix work you in general? I.e., are there no more errornous key releases detected using "Key Input Processing" when a key is kept held down for some time?


    It works on My PC (vista 32bit and 7 64bit).


    - Does the key input otherwise still work as usually?


    Yes.


    - Can you feel any performance impact compared to the normal version 1.61? (You can test it in some performance-hungry v1.61-based game, for example.)


    Nothing I feel. 

    View attachment Project1.zip
     
    #2
  3. Cherry

    Cherry RM2k(3) Developer (English Version) Developer

    Messages:
    105
    Likes Received:
    57
    Location:
    Austria
    First Language:
    German
    Thank you for your feedback!
     
    #3
  4. muramasa

    muramasa Abomination of life, or life itself. Veteran

    Messages:
    581
    Likes Received:
    293
    Location:
    CR
    First Language:
    Spanish
    Howdy! I did a small test for this, just to try and lag it the necessary. All it consists of is just two Show image commands inside of a parallel process. It's the basics when talking about making RM2k lag hahahaha.


    Anyway, attached is the test project.

    I kept some time comparing both, and it does seem to do the trick. With the original 1.61 executable, it takes on my PC just around 1-2 seconds for it to start twitching. I guess it depends on the PC though. Also if it lags too much, it kind of skips the frame where it should twitch. It's weird.

    I've tested it out a little, and yes, it seems to behave the same in both executables. Keys with a higher value take precedence over others when pressed at the same key (i.e. pressing both Shift and Z gives you a 7 -shift-, directions are < 5 -Z/Accept- so result is always 5, and that's how things are supposed to be).

    As long as I've tested, there is no negative impact. Neither positive.


    Salut!

    View attachment Project1.rar
     
    #4

Share This Page