#gemrb@irc.freenode.net logs for 15 Jan 2012 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:46:22] <Baldurer> when reporting a bug in gemrb that is specific to android, where is it best that I do it?
[00:56:28] <-- Maighstir has left IRC (Quit: .)
[00:58:09] --> joneirik has joined #gemrb
[01:13:32] --> brad_a has joined #gemrb
[01:14:05] <tomprince> Probably the forum.
[01:48:04] --> harijan_ has joined #gemrb
[01:50:45] <-- harijan has left IRC (Ping timeout: 248 seconds)
[02:38:30] <-- brad_a has left IRC (Quit: brad_a)
[02:54:41] <-- kettuz has left IRC (Quit: Leaving)
[04:12:34] <-- Baldurer has left IRC (Ping timeout: 260 seconds)
[04:21:52] --> Drakkar has joined #gemrb
[04:23:35] <-- PixelScum has left IRC (Ping timeout: 260 seconds)
[05:07:25] --> PixelScum has joined #gemrb
[05:07:48] <-- joneirik has left IRC (Remote host closed the connection)
[05:08:33] <-- Drakkar has left IRC (Ping timeout: 244 seconds)
[05:16:24] --> che_ has joined #gemrb
[05:26:16] <-- che_ has left IRC (Ping timeout: 240 seconds)
[06:34:10] --> nutron has joined #gemrb
[06:51:15] --> Drakkar has joined #gemrb
[06:52:56] <-- PixelScum has left IRC (Ping timeout: 240 seconds)
[07:20:30] <-- lachlans has left IRC (Quit: Page closed)
[07:44:46] --> PixelScum has joined #gemrb
[07:46:44] <-- Drakkar has left IRC (Ping timeout: 240 seconds)
[08:06:22] --> Drakkar has joined #gemrb
[08:08:50] <-- PixelScum has left IRC (Ping timeout: 252 seconds)
[08:44:03] --> PixelScum has joined #gemrb
[08:46:02] <-- Drakkar has left IRC (Ping timeout: 255 seconds)
[08:55:48] --> Drakkar has joined #gemrb
[08:58:38] <-- PixelScum has left IRC (Ping timeout: 255 seconds)
[09:42:05] --> PixelScum has joined #gemrb
[09:45:03] <-- Drakkar has left IRC (Ping timeout: 260 seconds)
[10:02:45] --> Yoshimo has joined #gemrb
[10:40:24] --> Drakkar has joined #gemrb
[10:42:16] <-- PixelScum has left IRC (Ping timeout: 240 seconds)
[10:59:53] <-- Yoshimo has left IRC (Quit: Yoshimo)
[11:14:06] --> kettuz has joined #gemrb
[11:44:22] --> PixelScum has joined #gemrb
[11:47:01] <-- Drakkar has left IRC (Ping timeout: 248 seconds)
[12:03:44] --> Baldurer has joined #gemrb
[13:23:07] --> Avenger has joined #gemrb
[13:23:07] --- ChanServ gives channel operator status to Avenger
[13:24:00] <Avenger> hmm, getting assertions in spritecover, most likely something about sprites
[13:25:18] <Avenger> line 699 in ScriptedAnimation: assert(cover->Covers(cx, cy, frame->XPos, frame->YPos, frame->Width, frame->Height));
[13:27:19] <fuzzie> and the animation is fine?
[13:28:08] <Avenger> this happens right after loading a game
[13:28:13] <Avenger> on windows
[13:28:31] <fuzzie> not pst?
[13:28:45] <Avenger> bg2
[13:28:55] <Avenger> any savegame
[13:29:12] <fuzzie> oh, new?
[13:29:14] <Avenger> this is from the latest refactoring from brad in sdl :D
[13:29:21] <fuzzie> seems unlikely
[13:29:36] <fuzzie> maybe you didn't rebuild everything?
[13:29:40] <Avenger> hmm
[13:29:57] <Avenger> could be
[13:30:06] <Avenger> all this stuff worked yesterday
[13:30:14] <fuzzie> nothing relevant changed
[13:30:32] <fuzzie> but the variables got rearranged a bit, so if you didn't rebuild something, it could be corruption due to that
[13:31:15] <Avenger> maybe, i try recompiling
[13:33:46] <Avenger> well i recompiled everything :(
[13:34:07] <fuzzie> ok, let me build it just to be sure
[13:35:20] <-- Avenger has left IRC (Quit: ChatZilla 0.9.88 [Firefox 9.0.1/20111220165912])
[13:35:39] <fuzzie> it is broken
[13:35:40] <fuzzie> great
[13:35:43] <fuzzie> wtf?
[13:36:34] <fuzzie> oh great, I missed a patch
[13:37:52] --> Avenger has joined #gemrb
[13:37:52] --- ChanServ gives channel operator status to Avenger
[13:38:14] <fuzzie> ok, let me revert that one
[13:38:15] <Avenger> i didn't have the latest sources in windows
[13:38:30] <Avenger> hmm, you found something?
[13:39:04] <fuzzie> yes
[13:39:06] <fuzzie> not brad's code
[13:39:19] <CIA-36> GemRB: 03fuzzie * r75b6ad1ffd0b 10gemrb/gemrb/plugins/SDLVideo/SDLVideo.cpp:
[13:39:19] <CIA-36> GemRB: Revert "Remove misleading statements and useless code, and factor out some common code."
[13:39:19] <CIA-36> GemRB: This reverts commit d0c645498f16a2efbfb265f97208718b0088172e.
[13:39:53] <fuzzie> who on earth pushed that one?
[13:40:12] <Avenger> brad
[13:40:17] <Avenger> but what's wrong with it
[13:40:18] <fuzzie> yeah?
[13:40:41] <Avenger> i had a suspicion that it was the wrong one, but what'swrong with it
[13:40:52] <fuzzie> it removes the XPos/YPos settings?
[13:41:59] <Avenger> just this one: - else
[13:42:01] <Avenger> - dest->YPos = sprite->YPos;
[13:42:03] <fuzzie> i mean i don't know if i'm missing something obvious here, but randomly removing the XPos/YPos code seems pretty clearly wrong
[13:42:11] <Avenger> this one seems to be odd: dest->XPos = dest->XPos;
[13:42:13] <fuzzie> since now your new sprites don't get a XPos/YPos..
[13:42:21] <Avenger> he removed it but that's ok :D
[13:42:42] <fuzzie> yeah, i was looking at Horizontal
[13:43:39] <Avenger> his commit wasn't a complete mess, just one line was excessly removed
[13:43:42] <fuzzie> i just don't quite see why it wasn't fixed by changing to 'dest->XPos = sprite->XPos;' rather than removing all the code..
[13:43:50] <Avenger> hehe
[13:43:57] <fuzzie> more than one line
[13:44:00] <Avenger> i just don't quite see why that didn't matter!
[13:44:05] <fuzzie> the else one in vertical, and the else and normal ones in horizontal
[13:45:04] <Avenger> well, he removed the misleading code :D just he was mislead too
[13:45:25] <-- Avenger has left IRC (Quit: ChatZilla 0.9.88 [Firefox 9.0.1/20111220165912])
[13:49:06] --> Avenger has joined #gemrb
[13:49:45] <fuzzie> while I remember, we are now leaking cursors after brad's patch because it doesn't do the refcounting right
[13:50:44] <fuzzie> and the drag cursors don't work...
[13:53:11] <fuzzie> phffffft I say
[13:53:40] <fuzzie> (looking at it)
[13:53:48] <Avenger> oh shit
[13:54:02] <Avenger> i look at the mirror refactoring, fixed it already
[13:54:42] --> Yoshimo has joined #gemrb
[13:55:02] <fuzzie> well it looked trivial to put the XPos/YPos stuff back properly, I just don't understand why it was committed
[13:55:04] <CIA-36> GemRB: 03avenger_teambg * ra6b8e9b64187 10gemrb/gemrb/plugins/SDLVideo/SDLVideo.cpp: SDLVideo::correctly clean up the sprite mirror code
[13:55:40] <fuzzie> that looks fine
[13:56:02] --> SiENcE has joined #gemrb
[13:56:07] <Avenger> well, he just looked at the code and saw x=x and said, wtf, lets simplify before trying to understand ;D
[13:56:54] <fuzzie> i'll commit a cursor fix in a minute
[13:57:10] <Avenger> cool
[13:58:12] <CIA-36> GemRB: 03fuzzie * rce0cc6c998d8 10gemrb/gemrb/ (core/Video.cpp plugins/SDLVideo/SDLVideo.cpp): fix drag cursors
[13:58:17] <fuzzie> doesn't fix the refcounting but I'm nervous about doing that in a hurry
[13:58:30] <Avenger> without him, we would have not find that x=x anyway
[13:58:43] <fuzzie> yes, the noticing is nice :-)
[13:59:06] <fuzzie> just bit worried about commits without trivial checking done
[14:00:53] <fuzzie> not a big deal since you noticed!
[14:02:05] <Avenger> hmm, i definitely don't understand Video::SetCursor :)
[14:02:19] <Avenger> was this like this before brad?
[14:02:23] <fuzzie> no
[14:02:29] <fuzzie> this is to remove the SetDragCursor special-case
[14:03:02] <Avenger> this part looks the most weird to me:
[14:03:04] <Avenger> } else if (curIdx == VID_CUR_DRAG)
[14:03:04] <fuzzie> to make it easier to do different cursor code on touchscreens etc
[14:03:05] <Avenger> CursorIndex = VID_CUR_UP;
[14:03:13] <fuzzie> well I just added that :)
[14:03:15] <Avenger> why is it 'else'
[14:03:23] <fuzzie> if you unset the drag cursor, then the cursor resets to the normal one.
[14:03:55] <Avenger> ah, i see
[14:03:56] <Avenger> comments, comments
[14:04:23] <fuzzie> yes, probably should have commented
[14:04:35] <fuzzie> sorry :)
[14:04:46] <Avenger> I also don't understand what is CursorIndex, and why it isn't set always
[14:04:58] <fuzzie> CursorIndex is the currently displayed cursor
[14:05:17] <fuzzie> VID_CUR_UP normally, VID_CUR_DOWN when you're holding the mouse down, and VID_CUR_DRAG when you have a 'drag' cursor
[14:06:02] <fuzzie> probably it would be much better with a bit more redesign, but this is just a 'one step' change
[14:06:36] <Avenger> you know this is another piece thrown out that was originating back from balrog :D
[14:06:58] <fuzzie> maybe one day, someone might be able to understand this stuff :)
[14:13:29] <CIA-36> GemRB: 03avenger_teambg * r36b112514293 10gemrb/gemrb/core/Video.cpp: some comments, so i will understand this a week later too :)
[14:13:32] <Avenger> ok, i added comments, so i will not forget, hopefully i understood it correctly
[14:15:11] <fuzzie> looks good
[14:21:29] <Avenger> meh, quickspells don't work?
[14:22:45] <fuzzie> lynx was struggling with those a bit
[14:25:36] <fuzzie> were working at some point though..
[14:25:39] <fuzzie> i mean, recentish
[14:25:42] <Avenger> i'm pretty sure i fixed this once or twice
[14:29:02] <Avenger> but as i remember i changed guiscript.cpp, which seems fine now
[14:29:46] <fuzzie> you did report problems before, but it was because you had a guicommonwindows in bg2
[14:30:08] <Avenger> findspellinfo is getting the correct value
[14:30:35] <Avenger> hmm, yes, i remember something like that too
[14:30:45] <fuzzie> (which ends up with an attempt at casting a spell with all zeros)
[14:31:35] <Avenger> yes, that's the symptom here too, but the cause is something else
[14:32:07] <Avenger> findspellinfo gets these parametersSPWI112 0 :
[14:32:24] <Avenger> it should be able to fill the spellinfo structure from that
[14:33:13] <Avenger> hmm, maybe type = 0 is a problem?
[14:33:35] <Avenger> heh
[14:33:47] <fuzzie> the only recent change is checking for SpellResRef for the icon rather than SpellbookIcon
[14:34:09] <Avenger> maybe this never worked
[14:34:24] <fuzzie> but type = -1 is the invalid one, type 0 should be ok..
[14:34:30] <Avenger> QuickSpellType is not stored in bg2, only in iwd2
[14:34:46] <Avenger> and findspellinfo strictly matches the type
[14:34:50] <Avenger> actually -1 would work
[14:35:21] <Avenger> hmm
[14:35:38] <Avenger> other problem is, the two findspellinfo functions don't work the same way regarding type
[14:36:21] <fuzzie> well i don't understand the python side
[14:37:11] <Avenger> i talk about the c side anyway
[14:37:19] <Avenger> the stuff in Spellbook
[14:37:32] <fuzzie> i think all the recent changes were on the python side though
[14:38:57] <fuzzie> oh btw, I get huge huge numbers for reaction in guirec
[14:39:01] <Avenger> then this never worked
[14:39:15] <fuzzie> but only in original savegames, not gemrb ones
[14:40:40] <fuzzie> the guiscript is using IE_REPUTATION for that
[14:41:21] <CIA-36> GemRB: 03avenger_teambg * rc93f8c1c95ab 10gemrb/gemrb/core/Spellbook.cpp: When looking for spells, if type is omitted (0) just ignore it
[14:41:55] <Avenger> Where is this 'reaction' used?
[14:41:57] <Avenger> in guiscript
[14:42:14] <fuzzie> # 10347 Reaction
[14:42:14] <fuzzie> stats.append ( (10347, GA (IE_REPUTATION,0), '0') )
[14:42:19] <Avenger> ie_reputation should be divided by 10
[14:42:30] <Avenger> hmm
[14:42:32] <Avenger> wait
[14:42:35] <fuzzie> i get numbers like 106927946
[14:43:10] <Avenger> reaction should be calculated from charisma, no?
[14:43:35] <fuzzie> i think it only works with my gemrb games because they are force-modified at startup, and then Game::SetReputation sets IE_REPUTATION manually for all party members
[14:43:48] <fuzzie> (since they are old gemrb games with an incorrect expansion value)
[14:44:42] <Avenger> the script is probably ok
[14:44:53] <fuzzie> and lynx changed it from IE_CHR to IE_REPUTATION, the log says "fixed reaction display in guirec"
[14:44:55] <Avenger> GetAbilityBonus in GuiScript should handle IE_REPUTATION
[14:45:24] <fuzzie> i am not so worried about the GUI display
[14:45:50] <fuzzie> just confused about it
[14:46:53] <Avenger> reaction = 10 + rmodrep[rep] + rmodchr[chr];
[14:47:08] <fuzzie> i'm just wondering why the stat is bad in the first place
[14:47:35] <fuzzie> but it isn't bad?
[14:47:40] <gembot> build #14 of autotools g++-4.4 is complete: Failure [failed minimal test] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.4/builds/14 blamelist: avenger_teambg@sourceforge.net
[14:47:42] <Avenger> well either rmordrep or rmodchr is wrong
[14:47:56] <fuzzie> oke
[14:47:57] <Avenger> but the script and guiscript.cpp are correct, imo
[14:48:19] <fuzzie> [ResourceManager]: Searching for rmodrep.2da...[chitin.key]
[14:48:19] <fuzzie> [ResourceManager]: Searching for rmodchr.2da...[chitin.key]
[14:48:21] <fuzzie> so looks ok..
[14:48:34] <Avenger> well, maybe it is a bad index
[14:48:55] <Avenger> rep = target->GetStat(IE_REPUTATION);
[14:49:04] <Avenger> it isn't divided by 10
[14:49:12] <Avenger> but that's for non pc's
[14:49:14] <fuzzie> that is only for non-pcs
[14:49:15] <fuzzie> yes
[14:50:24] <Avenger> i'll be adding: print("rep: %d chr: %d\n", rmodrep[rep], rmodchr[chr]);
[14:50:28] <Avenger> to see which one is bad
[14:51:17] <Avenger> interesting, for me, they are 3 and 1
[14:51:21] <Avenger> totally sane values
[14:51:26] <fuzzie> with original game?
[14:51:30] <Avenger> bg2
[14:51:35] <fuzzie> i mean, original save
[14:51:53] <Avenger> no i think this is gemrb save
[14:51:59] <fuzzie> it works for me with gemrb saves
[14:52:04] <fuzzie> let me try the print
[14:52:22] <Avenger> ok, i try an original save
[14:52:49] <fuzzie> rep: 1731173965 chr: 8
[14:52:53] <Avenger> hmm
[14:53:05] <Avenger> what do you see as 'reputation'
[14:53:28] <Avenger> between lore and open locks
[14:53:40] <fuzzie> ah heh!
[14:53:41] <fuzzie> rep is 20
[14:53:43] <fuzzie> out-of-bounds..
[14:54:08] <Avenger> ok, it is just off by one, or so
[14:54:27] <Avenger> we need proper boundary checking too
[14:54:57] <Avenger> interesting
[14:55:09] <Avenger> gemrb assumes it is 0-19
[14:56:42] <Avenger> it never goes below 1?
[14:57:02] <fuzzie> no idea, but that would be my first guess
[14:57:17] <Avenger> that's weird, because it is stored as * 10
[14:57:25] <Avenger> so in saved games it cannot go below 10
[14:57:54] <Avenger> in the 2da its columns are named 1-20
[14:57:59] <fuzzie> Yes, that is it, I have rep 20 in too many original saves I guess.. :)
[14:58:41] <fuzzie> but I don't know if it's safe to just subtract 1, like GetReaction already does for IE_CHR.
[14:58:48] <fuzzie> it does seem odd that it wouldn't go below 10.
[14:58:53] <Avenger> yes
[15:03:56] <Avenger> ok, lets hope this is fixed now
[15:04:07] <CIA-36> GemRB: 03avenger_teambg * r960ab5d34022 10gemrb/gemrb/core/GameScript/GSUtils.cpp: proper boundary checks in GetReaction
[15:06:32] <fuzzie> looks fine for all games now, thankyou
[15:09:36] <-- SiENcE has left IRC (Ping timeout: 240 seconds)
[15:13:08] <tomprince> fuzzie: This should fix the leaking, I think: https://gist.github.com/1616123
[15:13:29] <gembot> build #15 of autotools g++-4.4 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.4/builds/15
[15:14:48] <fuzzie> ah, was going to ask you if you thought moving the acquires would be ok
[15:15:33] <fuzzie> although I wouldn't change the logic of SetCursor at the same time, can't tell if that is just mis-typed :)
[15:16:10] <Avenger> hehe, that looks much cleaner
[15:16:50] <Avenger> problem is, if there is other use of setcursor
[15:17:40] <fuzzie> the other uses of SetCursor manage their own acquiring refcounting at the moment, although it isn't very clear which is why I was going to ask
[15:18:22] <Avenger> hmm, i see
[15:18:26] <tomprince> better patch: https://gist.github.com/1616140
[15:19:22] <fuzzie> but now it is double-acquiring, no?
[15:19:57] <Avenger> yep, the cur->acquire() remained in
[15:22:42] <gembot> build #19 of autotools g++-4.5 is complete: Failure [failed minimal test] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.5/builds/19 blamelist: avenger_teambg@sourceforge.net
[15:22:58] <tomprince> Well, everywhere that sets a drag cursor, gets a new sprite, almost.
[15:23:10] <tomprince> https://gist.github.com/1616153
[15:26:15] <tomprince> I am apprently not awake enough yet. :) https://gist.github.com/1616153
[15:27:02] <Avenger> tom, do you know wtf is wrong with the buildbot?
[15:27:53] <Avenger> i don't even know what is signal 11 :)
[15:28:20] <Avenger> segfault?
[15:28:57] <fuzzie> last one still doesn't make sense to me, but we are not in a rush :-p i guess https://gist.github.com/1616164
[15:29:04] <fuzzie> and i +1 that one
[15:30:02] <Avenger> hehe, tom's patches are all the same
[15:30:23] <Avenger> even the links
[15:30:24] <Avenger> :D
[15:30:28] <fuzzie> yes see the one I linked :)
[15:31:32] <Avenger> back to buildbot, if there is a segfault, shouldn't the valgrind log show some more stuff?
[15:32:02] <fuzzie> i think usually segfaults are just errors with buildbot
[15:35:49] <-- gembot has left IRC (Ping timeout: 248 seconds)
[16:00:00] --> SiENcE has joined #gemrb
[16:17:09] --> gembot has joined #gemrb
[16:23:51] <-- gembot has left IRC (Ping timeout: 252 seconds)
[16:53:17] <-- |Cable| has left IRC (Ping timeout: 244 seconds)
[16:55:26] --> |Cable| has joined #gemrb
[16:56:02] --> Cable_ has joined #gemrb
[18:16:04] --> gembot has joined #gemrb
[18:17:10] <-- Avenger has left IRC (Quit: bye!)
[18:28:17] <gembot> build #20 of autotools g++-4.5 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.5/builds/20
[19:01:50] <-- Baldurer has left IRC (Ping timeout: 248 seconds)
[19:02:18] --> Avenger has joined #gemrb
[19:02:36] <-- Avenger has left IRC (Client Quit)
[19:02:44] --> Baldurer has joined #gemrb
[19:19:24] --> brad_a has joined #gemrb
[19:21:35] <brad_a> wouldnt it make more sense to release the drag cursors after setcursor instead of acquiring the other cursors?
[19:21:54] <fuzzie> well, the drag cursors are the common case
[19:22:47] <fuzzie> but maybe - this is why I didn't just apply it
[19:23:00] <brad_a> true enough but thats not typical in my experience. of course this is my bad so maybe i should shut my gob
[19:23:01] <brad_a> :-P
[19:23:07] <-- tomprince has left IRC (Ping timeout: 244 seconds)
[19:23:31] <fuzzie> well it wold have been nice if the drag cursors worked, and if anyone had tested that PosX/PosY patch before applying it.. :-p
[19:23:41] <fuzzie> the refcount thing is a bit more subtle
[19:23:58] <fuzzie> e.g. Interface::SetDraggedPortrait is actually deliberately doing acquire() itself already
[19:24:38] <brad_a> yeah i dont know why i didnt test that. part of me wants to blame the fact that i wrote it forever ago but that isnt a good excuse
[19:25:23] <fuzzie> and there's an awful lot of video->SetCursor(core->GetScrollCursorSprite(7,numScrollCursor), VID_CUR_DRAG); calls where only the 7 differs which seems really silly
[19:25:38] <brad_a> so does duplicate sprite not copy the y/x pos? (for that other patch)
[19:25:43] <fuzzie> no
[19:26:54] <fuzzie> i am a bit terrified by the fact that XPos/YPos is in Sprite2D at all
[19:26:54] <brad_a> that does sound silly
[19:27:01] <brad_a> why?
[19:27:08] <fuzzie> why is it?
[19:27:29] <brad_a> well i dont know, but it has been there since before i came along :)
[19:27:33] <fuzzie> oh, sure
[19:27:42] <fuzzie> i mean the whole mess has been like this since before *I* came along
[19:27:54] <brad_a> for sure :)
[19:28:50] <fuzzie> and the reason is that gemrb is based about BAMs, which have xpos/ypos there
[19:29:05] <brad_a> ah see that sounds reasonable :)
[19:29:53] <fuzzie> anyway it's all 'fine' now
[19:30:01] <fuzzie> so nothing to worry about
[19:30:02] --> tomprince has joined #gemrb
[19:30:10] <brad_a> so the sprites x/y is an offset from someBlitAt(x,y,sprite)?
[19:30:33] <fuzzie> and it's just that the acquire-in-caller thing is an easy patch for the refcount, while doing something else would be more annoying and need more thought
[19:30:37] <fuzzie> yes
[19:31:03] <brad_a> that does seem unusual
[19:31:13] <fuzzie> which allows sprites to be compressed by removing empty space around their edges from the data entirely
[19:31:39] <fuzzie> which there is often quite a lot of in things like actor animations
[19:31:54] <brad_a> ah so it should be more internal/private to the sprite from the sound of it
[19:32:20] <fuzzie> but of course it is not internal/private to the sprite because everything is horrible :-p
[19:32:50] <brad_a> yes and i believe it is used in a few places outside the sprite code
[19:33:07] <fuzzie> in particular the SpriteCover code needs to know about it (to know what to cover), but that is mixed up with the video anyway
[19:33:46] <brad_a> but im content to just leave it as is :-P is there a reason why duplicate sprite doesnt set the x/y?
[19:34:25] <fuzzie> well, I don't know, but some of the callers seem to clearly expect it that way..
[19:35:15] <brad_a> oh well then. Im more concerned about fixing that leak then code that works :)
[19:41:22] <-- kettuz has left IRC (Quit: Leaving)
[19:43:06] <brad_a> i think i will try and get rid of the 0-7 sillyness you mentioned while im at it
[19:47:08] <brad_a> fuzzie: im having trouble seeing why mousescrollspd is even needed there.
[19:47:47] <brad_a> i mean moveX & moveY should be all you need to know which directions(s) you are scrolling
[19:47:49] <brad_a> right?
[19:48:25] <brad_a> he i see now there is a todo asking this same question
[19:48:47] <brad_a> at least i thin its asking the same question
[19:51:36] <fuzzie> i assume because the user might not be responsible for the scrolling
[19:51:49] <fuzzie> it seems silly though
[19:53:52] <brad_a> oh i see. so if some cut scene triggers a scroll the cursors shouldnt get updated type of thing?
[19:57:24] <fuzzie> that is already handled by the 'scrolling' variable it seems?
[20:01:14] <brad_a> well it certinly seems that scrolling is only set in mouse events
[20:01:29] <brad_a> but its also only cleared in mouse events...
[20:02:18] <fuzzie> well, maybe then, I didn't look too closely
[20:02:56] <brad_a> shouldnt those instances hide the mouse anyway?
[20:03:30] <fuzzie> I forget.
[20:03:40] <fuzzie> Are there no non-cutscene cases of the viewport being moved?
[20:03:51] <brad_a> im not sure at all
[20:04:06] <fuzzie> see, we're all lost without lynx
[20:04:21] <brad_a> i guess even if it were hidden upon being un hidden the cursor would be wrong until the mouse was moved
[20:04:37] <brad_a> so its probably moot
[20:08:11] <brad_a> im at least going to put a note with this todo about why it possibly is that way
[20:20:05] <tomprince> I have no idea what is going on with thtat segfault.
[20:28:02] <brad_a> whats the diff between sprite->release and video->freesprite()
[20:28:35] <brad_a> i guess i should use freesprite
[20:29:03] <fuzzie> release is just a wrapper around freesprite atm
[20:29:06] <fuzzie> no?
[20:29:07] <tomprince> There is no difference.
[20:29:17] <brad_a> ok i didnt thinks so
[20:29:39] <tomprince> Sprite2D depends to much on implementation details of SDLVideo, at the momemnt.
[20:29:56] <brad_a> so neither is preferred? ie is one deprecated?
[20:30:14] <tomprince> I haven't been able to gt things to segfault for me, on the buildslave machine.
[20:30:41] <tomprince> I'd be inclined to use release, but I think most things use FreeSprite ...
[21:43:32] <Baldurer> I found out that the c key on android gemrb is the key that highlights containers
[22:30:21] <-- brad_a has left IRC (Quit: brad_a)
[22:36:14] <-- Yoshimo has left IRC (Quit: Yoshimo)
[22:44:20] <-- SiENcE has left IRC (Quit: cya)
[22:53:36] --> brad_a has joined #gemrb
[22:53:54] <-- brad_a has left IRC (Client Quit)
[23:04:38] <-- Baldurer has left IRC (Ping timeout: 240 seconds)
[23:56:36] --> brad_a has joined #gemrb
[23:59:10] <brad_a> im having difficulty seeing the purpose of numScrollCursor = (numScrollCursor+1) % 15;
[23:59:35] <brad_a> as far as i can tell it starts out as 0 then that bumps it to 1 where is stays for eternity