[00:17:19] --> mihairu has joined #gemrb
[01:06:34] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[02:17:21] <-- |Cable| has left IRC (Ping timeout: 250 seconds)
[02:17:35] --> |Cable| has joined #gemrb
[04:43:19] <-- gembot_ has left IRC (Quit: buildmaster reconfigured: bot disconnecting)
[04:45:14] --> gembot has joined #gemrb
[05:34:47] --> Bo_Thomsen has joined #gemrb
[06:19:00] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[08:08:35] --> lynxlynxlynx has joined #gemrb
[08:08:35] --- ChanServ gives channel operator status to lynxlynxlynx
[08:10:56] <fuzzie> morning
[08:15:35] <lynxlynxlynx> oj
[08:24:05] <tomprince> night. :)
[08:24:46] --> lubos has joined #gemrb
[08:30:06] <edheldil> hi
[08:30:19] <fuzzie> i am playing with profiling wjp's blitter
[08:30:32] <fuzzie> and i am realising another reason our char anims look awful, the anim frames aren't synced to the movement
[08:30:55] <fuzzie> really should rewrite all the anim/move code i guess
[08:33:45] <wjp> aye
[08:33:46] <fuzzie> BlitTile_internal is spending huge amounts of time on that inner loop
[08:34:09] <fuzzie> twice the amount of time that the templated BlitGameSprite is taking entirely, for a screen full of fancy-effect actors
[08:34:33] <wjp> it might be worth it to reevaluate which flag combinations are common and/or very expensive
[08:35:27] <wjp> most of them are pushed to these conditionals
[08:35:57] <wjp> a long time ago I did some counting on which combinations I should speed up, but that might no longer be very representative
[08:35:59] <fuzzie> Map::GetBlocked and Map::ExploreTile are next in the profile list now, followed by BlitSprite and AddPolygonToSpriteCover
[08:36:11] <fuzzie> and only then BlitGameSprite, so it clearly helps quite a bit for me
[08:36:24] <wjp> the (horizontal) clipping in the inner loop is probably also an if too many in the inner loop
[08:36:59] <wjp> although the very quick experiment I did on that (#if 0'ed currently) seemed to slow it down
[08:37:25] <wjp> (oh, not just #if 0'ed, also sabotaged completely, now that I think about it)
[08:37:53] <wjp> do you get a separate profile counter for each template instantiation?
[08:38:08] <fuzzie> no, but i imagine i could get one
[08:38:29] <wjp> the "slow" ones go through _dispatch, if that helps
[08:38:46] <wjp> (and only those, at the moment)
[08:38:55] <fuzzie> but i am prodding at the tile thing a moment
[08:39:55] <wjp> palette handling for that could be better
[08:40:10] <fuzzie> it does it, no?
[08:40:23] <wjp> hm?
[08:41:22] <fuzzie> hm, i guess it spends 15% or so doing the shifts there
[08:44:46] <wjp> what part are you prodding at?
[08:45:17] <fuzzie> the TileRenderer you already did :)
[08:51:27] <fuzzie> although i haven't had enough coffee
[08:51:48] <wjp> I guess hardcoding the shift constants would help
[08:52:06] <wjp> also caching palettes in display format might
[08:52:23] <fuzzie> i hardcoded the shift constants, not much difference
[08:52:36] <fuzzie> profiler blames the non-masked blend() line
[08:53:54] <wjp> the inner loop is quite simple in the opaque unmasked case
[08:54:05] <fuzzie> the opaque/notint version, in fact
[08:54:11] <wjp> effectively just *buf++ = opal[*data++];
[08:57:39] <fuzzie> it fails to inline it
[08:57:43] <wjp> eep
[08:58:49] <wjp> does making the Blender& argument const help?
[08:59:40] <-- |Cable| has left IRC (Remote host closed the connection)
[09:00:27] <fuzzie> no, i lie, it mostly manages to inline it
[09:01:03] <fuzzie> really painful to read intermixed source and optimised asm
[09:07:14] <fuzzie> removing the struct doesn't help, maybe it's just the array
[09:16:37] <fuzzie> ah, i lie about the templates showig up thing
[09:16:43] <fuzzie> just most of them seem to get inlined
[09:17:15] <fuzzie> you're quite right about that hor clipping bit being expensive :)
[09:18:08] <fuzzie> but the std::list<Trapezoid> iterating is quite expensive too
[09:21:55] <fuzzie> and that seems fairly silly given we seem to only modify it on creation
[09:26:06] <wjp> AddPolygonToSpriteCover ?
[09:26:17] <fuzzie> yes
[09:26:22] <fuzzie> i switched it for a vector
[09:26:53] <fuzzie> but i'm sure that slightly larger bounding boxes or something would be far cleverer, that stuff is just beyond me
[09:28:30] <fuzzie> but the game sprites are really much-improved
[09:29:43] <wjp> I can't think of a reason why it is a list
[09:30:29] <fuzzie> alas, no magical framerate fix either
[09:31:59] <wjp> it does already re-use a SpriteCover if it is large enough
[09:32:17] <wjp> but I suppose it might be good to make one that is strictly larger when recreating it
[09:32:31] <fuzzie> at least if you're looking at a couple of pixels :)
[09:32:53] <wjp> hm?
[09:33:19] <fuzzie> as far as i can tell, this is mostly just characters swaying back/forth a bit
[09:33:32] <fuzzie> or maybe their mirror images etc swaying back/forth a bit
[09:33:55] <wjp> so alternating between x+1,y and x,y+1, roughly?
[09:34:00] <wjp> (dimensions)
[09:34:14] <fuzzie> i haven't looked in such detail :)
[09:34:19] <wjp> well, roughly :-)
[09:35:50] <wjp> hm, although animArea should already take care of this
[09:36:33] <fuzzie> removing drawing of mouse/etc directly onto SDL's buffer also doesn't help
[09:37:13] <wjp> at a quick glance it should only be regenerating sprite covers when switching animation
[09:40:43] <fuzzie> hmm
[09:41:18] <fuzzie> you think?
[09:43:38] * fuzzie peers some more
[09:44:32] <wjp> anim->animArea should cover all frames of anim
[09:44:57] <fuzzie> but the x/y can differ
[09:45:12] <fuzzie> do you understand this code? :P
[09:45:29] <fuzzie> it reads like extraCovers is reused for front+back mirror images and blur, but with different locations
[09:46:03] <fuzzie> well, not for blur, since they're one-or-the-other
[09:46:26] <fuzzie> oh right, the zorder should differ
[09:48:49] <fuzzie> well, simple enough to see, wiull add print statement
[09:49:36] <fuzzie> and indeed, it isn't making new covers often at all
[09:49:58] <fuzzie> well, not while stationary :P
[09:50:19] <wjp> optimizing it while moving is an interesting challenge
[09:51:09] <wjp> it's certainly possible to reduce the number of recomputations, but you'd have to keep track of which y-changes would trigger re-z-ordering
[09:51:30] <wjp> not something for now :-)
[09:53:42] <fuzzie> none of the other cover callers seem to be responsible either
[09:55:36] <fuzzie> ExploreMapChunk really is spectacularly bad though
[09:57:04] <fuzzie> can we avoid doing horrible bit manipulation there, i wonder
[09:59:26] <fuzzie> > CGameSprite::RenderMirrorImage(int, CRect &, CRect &, CRect &, CPoint &, CSearchBitmap *, CVisibilityMap *, CVidMode *, long &, unsigned long &, unsigned char &, unsigned char &, unsigned long &)
[09:59:31] <fuzzie> ^- o.O
[10:00:43] <fuzzie> bleh. :P
[10:00:47] <fuzzie> ok, time to do useful stuff
[10:30:06] <dhewg> useful stuff is overrated
[10:59:10] <fuzzie> yes
[11:16:43] --> SiENcE has joined #gemrb
[12:58:38] <-- mihairu has left IRC (Ping timeout: 258 seconds)
[13:21:27] <-- lubos has left IRC (Quit: Leaving.)
[13:41:40] <lynxlynxlynx> wow, that commit truly is awesome
[13:44:14] <fuzzie> yes :P
[13:45:37] <fuzzie> i should probably take a look at the LoadScreen logic rather than just sabotaging the whole thing in my local copy, but hate the GUI
[13:46:23] <fuzzie> and that on_condition thing is really annoying, i hate our fxqueue processing
[13:47:49] <wjp> loading was slow because of the _progress bar_??
[13:48:05] <fuzzie> it depends what you're loading :P
[13:48:30] <fuzzie> but yes, unmodified master seems to spend an awful lot of time drawing MOSes without that patch..
[13:49:38] <fuzzie> v.good spotting on dhewg's part
[13:49:55] <wjp> aye
[13:50:44] <fuzzie> my thought on MOSes in general, for now, is to make a TiledImage class which is just a collection of Sprite2Ds, and a draw function
[13:51:19] <fuzzie> in case anyone has thoughts while i'm thinking about it again
[13:53:08] <fuzzie> (the tiles are not all 64x64, the last ones in a given direction are <=64)
[14:02:40] --> adominguez has joined #gemrb
[14:02:40] <tomprince> As I said before, my suggestion would be to refactor Sprite2D.
[14:02:59] <fuzzie> yes
[14:03:00] <fuzzie> but how?
[14:03:18] <fuzzie> i think while we don't have an answer for this, i'd still like a solution for the MOS thing
[14:03:31] <fuzzie> but if there's some way i can do it in a less-invasive way, that'd be nice
[14:04:04] <fuzzie> I mean, I guess what you *really* want is a Drawable class.
[14:04:49] <tomprince> My thought was to have an SDLSprite, that is basically what we have now, and is generated by calling Video::CreateSprite.
[14:05:15] <tomprince> And have a TileSprite, which is your Sprite2D, each of which knows how to draw itself.
[14:05:19] <fuzzie> But every time we talk about refactoring Sprite2D it seems to end up with someone wanting to remove the BAM code.
[14:06:00] <fuzzie> Right, but how does it draw itself?
[14:06:28] <tomprince> Well, the TileSprite would likely contain a bunch of SDLSprites, so it would just delegate.
[14:06:53] <tomprince> SDLSprite would just call into the current functions on SDLVideo.
[14:06:59] <fuzzie> Right.
[14:07:03] <fuzzie> So it would derive from something?
[14:07:24] <tomprince> they would have a common base class.
[14:08:33] <fuzzie> I mean, that's what I meant by a Drawable class.
[14:08:50] <tomprince> Yes.
[14:09:15] <fuzzie> I'm not entirely sure making SDLSprite a subclass of that is a good idea though.
[14:10:26] <tomprince> Well, how else would you do it?
[14:11:09] <fuzzie> I'm just pondering and throwing out random ideas.
[14:11:52] <tomprince> You would need a subclass of drawable that at least holds a sprite2d.
[14:11:53] <fuzzie> The first thing that comes to mind is that the backends return a opaque reference of some kind, which may or may not have been invalidated by the next time a draw is attempted.
[14:13:03] <tomprince> What does one do if it is invalidated?
[14:13:13] <fuzzie> You'd have to create a new one.
[14:13:47] <fuzzie> So wrappers would have to be aware of the source of their data, as proposed by I think dhewg the other day.
[14:15:20] <tomprince> Re opaque refrences: that is essentially what sprite2d does in the non-bam case.
[14:16:20] <fuzzie> Isn't that what it does in the BAM case?
[14:17:07] <tomprince> Well, except that some of the processing of BAM is handled in Sprite2D in core.
[14:17:11] <fuzzie> Yeah.
[14:17:36] <fuzzie> Some of that can be avoided..
[14:18:47] <fuzzie> Not sure if there's anything which can't be avoided.
[14:19:58] <fuzzie> Doesn't look like it.
[14:20:06] <tomprince> I think we shouldn't design in invalidation handling, until we actually have something which uses it.
[14:20:07] <fuzzie> The data-sharing is necessary, of course.
[14:20:27] <fuzzie> Well, I don't mind not designing it in, but I don't want a design which doesn't work with it.
[14:20:38] <tomprince> Of course.
[14:21:01] <fuzzie> So I don't mean "let's write the code to recover from invalidation", that would be very silly.
[14:23:17] <tomprince> Under what circumstances would it be invalidated, when and by who?
[14:23:35] <fuzzie> Our current design doesn't work with limited texture memory.
[14:25:06] <fuzzie> It's probably sufficient just to keep the pointers around though..
[14:26:03] <fuzzie> Which we're doing anyway, as far as I can tell - that's what the 'pixels' in Sprite2D is.
[14:28:50] <tomprince> Do you just want to keep the pixel data in memory, and recreate the hardware surface occasionally?
[14:29:06] <fuzzie> That's not the standard way, but it looks like it would work.
[14:30:26] <fuzzie> The *other* issue is that you really don't ever want to be making calls like GetPixel and IsPixelTransparent into the backend.
[14:30:34] <tomprince> Well, I don't know the standard way. That simply seemed to be what you were describing.
[14:30:50] <fuzzie> But if we're going to keep the pixel data around, the wrapper class can know about the pixel data, and it can do all of that stuff.
[14:31:05] <tomprince> If that is what you wanted to implement, it seems that that should just be handled by the backend.
[14:32:23] <fuzzie> I mean, I'd like to stop the backend from having a bunch of non-SDL-specific code in it, ideally.
[14:32:33] <tomprince> The only time we call GetPixel is for snapshots, for save game previews, I think.
[14:32:38] <fuzzie> no
[14:33:14] <fuzzie> we call it in some stupid place which shows up in profiles..
[14:33:23] <tomprince> Where abouts?
[14:33:33] <fuzzie> ah, yes, ImageMgr::GetBitmap
[14:37:22] <tomprince> For what type of ImageMgr? Do you know?
[14:37:46] <wjp> that's only called for searchmap and heightmap, it seems?
[14:38:06] <wjp> (so BMP?)
[14:38:09] <fuzzie> wjp: yeah, but it ends up calling deep into SDL every iteration of the inner loop..
[14:38:16] <fuzzie> and yes, i think so
[14:38:18] <tomprince> and lightmap, which should all be bmps, which has its own GetBitmap ...
[14:38:50] <fuzzie> ooh. bug?
[14:40:11] <tomprince> Sounds like it.
[14:40:47] <fuzzie> maybe it was GetImage instead
[14:42:00] <wjp> that would be the lightmap
[14:43:08] <fuzzie> just remembering it because it was one of those 'crazy things using a lot of cpu time for not much work' cases
[14:43:46] <tomprince> That should be easy to fix. Just add a GetImage to BMPImporter.
[14:44:02] <fuzzie> right
[14:44:13] <fuzzie> but then we just kill GetPixel and reject all other image types?
[14:46:02] <tomprince> Or just leave it, and mark it as expensive.
[14:49:42] <fuzzie> well
[14:49:47] <fuzzie> i don't really like that idea
[14:50:03] <fuzzie> either we should support it, or not support it
[14:50:22] <tomprince> Does this look right: https://gist.github.com/951713
[14:50:38] <fuzzie> otherwise we leave this weird GetPixel function on the backend which really shouldn't be the backend's problem
[14:51:32] <fuzzie> tomprince: did you check the data?
[14:51:50] <fuzzie> oh, i see, it's converted at load
[14:53:20] <fuzzie> i'm not sure
[14:55:15] --> mihairu has joined #gemrb
[14:55:34] <fuzzie> hate this code :)
[14:57:53] <tomprince> Well, I have no objection to not going through the backend. I think that would either need to implement those code paths for each imagemgr, or writing a generic handler for the different pixel formats we pass to the backend.
[14:58:14] <fuzzie> well, that is what i'd prefer
[14:58:17] <tomprince> Or erroring out.
[14:58:29] <fuzzie> but i'd have to look at the other uses of GetPixel/etc
[14:58:46] <fuzzie> the bmp patch looks fine
[14:59:03] <fuzzie> i remember there being issues here, but i can't see any
[15:01:21] <fuzzie> i imagine it was Image::GetSprite2D() and presumably that's just going to be super slow for me
[15:04:13] <fuzzie> (i assume it's only used in debug functions though)
[15:10:29] <CIA-52> GemRB: 03tom.prince * r760c97453760 10gemrb/gemrb/plugins/BMPImporter/ (BMPImporter.cpp BMPImporter.h):
[15:10:30] <CIA-52> GemRB: BMPImporter: Add specialized version of GetImage.
[15:10:30] <CIA-52> GemRB: Signed-off-by: Tom Prince <firstname.lastname@example.org>
[15:16:25] <gembot> build #84 of cmake clang++ is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/84 blamelist: email@example.com
[15:17:04] <gembot> build #87 of cmake g++-4.6.0 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.6.0/builds/87 blamelist: firstname.lastname@example.org
[15:18:42] --> Maighstir has joined #gemrb
[15:19:54] <gembot> build #85 of cmake g++-4.5.2 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.5.2/builds/85 blamelist: email@example.com
[15:20:28] <gembot> build #84 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/84 blamelist: firstname.lastname@example.org
[15:20:54] <CIA-52> GemRB: 03tom.prince * r4fec76391772 10gemrb/gemrb/plugins/BMPImporter/BMPImporter.cpp:
[15:20:54] <CIA-52> GemRB: Fix broken commit.
[15:20:54] <CIA-52> GemRB: I forgot to amend. :(
[15:20:54] <CIA-52> GemRB: Signed-off-by: Tom Prince <email@example.com>
[15:21:36] <gembot> build #83 of autotools g++-4.4.5 is complete: Exception [exception interrupted] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.4.5/builds/83 blamelist: firstname.lastname@example.org
[15:21:36] <gembot> build #87 of cmake g++-4.2.4 is complete: Exception [exception interrupted] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.2.4/builds/87 blamelist: email@example.com
[15:21:40] <gembot> build #83 of autotools clang++ is complete: Exception [exception interrupted] Build details are at http://buildbot.gemrb.org/builders/autotools%20clang%2B%2B/builds/83 blamelist: firstname.lastname@example.org
[15:21:40] <gembot> build #82 of autotools g++-4.5.2 is complete: Exception [exception interrupted] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.5.2/builds/82 blamelist: email@example.com
[15:21:45] <gembot> build #83 of autotools g++-4.6.0 is complete: Exception [exception interrupted] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.6.0/builds/83 blamelist: firstname.lastname@example.org
[15:21:45] <gembot> build #83 of cmake g++-4.4.5 is complete: Exception [exception interrupted] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4.5/builds/83 blamelist: email@example.com
[15:22:06] <wjp> noisy bot :-)
[15:29:58] <-- gembot has left IRC (Quit: buildmaster reconfigured: bot disconnecting)
[15:30:25] --> gembot has joined #gemrb
[15:34:05] <gembot> build #85 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/85
[15:36:15] --> Avenger has joined #gemrb
[15:37:09] <-- SiENcE has left IRC (Quit: @all: cya)
[15:37:10] <tomprince> gembot: mute
[15:37:11] <gembot> Shutting up for now.
[15:38:13] <-- mihairu has left IRC (Remote host closed the connection)
[15:47:53] <tomprince> gembot: unmute
[15:47:53] <gembot> I'm baaaaaaaaaaack!
[15:48:46] <tomprince> I commited, was about to push and realised I hadn't compiled. Fixed it and forgot to ammend, and then pushed. :`(
[15:58:08] <fuzzie> i try to obsessively check 'git diff' and 'git log -p' before pushing
[15:58:16] <fuzzie> but everyone messes it up sometimes i think :)
[15:59:23] <tomprince> yes and yes. :)
[16:00:24] <Avenger> hehe
[16:00:37] <lynxlynxlynx> same here
[16:00:52] <tomprince> I think I probably did 'git commit --am' 'git add -p' instead of the other way around. :)
[16:01:05] <Avenger> compiling is not enough either
[16:01:19] <Avenger> testing, testing, testing
[16:01:21] <Avenger> :D
[16:01:33] <tomprince> That's why I want a test-suite. :)
[16:01:45] <fuzzie> the test-suite is tomprince in a box, playing games? :P
[16:01:52] <lynxlynxlynx> recently there's been more testing than work
[16:01:58] <fuzzie> phft
[16:02:10] <Avenger> yeah, ffmpeg devs have an easier job
[16:02:20] <lynxlynxlynx> much of both, not to be misunderstood
[16:02:24] <fuzzie> haha, well, ffmpeg devs know what they're meant to do :)
[16:02:31] <Avenger> they just convert the stuff to and from, and check for differences
[16:02:33] <fuzzie> easy if you know that
[16:02:48] <Avenger> how do you test an interactive game O_o
[16:03:33] <fuzzie> we should have some file-handling tests, so people don't break basic stuff like opening a file
[16:03:43] <fuzzie> just no-one has gotten around to that stuff
[16:04:09] <Avenger> not even valgrinding is automated
[16:04:21] <Avenger> you have to play the game, and do specific stuff
[16:04:50] <fuzzie> and no-one does :P
[16:05:01] <Avenger> though, maybe a script that loads a game then exits....
[16:05:12] <Avenger> and checks if valgrind log is unusually high
[16:05:34] <fuzzie> something like that would be a good check to add, but very expensive
[16:06:35] <Avenger> yep, i just mention something that is not entirely sci-fi :)
[16:06:38] <fuzzie> i have become a bit annoyed with the 0xe8 opcode
[16:06:38] <Avenger> or fantasy
[16:06:44] <fuzzie> it is so very badly documented
[16:06:54] <Avenger> cast spell on condition?
[16:06:56] <fuzzie> yes
[16:07:30] <tomprince> Write a script that will do that, or something and I can added it to my buildbot.
[16:07:31] <Avenger> YESS, i still know them by their opcode
[16:07:32] <Avenger> :D
[16:08:08] <Avenger> so i thought 0xe8 is well decoded
[16:08:11] <fuzzie> tomprince: you really have that much CPU time to waste? :P
[16:08:20] <Avenger> i think i wrote a list about the hardcoded triggers it creates
[16:08:28] <tomprince> Yes.
[16:08:33] <fuzzie> Avenger: me too, but everyone gets something wrong
[16:09:01] <fuzzie> like, which actor are the triggers *checked* on? :)
[16:09:27] <Avenger> http://forums.gibberlings3.net/lofiversion/index.php?t17289.html
[16:09:59] <fuzzie> yeah, that is the best post, but not very clear either
[16:10:17] <fuzzie> and no mention of param3
[16:10:26] <Avenger> that and looking on the code may be helpful
[16:10:30] <Avenger> oh param3???
[16:10:33] <Avenger> lemme think
[16:10:43] <fuzzie> i have Ascension64 notes for that
[16:11:07] <fuzzie> but i don't *like* disasm :P
[16:11:08] <Avenger> i don't know about param3
[16:12:02] <tomprince> fuzzie: Like I said, I have a 3-core server that basically sits around doing nothing. Serving music to 1 person and mail to 2.
[16:12:12] <Avenger> i will have to reboot to windows and look at IDA
[16:12:30] <fuzzie> well, i should probably do it myself, because it's spread across a whole bunch of functions
[16:14:03] <fuzzie> i guess for valgrind we should see if we can stop it from producing any error reports at all? there's some way to suppress python ones, i know
[16:14:12] <fuzzie> wjp reported something the other day
[16:19:16] <tomprince> I have an old python suppresion file, but some things still leak through. Perhaps there is an updated one.
[16:19:32] <fuzzie> or maybe we could make one :)
[16:19:41] <fuzzie> it's a good idea though
[16:21:17] <fuzzie> Avenger: ok, i'll go work out what those functions do now-ish
[16:26:26] <gembot> build #85 of cmake g++-4.4.5 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4.5/builds/85
[16:27:36] --> Bo_Thomsen has joined #gemrb
[16:31:07] <Avenger> anyone wants my python.supp file?
[16:31:37] <Avenger> hmm, i guess, i could upload it to the repo
[16:31:47] <Avenger> so, if someone improves it, others can get it for free
[16:31:55] <gembot> build #86 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/86
[16:32:48] <fuzzie> makes sense to mre
[16:33:36] <CIA-52> GemRB: 03avenger_teambg * r809c9aa8b1ea 10gemrb/testing/python.supp: python suppression file for valgrind
[16:52:00] <gembot> build #87 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/87 blamelist: firstname.lastname@example.org
[16:52:23] <tomprince> gembot:mute
[16:52:23] <gembot> Shutting up for now.
[16:52:25] <fuzzie> phfft :-p
[16:53:07] <tomprince> emerging valgrind on the slave now :P
[16:53:58] <wjp> it's not being kept busy enough already? :-)
[16:57:50] <tomprince> most days aren't like yesterday.
[16:57:58] <tomprince> :)
[17:11:51] <-- dhewg has left IRC (*.net *.split)
[17:12:40] --> dhewg has joined #gemrb
[17:38:51] <CIA-52> GemRB: 03lynxlupodian * r1be983c1ae1b 10gemrb/gemrb/core/GameScript/GameScript.cpp:
[17:38:51] <CIA-52> GemRB: partially reverted 3e52ed0ff8d3fba3601 to not shout anytime a cutscene is
[17:38:51] <CIA-52> GemRB: missing a target
[17:39:01] <CIA-52> GemRB: 03lynxlupodian * ra751a3daa60f 10gemrb/gemrb/core/Scriptable/Actor.cpp: charmed pcs get a red feet circle
[17:39:02] <CIA-52> GemRB: 03lynxlupodian * r218f421f0b72 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp: don't stack same disease opcodes either
[17:39:04] <CIA-52> GemRB: 03lynxlupodian * r0cdacbb4e7ba 10gemrb/gemrb/core/CharAnimations.cpp:
[17:39:04] <CIA-52> GemRB: hack two animation types to prevent crashes in bg2:
[17:39:04] <CIA-52> GemRB: - vampiric mist: mmist
[17:39:04] <CIA-52> GemRB: - ghoul: mghl
[17:42:16] <fuzzie> lynxlynxlynx: could you avoid removing the effects on stack?
[17:43:22] <lynxlynxlynx> it's not removing them, it just waits - maybe the other same source effects have a different duration and will come in play later
[17:43:51] <fuzzie> FX_NOT_APPLIED is a remove
[17:44:29] <lynxlynxlynx> hmm mhm
[17:45:03] <fuzzie> it's incorrect anyway because we should use the fastest effect, but that is trickier to fix
[17:46:18] <CIA-52> GemRB: 03lynxlupodian * r6a0af4490647 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp: don't remove stacked poison/disease effects
[17:47:20] <fuzzie> thanks
[17:59:13] <lynxlynxlynx> great, can't pickpocket a thief quest item
[17:59:22] <lynxlynxlynx> for some reason it is marked as unmovable
[17:59:56] <fuzzie> hm, i thought we fixed that
[18:00:07] <lynxlynxlynx> the normal undroppable flag is not set
[18:00:09] <fuzzie> there was a bug where 'essential' items were marked that way
[18:00:34] <lynxlynxlynx> so it may be a thing with IE_INV_ITEM_UNDROPPABLE vs IE_INV_ITEM_MOVABLE
[18:00:42] <lynxlynxlynx> Avenger: any thoughts?
[18:01:00] --> |Cable| has joined #gemrb
[18:10:55] <Avenger> essential items shouldn't be flagged with undroppable/not movable
[18:14:00] <lynxlynxlynx> i'm sure we all agree about that :)
[18:14:06] <fuzzie> yes
[18:14:31] <fuzzie> the slot flags being maintained in the inventory is a bit dubious anyway
[18:14:56] <fuzzie> well, i'm not sure it is, but it is if other code keeps checking them
[18:14:58] <lynxlynxlynx> what i wonder is this iwd2 mixup - should we be checking the movable bit for stealing at all? it doesn't sound like they're just opposite
[18:15:35] <lynxlynxlynx> and most of the code is using the undroppable bit
[18:20:16] <Avenger> yes, the movable bit should be checked
[18:20:39] <Avenger> if we have both bits, then both should be checked
[18:20:57] <Avenger> but the essential bit may be special
[18:21:18] <Avenger> i think i set it that essential items cannot be stolen
[18:21:27] <Avenger> but it may be a mistake
[18:21:37] <fuzzie> i'm pretty sure the essential stuff is gone
[18:21:55] <Avenger> so, what's lynx's problem
[18:22:11] <fuzzie> hm, i guess not
[18:22:17] <fuzzie> i mean, the essential stuff is gone
[18:22:27] <fuzzie> but i can see that there are worse problems with this
[18:22:48] <fuzzie> because there's the hack in there for picking up unmovable items
[18:24:05] <Avenger> #define ITM_STEALING (IE_INV_ITEM_UNSTEALABLE | IE_INV_ITEM_MOVABLE | IE_INV_ITEM_EQUIPPED)
[18:24:35] <Avenger> these bits should be set to 0 | 1 | 0
[18:25:07] <Avenger> also, the item should be in a stealable slot
[18:25:18] <lynxlynxlynx> it is
[18:25:29] <Avenger> lynx, did you debug which part of FindStealableItem bails out?
[18:25:38] <lynxlynxlynx> the flags
[18:25:51] <lynxlynxlynx> like i said, the movable bit matches
[18:26:02] <Avenger> the movable bit should be 1
[18:26:26] <Avenger> these bits should be set to 0 | 1 | 0
[18:27:09] <lynxlynxlynx> crap, it worked now
[18:27:13] <Avenger> LOL
[18:27:21] <Avenger> it doesn't always work
[18:27:27] <Avenger> just like in real life :)
[18:27:27] <lynxlynxlynx> maybe the item got inited properly on load
[18:27:38] <fuzzie> it was in an actor's inventory?
[18:27:46] <Avenger> there is a randomness to it!
[18:27:46] <lynxlynxlynx> it'd be fine if the pickpocket failed due to skill
[18:27:53] <Avenger> no
[18:28:03] <lynxlynxlynx> but the item was there before and it failed due to not finding any stealables
[18:28:14] <Avenger> there is a randomness, it picks a slot, then goes up or down till it reaches the end of the inventoyr
[18:28:22] <Avenger> but it never completes the search
[18:28:31] <tomprince> http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.4.5/builds/87/steps/minimal%20test/logs/valgrind
[18:28:39] <lynxlynxlynx> right, is that an original idiocy?
[18:28:44] <Avenger> fuzzie can confirm that this is how the original works, yes
[18:28:56] <Avenger> i coded exactly what i read :)
[18:29:27] <lynxlynxlynx> why do we copy that though, it is pretty silly to put it mildly
[18:29:33] <Avenger> tom: does that enter/leave the game?
[18:29:58] <fuzzie> lynxlynxlynx: you mean, why do we copy the fail on unmovable?
[18:30:02] <tomprince> No. It just uses the testing data set.
[18:30:20] <tomprince> Which doesn't have enough data to enter the game.'
[18:30:21] <lynxlynxlynx> no, why do we copy the "check only a random number of slots"
[18:30:31] <fuzzie> oh
[18:30:32] <fuzzie> hmm
[18:30:35] <fuzzie> that seems silly
[18:30:43] <fuzzie> i haven't checked original, busy
[18:30:43] <Avenger> well, that's how the original worked :)
[18:31:03] <Avenger> if fuzzie finds that the original is not as lame, then fine, change it :)
[18:31:15] <fuzzie> well, it's sometimes really sneaky
[18:31:31] <lynxlynxlynx> user unfriendly
[18:31:35] <Avenger> i think it is a good thing, balances stealing a bit
[18:31:44] <Avenger> it should say something like: you didn't find anything
[18:31:50] <Avenger> or whatever
[18:32:00] <lynxlynxlynx> target has no items :)
[18:32:18] <fuzzie> we can always feature it anyway
[18:32:30] <fuzzie> but i finally found a short amount of time to look at contingencies
[18:33:08] <tomprince> I don't have the original data installed on that machine, and anyway the original data doesn't really work for for running a test with no interaction.
[18:35:29] <fuzzie> it does
[18:35:42] <fuzzie> you can load a game and then exit, in python
[18:36:02] <fuzzie> usually i would suggest the bg2 demo data, but it is rather huge
[18:36:40] <tomprince> Maybe I will see about installing the data when I am not on the otherside of the country from that box. :)
[18:38:19] <fuzzie> well, i mean, since someone has put it in a .zip
[18:38:23] <fuzzie> although i can't imagine that will last
[18:47:42] <tomprince> do you have a direct link?
[18:57:14] <-- Avenger has left IRC (Quit: bye!)
[19:04:07] <tomprince> gembot:unmute
[19:04:07] <gembot> I'm baaaaaaaaaaack!
[19:05:01] <fuzzie> contingency stuff isn't so bad
[19:07:04] <dhewg> was that the root of the portal issue?
[19:07:27] <fuzzie> no
[19:07:34] <fuzzie> portal issue is like 5 minutes work
[19:07:36] <fuzzie> at most
[19:07:52] * dhewg looks at his watch
[19:07:57] <fuzzie> so it's just a 'fuzzie is really bad at getting around to things' thing there
[19:08:00] <fuzzie> this is fire shield etc
[19:08:40] <dhewg> ah
[19:08:49] <dhewg> :sp
[19:08:53] <dhewg> uhm, no.
[19:17:35] <fuzzie> bug me about that in a couple of hours i guess
[19:19:33] <tomprince> Should I also bug you about writing guiscript to test bg2demo non-interactively?
[19:21:25] <fuzzie> sure
[19:34:11] --> mihairu has joined #gemrb
[19:50:06] <lynxlynxlynx> i could do that
[20:02:02] --> SiENcE has joined #gemrb
[20:12:38] <-- SiENcE has left IRC (Ping timeout: 248 seconds)
[20:17:35] <-- mihairu has left IRC (Remote host closed the connection)
[20:19:35] --> mihairu has joined #gemrb
[20:33:40] <fuzzie> well, or lynx can do it and save me having to download a copy to try it with :)
[20:35:07] <lynxlynxlynx> your time is better spent elsewhere
[20:46:34] <fuzzie> so, the contingency stuff is indeed divided into two modes
[20:59:21] <fuzzie> keep hving to run off and do stuff
[20:59:24] <fuzzie> what was good example of this?
[21:02:28] <lynxlynxlynx> which part?
[21:02:31] <tomprince> of contingency? I don't think scripts use it.
[21:02:48] <fuzzie> the 0xe8, fire shield etc
[21:04:19] <fuzzie> the param3 basically controls a bunch of hardcoded strings, the portrait icon, and the autodestruct on use
[21:05:56] <fuzzie> and some weird HitBy thing
[21:06:08] <lynxlynxlynx> do you have keldorn handy?
[21:06:27] <fuzzie> yes, just bash at keldorn?
[21:06:32] <lynxlynxlynx> yep
[21:06:51] <lynxlynxlynx> his sword or armor deals 5 magic damage of retribution
[21:07:31] <lynxlynxlynx> for each hit only (once)
[21:07:57] <fuzzie> any idea if there are items/spells/etc using anything more interesting than HitBy/AttackedBy/TookDamage?
[21:08:55] <-- mihairu has left IRC (Ping timeout: 260 seconds)
[21:09:14] <lynxlynxlynx> the contingency ones
[21:09:34] <fuzzie> other than those :)
[21:10:00] <fuzzie> it seems that HitBy(Myself) is ignored for non-contingency uses
[21:10:06] <fuzzie> which i guess makes sense
[21:10:15] <lynxlynxlynx> i can't think of anything else
[21:11:04] <fuzzie> this is really trivial code though, nothing exciting
[21:13:01] <lynxlynxlynx> good
[21:14:35] <lynxlynxlynx> tomprince: can you set env vars before running individual tests?
[21:15:16] <lynxlynxlynx> i was thinking of extending the current 'test' gametype's script with a switch, so we wouldn't need a new gametype for each test
[21:15:42] <fuzzie> why not just run them all?
[21:15:52] <lynxlynxlynx> the demo data may not be there
[21:15:56] <fuzzie> oh, i guess you're .. right
[21:15:59] <lynxlynxlynx> but i guess it could check for that
[21:16:29] <lynxlynxlynx> i don't know if we want detailed test reporting though
[21:16:46] <lynxlynxlynx> in that way their results would be aggreggated
[21:16:53] <fuzzie> well, i would quite like to make the 'test' gametype go through and do a bunch of internal tests
[21:17:19] <lynxlynxlynx> i didn't explain myself well
[21:17:28] <fuzzie> and for bg2demo testing i'm not sure how much we can do without the actual bg2 gametype scripts?
[21:17:45] <fuzzie> since if you want to load a game and then quit, i guess it's going to want to load the gui etc too
[21:17:52] <lynxlynxlynx> what i don't know is how the bot likes to deal with tests - one per one or is all-in-one fine too?
[21:18:35] <lynxlynxlynx> cg+entergame could be faked
[21:19:08] <fuzzie> but then you don't test stuff :P
[21:19:33] <lynxlynxlynx> you don't test cg, which is gui anyway
[21:19:54] <lynxlynxlynx> a premade char needs minimal setup to get ingame iirc
[21:19:59] <fuzzie> well, i guess i don't know what you're thinking here
[21:20:03] <fuzzie> i mean, i don't think it's worth trying to test cg
[21:20:09] --> mihairu has joined #gemrb
[21:20:18] <tomprince> You can basically do anything. But either you need the exit status to report errors, and/or need to write a parser for the ouput.
[21:20:19] <fuzzie> but i do think it's important the gui gets loaded
[21:20:20] <lynxlynxlynx> not in this way
[21:20:33] <lynxlynxlynx> ah
[21:20:36] <fuzzie> because half the leaks come through that direction
[21:20:48] <fuzzie> this is rather irrelevant to your question though!
[21:21:03] <tomprince> They are currently run with SDL_VIDEODRIVER=dummy.
[21:21:10] <tomprince> Except on win32.
[21:21:16] <fuzzie> but that's fine
[21:21:25] <fuzzie> the dummy driver is internally consistent
[21:22:02] <fuzzie> i've actually (ab)used it before to have an SDL app which rendered into a Win32 widget, by snaffling the primary surface from the dummy driver at flip time
[21:43:28] <fuzzie> hmm
[21:43:33] <fuzzie> so does anyone know contingencies?
[21:44:17] <fuzzie> two of the conditions for the effect seem to be along the lines of PersonalSpaceDistance([ANYONE], 4)
[21:44:48] <lynxlynxlynx> yes, that's for globe of blades and similar spells
[21:45:01] <fuzzie> but i don't see a friendlies check..
[21:45:25] <lynxlynxlynx> i don't think that's a problem
[21:46:29] <fuzzie> this is listed as fixed in SCSII, which is worrying
[21:47:25] <lynxlynxlynx> gob's description specifically says anyone
[21:47:48] <lynxlynxlynx> sounds cheesy for scs to change it
[21:47:51] <fuzzie> ah, they are not using this effect
[21:48:32] <lynxlynxlynx> blade barrier works the same
[21:49:21] <lynxlynxlynx> but yes, these could just be aoe spells
[21:51:07] <fuzzie> no, i take it bacxk, globe of blades only is missing it
[21:51:27] <fuzzie> hrmph
[21:51:38] <fuzzie> i don't see how that would work, really
[21:51:49] <fuzzie> this stuff is only checked once per round and it checks distance of exactly 4
[21:53:59] <fuzzie> i will just dismiss the entire contents of google as lies, for now
[21:55:33] <lynxlynxlynx> keep in mind that 4 is very little, probably just one standard feet circle around the actor
[21:55:54] <fuzzie> well, if what people say is true, it only works at exactly that distance, which seems weird
[21:55:59] <fuzzie> but i never really understod it in original
[21:56:39] <lynxlynxlynx> maybe because there you're always infringing on that distance too
[21:56:49] <lynxlynxlynx> but that would complicate their checking
[21:57:27] <lynxlynxlynx> maybe they round it off greatly?
[22:02:55] <lynxlynxlynx> zzz time
[22:02:58] <DrMcCoy> lynxlynxlynx: gob?
[22:03:08] <lynxlynxlynx> globe of blades
[22:03:16] <fuzzie> hehe
[22:03:19] <DrMcCoy> Bleh
[22:03:21] <fuzzie> you have that on highlight? :P
[22:03:26] <DrMcCoy> fuzzie: Of course
[22:03:41] <fuzzie> (DrMcCoy works on the gob engine for scummvm)
[22:03:43] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[22:04:00] <DrMcCoy> fuzzie: Also get random highlighs when someone says he's gobsmacked. Or for some YouTube videos
[22:33:29] <fuzzie> ok, i summoned an Ettercap to attack Keldorn, and i can't attack.
[22:34:44] <fuzzie> and none of my keldorns seem to have a 0xe8 anyway, v.sad
[22:35:28] <fuzzie> oh right, hallowed redeemer ability
[22:39:03] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[22:40:25] <fuzzie> so, i hit keldorn, keldorn does 5 damage to me
[22:40:38] <fuzzie> after a bit of battling with my segfaulting tile renderer
[22:40:42] <fuzzie> this seems .. disappointing
[22:46:26] <-- Drakkar has left IRC (Quit: The beer is meal.)
[22:48:44] --> Drakkar has joined #gemrb
[23:46:51] <-- Drakkar has left IRC (Read error: Connection reset by peer)
[23:47:17] --> Drakkar has joined #gemrb
[23:48:43] <-- adominguez has left IRC (Quit: Saliendo)