#gemrb@irc.freenode.net logs for 15 Oct 2014 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:07:49] <brada> i dont know much about compiler optimization, but i dont see anything in this O2 list that jumps out
[00:07:50] <brada> http://stackoverflow.com/questions/15548023/clang-optimization-levels
[00:07:52] <Pepelka90> Clang optimization levels - Stack Overflow
[00:08:34] <brada> clang 3.5 btw
[00:52:16] <-- brada has left IRC (Quit: brada)
[01:41:42] --> gembot_ has joined #gemrb
[01:42:44] --> tomprinc1 has joined #gemrb
[01:42:54] <-- gembot has left IRC (Ping timeout: 260 seconds)
[01:42:54] <-- tomprince has left IRC (Ping timeout: 260 seconds)
[02:03:53] --> brada has joined #gemrb
[02:33:30] --> Drakkar has joined #gemrb
[02:44:44] <brada> so i did do a profile with a debug build, and it does seem to pinpoint ContentAtPoint as I suspected
[02:48:43] <brada> so yeah, implementing some type of sorted container so we can do a binary search and bail early is what comes to the top of my head
[02:51:35] <brada> oh, and if numbers interest you. over the stretch of time for entering SetSelectOptions and exiting, ContentAtPoint takes 97.8% of CPU time
[02:51:59] <brada> still kinda wonder why a release build is nearly imperceptible delay…
[02:53:28] <brada> hell, even just making a second container for the ordering would be fine
[02:53:59] <brada> anyway, ill wait to hear what you guys have to say
[03:13:19] --> Eli2 has joined #gemrb
[03:15:10] <-- Eli2_ has left IRC (Ping timeout: 250 seconds)
[03:20:01] <brada> of course we already have an ordered list of content derp. so yeah, i guess i should just use that to search
[03:20:10] <-- brada has left IRC (Quit: brada)
[03:24:54] --> brada has joined #gemrb
[04:00:48] --> raevol has joined #gemrb
[04:43:39] <-- brada has left IRC (Read error: Connection reset by peer)
[06:37:36] <-- Lightkey has left IRC (Ping timeout: 260 seconds)
[06:50:10] --> Lightkey has joined #gemrb
[07:03:23] <-- raevol has left IRC (Read error: Connection reset by peer)
[07:21:23] --> raevol has joined #gemrb
[08:03:09] --> lynxlynxlynx has joined #gemrb
[08:03:09] --- ChanServ gives channel operator status to lynxlynxlynx
[09:22:02] <-- raevol has left IRC (Quit: Leaving)
[12:54:40] <-- lynxlynxlynx has left IRC (Ping timeout: 272 seconds)
[13:08:24] --> lynxlynxlynx has joined #gemrb
[13:08:24] <-- lynxlynxlynx has left IRC (Changing host)
[13:08:24] --> lynxlynxlynx has joined #gemrb
[13:08:24] --- ChanServ gives channel operator status to lynxlynxlynx
[13:17:42] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[13:19:02] --> lynxlynxlynx has joined #gemrb
[13:19:02] <-- lynxlynxlynx has left IRC (Changing host)
[13:19:02] --> lynxlynxlynx has joined #gemrb
[13:19:02] --- ChanServ gives channel operator status to lynxlynxlynx
[14:03:47] --> brada has joined #gemrb
[14:10:18] <-- brada has left IRC (Ping timeout: 244 seconds)
[14:12:29] --> brada has joined #gemrb
[16:08:21] --> fizzle has joined #gemrb
[17:31:42] --> maighstir has joined #gemrb
[17:43:30] <lynxlynxlynx> more crashes
[17:43:50] <lynxlynxlynx> does anyone else get missing symbol errors with the minimal test?
[17:51:14] <fizzle> how does one run the minimal test?
[17:53:31] <lynxlynxlynx> GameType=test
[17:53:55] <lynxlynxlynx> GamePath=/.../gemrb/tests/minimal/
[17:54:12] <lynxlynxlynx> GemRBPath=../gemrb # if you put it in the build dir
[17:54:38] <lynxlynxlynx> PluginsPath as usual
[17:56:43] <fizzle> exited normally
[18:01:19] <lynxlynxlynx> thanks
[18:01:31] <lynxlynxlynx> maybe something didn't get recompiled on branch switch
[18:11:05] <brada> care to elaborate?
[18:14:47] <wjp> brada: is this loop in LayoutContentsFrom intended to just find the bottom-right point of the current layout?
[18:15:29] <wjp> if so, would it be an idea to cache that in ContentContainer, and update it directly after adding a new item?
[18:15:49] <brada> prtty much. if you missed my monolouge the problem is ContentAtPoint because it loops though everything needlessly
[18:16:18] <wjp> well, that's part of it
[18:16:33] <wjp> it does three loops, and if you cache LayoutPoint, then you get rid of two of them
[18:22:29] <brada> if you say so
[18:22:40] <brada> i really dont know what you are talking about. feel free to try it
[18:23:33] <brada> would still need to optimize ContentAtPoint anyway
[18:23:45] <brada> which shouldnt be terribly hard
[18:24:46] <brada> just need an ordered container so we can bail out when we get content that is above the point
[18:33:29] --> brada_ has joined #gemrb
[18:33:33] <-- brada has left IRC (Ping timeout: 260 seconds)
[18:33:33] --- brada_ is now known as brada
[18:38:43] <wjp> I mean that every time LayoutContentsFrom() gets called, it starts by doing exactly the same thing
[18:39:00] <wjp> (looping over the entire content until it finds a free spot at the end, if I understand it correctly)
[18:39:16] <wjp> and then the next time, it goes over this exact same list again
[18:39:50] <wjp> so as long as it's just appending, you can just resume where it ended the previous time. I think.
[18:43:19] <wjp> but I'm also pretty sure I still don't understand parts of this code
[18:45:46] <brada> i dont think you do understand it correctly
[18:46:01] <brada> i assume you are suggesting something functionally similar to this: http://paste.debian.net/127000/
[18:46:02] <Pepelka90> debian Pastezone
[18:46:07] <brada> which does not work
[18:46:37] <wjp> no, that sets the next point to the bottom right
[18:46:42] --> raevol has joined #gemrb
[18:49:57] <brada> you are going to have to show me then
[18:55:18] <wjp> something like this: http://www.usecode.org/gemrb/gemrb_layout.patch
[18:58:00] <-- cable_ has left IRC (Ping timeout: 246 seconds)
[18:58:25] --> cable_ has joined #gemrb
[18:58:54] <wjp> (oh, it should probably also reset it in RemoveContent)
[19:00:38] <brada> sure, i thought you were suffesting something to remove those loops
[19:01:28] <brada> suggesting*
[19:01:42] <brada> anyway, go ahead and commit that.
[19:03:18] <wjp> together with your ContentAtPoint improvements that should make this pretty fast
[19:03:37] <brada> yes, i was going to say its still slow without the ContentAtPoint change
[19:03:48] <brada> when you scroll the list with the cursor over the items
[19:04:23] <brada> loading is now fast tho :)
[19:04:26] <brada> so thats nice
[19:04:53] <wjp> oh, when trying that I sometimes end up with two highlighted entries
[19:05:04] <brada> yeah
[19:05:08] <brada> i just noticed that too
[19:05:36] <wjp> but of course not when I'm actively trying to reproduce :-)
[19:05:41] <fuzzie> :-)
[19:06:03] <brada> also what i was about to say
[19:07:10] <brada> it does seem to only happen when it lags out tho
[19:07:36] <brada> so hopefully that disappears with a more efficient ContentAtPoint
[19:08:03] <wjp> (I've cleaned up this patch slightly and pushed it to font-rewrite)
[19:08:42] <brada> thanks wjp
[19:09:05] <brada> i can reproduce the highlight bug fairly regularly by scrolling while also moving the mouse
[19:09:41] <brada> so it may be related to conflicts between the 2 events
[19:26:54] <lynxlynxlynx> hmm, nothing major changed in Actor
[19:28:26] <brada> lynx: were you saying you found more bugs/crashes?
[19:28:43] <lynxlynxlynx> yeah, i'm looking at that again now
[19:28:48] <brada> cool
[19:29:05] <lynxlynxlynx> pst crashes in combat immediately
[19:29:22] <lynxlynxlynx> verbal constant related, but you didn't seem to touch that at all
[19:32:28] <lynxlynxlynx> well, on-hit
[19:38:43] <brada> i added the “subtitle” option, and something to make ony the first selected PC perform the VC. dont know if that is relevant
[19:38:49] <lynxlynxlynx> maybe a data problem i said and tried another save
[19:38:52] <lynxlynxlynx> boom, new crash
[19:39:02] <brada> also the combat roll stuff
[19:39:20] <brada> so maybe an overflow there similar to the ones wjp patched
[19:39:51] <lynxlynxlynx> SetOverheadText doesn't like NULL
[19:40:33] <lynxlynxlynx> terminate called after throwing an instance of 'std::logic_error' <-- that's a first
[19:43:12] <lynxlynxlynx> seems it vomits while trying to make a const String reference out of it
[19:43:19] <lynxlynxlynx> doesn't even reach the target function
[19:44:20] <brada> im suprised there isnt a compiler warning for that
[19:46:29] <lynxlynxlynx> passing String() works around it, but it's not that nice
[19:46:29] <brada> for the case i see where it is explicitly passed null. then again i suppose NULL is just an int or something in c++
[19:46:39] <brada> L”” would work too
[19:46:53] <lynxlynxlynx> even yuckier if you ask me
[19:47:11] <brada> you can refactor it to use String* instead if you like
[19:47:21] <brada> im not married to anything
[19:50:09] <lynxlynxlynx> nah, not for a single outlier
[19:51:25] <lynxlynxlynx> the vb one seems to be persistent
[19:51:33] <lynxlynxlynx> i get it even in ed's saves
[19:55:09] <lynxlynxlynx> eh, maybe i'll just bisect the other one
[19:55:18] <lynxlynxlynx> too common to not be new
[19:57:29] <lynxlynxlynx> btw, iwd1 still has an odd issue with the portrait icons in guirec
[19:57:49] <lynxlynxlynx> for the first loaded pc, the first line is all symbols, mostly duplicated into the second one
[19:57:56] <lynxlynxlynx> the rest display normally
[19:58:42] <lynxlynxlynx> the glyphs are repeating, so it probably just uses the wrong font for some reason
[19:59:58] <lynxlynxlynx> lynxlynx.info/bugs/iwdstates1.jpg
[20:00:24] <lynxlynxlynx> if i reorder the party, it doesn't change anything
[20:02:27] <lynxlynxlynx> cool, it's specific effects that cause it
[20:02:35] <lynxlynxlynx> and i have an item that can toggle it
[20:04:34] <lynxlynxlynx> 1/12 effects, from which Icon:Display sounds the most suspicious
[20:05:02] <lynxlynxlynx> but a ring that also uses it doesn't show problems
[20:06:39] <-- fizzle has left #gemrb
[20:11:11] <brada> mostly fixed the hover span issue
[20:11:55] <brada> still can leave one stuck in the “hover” mode when the mouse leaves though means that dont trigger OnMouseLeave
[20:12:07] <brada> no more muliple hover spans at least
[20:14:42] <lynxlynxlynx> doesn't sound like anything i've seen
[20:15:51] <brada> wjp and i were talking about it
[20:26:54] <brada> lynx, i dont even own IWD so not much i can do there. it would be usefull to know if its the GUIScript thats messing up, or something else. I would suspect the code that builds the info table got messed up by some of my changes
[20:27:33] <brada> it there some other text that should go there?
[20:27:48] <lynxlynxlynx> the state name?
[20:28:09] <lynxlynxlynx> looking at the lookup, i get U[
[20:28:22] <lynxlynxlynx> too high value
[20:28:25] <lynxlynxlynx> [ is at 91
[20:28:50] <brada> i wonder what is supposed to be printed there
[20:28:54] <lynxlynxlynx> we also seem to fetch the states very often, but it could be party size related
[20:29:12] <lynxlynxlynx> the guirec part is fine, it looks up the correct strref
[20:29:19] <lynxlynxlynx> ord(c) is already bad there
[20:30:00] <brada> i know one way this can happen would be if something is getting appended one character at a time
[20:30:35] <brada> but all of that should be wrapped in the [p] tag so that shouldnt matter
[20:30:45] <lynxlynxlynx> actor->GetStateString() looks ok at first glance
[20:31:03] <lynxlynxlynx> the effects were setting ok values too (25)
[20:31:40] <lynxlynxlynx> oh
[20:31:56] <lynxlynxlynx> maybe something else is missing the 66 adjustment
[20:32:05] <brada> did you say this is IWD1 or 2
[20:32:14] <brada> 1
[20:32:19] <lynxlynxlynx> 1
[20:32:26] <brada> so it doesnt have its own guirec
[20:32:30] <lynxlynxlynx> forget about the [ being too high
[20:33:23] <brada> i would check some of those GameCheck.IsIWD1() instances in GUIREC
[20:34:04] <lynxlynxlynx> hehe, i can decode the glyph puzzle; it actually just prints the state name in that font, overwriting the icon, spaces and dash
[20:34:57] <brada> ha ha
[20:35:03] <lynxlynxlynx> the gametype checks are irrelevant
[20:35:09] <brada> sure
[20:35:32] <lynxlynxlynx> so it actually may be something you already worried about
[20:35:44] <lynxlynxlynx> if you look at the picture, the whole first line represents Protection
[20:35:51] <lynxlynxlynx> maybe it's too long to fit?
[20:36:19] <brada> no, there are plenty of examples of effects with long names that wrap appropriately
[20:36:45] <lynxlynxlynx> but do they have a long first word?
[20:37:17] <brada> all of the protections in BG2 work
[20:37:38] <brada> but i dont know if the TA width is diffrent between BG2 and IWD1
[20:37:52] <brada> i still have trouble seeing how that would screw up in this manner
[20:38:05] <brada> iirc it just wouldnt print anything if it didnt fit
[20:38:19] <brada> you can see what it would do by altering a line of code in Button.cpp
[20:38:38] <brada> line 313 remove the + 1
[20:39:14] <lynxlynxlynx> if i manually set it to a shorter string, the problem persists, just in one line
[20:39:19] <brada> yeah
[20:39:40] <lynxlynxlynx> this is all from one effect, one icon btw
[20:39:42] <brada> a raw dump of the string passed to AppendText would be handy
[20:40:02] <lynxlynxlynx> [Python]: 11111 91 17416
[20:40:11] <brada> oh it does resrefs?
[20:40:12] <lynxlynxlynx> 91 for [ and the last one for the name
[20:40:49] <lynxlynxlynx> yeah, guirec is full of helpers to make the overview easier to construct
[20:41:26] <brada> i meant the markup string returned from GetStatOverview
[20:41:38] <brada> curious if that will shed some light on this
[20:43:26] <lynxlynxlynx> that's from there, but i'll go dump it fully
[20:43:45] <lynxlynxlynx> oh, i doubt it matters, but the icon is displayed properly on the button
[20:44:07] <lynxlynxlynx> [cap][%[/cap][p]Protection from Cold[/p]
[20:44:08] <brada> well thats good, but yes, irrelevant here
[20:44:11] <brada> really?
[20:44:21] <brada> so it looks fine in the raw string
[20:44:27] <brada> oh
[20:44:28] <brada> wait
[20:44:35] <brada> why is it “[%"
[20:44:38] <lynxlynxlynx> % is the dash?
[20:44:42] <brada> thats probably jacking up the parser
[20:44:47] <brada> right
[20:45:01] <brada> but notice that it is “[%”
[20:45:01] <lynxlynxlynx> hehe
[20:45:07] <lynxlynxlynx> well that's just the data
[20:45:24] <brada> removing the offending “[“ would fix it
[20:45:31] <brada> no idea where that is coming from
[20:45:34] <lynxlynxlynx> from all the effects, we are very lucky that something as common as protection from cold is assigned that icon
[20:45:57] <lynxlynxlynx> http://www.gemrb.org/wiki/lib/exe/fetch.php?media=engine:states-overview.png <-- 25
[20:46:01] <lynxlynxlynx> +66 == 91
[20:46:06] <lynxlynxlynx> == [
[20:46:15] <brada> oh derp
[20:46:18] <brada> yes
[20:46:25] <brada> suprised i overlooked that
[20:46:33] <brada> wondering a good way to fix this
[20:47:54] <lynxlynxlynx> ignore tag markers inside [cap]s?
[20:48:46] <brada> nah, probably better and easier to be more general
[20:49:01] <brada> ill think on it.
[20:49:05] <brada> have to go to class soon
[20:51:07] <lynxlynxlynx> ok
[20:51:24] <brada> probably jsut add ‘[‘ to the OPEN_TAG state
[20:52:07] <brada> then append it to the token after switching to TEXT state
[20:53:14] <-- brada has left IRC (Quit: brada)
[21:48:21] <-- Eli2 has left IRC (Remote host closed the connection)
[22:56:19] <-- maighstir has left IRC (Remote host closed the connection)
[23:31:11] --> brada has joined #gemrb