- changed title to Bug with mod_multi
Bug with mod_multi
I found a bug with the multi module (used for touch behaviors on Android for example). When you tap alternatively on two different region of the screen quickly, the touch module stops to works correctly. After that the bug appear, the touch position is updated only if you touch the screen with two fingers.
Here is the code to reproduce the bug :
import "mod_video"
import "mod_key"
import "mod_text"
import "mod_sound"
import "mod_wm"
import "mod_map"
import "mod_draw"
import "mod_say"
import "mod_file"
import "mod_text"
import "mod_multi"
import "mod_mouse"
import "mod_proc"
import "mod_screen"
import "mod_rand"
import "mod_grproc"
import "mod_math"
import "mod_scroll"
import "mod_effects"
import "mod_timers"
import "mod_mem"
import "mod_multi"
global
string touch_position;
end
begin
set_mode(300, 400, 32);
set_fps(60,0);
write_var(0, 0, 0, 0, touch_position);
while(!key(102) && !key(_esc) && !exit_status)
touch_position = "Touch : " + multi_info(0, "X") + ", " + multi_info(0, "Y");
frame;
end
exit();
end
You can try on a Android device with this APK :
Comments (22)
-
reporter -
reporter I made a video ; https://youtu.be/BXWWDB9TYgM
-
I had a look at the code of mod_multi. Perhaps it would be of help if you wrote also the result of modmulti_numpointers when you do the test.
-
And perhaps output multi_info(x, "ACTIVE") for x = 0; x < 10.
-
reporter import "mod_video" import "mod_key" import "mod_text" import "mod_wm" import "mod_proc" import "mod_multi" begin set_mode(300, 400, 32); set_fps(60,0); while(!key(102) && !key(_esc) && !exit_status) write(0, 0, 0, 0, "Pointers : " + multi_numpointers()); for(x = 0; x < 10; x++) write(0, 0, 10 + x * 10, 0, "Multi [" + x + "] (active : " + multi_info(x, "ACTIVE") + ") : " + multi_info(x, "X") + ", " + multi_info(x, "Y")); end frame; delete_text(all_text); end exit(); end
-
reporter - attached PixTudio SandBox-debug.apk
Updated APK
-
reporter The best way to reproduce the bug is to make the same thing than I show on my video but with two fingers by each hand.
-
Hi,
I tested your code with both examples, and as I was suspecting, in the second case you can see that the Index 1 gets updated "when the bug appears", and that is why you do not see anything in the first example.
I am not sure what were the intentions when the mod_multi was developed but in the way I look at it, modmulti_numpointers just gives you how many fingers are touching the screen, it does not tell you anything about the indexes that you pass to the modmulti_info!
You have to loop through all possible indexes, which are 0 to 9, and see which one is "ACTIVE". If you test your second example, you will see that "when the bug happens", the index that changes is 1, and that is the only one that is active.
Some improvements that I would like to see (I can do them myself and do a pull-request):
-
mod_multi shall export a constant that defines the maximum possible index, or perhaps better, this maximum number shall be configurable somehow.
-
modmulti_info can currently return X, Y, PRESSURE and ACTIVE. I would like it to return also the FINGER_ID.
-
-
reporter Your suggested improvements looks fine but why not simply reset the multi indexes when there is no finger active ? In this way, the first finger that touch the screen will take the first index. I don't know if you understand what I mean (I'm sorry, I'm french and my english is not 100% good ! :) )
-
I understand what you mean, but there is a problem. Consider the following situation:
You touch the screen with two fingers. Now you lift-up one. How can you know which one is the one you lifted up (fingers might had move on the screen! who knows if finger 1 is where finger 0 was and finger 0 where finger 1 was) ? For some applications it may not matter, for for other it does!
The code in mod_multi ensures that in such an operation, the index 0 to 9 will not change, which means that if you know that 0 and 1 were active, and in next frame index 0 is not active, then the first finger is exactly the finger that was lifted up. If you would touch with a "third" finger at the same moment you lift finger 0, that will be registered in index "2", so it does not affect "your reading" of finger "0".
In Java and ADK, you make use of the "FINGER_ID" that I mentioned in my suggestion, which is a kind of uuid that allows you to always know if a touch event (motion, up or down) belongs to the same "finger operation" or if it is a new one. This is, in theory not necessary in PixTudio, because PixTudio will keep the information relative to the same "finger operation" in the same index. Unless you touch the screen with more than 10 fingers... which I guess is rare...
In any case, as I said, it is difficult for me to know what were the intentions of joseba and it is him who has the last word...
-
reporter I understand what you say, but if there is no fingers on the screen (0), I think the first finger that touch the screen should take the first index. It should not affects the behaviors that you've described. Am I wrong ?
-
It does make sense what you say. But let's see if someone else that knows more than me has something to add :)
-
repo owner I'm out of home until Sunday. Let me reply then 😃
-
repo owner I've been having a look at this (thank you very much, Benjamin, for your detailed report, examples and video). The intended behaviour of mod_multi is pretty much as Darío states: * ID of a finger should not change as long as a finger is touching the screen * modmulti_numpointers reports the total number of fingers down when you get it, it's not guaranteed that the fingers necessarily start at index 0 (for the reasons that Darío already pointed out). In order to check for active fingers, you must look for the active flag from 0 to 9 (the total number of possible ifngers is 10 right now). When I wrote the code, only my iPad and my Nexus phone could handle 10 pointers, other devices could only handle 3 or 5 pointers at a 10, so 10 seems like a sensible number.
That said, and looking at the code, when all the fingers are lifted and then one finger touches the screen, the index should be 0 again, unless SDL events are being dropped. Let me look at it.
-
repo owner Commit b07ebfd adds a constant that indicates the maximum number of pointers the module can work with.
-
repo owner Benjamin, could you please try the code in the latest commit?
-
reporter Thanks for your modifications. But I think that it will not fix the bug to know the maximum number of pointers. When all the fingers are released, the next finger index must be 0. Indeed I can check all the indexes and return the first active, but the constant of maximum number of pointers is not very helpfull since I can check from 0 to 9. And in my case, the bug occurs with only two fingers. Maybe I'm missing something.
I've tried to compile the source from the last commit, but when I try to compile and run my game with the new pxtb and pxtp exes, the game exits immediatelly with exit code 0:
PixTudio Blender 1.0.0 (Jul 4 2016 12:39:01) Pixtudio comes with ABSOLUTELY NO WARRANTY See COPYING for copyright details File main.dcb compiled (572779 bytes): Processes 392 Global data 108884 bytes Local data 344 bytes Private data 11860 bytes Public data 0 bytes Code 234720 bytes System processes 257 Globals vars 158 Locals vars 50 Private vars 1009 Publics vars 0 Identifiers 1585 Structs 22 Strings 112 (1052 bytes) D:\Creations\Programmation\VideoGames\BennuGD\Tools\DivLike-IDE\pixtudio\\pxtp.exe main.dcb <<< Process finished. (Exit code 0) ================ READY ================
What am I doing wrong ?
-
I believe he meant this commit, which does modify the mod_multi function in a way it can impact the result.
-
reporter Thank you Dario, I did not notice it.
-
repo owner - attached MyGame-debug.apk
I've repackaged your original code with the latest code of PixTudio for Android. I cannot seem to reproduce the bug with this latest version.
Could you please check?
(If that works, we can move on to your other issue)
-
reporter I confirm the bug is fixed! I made several attempts, the bug no longer occurs.
-
repo owner - changed status to resolved
Cool, Closing this bug.
Can you, please, create a new bug report for your code quitting inmediately? Also, please include the output of running pxtp with the "-d" flag in two cases: * After compiling your code without debugging information (pxtb main.prg && pxtp -d main.dcb) * After compiling your code with debugging information (pxtp -g main.prg && pxtp -d main.dcb)
- Log in to comment