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

Archive Today Yesterday Tomorrow
GemRB homepage

[00:11:07] --> brada has joined #gemrb
[00:24:03] <-- brada has left IRC (Quit: brada)
[00:32:04] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[00:45:32] --> brada has joined #gemrb
[01:44:09] <-- brada has left IRC (Quit: brada)
[02:20:46] --> brada has joined #gemrb
[02:28:19] <brada> fixed the dialog issue i found
[02:28:52] <brada> i likely wont have any more time to work on any other problems tho :(
[02:29:01] <brada> for the time being anyway
[02:29:16] <brada> they were all in non-BG2 games anyway :p
[02:29:27] <brada> feel free to hack at it
[02:49:25] --> kpedersen has joined #gemrb
[02:54:00] <-- Eli2 has left IRC (*.net *.split)
[02:54:02] <-- kpederse1 has left IRC (*.net *.split)
[03:02:47] --> Eli2 has joined #gemrb
[03:12:16] --> Eli2_ has joined #gemrb
[03:15:12] <-- Eli2 has left IRC (Ping timeout: 250 seconds)
[03:20:59] <-- Mechanimal has left IRC (Read error: Connection reset by peer)
[03:25:46] --> Mechanimal has joined #gemrb
[03:27:56] <-- brada has left IRC (Quit: brada)
[03:42:42] --> brada has joined #gemrb
[04:23:30] <-- brada has left IRC (Quit: brada)
[05:04:40] --> raevol has joined #gemrb
[06:14:47] --> edheldil_ has joined #gemrb
[06:30:00] <-- edheldil_ has left IRC (Ping timeout: 244 seconds)
[06:37:37] <-- Lightkey has left IRC (Ping timeout: 272 seconds)
[06:49:58] --> Lightkey has joined #gemrb
[07:34:27] --> edheldil_ has joined #gemrb
[07:41:59] --> fizzle has joined #gemrb
[08:23:24] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[08:23:24] <-- edheldil has left IRC (Ping timeout: 272 seconds)
[08:23:47] --> edheldil_ has joined #gemrb
[08:23:51] --> edheldil has joined #gemrb
[08:23:51] --- ChanServ gives channel operator status to edheldil
[08:37:19] <-- fizzle has left IRC (Ping timeout: 272 seconds)
[08:47:43] <-- raevol has left IRC (Quit: Leaving)
[08:52:58] --> fizzle has joined #gemrb
[08:53:38] <-- edheldil has left IRC (Ping timeout: 244 seconds)
[08:54:04] <-- edheldil_ has left IRC (Ping timeout: 250 seconds)
[10:39:16] --> edheldil has joined #gemrb
[10:39:16] --- ChanServ gives channel operator status to edheldil
[12:10:31] <fizzle> fuzzie: after looking at our past discussions and your notes again, would this make sense? http://paste.debian.net/126105/
[12:10:32] <Pepelka90> debian Pastezone
[12:38:57] <lynxlynxlynx> nice work btw
[12:38:59] <gembot> build #708 of cmake clang++ is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/708
[12:39:09] <lynxlynxlynx> if you need any extended testing, let me know
[12:39:45] <lynxlynxlynx> i'll try to iron out font-rewrite first, but then it will need a lot of game time anyway
[12:40:00] <lynxlynxlynx> another patch or three won't make a difference
[12:42:06] <fizzle> I guess if those action processing changes go in, some extended testing would be great
[12:42:48] <fizzle> I'm still holding those back until I've gotten some kind of go ahead
[12:44:35] <gembot> build #705 of cmake g++-4.2 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.2/builds/705
[12:46:52] <lynxlynxlynx> do you know any spells that use fx_drain_spells?
[12:47:07] <lynxlynxlynx> off the top of your head, i mean
[12:49:13] <lynxlynxlynx> ah, iesdp clears it
[12:49:35] <gembot> build #702 of cmake g++-4.4 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4/builds/702
[12:49:38] <lynxlynxlynx> the priest stuff was only our extension
[12:59:45] <gembot> build #680 of cmake g++-4.5 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.5/builds/680
[13:03:25] --> mlilenium_ has joined #gemrb
[13:03:35] <-- mlilenium_ has left #gemrb
[13:31:01] --> brada has joined #gemrb
[13:34:25] <brada> heh there will be merge conflicts there :p
[13:35:04] <brada> hopefully i also fixed that leak
[13:38:53] <-- brada has left IRC (Quit: brada)
[14:33:37] --> brada has joined #gemrb
[14:40:43] <kujeger> GOG has linux-versions (prepackaged wine+game) of BG1&2 + PST now. Makes it easier to grab the data for use in gemrb, at least
[14:55:05] <brada> yeah, been that way for a while right?
[14:55:14] <brada> has for mac versions anyway
[15:36:09] <kujeger> nah, linux came today
[16:16:24] <lynxlynxlynx> (fuzzie) ”(…)our script code is force-unlocking doors when it closes or opens them” That undermines all “surprisingly locked in” quasi trap scripts. <-- i can't reproduce this; the spellhold umber hulk trap is the only thing that came to mind to check
[16:16:41] <lynxlynxlynx> anyone remembers the starting report?
[16:27:20] <-- fizzle has left #gemrb
[16:28:14] <fuzzie> umm
[16:28:55] <fuzzie> SetDoorOpen is clearly doing that, no?
[16:45:05] <lynxlynxlynx> but is there an actual, "real life" problem stemming from that?
[16:48:38] <fuzzie> yes, I encountered one, but um :/
[16:54:03] <lynxlynxlynx> ooh, i remembered another candidate
[16:54:31] <lynxlynxlynx> the mephit room in ci2 likely locks at least some of the doors
[16:59:36] <brada> isnt there a part in durlags tower too?
[17:02:17] <lynxlynxlynx> haven't been there yet
[17:49:00] <brada> lynx: do you have the font/text bug on the wiki or somewhere I can see the remaining issues?
[17:49:20] <lynxlynxlynx> heh, i was just about to say that the ( is fixed
[17:49:27] <lynxlynxlynx> http://www.gemrb.org/wiki/doku.php?id=developers:lynx
[17:49:29] <Pepelka90> developers:lynx [GemRB wiki]
[17:49:42] <lynxlynxlynx> crashed how pretty fast though, rerunning in gdb now
[17:50:08] <lynxlynxlynx> inventory icons and iwd portrait icons and dashes are still broken
[17:50:28] <lynxlynxlynx> yeah, the crash is new
[17:50:33] <lynxlynxlynx> nicely reproducible
[17:50:42] <brada> an assert?
[17:51:12] <lynxlynxlynx> no
[17:51:25] <lynxlynxlynx> overhead text
[17:51:36] <lynxlynxlynx> 0x00007ffff7a133a0 in GemRB::Font::RenderText (this=0x0,
[17:51:36] <lynxlynxlynx> string=L"\"Wonder how long we'll be staying in this hole?\" ", rgn=..., color=0x6c9ff0,
[17:51:36] <lynxlynxlynx> alignment=17 '\021', point=0x7fffffffd880, canvas=0x0, grow=false)
[17:51:36] <lynxlynxlynx> at /home/lynx/dev/gemrb/gemrb/delme/gemrb-tmp/gemrb/core/Font.cpp:256
[17:52:21] <brada> oh ill bet i know what needs to be done for that separator glyph
[17:52:31] <lynxlynxlynx> this=0x0 in the previous frame too, so the first sane one looks like GemRB::Scriptable::DrawOverheadText
[17:52:42] <brada> null font
[17:53:00] <lynxlynxlynx> yea
[17:53:08] <brada> so the font its looking for doesnt exist in the map i guess
[17:53:58] <brada> breakpoint in the GetFont method should at least tell us what resref
[17:55:10] <brada> the assert crash is (hopefully) fixed
[17:55:23] <brada> i dont know where you were triggering it to recheck exactly
[17:55:39] <lynxlynxlynx> INFOFONT instead of FLOAT
[17:56:06] <lynxlynxlynx> so the default doesn't appear to be changed anywhere, fonts.2da ignored/misread/x
[17:57:31] <lynxlynxlynx> yep
[17:58:53] <lynxlynxlynx> i guess it's easiest to move it to gemrb.ini and handle it like the rest
[18:00:34] <brada> probably
[18:01:35] <lynxlynxlynx> dialog scrolling is off, but worse than before
[18:02:15] <lynxlynxlynx> now it doesn't always start at the top, plus interjections don't start there either
[18:02:26] <lynxlynxlynx> so i couldn't even see all the text
[18:02:51] <lynxlynxlynx> random test case that showed it - boy and girl near bayle's house in the slums
[18:02:59] <lynxlynxlynx> talk to the boy multiple times
[18:03:58] <brada> did you pull my latest changes?
[18:04:07] <brada> because i cant reproduce that anymore
[18:04:14] <brada> http://paste.debian.net/126198/
[18:04:15] <Pepelka90> debian Pastezone
[18:04:20] <lynxlynxlynx> TextArea: override SetAnimPicture
[18:04:21] <brada> does that fix the separator glyph thing?
[18:04:31] <brada> you may need to verify that glyph number is correct
[18:04:42] <brada> the seperators in BG1 & 2 work for me
[18:04:46] <brada> so im just guessing on that
[18:05:01] <brada> bbl
[18:06:38] <lynxlynxlynx> it does fix it
[18:08:05] <lynxlynxlynx> http://www.gemrb.org/wiki/lib/exe/fetch.php?media=engine:states-overview.png <- for glyphs
[18:23:50] <brada> why am i just learing about that now?!
[18:24:30] <lynxlynxlynx> i did it only weeks before i left
[18:26:04] <brada> oh, well its nice!
[18:27:30] <lynxlynxlynx> 2014/06/25 17:59 to be exact
[18:28:03] <lynxlynxlynx> yes, ed generated the base and i finished it up
[18:30:07] <lynxlynxlynx> different crash in pst
[18:30:50] <lynxlynxlynx> same reason though
[18:32:01] <lynxlynxlynx> i'll just go fix this textfont thing now
[18:32:18] <brada> please do
[18:40:56] <lynxlynxlynx> MovieFont is also not set in all games (bg1, pst, iwd2)
[18:41:09] <brada> where is bayle’s house again?
[18:41:17] <brada> i cant seem to locate these urchins
[18:42:11] <brada> its the ship right?
[18:43:10] <brada> do they disappear if youve already talked with them?
[18:43:45] <brada> ah they are just noth of that ship house
[18:44:28] <brada> ok so it works fine except the first time it seems
[18:45:50] <brada> interestingly those 2 are *actually* called urchin in their dlg ha ha
[18:49:42] <lynxlynxlynx> pst dialogs are completely foobared, you can't even go past the first exchange
[18:52:21] <brada> so commenting out the first line of TA::SetAnimPicture will work around part of the issue
[18:52:50] <brada> but then i hit an exception in DialogHandler line 79
[18:53:06] <brada> so just need to handle that better
[18:53:30] <brada> obviously String::npos is not a good thing to pass to resize lol
[18:55:03] <brada> lynx: does commenting out that line fix PST dialogs?
[18:55:12] <brada> or is the problem something completely diffrent?
[18:55:44] <lynxlynxlynx> i can check, it looked like i couldn't even click the button properly
[18:55:52] <lynxlynxlynx> its label overflowed too
[18:56:54] <gembot> build #710 of cmake clang++ is complete: Failure [4failed minimal test] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/710 blamelist: Jaka Kranjc <lynxlupodian@users.sourceforge.net>
[18:59:06] <lynxlynxlynx> interesting, it doesn't work for me either
[18:59:15] <lynxlynxlynx> missing symbols in our plugins oO
[18:59:18] <gembot> build #707 of cmake g++-4.2 is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.2/builds/707 blamelist: Jaka Kranjc <lynxlupodian@users.sourceforge.net>
[19:00:30] <lynxlynxlynx> your SetOptions change broke iwd2 video listing
[19:01:37] <gembot> build #704 of cmake g++-4.4 is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4/builds/704 blamelist: Jaka Kranjc <lynxlupodian@users.sourceforge.net>
[19:03:00] <lynxlynxlynx> odd error, claims the python list is not a list
[19:09:08] <brada> not suprised that broke, but last i checked the list in BG2 charget worked...
[19:10:19] <lynxlynxlynx> it's erroring out in the meta layer already
[19:10:36] <lynxlynxlynx> investigating
[19:12:38] <gembot> build #682 of cmake g++-4.5 is complete: Failure [4failed minimal test] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.5/builds/682 blamelist: Jaka Kranjc <lynxlupodian@users.sourceforge.net>
[19:36:36] <brada> lynx: commited those dialog fixes
[19:39:40] <lynxlynxlynx> ok, thanks
[19:40:08] <lynxlynxlynx> where did the SetAnimPicture part show up?
[19:41:08] <brada> are you asking why that is needed?
[19:41:32] <lynxlynxlynx> no, just checking if it's related to anything i've seen
[19:41:43] <brada> oh, its related to dialog problems
[19:42:09] <brada> should fix the dialogs that dont set a picture
[19:42:15] <brada> so those urchins work now
[19:42:25] <lynxlynxlynx> ah, cool
[19:50:05] <brada> im curious if the performance of the opengl driver improved/worsened betwen this branch and master, but i dont want to go thought the pain of getting it to build for me again :p
[19:50:30] <fuzzie> I forget what you changed, again
[19:50:40] <fuzzie> are you rebuilding the whole texture every frame, or..?
[19:51:35] <lynxlynxlynx> it's easy for me to test, i still have the old bench data
[19:51:59] <lynxlynxlynx> at the time text rendering was completely broken for opengl though, so exactly that remains to be retested
[19:52:07] <brada> fuzzie: no not rebuilding every frame
[19:52:18] <brada> with BAM just build at beginning
[19:52:44] <fuzzie> you're still drawing individual glyphs?
[19:52:48] <brada> the change was that they are not all individual sprites
[19:52:49] <fuzzie> or you mean when the text is created?
[19:52:58] <brada> no they are in “pages” now
[19:53:17] <brada> and the pages are built when the font is created
[19:53:59] <brada> pages can be added/extended at runtime tho, but for BAM that wont happen
[19:54:32] <fuzzie> oh
[19:54:41] <fuzzie> you're still drawing individual glyphs?
[19:55:16] <lynxlynxlynx> spans i think
[19:58:01] <brada> fuzzie: maybe i dont know what you are asking
[19:58:24] <brada> many glyphs are rendered on a “page” 1024px wide
[19:58:32] <brada> there can be several pages
[19:58:41] <lynxlynxlynx> ah, the movie problem is due to setoptions getting strrefs instead of strings - it can't deal with them
[19:58:56] <brada> but not 1 individual texture per glyph as it was before
[19:59:10] <brada> lynx: do’h that makes sense
[19:59:14] <fuzzie> brada: yes, but you don't just render text labels into one texture and blit that
[19:59:16] <lynxlynxlynx> she's asking how a sentence is printed, in how many chops
[19:59:20] <fuzzie> right :)
[19:59:44] <brada> fuzz: no. did we want to do that? the support for that is there as well
[20:00:06] <fuzzie> it probably drastically increases opengl performance if you can keep the #textures down
[20:00:13] <fuzzie> but probably best to wait until this works first
[20:00:37] <brada> well isnt the way i have it pretty close to the minimum number of textures?
[20:00:52] <brada> each font is only like 4 or 5 textures
[20:01:15] <fuzzie> yes, but the overhead of the rendering will be terrible
[20:01:32] <fuzzie> so we can make the opengl backend just render *all* the glyphs at once
[20:01:38] <fuzzie> but then I have to have time
[20:01:48] <fuzzie> and I have exams on Tues/Wed next week. so.
[20:02:04] <brada> well, “terrible” maybe, but shouldnt it be drastically better than each glyph being its own texture?
[20:02:57] <brada> TTF fonts will still be a problem there…
[20:06:05] <brada> the reason i decided not to flatten a TextArea’s text onto a sprite is because eventually we will need to edit that text
[20:06:30] <brada> and that wouldn mean destroying and recreating a potentially massive texture each time a change is made
[20:19:48] <lynxlynxlynx> bikplayer crashes too; doesn't appear to be moviefont related on first sight though
[20:21:55] <brada> i dont recall touching bikplayer
[20:23:26] <lynxlynxlynx> it could be the font, just not obviously
[20:25:13] <lynxlynxlynx> and if not, it's faster to just check the last few commits, as it hasn't been modified much
[20:26:30] <lynxlynxlynx> i think i fixed setoptions, but the rendering itself is still foobared, so maybe i need to pull first
[20:31:29] <lynxlynxlynx> nope
[20:31:59] <lynxlynxlynx> you can see it yourself, if you start bg2 and go to options directly, the movies/credits list will be bonkers
[20:33:12] <lynxlynxlynx> chargen also shows the problem
[20:35:46] <brada> i tested with chargen originally, so it was working at one point
[20:36:21] <brada> push up your changes?
[20:37:15] <lynxlynxlynx> it only breaks once you get to voice, since nothing before it uses a list
[20:37:54] <brada> but yes, that is very broken
[20:37:58] <brada> right
[20:38:06] <brada> i know it did used to work tho
[20:38:19] <lynxlynxlynx> http://sprunge.us/TJQf?diff
[20:38:43] <lynxlynxlynx> so i doubt it affects it
[20:38:49] <brada> right
[20:39:05] <brada> i just didnt want to have to go though chargen to see what you were talking about :p
[20:39:14] <brada> wonder what i did to break it
[20:39:28] <brada> likely with my last 10 commits
[20:39:36] <lynxlynxlynx> i said guiopt is the fastest way :P
[20:39:57] <brada> it still sort of works he he
[20:40:05] <brada> you can hover over the very edge
[20:40:08] <lynxlynxlynx> yeah, not an ancient problem, as i recall the script list was working
[20:40:15] <lynxlynxlynx> aha
[20:40:19] <lynxlynxlynx> even select
[20:43:02] <brada> oh, ill bet i know exactly the problem
[20:43:37] <brada> it that i moved the TextContainer resize out of Draw and that TA doesnt get created with the correct size
[20:43:48] <brada> so we really need to address that FIXME now :p
[20:49:53] <brada> heh calling SetAnimPicture(NULL) in the initializer is enough to work around that issue
[20:50:56] <brada> lynx: fixed
[20:53:17] <lynxlynxlynx> :)
[21:43:11] <lynxlynxlynx> textarea list construction became very heavy
[21:43:42] <lynxlynxlynx> cg pauses for a few seconds before displaying the soundsets
[21:45:17] <lynxlynxlynx> wierd
[21:49:26] <brada> yeah, i noticed that too, but i wasnt sure that wasnt like that before
[21:49:55] <brada> i do wonder what is going on there then
[21:50:39] <wjp> is this the font-rewrite branch?
[21:50:47] <brada> yes
[21:51:19] <wjp> hm, crashing here once it reaches the bg2 menu
[21:51:43] <lynxlynxlynx> the movie list doesn't show it or not that badly
[21:51:56] <brada> shorter list
[21:52:23] <brada> so it could be the number of list items, or it could be overhead related to iterating the directories
[21:53:06] <wjp> huh. The _FPS counter_ is crashing it
[21:54:04] <lynxlynxlynx> works here with it
[21:54:13] <brada> obviously that is not the case fo me
[21:54:21] <brada> so did you update all your files?
[21:54:31] <wjp> all my files?
[21:54:35] <brada> the ini files
[21:54:38] <brada> guiscripts
[21:54:40] <brada> etc
[21:54:45] <lynxlynxlynx> font-rewrite in the main repo btw
[21:54:46] <wjp> well, I switched branches
[21:54:51] <wjp> oh, main repo
[21:55:45] * wjp switches and rebuilds
[21:55:45] <brada> ah that would do it
[21:57:27] <wjp> aha
[21:57:37] <wjp> swprintf(fpsstring, sizeof(fpsstring), ...) is wrong
[21:57:59] <wjp> so that's smashing the stack
[21:58:12] <wjp> sizeof(fpsstring)/sizeof(fpsstring[0]) fixes it
[21:59:34] <brada> push it
[22:00:22] <wjp> not the only instance it seems
[22:00:42] <brada> ProcessDirectoryForTAOptions could stand to be more effitient for sure. not sure if that totally responsible for the slowness there
[22:01:59] <brada> probably sizeof(w_chart) instead
[22:03:19] <wjp> same thing right?
[22:03:25] <wjp> or do you have a strong preference?
[22:04:50] <brada> no strong preference, but yes same thing
[22:05:47] <wjp> ok, pushed
[22:05:51] <wjp> I hope I have them all
[22:06:52] <brada> thanks
[22:07:00] <wjp> no problem
[22:07:36] <fuzzie> strings :/
[22:08:13] <wjp> oh, we still have those inlining warnings too
[22:09:03] <wjp> the sound list window is instant on master
[22:09:11] <wjp> and slow on font-rewrite
[22:09:39] <brada> correct
[22:09:58] <brada> remerging master should fix those warnings tho right?
[22:10:13] <brada> this branch is a few dozen commits behind or so
[22:10:28] <wjp> also still on master
[22:10:45] <brada> oh
[22:11:16] <wjp> oh, or maybe we concluded compiler bug
[22:11:50] <wjp> the specifics of these warnings don't make much sense anyway. So I'll just ignore them
[22:11:58] <lynxlynxlynx> but we disabled the warning then, at least for werror
[22:12:35] <wjp> yeah. I seemed to have forgotten about this, sorry
[22:13:36] <brada> so the first bad thing i notice about those lists is the copying of each string
[22:13:48] <brada> but i dont know if that alone explains the slowdown
[22:18:11] <wjp> could it be the layouting?
[22:19:46] <brada> perhapps. tho nothing else seems to be slow
[22:20:09] <brada> thats easy to test i guess
[22:23:44] <wjp> at first glance it looks like the only bit that's potentially asymptotically very slow
[22:23:56] <brada> it must be that i guess. commenting out that loop and appending a bunch of “tests” is also slow
[22:24:08] <wjp> but I don't know this ContentContainer code at all
[22:24:27] <brada> probably could use some optimization
[22:24:59] <brada> it shouldnt be needing to layout all the contents everytime it appends something tho
[22:25:30] <brada> but text areas with huge amounts of text dont “lag” afik
[22:25:38] <brada> so maybe something more specific with select options
[22:30:24] <wjp> it does seem to add quite a few items to the container per entry
[22:31:12] <wjp> it ends up calling LayoutContentsFrom 845 times
[22:32:25] <wjp> with a linearly growing number of iterations in the inner while loop
[22:32:54] <brada> yeah
[22:33:32] <brada> an easyish optimization would be to not immidiately layout the content
[22:35:29] <brada> tho i wonder why that many? how many entries is that for?
[22:37:19] <wjp> maybe 100
[22:37:32] <wjp> not sure why there are so many entries in this sound list
[22:38:01] <wjp> FEMALE10..FEMALE4_ and MALE0010..MALE005_
[22:38:59] <brada> probably a bug it the code that is iterating the directory if there are more than there should be
[22:39:26] <wjp> I'm not sure if postponing the layout will help, by the way
[22:39:43] <wjp> it's only calling LayoutContentsFrom on the newly appended item each time
[22:39:54] <wjp> it's the loop over all existing items that makes it add up
[22:40:13] <wjp> and it'll probably have to do that too when it does everything at the end
[22:40:28] <brada> it shouldnt be laying out items that already have been layed out
[22:40:36] <wjp> it isn't, as far as I can tell
[22:41:17] <wjp> I'm not 100% sure what this code is doing, but for every new item it's looping over many existing items in this 'while (exContent)' loop
[22:42:23] <wjp> which is a bit silly for a linear vertical list
[22:43:25] <wjp> (but I'm assuming it's written for a more complicated situation)
[22:44:09] <wjp> anyway, bedtime for now. Good night
[22:44:18] <brada> night
[22:48:14] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:55:44] <wjp> but one last thing: this entire 'while (exContent)' loop doesn't seem to depend on the new item at all, right? Couldn't it be pre-computed and/or cached?
[23:00:38] <brada> oh, im not sure atm. im a bit tired myself. but i did figure out that at least a huge part of the delay is the Region bounds bit at the bottom
[23:00:54] <brada> commenting that out shaves it from ~5s to ~1-2
[23:03:22] <brada> that exContent loop is to find the position following the previous content that can fit the new content
[23:05:56] <brada> and that loop does depend on the new item
[23:06:02] <brada> er
[23:06:06] <brada> i guess thats the outer loop
[23:06:37] <brada> no, the new content does get assigned to exContent at the bottom of the outer loop
[23:06:50] <brada> jeez you’d think i didnt write this or something
[23:13:56] <brada> probably could implement some sort of sorting so we dont have to scan though everything in ContentAtPoint
[23:27:45] <brada> um… this is interesting. i decided i wanted to profile the problem and apparently building a “release” build there is no problem
[23:28:00] <brada> lists are instantly populated for me on a release build
[23:29:33] <brada> well, close enough to instant. a couple of seconds
[23:29:40] <brada> er less than a second i mean
[23:30:19] <-- NoseGoth has left IRC ()
[23:30:32] <-- brada has left IRC (Quit: brada)
[23:42:15] --> brada has joined #gemrb
[23:43:35] <brada> does it sound like an RVO problem maybe?
[23:46:00] <brada> speaking of RVO, ProcessDirectoryForTAOptions should probably return the vectory instead of taking a reference to one
[23:47:48] <brada> there are 280 sounds in my BG2 sound folder BTW
[23:47:59] <brada> so 200 ms for listing that isnt too bad imo
[23:51:11] <brada> whatever specific optimization it is, it requires at least O2