#gemrb@irc.freenode.net logs for 30 Apr 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:53:13] <-- Drakkar has left IRC (Ping timeout: 260 seconds)
[00:53:41] --> Drakkar has joined #gemrb
[01:16:06] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[03:43:19] --- barra_away is now known as barra_home
[07:09:14] --> test32894789234u has joined #gemrb
[07:24:33] --> boriskr has joined #gemrb
[07:57:03] --> lynxlynxlynx has joined #gemrb
[07:57:03] --- ChanServ gives channel operator status to lynxlynxlynx
[07:58:17] * lynxlynxlynx bugs fuzzie to commit and runs off
[07:58:54] <fuzzie> hehe
[07:58:58] <fuzzie> g'morning
[07:59:12] <fuzzie> it turns out i put it in the shiny new Update function so not so trivial to just pick it ou
[07:59:15] <fuzzie> t
[08:12:47] <lynxlynxlynx> that part being unfinished?
[08:14:06] <fuzzie> yeah, broken
[08:14:32] <fuzzie> see the "// FIXME: completely wrong place for this!" in Scriptable.cpp
[08:15:03] <fuzzie> could be moved to Map::UpdateScripts for now
[08:15:13] <fuzzie> or i could do it, when awake
[08:15:31] <fuzzie> more worried about the non-actor effects
[08:16:19] <fuzzie> how do we do those normally?
[08:16:54] <lynxlynxlynx> you mean those without a target?
[08:16:58] <fuzzie> yes
[08:17:12] <lynxlynxlynx> handled in the effect
[08:17:20] <fuzzie> but i mean, at a higher level
[08:17:29] <fuzzie> they just run on a random EffectQueue which is instantly deleted?
[08:17:31] <lynxlynxlynx> via that new flag that tomprince added
[08:17:51] <lynxlynxlynx> i don't think they are special
[08:17:58] <fuzzie> i mean, specifically, i'd like to know how to implement fx_apply_effect
[08:18:50] <fuzzie> which adds to the target's fxqueue right now..
[08:18:55] <lynxlynxlynx> then maybe yes, a throwaway queue, like for selfapplyign
[08:19:17] <lynxlynxlynx> not sure if it would make any difference
[08:20:45] <fuzzie> there's only one effect in the original which actually works on non-actors, CGameEffectRandomSummon
[08:20:59] <fuzzie> otherwise it's just some effect ids hard-coded in places
[08:21:55] <fuzzie> so hopefully a throaway queue would be fine, but i miss Avenger's confirmation of such things :)
[08:58:25] <fuzzie> lynxlynxlynx: do you know if that case ever worked (portal in first spellhold level)?
[09:29:32] <lynxlynxlynx> case?
[09:29:51] <lynxlynxlynx> oh, the gem one
[09:30:10] <lynxlynxlynx> iirc i did manage to summon all of them
[09:30:30] <lynxlynxlynx> but something was slightly wrong too or i was too weak
[09:30:37] <lynxlynxlynx> i just remember having issues
[09:34:37] <fuzzie> for the ForceSpellPoint([236.494],SUMMON_DJINN_TRAP), it does fx_apply_effect on spdjinn which does the actual summon
[09:36:20] <fuzzie> so hmph.
[09:49:29] <wjp> fuzzie: for a first blitter, would you prefer a 888 or 565 one to test/profile?
[09:59:05] <-- boriskr has left IRC (Remote host closed the connection)
[10:01:08] <fuzzie> um
[10:01:46] <fuzzie> well, 565 one is going to mean you'd have to run X at that depth or find a way to exclude the SDL overhead
[10:01:59] <fuzzie> so 8888 seems more sensible
[10:05:24] <wjp> I was hoping you'd say that :-)
[10:06:13] <fuzzie> well, you can figure it out as well as I can :)
[10:06:22] <fuzzie> i'd suggest we ignore 565 entirely if it weren't for the embedded platforms
[10:07:13] <wjp> I just didn't know if you were running 888 or 565 yourself on powerpc
[10:07:51] <fuzzie> i am honestly not too worried about performance on powerpc :-)
[10:08:02] <fuzzie> i imagine it is 888 though
[10:19:29] <fuzzie> xor doesn't seem any worse on ppc than on x86/arm
[10:55:05] <wjp> well, no more xors anyway now
[11:02:41] --> Bo_Thomsen has joined #gemrb
[12:44:15] <fuzzie> any luck?
[12:59:18] <wjp> so far so good; have mostly been doing other stuff though :-)
[12:59:58] <fuzzie> i have come back home to hide from the orange
[13:00:03] <wjp> did everything for the RLE part except for the actual pixel manipulation in the inner loop
[13:00:06] <wjp> ah yes, orange
[13:09:24] <-- test32894789234u has left #gemrb
[13:13:10] <-- barra_home has left IRC (Quit: Verlassend)
[13:23:12] <dhewg> hi
[13:24:46] <fuzzie> hello
[13:34:00] <dhewg> any hacks for my djinn issue?
[13:38:42] <fuzzie> not yet, it is a bit annoying
[13:39:06] <fuzzie> you could mark it as good for actors and make it work on a new fxqueue and copy the point param, but pretty sure you don't understand a word of that :p
[13:39:48] <dhewg> only the idea :P
[13:40:14] <-- mihairu has left IRC (Remote host closed the connection)
[13:44:51] <dhewg> shapeshifting has a few issues
[13:44:53] <dhewg> known?
[13:47:02] <fuzzie> don't know :)
[13:47:13] <fuzzie> i really tend to leave the effect stuff to other people if at all possible
[13:47:51] <dhewg> k, but this may be related to messed up char stats
[13:48:10] <dhewg> i'll just list the stuff, if only for the backlog
[13:48:21] <fuzzie> the polymorph effect just copies the creature stats over your stats
[13:48:29] <fuzzie> again, only temporary
[13:48:41] <dhewg> yeah, but when you go back your char is unequipped
[13:48:49] <dhewg> the stuff is there, just not considered
[13:48:59] <fuzzie> hmph, that shouldn't happen
[13:48:59] <dhewg> weapons are in their slots, but the char is naked
[13:49:15] <dhewg> also the special ability to polymorph back is disabled
[13:49:26] <dhewg> prolly because i tried it on a mage
[13:49:39] <fuzzie> "polymorphing innates don't go away after use and can be regenerated with sleeping"
[13:50:04] <dhewg> and when the polymorph time is up, the back spell is still there
[13:50:46] <dhewg> also, the polymorphed char animation is sometimes not used
[13:50:48] <fuzzie> i wrote the most recent version of the polymorph stuff, i guess
[13:51:01] --> mihairu has joined #gemrb
[13:51:10] <dhewg> i got the rat attack icons, but saw the normal char animation
[13:51:36] <fuzzie> the thing is, the polymorph stuff *only* modifies stats
[13:52:07] <fuzzie> it sets polymorphed stat, disables mage/cleric spells and copies stats from the target
[13:52:45] <dhewg> where do the attacks from the poly target come from?
[13:52:51] <dhewg> is that part of the poly spell?
[13:52:56] <fuzzie> presumably.. :P
[13:53:04] <fuzzie> got a spell ref?
[13:53:11] <dhewg> who unequipps stuff?
[13:53:15] <dhewg> the spell too?
[13:53:19] <fuzzie> also presumably
[13:53:35] <dhewg> i see Use item: clck27
[13:53:40] <dhewg> thats my poly ring
[13:54:21] <dhewg> but even afer sleeping im still unequipped
[13:54:33] <dhewg> maybe thats related to the same issue upon loading?
[13:54:49] <fuzzie> maybe. i haven't seen the issue.
[13:54:58] <dhewg> char modifier are sometimes not used, or like lynxlynxlynx said their used twice
[13:55:51] <fuzzie> i know, but i haven't seen i
[13:55:52] <fuzzie> t
[13:57:15] <dhewg> hm
[13:57:22] <fuzzie> how do you mean that the special ability to polymorph back is disabled?
[13:57:46] <dhewg> if i poly a mage into a rat, i get "your mage spells have been disabled"
[13:57:55] <dhewg> and so is the ability to poly into the natural form
[13:57:59] <fuzzie> that is correct
[13:58:02] <dhewg> really?
[13:58:08] <fuzzie> but the ability to poly back into natural form is an innate, not a mage spell
[13:58:09] <dhewg> i can only wait for it?
[13:58:14] <fuzzie> it should show up under innates (the last button)
[13:58:22] <fuzzie> is the bug that it doesn't?
[13:58:28] <dhewg> yes, "special ability" reads the icon
[13:58:35] <dhewg> yeah, i mean that
[13:58:40] <fuzzie> or is the bug that you can't cast an innate?
[13:59:18] <dhewg> i dont know if all are affected
[13:59:34] <dhewg> but at least the natural form innate is disabled
[13:59:41] <fuzzie> but it shows up in the right place?
[13:59:45] <dhewg> yeah
[13:59:51] <fuzzie> ieDword spelltype = ResolveSpellNumber(spell->spellname)/1000;
[13:59:55] <dhewg> also, it stays there, even if the rat poly times out
[13:59:56] <fuzzie> ^- this is the stupid bit, i think
[14:00:05] <dhewg> which also works
[14:00:06] <fuzzie> it's SPWI491 -> 2491, but it is not type 2 (wizard)
[14:00:20] <dhewg> as in: it does something and vanishes then
[14:00:23] <fuzzie> but that really sucks
[14:00:36] <dhewg> hehe
[14:00:45] <dhewg> im just messing around in front of the portal :p
[14:01:00] <fuzzie> i think probably all uses of ResolveSpellNumber are incorrect
[14:01:46] <fuzzie> hm
[14:01:50] <fuzzie> i take it back, that is the only relevant use
[14:02:34] <fuzzie> well, replace the ResolveSpellNumber line in GUIScript.cpp with just 'spell->type' i guess
[14:02:47] <dhewg> k, will try
[14:03:02] <dhewg> also weird: if i cast chromatic orb at minsc, i cant select him anymore
[14:03:12] <dhewg> as if that action kicked him out of the party
[14:03:31] <dhewg> and the attacking char keeps attacking him over and over again
[14:05:19] <fuzzie> poor minsc :(
[14:05:28] <dhewg> hehe
[14:05:41] <dhewg> but messing around yields the most problems!
[14:06:25] <fuzzie> hmm
[14:06:52] <fuzzie> PC vs PC isn't meant to set LastAttacker, i know
[14:07:20] <dhewg> that guiscript hack doesnt make natural form sensitive
[14:07:39] <fuzzie> you mean, it's still unusable?
[14:07:44] <dhewg> yes
[14:07:47] <fuzzie> weird
[14:08:07] <dhewg> i also get the normal footsteps sfx when walking around as rat :P
[14:08:20] <fuzzie> hmm
[14:08:34] <fuzzie> you replace the whole line, for spelltype?
[14:08:47] <dhewg> ieDword spelltype = spell->type;
[14:08:51] <fuzzie> yeah
[14:08:52] <fuzzie> weird
[14:09:16] <fuzzie> maybe it's just unset, i didn't really look at the code
[14:09:16] <dhewg> yeah, but no biggie
[14:09:58] <fuzzie> yeah, i guess the whole spellbook is broken in this regard
[14:10:09] <fuzzie> fail
[14:10:33] <fuzzie> and i don't know if we handle different footstep types
[14:10:41] <fuzzie> i don't think so
[14:11:25] <fuzzie> our pathfind just has a single line
[14:11:38] <fuzzie> while there's huge numbers of them in the executable
[14:11:49] <dhewg> its all hardcoded?
[14:11:59] <fuzzie> yup
[14:12:08] <dhewg> ugh
[14:12:09] <fuzzie> $ strings ~/src/gemrb/bg2/bgmain.exe | grep -c WAL_
[14:12:09] <fuzzie> 145
[14:12:16] <dhewg> ouch
[14:12:23] <fuzzie> mostly duplicates i imagine
[14:12:31] <fuzzie> but that is again, in the animation code :P
[14:12:42] <dhewg> hehe
[14:12:56] <fuzzie> along with walk speed and cast height and death sounds and blood colours and etc
[14:15:13] <dhewg> try to use item misc3h
[14:15:38] <dhewg> is it supposed to teleport like that?
[14:16:30] <fuzzie> oh god, the stupid horn of blasting
[14:16:33] <fuzzie> what does it do for you?
[14:16:55] <dhewg> it damages ppl in the area, like in the description
[14:17:05] <dhewg> but everyone is warped a little to the north
[14:17:18] <fuzzie> they should all be pushed away from yo
[14:17:18] <fuzzie> u
[14:17:36] <dhewg> i thought so, but its not related to where im standing
[14:17:43] <dhewg> its always north
[14:17:44] <fuzzie> yes
[14:17:50] <fuzzie> it's WB_FIXDIR according to gemrb source
[14:18:00] <fuzzie> maybe something Avenger made up
[14:18:13] <fuzzie> no, i think Avenger just got values wrong
[14:18:20] <fuzzie> see WB_AWAY in FXOpcodes.cpp
[14:19:24] <fuzzie> i don't know what correct values are .. WB_AWAY should be 2
[14:19:29] <fuzzie> which is your situation
[14:20:06] <dhewg> maybe exchange 0 and 2?
[14:20:07] <fuzzie> ah, IESDP has it
[14:20:21] <dhewg> what im seeing looks more like FIXDIR
[14:20:35] <fuzzie> yes, which gemrb has as 2 :P
[14:20:37] <dhewg> judging just from the name
[14:20:46] <fuzzie> unfortunately none of it makes much sense
[14:20:57] <dhewg> hehe
[14:21:07] <fuzzie> WB_AWAYDEST is 1, WB_AWAY is 2, WB_TOWARDSDEST is 3, WB_TOWARDS is 4
[14:21:16] <fuzzie> good luck reconciling that with gemrb's source
[14:23:34] <dhewg> heh
[14:23:37] <fuzzie> the last commit to that code was more than 5 years ago, probably should be rewritten
[14:23:39] <dhewg> yes, its 2 in my case
[14:23:48] <dhewg> but it again doesnt make any difference
[14:23:53] <fuzzie> oh?
[14:24:02] <dhewg> mybe GetOrient is wrong there?
[14:24:13] <fuzzie> ok, you broke it :P
[14:24:34] <dhewg> i changed the defines :P
[14:24:47] <fuzzie> did you see if it gets called?
[14:24:55] <fuzzie> i mean, if you change it, it shoudl do *something* diferent
[14:24:56] <dhewg> fx_wing_buffet (235): Value: 10, Stat: 2
[14:25:07] <dhewg> for all chars
[14:27:24] <dhewg> its still always north, no matter how i change the defines
[14:27:38] <dhewg> tried the first 3 cases
[14:27:56] <dhewg> it also warps the actor blasting the horn
[14:29:53] <fuzzie> mph
[14:30:34] <fuzzie> well i still think it requires a rewrite
[14:30:47] <fuzzie> but it really shouldn't do that
[14:30:52] <fuzzie> you tried seeing which case it actually hits?
[14:30:57] <dhewg> yes, djinn first kthx :P
[14:31:04] <dhewg> yeah
[14:31:09] <dhewg> i printed 'dir'
[14:31:16] <dhewg> with as-is dir=0
[14:31:33] <dhewg> but when fiddling around i get 2 or 14
[14:31:37] <fuzzie> mprhle
[14:31:38] <dhewg> but its still north
[14:31:49] <fuzzie> well i don't understand the line movement code
[14:31:52] <fuzzie> but i'm pretty sure it sucks
[14:32:00] <dhewg> heh
[14:32:51] <fuzzie> seriously it makes no sense
[14:33:09] <dhewg> dir 6 and 8 also seen
[14:33:14] <fuzzie> the caller isn't even dividing by the right amount!
[14:33:37] <fuzzie> srsly, Scriptable/Scriptable.cpp:1776 should be 12
[14:34:15] <dhewg> heh
[14:34:26] <dhewg> isnt that comment there redudant now?
[14:34:38] <fuzzie> no
[14:34:48] <fuzzie> you could replace it 'oh dear lord what is this doing', maybe
[14:35:01] <fuzzie> i will peer closely at wing buffet shortly
[14:36:54] <dhewg> god, if only loading a game wouldnt take ages
[14:37:31] <dhewg> ok, so if i exchange 0 and 2 in fx_wing_buffet and use /=12 in MoveLine, it looks better
[14:37:37] <fuzzie> whoo!
[14:37:39] <dhewg> but its a tiny amount
[14:37:42] <fuzzie> but i assume it still sucks
[14:37:47] <dhewg> it prolly needs a multiplier now?
[14:37:50] <fuzzie> i don't even know what on earth that effect is called
[14:38:03] <fuzzie> but seriously, more than 5 years old
[14:38:10] <fuzzie> so i just assume the whole concept is bad
[14:38:35] <fuzzie> maybe it's CGameEffectPushPull
[14:38:44] <dhewg> im not judging anything, but the more i find and you fix the better, right?
[14:38:53] <fuzzie> well
[14:39:07] <fuzzie> i would prefer less of the me fix and more of the others fix :) but lack of help atm
[14:39:18] <dhewg> hehe
[14:39:31] <dhewg> well, im glad you fixed so many issues i ran into
[14:39:34] <dhewg> i really am
[14:39:42] <dhewg> but i can see that its getting too much sometimes
[14:39:59] <dhewg> maybe at least leave a FIXME comment there with the current finding?
[14:40:03] <dhewg> so its not totally lost
[14:40:19] <fuzzie> well, if you can commit hacks to a branch, that always helps
[14:40:51] <dhewg> but i can only try what you suggest, because i have no idea how this all fits together
[14:41:14] <fuzzie> so much gets lost
[14:41:21] <fuzzie> i still have that PlayDead stuff in my tree, for example
[14:41:40] <dhewg> why not just push it?
[14:41:53] <dhewg> maybe its not 100% done, but its broken anyway
[14:42:17] <dhewg> and maybe others peek at it because of a recent commit
[14:42:49] <fuzzie> because i'm irrational and crazy
[14:44:00] <fuzzie> the PushPull thing rejects any param except 1, 2, 3 and 4
[14:44:15] <fuzzie> some default handling otherwise
[14:44:56] <dhewg> heh @1st line
[14:45:20] <fuzzie> if you haven't noticed that by now.. :p
[14:45:42] <dhewg> :P
[14:45:51] <dhewg> what also funny about this stupid horn: ppl get pushed and stunned, right?
[14:46:04] <dhewg> so they are there, incapable to move
[14:46:21] <dhewg> but i can hear foorstepts until the stun effect is over
[14:46:25] <fuzzie> in all seriousness, irc/gemrb tend to get my time only when i'm tired/ill/busy so i don't really trust myself to make commits without at least thinking a little
[14:47:28] <dhewg> and what minsc replies with "great fun! right boo?" to my friendly fire, thats almost hilarious
[14:48:18] <dhewg> well, if you fix something i noticed, i'll gladly try the scene again with the fix
[14:48:38] <dhewg> and there's still enough left in this game, so i can test the fix in upcoming situations too
[14:51:37] <dhewg> whats 16/12? is that a wold map tile size?
[14:52:14] <fuzzie> yes
[14:52:24] <fuzzie> we didn't really decide what should deal with it yet
[14:52:34] <fuzzie> it's tricky because the stupid scripting needs to know about it in a few places
[14:55:26] <dhewg> hm
[14:56:25] <dhewg> i looked at these cache implementations again
[14:56:36] <dhewg> like the key dictionary or Cache.cpp
[14:56:59] <fuzzie> you see how they work yet? :)
[14:57:07] <dhewg> yeah and i hate it
[14:57:38] <dhewg> its kinda easy, but the code makes it hard to read
[14:58:20] <dhewg> for example, that MemBlock struct is totally not necessary
[14:59:14] <fuzzie> well, the challenge is to avoid allocating a block for every entry
[14:59:30] <dhewg> anyway, the only reason i can think of that these are better compared to std::map on whatever platform/stl is a sucky allocator
[14:59:38] <fuzzie> yes
[14:59:46] <fuzzie> but that means you don't understand it :)
[14:59:59] <wjp> but don't underestimate the impact of sucky allocators :-)
[15:00:06] <fuzzie> slow trees are slow
[15:01:03] <dhewg> you mean the std::map?
[15:01:07] <fuzzie> yes
[15:03:37] <fuzzie> i mean, a tidier templated implementation of a hashmap in-tree would be awesome
[15:04:14] <dhewg> i didnt profile anything in gemrb yet, but from other projects i really cant confirm a stl::map slowness
[15:04:34] <fuzzie> but backing onto stl::map makes it a sorted tree to do binary search on, not a hashmap
[15:06:31] <fuzzie> and that's nothing about the implementation being slow, it's just about the design being inherently slower for these cases
[15:07:53] <fuzzie> (std::unordered_map is STL's hashmap, C++0x only)
[15:10:41] <wjp> it's been in gcc in various incarnations for ages already, but not sure about MSVC
[15:11:28] <wjp> (std::hash_map, __gnu_cxx::hash_map, std::tr1::unordered_map, ...)
[15:24:50] <fuzzie> well, it's been in libstdc++
[15:25:06] <fuzzie> which is not always the available STL implementation
[15:26:47] <fuzzie> but yes, we should get a hash map of our own
[15:27:10] <fuzzie> i doubt the default array size for our Variables/etc is particularly good anyway
[15:27:22] <fuzzie> but am not going to do Data Structures 101, busy cooking
[15:33:25] <-- mihairu has left IRC (Remote host closed the connection)
[15:34:36] --> boriskr has joined #gemrb
[16:07:11] <dhewg> k so what do i do with my current std::map based stuff?
[16:07:56] <fuzzie> keep it
[16:08:00] <dhewg> i mean, thats the easy way out, and for e.g. they keyimporter still nicer than what its doing now
[16:08:01] <fuzzie> i mean, it doesn't expose implementation details
[16:08:29] <fuzzie> so the internals can be replaced with whatever
[16:08:40] <dhewg> yeah, but on the other side for a proper hashmap template is prolly doesnt make much sense to reinvent the wheel
[16:08:59] <dhewg> are there gpl compatible implementations that we can reuse?
[16:09:37] <fuzzie> well, or the whole thing can be replaced with whatever :P
[16:10:06] <dhewg> yeah
[16:10:15] <dhewg> i mean look at it, it doesnt do much :P
[16:10:31] <dhewg> and it sounds like you worked with that stuff more than i did, so.. any suggestions?
[16:10:33] <fuzzie> but making stuff use it, useful
[16:10:52] <fuzzie> at some point tomprince suggested LLVM's one
[16:11:07] <fuzzie> and you mentioned the Qt one and there's whatever boost and libstdc++ have
[16:11:07] <dhewg> havent looked at that yet
[16:11:11] <dhewg> what about boost?
[16:11:25] <dhewg> i consider ppl working on that generally way smarter than me :)
[16:11:58] <fuzzie> but i don't know about any of them
[16:12:31] <dhewg> benchmarking the most common one is also annoying
[16:12:36] <dhewg> *ones
[16:13:40] <dhewg> google suggests that unordered_map is part of msvc since 2008
[16:14:44] <fuzzie> not too helpful to us :)
[16:15:03] <dhewg> i know, just throwing that in here
[16:15:10] <fuzzie> apparently maybe you can steal bits and bobs from various places and make the full version of visual studio 2008 be useful for old code
[16:15:44] <fuzzie> it's such a nightmare anyway
[16:16:00] <fuzzie> i noticed the AGS post was saying the remaining unreleased code required a pay-for msvc, too
[16:16:02] <dhewg> it usually is
[16:16:26] <fuzzie> just, pretty please can't we have a nice open-source windows compiler.
[16:16:26] <dhewg> so many ports have so many common code because its not portable enough
[16:16:30] <fuzzie> maybe llvm will work out.
[16:16:44] <dhewg> mingw is pretty good
[16:16:48] <fuzzie> it isn't really
[16:16:51] <dhewg> heh
[16:16:55] <fuzzie> gcc is missing a huge amount of windows-specific stuff
[16:17:13] <dhewg> when i say mingw i really mean mingw64
[16:17:37] <fuzzie> i mean, it's nice if you're just building open-source stuff and you can't have to interoperate with anything, but i've given up on any chance of it even supporting basic stuff like SEH
[16:17:39] <dhewg> that dude, whats his name? tiez? he works with upstream
[16:18:53] <dhewg> and keeping msvc6 compability is insane in itself :P
[16:19:02] <tomprince> There are a number of people working on different bits of clang for windows.
[16:19:37] <tomprince> I think that it can (or at least almost) parse all the C++ headers from 2010.
[16:20:43] <tomprince> Well, it is a choice between breaking msvc6 compat, and having avenger. I know I would choose the latter.
[16:21:07] <fuzzie> dinnertime
[16:21:31] <dhewg> im not suggesting that, i get that you wanna keep it. but i guess that makes more stuff than just a hashmap more complicated
[16:22:17] <tomprince> fuzzie was suggesting that if somebody updates dltcep, to use something other than mfc6, we might be able to move.
[16:22:50] <dhewg> which really does not sound like a short term solution :)
[16:24:46] <tomprince> Well, we don't use alot of the fancy stuff STL does, so I suspect msvc6 compat of a hashmap impl isn't going to be entirely insane: we can probably just ax most of the bits that cause problems.
[16:30:34] <dhewg> heh: http://tinodidriksen.com/2009/10/04/cpp-map-speeds-msvc-edition/
[16:30:57] <dhewg> thats just sick
[16:31:12] <dhewg> on the other hand: http://tinodidriksen.com/2009/07/09/cpp-map-speeds/
[16:31:29] <dhewg> maybe i should start with borrowing from std::tr1::unordered_map?
[16:34:24] --> mihairu has joined #gemrb
[16:34:41] <fuzzie> and yes, DLTCEP is very very huge
[16:39:07] <fuzzie> but i complain abou windows compilers because i would like to not use msvc at all, i would take gcc and writing missing stuff in asm over msvc6 :P
[16:41:18] <dhewg> stl is gpl3+ by now
[16:41:28] <dhewg> gemrb is 2+, right?
[16:43:29] <tomprince> Well, if we started including gcc stl, then we would become 3+.
[16:43:48] <dhewg> yeah, which is not good
[16:44:04] <dhewg> but the new bsd license is gpl compatible
[16:44:04] <tomprince> There is libc++, which from what I have seen has nicer to read code than libstdc++ anyway.
[16:45:25] <fuzzie> is it intended to be portable, though?
[16:46:01] <dhewg> i found this: http://code.google.com/p/cache-table/
[16:46:12] <dhewg> seems to borrow ideas from boost
[16:46:13] <tomprince> One reason I suggested LLVM StringMap, is because I think all we are hashing is strings, and that handles storing a copy of the string, without needing to have a key type of std::string.
[16:46:18] <dhewg> its just 4 header files
[16:46:58] <fuzzie> only works for a cache, though
[16:48:55] <fuzzie> and the keyimporter hashes on string+type combo but dhewg would know better than me
[16:49:11] <dhewg> thats just a trick
[16:49:22] <dhewg> it uses the type as seed for the hash
[16:49:39] <dhewg> but i've seen 3 different uses so far in gemrb
[16:50:06] <fuzzie> yeah, but it also *stores* the type
[16:50:10] <dhewg> 1) just hash the string with tolower() 2) same as 1 with a seed 3) same as 1 but skip spaces
[16:50:22] <fuzzie> so your key value is not just a string
[16:50:50] <dhewg> yes, it gives another hash, it only needs to get the associates value though
[16:51:04] <dhewg> apart from that it doesnt care about the type
[16:51:15] <fuzzie> it maps (resref, type) -> location
[16:51:46] <dhewg> yeah
[16:51:54] <dhewg> which is what i mean if it wasnt clear
[16:52:17] <dhewg> its like hash(str=resref, seed=type)
[16:52:21] <fuzzie> no
[16:52:27] <fuzzie> :P
[16:52:55] <dhewg> uhm
[16:52:58] <dhewg> yes :p
[16:53:03] <fuzzie> no, it isn't
[16:53:13] <fuzzie> if you have a collision and it chains, it checks the type
[16:53:33] <tomprince> It is, but that is an implemnation detail.
[16:54:12] <dhewg> yeah, but i could eliminate collisions with a more expensive hash functions
[16:54:24] <dhewg> but a proper hashmap would also take care of that
[16:54:36] <fuzzie> you can't really, though
[16:54:46] <tomprince> The fact that you use the type as a seed to implement indexing on a tuple (type, resref) is true but irrelevant.
[16:54:53] <fuzzie> yes
[16:55:37] <fuzzie> i was just noting it because StringMap probably wouldn't work out as-is
[16:57:46] <fuzzie> dhewg: the problem with avoiding collisions in gemrb is that the input data is completely unpredictable, there's a huge about of modding data
[16:58:00] <fuzzie> so you can't build a perfect hash function at compile time
[16:59:02] <dhewg> yeah true
[17:00:07] <fuzzie> it's annoying, because a perfect (no-collisions) function would be awesome
[17:01:02] <fuzzie> scummvm's hashmap.h has compiler hacks, how depressing
[17:09:42] <tomprince> For KEYImporter, we could create a perfect hash on startup. Don't know if it would be worth it. There is at least http://cmph.sourceforge.net/
[17:11:31] <fuzzie> last time i looked at the profile, it took a rather tiny amount of time
[17:11:47] <tomprince> That was my thought.
[17:13:58] <fuzzie> i think file I/O (including zlib) is still top
[17:14:21] <fuzzie> tolower() is stupidly high, we should use the pre-generated arrays in core
[17:15:54] <fuzzie> then mostly it's noise
[17:16:03] <fuzzie> all kinds of random silliness, like Image::Image doing GetPixel
[17:17:08] <fuzzie> the KEYImporter hash *construction* shows up though
[17:17:27] <fuzzie> oh, right, it's calling tolower()..
[17:18:10] <fuzzie> wow, that adler32 zlib function takes absurd amounts of time
[17:18:48] <fuzzie> also, SDL_FillRect(?!)
[17:36:55] <fuzzie> dhewg: should maybe file a bug if <tab> isn't bringing piles to the top in gemrb
[17:43:08] <dhewg> like... on a bug tracker?
[17:45:30] <fuzzie> that kind of thing
[17:46:19] <dhewg> thats new :p
[17:46:57] <fuzzie> the place where bugs go to be forgotten and die
[17:47:18] <dhewg> if you put it that way i wont even bother with it :P
[17:47:31] <dhewg> instead i keep poking in here until its fixed!
[17:47:57] <fuzzie> only works if you don't forget though :)
[17:48:22] <dhewg> it really happens often, that should not happen :)
[18:05:58] <fuzzie> i was wondering if people were really meant to stand again if killed while dyig down, seems so in original
[18:06:52] <fuzzie> now Anomen is talking to me-as-slayer in original o.O
[18:30:21] <wjp> you know, sometimes macros are really very convenient compared to templates
[18:30:53] <wjp> is it very bad that I'm now also considering global variables?
[18:31:15] --> barra_home has joined #gemrb
[18:35:20] <fuzzie> you can always macro the templates ;p
[18:36:07] <wjp> the possibilities for evil are endless
[18:36:23] <wjp> surprisingly I didn't see any reason to use goto yet
[18:48:32] <lynxlynxlynx> make it multithreaded while you're at it :)
[18:48:57] <fuzzie> yes. magical multithreading makes everything better!
[18:51:26] <wjp> aww, but I'll have to forget about the globals then
[18:51:52] <tomprince> Not if it is magical multithreading.
[19:08:52] <wjp> if only I'd memorized those spells today
[19:09:18] <wjp> I suppose I'll have to wait until tomorrow... time to go for now
[19:33:53] <fuzzie> phft :(
[19:54:12] <tomprince> fuzzie: does my string branch fix tolower dominating the profile?
[19:55:36] <fuzzie> can't run gemrb atm
[19:56:02] <fuzzie> but i'm not sure it would
[19:56:20] <fuzzie> since i think the function call overhead is a large part of it
[19:56:38] <gembot_> build #75 of msvc++6 is complete: Failure [failed compile minimal test] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/75 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:56:41] <fuzzie> but, well, i am assuming libc's tolower() isn't entirely stupid
[19:56:49] <gembot_> build #59 of autotools g++-4.2.4 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.2.4/builds/59 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:57:33] <fuzzie> also yes what buildbot said
[19:58:29] <fuzzie> but mostly the function-not-good thing, especially not across a library boundary
[19:59:44] <gembot_> build #62 of cmake g++-4.2.4 is complete: Failure [failed minimal test] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.2.4/builds/62 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:59:46] <gembot_> build #58 of autotools g++-4.4.5 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.4.5/builds/58 blamelist: Tom Prince <tom.prince@ualberta.net>
[20:02:50] <gembot_> build #49 of mingw32 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/49 blamelist: Tom Prince <tom.prince@ualberta.net>
[20:04:07] <gembot_> build #58 of autotools g++-4.6.0 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.6.0/builds/58 blamelist: Tom Prince <tom.prince@ualberta.net>
[20:05:22] <-- boriskr has left IRC (Remote host closed the connection)
[20:05:37] <gembot_> build #58 of cmake g++-4.4.5 is complete: Failure [failed minimal test] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4.5/builds/58 blamelist: Tom Prince <tom.prince@ualberta.net>
[20:07:27] <gembot_> build #58 of autotools clang++ is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/autotools%20clang%2B%2B/builds/58 blamelist: Tom Prince <tom.prince@ualberta.net>
[20:07:40] <fuzzie> ok. maybe need smarter bot. :P
[20:07:49] <gembot_> build #59 of cmake clang++ is complete: Failure [failed minimal test] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/59 blamelist: Tom Prince <tom.prince@ualberta.net>
[20:11:25] <gembot_> build #58 of autotools g++-4.5.2 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.5.2/builds/58 blamelist: Tom Prince <tom.prince@ualberta.net>
[20:14:50] <tomprince> Smarter bot would be good.
[20:16:01] <dhewg> i solved the same issue with a delayed timer to report failed builds in one line if you're interested
[20:16:37] <gembot_> build #63 of cmake g++-4.2.4 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.2.4/builds/63
[20:17:05] <tomprince> Sure. Is it upstreamable?
[20:17:48] <gembot_> build #59 of autotools g++-4.6.0 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.6.0/builds/59
[20:18:05] <dhewg> like for the official buildbot repo?
[20:18:16] <tomprince> Yes.
[20:18:40] <dhewg> i didnt try because i had a derived ircbot class for scummvm anyway
[20:19:18] <dhewg> http://sourceforge.net/apps/trac/scummvm/browser/buildbot/config/scumm.py line 191
[20:19:46] <gembot_> build #76 of msvc++6 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/76
[20:21:54] <gembot_> build #59 of autotools g++-4.4.5 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.4.5/builds/59
[20:23:46] <gembot_> build #60 of autotools g++-4.2.4 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.2.4/builds/60
[20:26:43] <gembot_> build #59 of cmake g++-4.4.5 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4.5/builds/59
[20:28:17] <gembot_> build #59 of autotools clang++ is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/autotools%20clang%2B%2B/builds/59
[20:28:55] <gembot_> build #60 of cmake clang++ is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/60
[20:29:36] <gembot_> build #50 of mingw32 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/50
[20:32:19] <gembot_> build #59 of autotools g++-4.5.2 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.5.2/builds/59
[20:37:29] <tomprince> dhewg: I should really publish my config.
[20:38:21] <tomprince> Your IRC status client looks nice. I think that at least some of it might be nice to include upstream.
[20:38:46] <tomprince> The non-wall-of-text looks nice.
[20:38:54] <dhewg> maybe at least this relevant 'timer' stuff
[20:39:29] <dhewg> but we had exactly the same spam on #scummvm
[20:39:57] <dhewg> and now 23 ports on it :)
[20:44:53] <tomprince> Another option that would help is to filter only builds that come from sf, rather than github.
[20:45:37] <tomprince> Or even know how to associate repos to nicks, and just spam the relevent person.
[20:45:58] <fuzzie> the public notifies are nice
[20:46:17] <tomprince> Even for github branches?
[20:46:55] <fuzzie> well, that could maybe get annoying, i don't know
[20:47:18] <dhewg> didnt buildbot have some 'try' feature?
[20:47:26] <tomprince> It does.
[20:47:29] <dhewg> i vaguely remember something
[20:48:08] <tomprince> 'buildbot try'
[21:06:03] <fuzzie> someone with clang etc might try running include-what-you-use on gemrb, also
[21:26:30] <tomprince> I did try at one point, but I couldn't get it to give me sane results at the time. One thing that causes issues for it is globals.h and win32def.h including a bunch of stuff.
[21:27:34] <fuzzie> I guess that's where tolower/toupper alternatives should go, too.
[21:27:50] <fuzzie> I mean, not that. I mean, inline stle.
[21:29:39] <fuzzie> also i should remember that lynx's stack thing is probably wrong
[21:32:15] <CIA-52> GemRB: 03tom.prince * rbd0929a17370 10gemrb/gemrb/core/ (CMakeLists.txt Core.cpp Makefile.am System/String.cpp):
[21:32:15] <CIA-52> GemRB: Add file for generic string functions.
[21:32:15] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[23:04:43] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:38:37] <-- mihairu has left IRC (Read error: Operation timed out)
[23:56:19] <-- Bo_Thomsen has left IRC (Quit: Leaving.)