#gemrb@irc.freenode.net logs for 22 Feb 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:11:33] --> traveler has joined #gemrb
[00:13:33] <lynxlynxlynx> cool
[00:18:58] --> rocket_hamster has joined #gemrb
[00:25:16] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[00:50:37] --> thomcom has joined #gemrb
[02:06:05] <-- edheldil_ has left IRC (Read error: Operation timed out)
[02:25:50] <-- rocket_hamster has left IRC (Quit: bye!)
[02:39:01] <-- thomcom has left IRC (Ping timeout: 245 seconds)
[03:37:45] --> thomcom has joined #gemrb
[04:13:23] <-- thomcom has left IRC (Ping timeout: 245 seconds)
[05:23:07] --> thomcom has joined #gemrb
[05:31:43] <-- thomcom has left IRC (Ping timeout: 245 seconds)
[05:33:35] <-- brada has left IRC (Quit: brada)
[05:38:31] --> brada has joined #gemrb
[06:09:02] <-- brada has left IRC (Quit: brada)
[06:24:07] <-- nutron has left IRC (Remote host closed the connection)
[06:38:51] --> nutron has joined #gemrb
[08:14:03] --> WingedHussar has joined #gemrb
[08:47:27] --> edheldil_ has joined #gemrb
[09:04:24] <-- edheldil_ has left IRC (Ping timeout: 264 seconds)
[09:04:40] --> edheldil_ has joined #gemrb
[09:30:02] <-- |Cable| has left IRC (Ping timeout: 255 seconds)
[09:41:59] --> |Cable| has joined #gemrb
[10:13:36] --> lynxlynxlynx has joined #gemrb
[10:13:36] <-- lynxlynxlynx has left IRC (Changing host)
[10:13:36] --> lynxlynxlynx has joined #gemrb
[10:13:36] --- ChanServ gives channel operator status to lynxlynxlynx
[10:51:13] --> WingedHussar1 has joined #gemrb
[10:52:42] <-- WingedHussar has left IRC (Ping timeout: 252 seconds)
[11:11:55] --> rocket_hamster has joined #gemrb
[11:47:17] --> duckpunch has joined #gemrb
[14:29:12] --> thomcom has joined #gemrb
[15:19:13] <-- thomcom has left IRC (Ping timeout: 245 seconds)
[15:39:44] <-- rocket_hamster has left IRC (Quit: bye!)
[15:52:13] --> kida has joined #gemrb
[16:22:34] --> thomcom has joined #gemrb
[16:53:56] --> brada has joined #gemrb
[17:15:36] <brada> psch: ready to work on touch input?
[17:18:45] <-- kida has left IRC (Quit: Leaving)
[17:18:57] --> kida has joined #gemrb
[17:19:23] <brada> your biggest problem is that firstFingerDown.fingerId is likely always 0 for you
[17:22:11] <psch> yeah im free right now
[17:23:51] <psch> that's a limitation from sdl2?
[17:25:30] <brada> its a limitation of the documentation for sdl i guess
[17:25:41] <brada> i had to figure this out on my own
[17:26:17] <psch> if variable names are any indication, isn't that actually semantically perfectly fine?
[17:26:30] <psch> as in, the first finger's id should always be 0
[17:26:44] <brada> where does it say that?
[17:26:46] <psch> i don't know how the event comes
[17:27:05] <psch> i'm probably assuming too much
[17:27:13] <psch> i'd think, for any touch event, the first finger would be 0
[17:27:23] <psch> to be able to distinguish multitouch events
[17:27:31] <psch> but that's probably an overbearing assumption
[17:28:02] <brada> well my first fingerid is 39368864
[17:28:13] <brada> so no at least on ios it is not that way
[17:28:20] <psch> i see
[17:28:57] <brada> my touchid is 0 however
[17:29:41] <brada> time to see if there is any documentation about this now
[17:29:46] <psch> ill actually read through SDL_androidtouch.c a bit first, before trying to make sense from varnames
[17:31:18] <psch> SDL_TouchID touchId; /**< The touch device id */
[17:31:27] <psch> so that makes sense for touchId to be 0 at least
[17:33:00] <brada> ok
[17:33:19] <brada> maybe all i have to do is set finderid to -1 when invalid instead of 0
[17:33:47] <brada> except
[17:34:06] <brada> well lets try it
[17:35:36] <brada> and finderid is a 64bit int...
[17:36:04] <brada> unlikely that it is actually supposed to be indicative of the finger index
[17:36:19] <psch> true
[17:36:29] <psch> i was definitely making wrong assumptions heh
[17:36:50] --> rocket_hamster has joined #gemrb
[17:38:51] <brada> seemingly works for ios
[17:38:57] <brada> ill post a patch for you
[17:39:06] <brada> i dont want to commit this expirament :p
[17:39:17] <psch> heh
[17:39:37] <fuzzie> touchId 0 is definitely valid
[17:39:38] <-- thomcom has left IRC (Ping timeout: 245 seconds)
[17:39:43] <fuzzie> touchId -1 is not :)
[17:40:09] <fuzzie> no idea otherwise :P
[17:40:25] <brada> http://paste.debian.net/237136/
[17:40:26] <Seniorita> debian Pastezone
[17:40:41] <brada> fuzzie: how do you know?
[17:41:02] <psch> i like how fingerId is the only field of the SDL_TouchFingerEvent that isn't documented on the sdl wiki
[17:41:08] <brada> i know right
[17:41:15] <brada> just apply that patch
[17:41:23] <brada> see if things come to life magically
[17:42:04] <fuzzie> brada: because the finger id in sdl comes from android apis
[17:42:11] <brada> oh ok
[17:42:42] <fuzzie> via JNI (core/android/SDL_android.cpp) -> Android_OnTouch (video/android/SDL_androidtouch.c) -> SDL_SendFingerDown/etc if it helps
[17:42:48] <brada> well thats definitely at least part of the problem
[17:42:54] <psch> alright, building
[17:43:29] <fuzzie> obviously if it doesn't work sitll then it might be worth reading the code, since I'm pretty tired and might be stupid
[17:43:38] <brada> nah
[17:43:51] <brada> i remember beholder was able to gt it working fairly easily
[17:44:08] <brada> would have been nice if it had been done in the public channel :/
[17:44:26] <fuzzie> yes
[17:44:35] <fuzzie> usually I try my best to move things out of query for that reason
[17:44:55] <brada> well at the time there was a rather busy conversation in the main channel
[17:44:57] <fuzzie> even if people keep logs, they're not always around forever/always
[17:45:08] <brada> and it was annoying trying to filter it out
[17:45:14] <fuzzie> *nod*
[17:48:43] * brada eargly awaits test results
[17:48:44] <psch> http://nopaste.info/3f153d346e.html
[17:48:45] <Seniorita> Nopaste - powered by project-mindstorm IT Services
[17:48:46] <psch> crash
[17:50:00] <brada> need more info
[17:50:04] <brada> what line?
[17:51:35] <psch> 0x69140340 in GemRB::SDL20VideoDriver::ProcessEvent (this=0x67efce08, event=...) at jni/src/main/gemrb/plugins/SDLVideo/SDL20Video.cpp:427
[17:51:56] <psch> that's lastFingerId = state->fingers[0]->id;
[17:52:10] <brada> no fingers is null i guess
[17:52:17] <brada> how can that be?
[17:52:33] <psch> (gdb) print state->fingers
[17:52:33] <psch> Cannot access memory at address 0x64
[17:52:54] <brada> or state is null
[17:52:56] <brada> then
[17:53:00] <psch> state is null yeah
[17:53:07] <brada> but again how can that be?
[17:53:14] <brada> state should be valid for any ouch event
[17:53:18] <brada> touch
[17:53:21] --> fizzle has joined #gemrb
[17:54:31] <brada> fizzle: have you had anymore audio errors?
[17:55:08] <psch> README.touch:IMPORTANT: If the touch has been removed, or there is no touch with the given ID, SDL_GetTouch will return null. Be sure to check for this!
[17:56:08] <brada> that doesnt make sense tho
[17:56:20] <brada> if the touch is "removed" why is it a finger down?
[17:56:23] <psch> i don't know what "the touch has been removed" could mean
[17:56:23] <-- rocket_hamster has left IRC (Remote host closed the connection)
[17:57:04] <brada> well put a check above that line then
[17:57:09] <brada> see where that gets you
[17:57:35] <fuzzie> that's in SDL_FINGERMOTION?
[17:58:02] <psch> yeah
[17:59:03] <psch> i added a check for state != null around the assignment to lastFingerId now
[18:01:55] <fuzzie> it looks like finger state, at least, gets removed the moment the user releases the finger
[18:02:10] <fuzzie> so presumably touch state can also be removed the moment the user releases all fingers
[18:02:38] <fuzzie> why not just use event.tfinger.fingerId, brada? new?
[18:03:14] <brada> dont remember :D
[18:03:18] <brada> maybe no reason at all
[18:03:44] <brada> well
[18:03:54] <fuzzie> well i think it's probably more complicated than that
[18:04:01] <brada> it looks like i specifically want the first finger that contactd
[18:04:32] <brada> i vaguely remember something about queer behavior otherwise
[18:04:33] <fuzzie> as far as I can tell you basically have to remember that internally
[18:04:41] <fuzzie> based on the ids
[18:04:59] <fuzzie> but it all seems a bit crazy
[18:05:48] <brada> im surprised that ios and android are so different when using SDL
[18:07:14] <psch> with the check i don't crash at least
[18:07:22] <psch> still no reaction from the touchscreen though
[18:07:24] <fuzzie> brada: are they that different really?
[18:07:43] <fuzzie> I mean, I think it's mostly that the 'correct way' to use the touch APIs isn't documented.
[18:07:45] <brada> well this code works wonderfully on ios and doesnt work at all on android :D
[18:07:53] <fuzzie> So you end up using sekrit iOS-specific behaviours.
[18:08:50] <brada> psch: you are going to have to gdb / print out some trace info
[18:08:56] <psch> sure
[18:09:44] <brada> ProcessFirstTouch is going to be one target
[18:10:10] <fuzzie> it seems like down/up should work ok
[18:10:16] <brada> yeah
[18:10:20] <brada> thats what i thought
[18:10:24] <fuzzie> as long as you don't do it too quickly :P
[18:11:28] <psch> so what should i look at?
[18:11:42] <psch> i am at bp on the entry into ProcessEvent
[18:12:01] <psch> there's another set at ProcessFirstTouch
[18:12:26] <psch> im wondering though if debugging the touch events could be kinda wonky
[18:12:33] <brada> i see a place i missed in that patch
[18:12:44] <psch> as in, when i continue and am not touching anymore...?
[18:13:05] <fuzzie> the code in git confuses me
[18:13:08] --> rocket_hamster has joined #gemrb
[18:13:10] <brada> :(
[18:13:51] <fuzzie> when is firstFingerDown.fingerId *not* zero?
[18:14:20] <fizzle> brada: no, but I haven't played, either ;)
[18:14:21] <fuzzie> it seems only set when the first finger goes down
[18:14:51] <brada> updated patch: http://paste.debian.net/237148/
[18:14:52] <Seniorita> debian Pastezone
[18:15:14] <fuzzie> and then ProcessFirstTouch resets it back to zero
[18:15:16] <brada> fuzzie:
[18:15:25] <brada> fuzzie: thats what the patch is for
[18:15:27] <fuzzie> oh right you patch it :)
[18:19:57] <brada> psch: does changing that other line change anything?
[18:19:59] <fuzzie> bit busy for a moment, but that change seems to cover the bases
[18:20:17] <psch> im building right now
[18:20:28] <fuzzie> presumably if SDL_GetTouch returns NULL then numFingers being 0 is the correct result
[18:21:08] <brada> presumably
[18:21:14] <brada> would be nice if there were docs
[18:21:37] <fuzzie> so the most obvious problem is .. ignoreNextFingerUp being true?
[18:22:03] <fuzzie> oh, you set that in SDL_FINGERMOTION
[18:23:09] <fuzzie> oh, but you set it back to false in the numFingers<=1 case
[18:24:57] <psch> my bp at GemRB::SDL20VideoDriver::ProcessFirstTouch gets hit the first time after touching to skip the 3rd dev intro video, wotc
[18:25:04] <psch> maybe something doesn't get reset?
[18:25:42] <fuzzie> ProcessFirstTouch is always called for SDL_FINGERUP
[18:25:46] <fuzzie> you don't get it at all after the first time?
[18:26:09] <fuzzie> or is your bp inside the if?
[18:26:19] <psch> my bp is on the function
[18:26:31] <psch> i hit it again after the videos
[18:26:45] <brada> the videos input is handled elsewhere
[18:26:53] <psch> but not when i skip bwdragon or bislogo
[18:27:02] <psch> that's probably the reason then
[18:27:50] <psch> (gdb) print firstFingerDown
[18:27:50] <psch> $3 = {type = 0, timestamp = 0, windowID = 0, touchId = 0, fingerId = -1, state = 0 '\000', padding1 = 0 '\000', padding2 = 0 '\000', padding3 = 0 '\000', x = 0, y = 0, dx = 0, dy = 0, pressure = 0}
[18:27:57] <psch> that doesn't look right to me
[18:27:59] <brada> SDLVideoDriver::PollMovieEvents()
[18:28:05] <fuzzie> psch: where is that?
[18:28:07] <brada> is where the movie events are handled
[18:28:12] <brada> dont worry about it
[18:28:12] <psch> that's in the menu, in ProcessFirstTouch
[18:28:15] <brada> its irrelevant
[18:29:48] <brada> in the menu?
[18:29:55] <psch> yeah, the gdb print is from the menu
[18:29:58] <psch> bg2 menu
[18:30:04] <brada> oh i see
[18:30:11] <brada> but where is that bp?
[18:30:26] <psch> the bp is on GemRB::SDL20VideoDriver::ProcessFirstTouch
[18:30:28] <brada> because firstFingerDown does get reset at the end
[18:30:52] <psch> Breakpoint 1, GemRB::SDL20VideoDriver::ProcessFirstTouch (this=0x67efce08, mouseButton=1) at jni/src/main/gemrb/plugins/SDLVideo/SDL20Video.cpp:310
[18:30:55] <psch> 310 if (!(MouseFlags & MOUSE_DISABLED) && firstFingerDown.fingerId >= 0) {
[18:31:56] <brada> processfirsttouch gets called alot and it isnt always expected that firstFinderDown be valid
[18:32:08] <brada> thats why there is a check that it is valid
[18:32:34] <brada> put bps where firstFinderDown is set
[18:32:40] <brada> to a valid finger
[18:33:10] <brada> line 432
[18:33:18] <brada> well after that
[18:33:26] <brada> so we can inspect the "valid" touch
[18:33:36] --> thomcom has joined #gemrb
[18:34:27] <brada> put it on 441
[18:35:08] <psch> i put it on 434, firstFingerDown = event.tfinger;
[18:35:23] <psch> if that's the statement but im not reaching there
[18:35:37] <psch> that's probably 432 for you, because of my state != NULL check
[18:35:47] <brada> ah
[18:36:29] <brada> seems like it should be impossible not to reach there
[18:37:21] <brada> it is a touch with a finger in contact
[18:37:27] <brada> therefore state should be valid
[18:37:33] <brada> and numFingers should be 1
[18:37:59] <fuzzie> no
[18:38:06] <brada> so check to see if state is *ever* valid
[18:38:09] <fuzzie> since state isn't necessarily ever valid
[18:38:13] <brada> really?
[18:38:15] <brada> never ever?
[18:38:22] <fuzzie> well, if the finger is still held down
[18:38:26] <brada> right
[18:38:28] <brada> thats what i mean
[18:38:38] <brada> this is in finger down
[18:38:51] <fuzzie> but obviously if you tap quickly then it can be invalid in finger down
[18:38:59] <fuzzie> it seems a bit of a flawed design
[18:39:00] <psch> im holding for 1-2 seconds
[18:39:29] <fuzzie> hm where's the touch code?
[18:39:39] <brada> psch: put a bp in the state check at the top of the function
[18:39:50] <brada> does it ever trip?
[18:40:03] <fuzzie> ok, so touches are deleted by SDL_DelTouch only
[18:40:29] <psch> yeah
[18:40:37] <psch> the state bp is reached
[18:40:42] <brada> just by tapping?
[18:40:45] <psch> yup
[18:40:48] <psch> and state is valid there
[18:40:51] <fuzzie> but Android_OnTouch isn't using the id..
[18:40:59] <psch> i think it is
[18:41:05] <fuzzie> oh, it is
[18:41:07] <psch> probably only while i touch
[18:41:34] <psch> nope, i was wrong there, state is null
[18:41:34] <fuzzie> yes, state is only valid when you touch..
[18:41:38] <brada> right
[18:41:41] <psch> even with still touching
[18:41:51] <brada> but that doesnt explain why that code is never reached in finger down
[18:42:01] <brada> ie if he is holding his finger down for 2 sec
[18:42:16] <fuzzie> how long is the right-click delay, a lot longer?
[18:42:20] <brada> so what is numFinders set to when you tap with one finger?
[18:42:27] <brada> in that state check
[18:42:35] <brada> 500 ticks iirc
[18:42:35] <psch> (gdb) print state
[18:42:35] <psch> $3 = (SDL_Touch *) 0x0
[18:42:53] <psch> reached bp when touching, kept touching, printed
[18:43:07] <psch> released after printing
[18:43:18] <brada> but what about numFingers?
[18:43:35] <brada> when you first hit that state check is it getting set to 1?
[18:44:17] <psch> (gdb) print numFingers
[18:44:17] <psch> $4 = 0
[18:44:21] <brada> see
[18:44:21] <fuzzie> the SDL code is confusing as heck
[18:44:30] <fuzzie> the SDL_SendFingerDown function is used to send finger up events.
[18:44:31] <brada> 0 clearly shouldnt be correct
[18:44:56] <brada> and that explains why that code is never reached
[18:45:13] <fuzzie> however, the android code never calls SDL_DelTouch
[18:45:17] <psch> numFingers gets initialized one line higher?
[18:45:33] <brada> so basically you arent checking what i asked?
[18:45:37] <-- rocket_hamster has left IRC (Quit: bye!)
[18:45:48] <fuzzie> SDL_DelFinger is called immediately after SDL_FINGERUP is queued though. ick.
[18:45:54] <brada> the result following line 350 is what i want
[18:45:57] <psch> oh
[18:46:18] <psch> yeah i didnt see that you wanted me to step further
[18:46:23] <brada> and also will you give me the event type when that first trips
[18:47:15] <psch> so, breakpoint at SDL20Video.cpp:348 right?
[18:47:22] <brada> no
[18:47:27] <brada> 351
[18:47:30] <psch> ok
[18:47:36] <-- edheldil_ has left IRC (Ping timeout: 264 seconds)
[18:47:51] <psch> doesn't happen
[18:47:54] <brada> ever?
[18:48:05] <psch> not with tapping briefly, not with holding
[18:48:15] <psch> happens with multi touch
[18:48:17] <brada> well that is a huge problem
[18:48:47] <brada> saht is the event touchId for multi vs single touch?
[18:49:03] <fuzzie> is this touch->num_fingers?
[18:49:08] <fuzzie> sorry, no code here now
[18:49:15] <brada> fuzzie: yes
[18:49:16] <fuzzie> but touch->num_fingers should definitely be 1
[18:49:27] <brada> but more important state is never valid unless its multitouch
[18:49:39] <brada> on android
[18:49:44] <brada> which seems silly
[18:50:09] <psch> only with 3 fingers, too
[18:50:14] <psch> two doesn't trip
[18:50:14] <fuzzie> sorry, i'm still tracing my way through code
[18:50:31] <psch> and state->num_fingers is set to 3 then, too
[18:50:38] <brada> psch: the touchId on valid vs invalid states?
[18:51:04] <psch> im trying to get through the SDL_event members
[18:51:13] <psch> kind of hard to read for, it's a big struct
[18:51:17] <psch> ill put the output up
[18:51:24] <brada> should be event.tfinger.touchid
[18:51:42] <brada> touchID rather
[18:51:42] <psch> that's 2
[18:51:48] <psch> with 3 fingers
[18:51:56] <fuzzie> state should always be valid.
[18:52:02] <brada> fuzzie: yes
[18:52:06] <brada> but its not
[18:52:08] <fuzzie> well, no, i mean, there's no guarantee
[18:52:12] <brada> right
[18:52:24] <brada> but it shouldnt be limited to multitouch with 3 or more fingers
[18:52:24] <fuzzie> but I see no place it can be deleted in the android code
[18:52:37] <brada> its completely useless
[18:52:48] <fuzzie> and it's always created for every new touch event
[18:52:49] <brada> and the only way i know to get the info needed
[18:53:01] <brada> then how come his bp never trips?
[18:53:11] <brada> unless its 3 fingers?
[18:53:20] <brada> no matter how long he holds or moves
[18:53:22] <fuzzie> yes
[18:53:25] <fuzzie> no use complaining at me :P
[18:53:29] <fuzzie> i just say how the code works
[18:54:11] <fuzzie> oh
[18:54:25] <fuzzie> so, what happens is
[18:54:36] <fuzzie> the native android touch handler calls SDL_GetTouch(touchDeviceId)
[18:54:48] <fuzzie> if it gets a NULL, then it makes a new touch struct with id==touchDeviceId and passes it to SDL_AddTouch
[18:56:52] <brada> why did this work with beholder?
[18:56:58] <fuzzie> so I don't see how this would fail
[18:57:02] <brada> we never had to piss with the touch state
[18:57:17] <fuzzie> right, but it was a different sdl2 :P
[18:58:32] <fuzzie> psch: you have nothing in android log, right?
[18:59:13] <fuzzie> brada: if you have a local checkout of the sdl2 tree, maybe see if SDL_DelTouch is called anywhere?
[18:59:37] <psch> the android log doesn't output anything, no
[18:59:52] <brada> its called 1 place
[19:00:00] <psch> oh wait
[19:00:07] <brada> in SDL_TouchQuit
[19:00:13] <fuzzie> yeah, that's what I found too
[19:00:13] <psch> there's 2 lines from InputDispatcher
[19:00:16] <psch> i overlooked those
[19:00:16] <fuzzie> and that one is irrelevant right?
[19:00:24] <brada> i think
[19:00:27] <psch> I/InputDispatcher( 481): Window 'Window{421a8d50 u0 net.sourceforge.gemrb/net.sourceforge.gemrb.GemRB}' spent 57790.7ms processing the last input event: MotionEvent(action=2, deviceId=2, source=0x00001002, displayId=0)
[19:00:34] <psch> that's one example
[19:00:48] <fuzzie> 57s to process an event is probably bad
[19:01:11] <fuzzie> but it's just because you have it in gdb
[19:01:14] <psch> probably because of the bp
[19:01:14] <fuzzie> if it's in gdb
[19:01:18] <psch> yeah
[19:01:18] <fuzzie> right :)
[19:02:16] <brada> maybe we need an sdl error check after trying to get the state
[19:02:30] <fuzzie> maybe before it, too
[19:02:36] <fuzzie> i think only before it, actually
[19:02:47] <fuzzie> well it does't matter. but the state get func sets no errors.
[19:03:52] <fuzzie> anyway this makes no sense
[19:04:19] <fuzzie> SDL_SendFingerDown is the only thing which sends fingerup/fingerdown messages, right?
[19:04:37] <fuzzie> and it errors out, without sending an event, if SDL_GetTouch(touchId) is null
[19:05:03] <fuzzie> and psch is getting FINGERUP/FINGERDOWN, right?
[19:07:15] <psch> if i touch, continue in gdb, and then lift i hit the bp again
[19:07:23] <psch> so, yeah, i guess both of those come through
[19:07:33] <psch> for three fingers
[19:08:11] <brada> are you getting FINGERUP/FINGERDOWN events?
[19:08:41] <psch> event.type?
[19:09:18] <psch> event.type for removing three fingers is 1793
[19:09:20] <psch> err
[19:09:25] <psch> yeah
[19:09:28] <psch> no
[19:09:29] <psch> 1794
[19:09:48] <psch> im getting FINGERMOTION then
[19:09:53] <brada> just put a bp inside the case
[19:10:01] <brada> for finger down
[19:10:44] <brada> on this line: if (numFingers == 1) {
[19:10:48] <psch> yeah
[19:11:26] <psch> the event.type im getting for 3 or more fingers is 1794, which is 0x702 in hex
[19:11:30] <psch> i.e. SDL_FINGERMOTION
[19:11:43] <psch> and im not tripping in case SDL_FINGERDOWN:
[19:11:48] <psch> or rather, at the if right after
[19:12:30] <brada> yes you need to put bps *after* the evaluation
[19:12:40] <brada> otherwise they trip whenever its evaluated :)
[19:12:47] <brada> wether its true or false
[19:13:06] <psch> i put the bp on if(numFingers == 1) {
[19:13:23] <brada> right that is after the eval for fingerdown
[19:13:26] <psch> and im not reaching it
[19:13:31] <brada> ok
[19:13:36] <brada> fuzzie: no he doesnt
[19:13:55] <brada> apparently not ever
[19:13:57] <psch> as i said, the events that i get are SDL_FINGERMOTION
[19:14:09] <brada> so wtf?
[19:14:40] <psch> event.type is 1794, which is 0x702 in hex, which is SDL_FINGERMOTION
[19:14:52] <fuzzie> ok, that makes more sense
[19:15:18] <psch> what the heck
[19:15:24] <psch> i got a fingerdown just now from swiping
[19:15:26] <psch> ...?
[19:15:35] <psch> im confused
[19:15:43] <psch> im getting SDL_FINGERDOWN now
[19:15:53] <psch> after sitting in the debugger for 10 minutes
[19:16:52] <psch> http://nopaste.info/24e86473bb.html
[19:16:53] <Seniorita> Nopaste - powered by project-mindstorm IT Services
[19:16:57] <psch> that's event now
[19:17:08] <psch> with horrible linebreaks
[19:17:24] <fuzzie> that's valid
[19:17:28] <fuzzie> state should be valid there?
[19:17:36] <fuzzie> and numFingers should be set
[19:18:08] <psch> state is NULL, numFingers is 0
[19:18:34] <fuzzie> sounds like something pretty fundamental is broken then
[19:18:56] <psch> i dont even get how i suddenly got SDL_FINGERDOWN
[19:20:40] <psch> blame upstream? :/
[19:21:11] <psch> i restarted the app, no SDL_FINGERDOWN anymore
[19:24:11] <brada> time to post on SDL forum?
[19:24:35] <fuzzie> the only difference if you're holding multiple fingers is that the finger id changes
[19:25:37] <fuzzie> well, this code also futzes with the coordinates
[19:27:00] <fuzzie> but shouldn't matter
[19:27:32] <fuzzie> it does refuse to send SDL_FINGERDOW if it thinks the finger is down
[19:27:53] <fuzzie> but for SDL_FINGERUP, as long as the touch is valid, either it gets sent, or an sdl error is sent
[19:27:56] <psch> can i disable the ANR popup somehow?
[19:28:00] <fuzzie> it sounds like more fundamental brokenness to me
[19:29:32] <fuzzie> e.g. bad headers or misbuilt or something
[19:29:34] <fuzzie> but i don't see how
[19:29:44] <brada> yeah
[19:29:54] <fuzzie> psch: no idea
[19:30:23] <psch> cause that might be messing with the state during debugging
[19:30:25] <psch> but well
[19:30:29] <brada> i had something similare when i forgot to update my headers
[19:30:53] <psch> ill get the hg repo then
[19:32:44] <brada> and dont forget to update your headers :p
[19:33:24] <brada> if we are sure that fingerid 0 is valid then ill go ahead and commit this
[19:33:47] <psch> oh, /usr/include you mean?
[19:34:37] <brada> probably
[19:34:48] <psch> well duh
[19:34:49] <brada> where ever it is that gemrb is looking for them
[19:34:52] <psch> i was thinking it doesn't look there
[19:35:02] <psch> at least those paths arent in the makefiles
[19:35:15] <psch> i'd feel a bit dumb if that'd be it
[19:35:21] <psch> cause i don't have any sdl2 headers in /usr/include
[19:35:49] <brada> well you have to have them somehwere that gemrb is loking
[19:35:57] <brada> otherwise it would never compile
[19:35:59] <psch> yeah, i do
[19:36:28] <psch> i have the untarred SDL2.0.0-6862.tar.gz symlinked and i am pointing the makefile into that directory
[19:37:02] <brada> it would be a lot quicker if you didnt rebuild all the deps
[19:37:05] <brada> every time
[19:37:18] <psch> i know, i haven't gotten around to that yet
[19:37:22] <brada> ok
[19:37:31] <psch> i could remove sdl_mixer and the deps now i guess
[19:37:43] <psch> but then i'd have to first figure out what i dont have to compile anymore
[19:38:18] <psch> or rather, id have to let it break during compile to see what i dont have to compile
[19:40:37] <brada> well remove sdl_mixer
[19:40:49] <brada> as for the others once you build them you dont ever need to rebuild them
[19:40:57] <brada> unless you need/want to update the lib
[19:44:35] <psch> yeah, that involves chaning all the makefiles
[19:44:48] <psch> currently im calling them recursively
[19:46:02] <psch> i should probably set up a secondary build env that doesn't rebuild nearly everything
[19:46:37] <psch> i dont have anything smart-ish in the makefile not compile files that belong to a dependency either
[19:46:52] <psch> it's quite ad-hoc, currently
[19:55:09] <psch> behavior is the same with sdl hg
[19:56:10] <psch> event.type is fingerdown though, not motion
[19:56:13] <psch> but only with 3 or more fingers
[19:56:49] <brada> time to go ask the sdl people
[19:59:36] <psch> i dont feel confident enough to answer potential questions about the gemrb code
[19:59:58] <psch> but then, it probably doesn't really make sense to have someone without access to a device talk to them?
[20:00:02] --> edheldil_ has joined #gemrb
[20:16:12] <brada> yeah. you can just link them to the relavant code file
[20:39:22] --> kingron has joined #gemrb
[21:11:57] --> Cable_ has joined #gemrb
[21:12:18] <thomcom> you don't have a device psch?
[21:14:04] <psch> i do
[21:14:06] <-- |Cable| has left IRC (Read error: Operation timed out)
[21:14:10] <psch> but i dont know the gemrb code base
[22:09:52] <psch> so
[22:10:04] <psch> ive decided to keep looking instead of writing, because i didnt feel comfortable and all
[22:10:42] <psch> and SDLVideoDriver::ProcessEvents sees the SDL_FINGERDOWN
[22:10:47] <psch> is that a miscompile on my end?
[22:11:35] <psch> from what it looks like to me, SDLVideoDriver does things SDL12VideoDriver and SDL20VideoDriver need
[22:12:07] <psch> wait, not ProcessEvent, PollEvents
[22:12:49] <psch> but ProcessEvent gets called one line after where i log
[22:13:00] <psch> so i guess ProcessEvent probably sees it too
[22:19:32] <psch> are the event dispatched to the different ProcessEvent functions somewhere that im not seeing?
[22:21:06] <psch> i mean, SDL20VideoDriver::ProcessEvent calls SDLVideoDriver::ProcessEvent
[22:23:11] <psch> okay, i now see SDL20VideoDriver::PollEvents calling SDLVideoDriver::PollEvents
[22:24:17] <psch> and the latter calls SDLVideoDriver::ProcessEvent
[22:30:13] <psch> so
[22:30:37] <psch> the first event i get in SDLVideoDriver::PollEvents is 1024, SDL_MOUSEMOTION
[22:30:49] <psch> then 1025, SDL_MOUSEBUTTONDOWN
[22:30:54] <psch> then 1792, SDL_FINGERDOWN
[22:31:16] <psch> then on release i get 1026, SDL_MOUSEBUTTONUP and 1793, SDL_FINGERUP
[22:34:34] <psch> and SDL_MOUSEBUTTONDOWN, SDL_MOUSEBUTTONUP and SDL_MOUSEMOTION fall through to a break; in SDL20VideoDriver::ProcessEvent
[22:35:00] <fuzzie> which is correct
[22:35:29] <psch> but the default case in the switch calls SDLVideoDriver::ProcessEvent
[22:35:40] <psch> which sees my SDL_FINGERDOWN
[22:35:44] <psch> so the #ifdef is wrong?
[22:36:32] <psch> #if TARGET_OS_IPHONE || ANDROID
[22:36:39] <psch> shouldnt that be an #ifdef instead of #if?
[22:41:13] <psch> that still wouldnt explain fingerdown falling through though i guess
[22:42:08] <psch> i dont see where SDL20VideoDriver::ProcessEvent gets called, except for the right-click
[22:43:06] <psch> oh that's ProcessFirstTouch, anyway
[22:47:39] <brada> not that #if is fine
[22:48:35] <brada> the event flow logic is clearly correct since it works on ios
[22:49:03] <brada> the sdl api stuff is another matter
[22:49:34] <psch> so the problem is that event.type somehow doesn't have the correct value in the switch SDL20VideoDriver, but does have it in SDLVideoDriver?
[22:49:38] <psch> that's what it looks like to me
[22:50:29] <psch> because SDL20::ProcessEvent defaults to calling SDL::ProcessEvents, and fingerdown, ~up and ~motion do reach the switch in SDLVideoDriver::ProcessEvent
[22:51:50] <brada> afik nothing manipulates teh passed in events
[22:52:33] <psch> could the order matter? cause im getting mousedown first, and the fingerdown
[22:52:38] <-- fizzle has left #gemrb
[22:52:40] <brada> and there is not finger event handling outside sdl20driver
[22:52:59] <brada> mousedown events get dropped
[22:53:42] <brada> i dont know what you mean by order
[22:53:50] <brada> but sdl is what queues the events
[22:53:56] <brada> in the order they arrive
[22:54:03] <psch> yeah the question probably was rather dumb
[22:54:10] <psch> i mean, i can see that it gets dropped
[22:55:18] <brada> as far as i can tell from ur conversation something is not right inside sdl
[22:55:27] <thomcom> shocking
[22:57:14] <thomcom> Last I checked Android SDL wasn't quite up to snuff but we already knew that
[22:58:04] <brada> seems bizarrely broken tho
[22:58:33] <brada> and i cant find anybody else having touch input problems of this nature
[22:58:41] <fuzzie> yes
[22:58:47] <fuzzie> the relevant code hasn't changed in a relevant way recently
[22:58:57] <fuzzie> i mean, in quite some time
[22:59:02] <fuzzie> so it seems doubtful that it would be broken
[22:59:22] <brada> yeah
[22:59:33] <fuzzie> although you heard my opinion of their code already :p
[22:59:36] <brada> right
[22:59:53] <fuzzie> and I don't know what's out there using this..
[22:59:59] <thomcom> but who is using SDL2?
[23:00:06] <brada> on android?
[23:00:09] <thomcom> right
[23:00:15] <brada> not sure
[23:00:23] <brada> iv seen a few ios projects
[23:01:09] <fuzzie> well so https://play.google.com/store/apps/details?id=com.sensemagic.gravity is a recent one
[23:01:10] <Seniorita> xorf - Aplikacije za Android v storitvi Google Play
[23:01:11] <thomcom> dolphin player is still on SDL 1.1 or something as of 7 months ago
[23:01:24] <brada> but he *never* gets fingerDown events
[23:01:39] <fuzzie> he reported above seeing fingerdown
[23:01:47] <fuzzie> pretty sure it's got to be some madness in our code
[23:01:55] <brada> but where?
[23:02:27] <psch> i get fingerdown in SDLVideoDriver::PollEvents
[23:02:40] <psch> same for ~up and ~motion
[23:02:48] <brada> how?
[23:03:50] <brada> you mean in ProcessEvent?
[23:04:05] <fuzzie> so
[23:04:34] <psch> i added a Log call
[23:04:40] <brada> but wehre?
[23:05:03] <psch> in SDLVideoDriver::PollEvents, in the while loop
[23:05:11] <brada> yeah
[23:05:13] <fuzzie> 19:42 <brada> 500 ticks iirc
[23:05:18] <fuzzie> ^- that is actually 500ms?
[23:05:33] <brada> id have to look at the code
[23:05:40] <fuzzie> it is doing GetTickCount() - firstFingerDownTime >= TOUCH_RC_NUM_TICKS
[23:05:41] <brada> psch: that is epected there
[23:05:42] <fuzzie> which is ms
[23:05:46] <-- kingron has left IRC (Quit: Leaving)
[23:05:52] <fuzzie> which means ignoreNextFingerUp gets set to true
[23:06:01] <fuzzie> if more than 0.5s passes
[23:06:09] <brada> sure
[23:06:18] <brada> but he should have gotten a finger down before that
[23:06:18] <fuzzie> which would break MouseUp for psch's testing
[23:06:36] <brada> why look for finger up before down? :P
[23:06:41] <fuzzie> yeah I'm a bit suspicious psch's gdb is not very reliable
[23:06:51] <fuzzie> so I'm looking for that would go wrong in practice
[23:06:58] <fuzzie> assuming that everything is actually working fine
[23:07:16] <brada> psch: that loop will get all events but the processing will go though sdl20 first
[23:07:26] <brada> then if not handled there it gets processed in sdlvideo
[23:07:37] <brada> touch events are always handled
[23:10:15] <brada> i dont see another way to get the number of fingers
[23:10:24] <brada> other than SDL_touch
[23:10:32] <brada> which seemingly never exists for him
[23:11:26] <brada> that and the scale factor
[23:11:30] <brada> which is crutial
[23:12:16] <fuzzie> i think you're meant to keep track of it yourself :p
[23:12:26] <brada> well when tho?
[23:12:47] <brada> if we never get it where im checking for it
[23:12:48] <fuzzie> i mean, the number of fingers
[23:13:06] <fuzzie> you add one for finger down, subtract one for finger up, done
[23:13:13] <fuzzie> the scale factor is rather more problematic
[23:13:22] <fuzzie> but in any case the android SDL code guarantees you get the touch struct
[23:13:34] <fuzzie> and so I'm suspicious psch's gdb is not very reliable, or there's a build issue
[23:13:39] <brada> yes
[23:13:52] <brada> id feel better if you could look at it :p
[23:14:02] <fuzzie> but numfingers in the touch struct is not very useful
[23:14:27] <psch> i never get any event.tfinger.type != NULL except for in the right-click while
[23:14:43] <psch> i added that as a condition for a few more log calls to the two ProcessEvent functions
[23:14:46] <psch> and nothing gets printed
[23:14:47] <fuzzie> yeah, i totally have no time :(
[23:15:22] <psch> no wait
[23:15:27] <psch> that's wrong, didnt update the build on the tablet
[23:15:28] <psch> my bad
[23:15:49] <psch> at the start of SDL20VideoDriver::ProcessEvent it's there
[23:16:16] <psch> right after entry into the method i added an if(event.tfinger.type != NULL) { Log() }
[23:16:19] <psch> and that goes out
[23:16:45] <brada> i have to go out. i can talk more tomorrow
[23:16:56] <psch> alright
[23:16:57] <psch> have fun
[23:24:28] <psch> i think i found something
[23:24:41] <psch> in SDL/src/events/SDL_touch.c
[23:24:51] <psch> event.type is never set to SDL_FINGERDOWN or similar
[23:24:56] <psch> only event.tfinger.type is
[23:25:44] <psch> which would a) explain the behavior, because im looking at event.tfinger.type, and not event.type and get fingerdown and ~up
[23:25:49] <psch> and b) probably be a bug upstream
[23:26:03] <psch> seeing as event.type should be shared with everything in the union
[23:29:19] <psch> it does get set to SDL_TOUCHBUTTONDOWN and SDL_TOUCHBUTTONUP though
[23:30:28] <psch> is the ios port built against sdl2?
[23:33:40] <fuzzie> SDL_Event is a union
[23:33:56] <fuzzie> the type field is the same as tfinger.type is the same as button.type etc
[23:34:02] <fuzzie> it's really confusing
[23:39:02] <psch> alright, i think i get that union thing
[23:40:14] <psch> a union defines a container for multiple kinds of struct, one at a time, without needing space for all of them allocated
[23:40:46] <psch> and members of the sub-structs can be accessed directly as members of the union if they are defined there as well
[23:41:11] <psch> kind of like a crude template, if i understand it correctly
[23:44:11] <wjp> "if they are defined there as well" is not really what happens though. It's just that the first field of those sub-structs has the same memory location as the type field
[23:44:25] <psch> ah alright
[23:45:14] <psch> that's what the padding{1,2,3,*} vars are for
[23:45:56] <thomcom> all members of union are defined if any member of union is defined, but their data is ?
[23:46:44] <psch> whatever is in memory at the corresponding location at that time, no?
[23:46:50] <thomcom> their data is exactly the same bits across all union members :)
[23:46:56] <psch> oh
[23:47:03] <psch> where member of a union == sub-struct
[23:47:04] <psch> right
[23:47:07] <thomcom> yeah
[23:47:29] <psch> yeah that's how i undestood it, the members of a union just define different "cupboard layout"
[23:47:39] <psch> which is a horrible analogy
[23:48:46] <thomcom> simplest example of a union is to store an int32 and a float in the same location. If you access the float sub-struct of the union you get the floating point value of those bits, if you access the int sub-struct you get the int value. Change the int struct to "5" and the float value changes to the corresponding float value for "10100...000"
[23:49:09] <psch> yeah
[23:49:23] <psch> soo i found nothing except a lack of knowledge of c on my part :)
[23:51:46] <thomcom> unions are cool
[23:51:50] <thomcom> i can't claim to understand how they work
[23:52:55] <thomcom> an int casted pointer to the same block of memory that a float casted pointer also points to?
[23:53:29] <psch> well i've seen these type of casts without unions
[23:53:39] <psch> the quake 3 source code has a popular example
[23:53:43] <psch> the fast inverse square root
[23:53:58] <psch> ...i don't really understand it
[23:54:41] <psch> the union just abstracts the "manual" casts
[23:54:46] <psch> at least that's how i understand it
[23:55:37] <psch> i don't have any clue how it actually works, but that's machine code anyway