#gemrb@irc.freenode.net logs for 10 Apr 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:55:15] --> raevol has joined #GemRb
[01:20:38] <-- raevol has left IRC (Quit: Leaving.)
[02:34:41] <-- ratpor has left IRC (Quit: Get used to disappointment.)
[02:58:46] --> _pickle has joined #GemRb
[03:15:05] --> Gekz_ has joined #GemRb
[03:15:11] <-- Gekz has left IRC (Read error: Connection reset by peer)
[04:29:31] <-- _pickle has left IRC (Remote host closed the connection)
[05:22:23] --> raevol has joined #GemRb
[06:51:55] <-- raevol has left IRC (Quit: Leaving.)
[07:17:09] --> Gekz has joined #GemRb
[07:17:55] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[07:49:41] <-- edheldil_ has left IRC (Ping timeout: 245 seconds)
[09:36:12] --> Edheldil_ has joined #GemRb
[10:26:58] <CIA-74> GemRB: 03wjpalenstijn * rae8ca3cdba32 10gemrb/gemrb/plugins/SDLVideo/SDLVideoDriver.inl: Improve SDLVideoDriver.inl layout and comments
[10:27:00] <CIA-74> GemRB: 03wjpalenstijn * rc467378bd785 10gemrb/gemrb/plugins/SDLVideo/SDLVideoDriver.inl: Fix masking bug in (unused) tinted, half_trans renderer
[10:34:36] <fuzzie> any more thoughts on global tinting? i noticed the broken patch breaks colour-keying.
[10:36:23] <wjp> yeah, I was lazy
[10:36:59] <wjp> I'm faking a sprite struct with a transindex hardcoded to 255 when including the .inl
[10:37:49] <fuzzie> i tried a few comparisons between original bg1 and it, and it looks okay (at a visual glance); don't know if it's different in bg2.
[10:38:21] <wjp> so I guess tinting is the right approach then; thanks for checking
[10:38:37] <fuzzie> but it's a huge improvement for all the cutscenes which are meant to be dark and stormy!
[10:39:33] <wjp> there's basically two approaches to global tinting I think: apply it when rendering sprites, or apply it in a post-processing step on the entire game window
[10:40:33] <wjp> an issue with the former is that there's no real solid distinction between game sprite rendering functions and other (GUI) sprite rendering functions
[10:41:34] <wjp> and the latter option is likely a lot slower (although maybe it can combined with the backbuf->screen blitting step)
[10:41:36] <fuzzie> We could easily add enable/disable calls of some kind around the game window drawing, if that would help.
[10:42:13] <wjp> or maybe we could use BlitGameSprite for all game sprites
[10:42:28] <wjp> (as if that function didn't have enough special cases yet...)
[10:43:09] <fuzzie> We probably don't really want to be calling into Game from the video driver anyway, so a SetGlobalTint on the driver might make sense either way?
[10:43:29] <wjp> yes, I agree
[10:45:06] <fuzzie> WB_LIGHTNING might be worth considering too, I don't know if that would be done with tinting or something else.
[10:45:22] <wjp> white flashes?
[10:45:43] <fuzzie> I think so; if you have ToB installed, try the very first ToB area.
[10:45:54] <wjp> tinting can't make things brighter unfortunately
[10:47:34] <wjp> SetFadeColor might work
[10:55:50] * fuzzie peers
[10:57:57] <fuzzie> don't think it's so complicated
[10:58:50] <fuzzie> doesn't seem to be flashing the sprites at all
[11:00:19] <fuzzie> so not to worry about.
[11:01:41] <wjp> what does it flash? I don't have a runnable ToB here right now
[11:03:05] <fuzzie> the raindrops, i think
[11:03:41] <fuzzie> i can't focus on the screen very well atm, so i may well be wrong
[11:04:14] <fuzzie> but the rain is controlled by the weather, so it can change the colours itself
[11:18:21] --> lynxlynxlynx has joined #GemRb
[11:18:21] --- ChanServ gives channel operator status to lynxlynxlynx
[11:33:30] <fuzzie> maybe lynx knows better?
[11:50:53] <lynxlynxlynx> oj
[11:51:37] <lynxlynxlynx> nope, i don't remember how it looks
[12:33:44] <fuzzie> we are also still missing projectiles
[12:34:18] <fuzzie> i thought the bg1 ones were done :/
[12:39:21] <fuzzie> bg1 is missing the CG* ones, COLRSPRY, FIREBLGR, HLYMITE, HOLD, INAREANP, INAREANS, INAREAPA, LIGHTB, SKYBOLT2, SPBRNHND, SPCONECO and SPCONEFI
[12:40:10] <fuzzie> and it has SPFIREWL in the list, but an unused 'spfirebl.pro'.
[12:40:49] <fuzzie> don't know how many of those are relevant, i just noticed the missing LIGHTB
[12:44:44] <fuzzie> (and i don't want to just copy the bg2 one, i think it has special flags)
[12:44:51] <fuzzie> so, i make Avenger-summoning motions again
[12:45:44] <fuzzie> huh, bg1 is really unloved, most of those are in the other directories :(
[12:53:04] <lynxlynxlynx> what do you mean?
[12:53:19] <lynxlynxlynx> analogous projectiles for other gametypeS?
[12:54:03] <fuzzie> yes
[12:54:31] <wjp> bg1 does have a lot of .pro's
[12:54:51] <fuzzie> COLRSPRY, for instance: there's an iwd/how/iwd2 one, a bg2 one and a pst one, but no bg1 version
[12:54:51] <wjp> ok, iwd* have a lot more :-)
[12:55:15] <fuzzie> wjp: well, it doesn't matter if it's not in the gemprjtl.ids, which is why i gave a missing list above :)
[12:55:53] <fuzzie> (i just diffed the resrefs in that with the directory listings for shared/ and bg1/)
[12:58:51] <-- Edheldil_ has left IRC (Remote host closed the connection)
[13:48:10] <fuzzie> hm, pst Journal doesn't work? and the item interaction buttons are wonky
[13:48:22] <Gekz> I just killed the shit out of Sarevok.
[13:48:29] <fuzzie> which one? :)
[13:48:42] <Gekz> BG1
[13:48:51] <fuzzie> there's so much cheese possible there in bg1..
[13:48:57] <Gekz> cheese?!
[13:49:07] <Gekz> I think the lighting in BG1 is shit
[13:49:11] <Gekz> and it should be punished
[13:49:23] <fuzzie> filling the area with summons and area projectiles, etc :)
[13:49:31] <Gekz> oh
[13:49:37] <Gekz> do you know how I did it?
[13:49:39] <Gekz> I solo'd him.
[13:49:42] <Gekz> without buffs other than haste.
[13:49:47] <Gekz> as a paladin.
[13:50:15] <fuzzie> http://www.sorcerers.net/Games/BG2/SpellsReference/Stuff/Cheese.htm
[13:51:00] <fuzzie> ^- i like this list in particular
[13:51:17] <fuzzie> although i imagine there must be more organised ones
[13:51:37] <fuzzie> we shall have to have a cheese-squishing squadron.
[13:54:06] <lynxlynxlynx> improved anvil? hehe
[13:54:18] <Gekz> i didnt cheat in any way though
[13:54:32] <Gekz> I just kept hitting him with near crits with a +3 two-handed sword
[13:54:32] <lynxlynxlynx> i think scs and some rebalancing mods kill a lot of the cheese
[13:54:44] <fuzzie> Gekz: very good :)
[13:55:31] <Gekz> the only "cheating" I did was add gem and scroll bags to BG1
[13:55:37] <Gekz> because I forgot to add the ease of use mods
[13:55:50] <Gekz> and a trigger broke, which you recall
[13:55:54] <Gekz> so i had to teleport where I was going
[13:56:07] <Gekz> now I'm up to BG2 and I'm bored :<
[13:56:15] <Gekz> I've finished BG2 like 5 time
[13:56:20] <Gekz> never finished ToB
[13:56:22] <Gekz> finished BG twice
[13:56:36] <fuzzie> play pst/iwd? :)
[13:57:05] <lynxlynxlynx> and you pick a boring class like a paladin
[13:57:23] <lynxlynxlynx> play a wild mage or a bard
[13:57:27] <Gekz> fuck that shit
[13:57:39] <Gekz> this is the first time I've played a paladin
[13:57:40] <Gekz> EVER
[13:57:42] <Gekz> in any game
[13:57:52] <lynxlynxlynx> heh, my first protagonist was one
[13:58:01] <Gekz> my first one was a bard
[13:58:05] <Gekz> then a pure mage
[13:58:06] <lynxlynxlynx> :P
[13:58:15] <Gekz> then a barbarian gnome
[13:58:19] <Gekz> who pwned so hard it was unbelievable
[14:05:42] <fuzzie> Hmm, GiveItemCreate() after a Kill(Myself) isn't working, either.
[14:07:40] <fuzzie> Nor the return-to-location.
[14:11:23] <fuzzie> And thus ends another episode of "how many new broken things can you find in the first area of PS:T", I guess.
[14:11:39] <fuzzie> Definitely getting there.
[14:15:02] <Gekz> getting where
[14:15:06] <Gekz> to a point where more things break than work?
[14:15:07] <Gekz> xD
[14:24:21] <fuzzie> Qwinn certainly has obsessively documented the PS:T fixpack
[14:34:22] <Gekz> I like the obsessive documentation
[14:34:25] <Gekz> I do not like PS:T
[14:34:27] <Gekz> I dont know why
[14:34:29] <Gekz> i just cant get into it
[14:34:35] <Gekz> and I cant get the widescreen mod to work with it
[14:34:48] <fuzzie> it is a very different game :) widescreen mod should work fine, though
[14:34:57] <Gekz> it wont install
[14:34:59] <Gekz> it shits a brick
[14:35:24] <fuzzie> you've got to do a full install (so, manual copying), apply Patch 1.1, and then the mod
[14:35:39] <fuzzie> it is a bit of a pain, there's always someone asking for help with it in the forums
[14:35:42] <Gekz> I did that
[14:35:52] <Gekz> someone should just make an installer
[14:35:55] <Gekz> a proper instlaler
[14:36:04] <Gekz> I COULD BE THAT SOMEONE
[14:36:11] <Gekz> but I wont be.
[14:37:38] <fuzzie> :)
[14:39:52] <fuzzie> it would be nice to have a weidu which wasn't completely crazy
[14:40:00] <fuzzie> but i guess that is hopeless
[14:40:42] <tomprince> The completly wacky language that is unlike anything else in existence?
[14:41:07] <fuzzie> well, it made sense to begin with :)
[14:41:54] <lynxlynxlynx> i wouldn't call it a language
[14:42:04] <fuzzie> very good example of the disasterous consequences of just adding on bits for a single task and then other people starting to use them..
[14:42:05] <Gekz> I would
[14:42:07] <Gekz> it's a functional language
[14:42:14] <lynxlynxlynx> non*
[14:42:15] <tomprince> I haven't done much with it, but its syntax seems horibly non-orthogonal.
[14:42:27] <Gekz> it's functional!
[14:42:29] <Gekz> >_>!
[14:42:39] <tomprince> It seems like it is probably turing-complete, but you can hardly tell under all the special cases.
[14:42:41] <lynxlynxlynx> and it's written in ocaml, so really no hope of improving
[14:42:51] <lynxlynxlynx> tomprince: i doubt it
[14:43:06] <fuzzie> if you start with the realisation that it was designed to work with dialogs/strings, it makes more sense.
[14:43:26] <lynxlynxlynx> i wrote the support for gemrb in the widescreen mod, which didn't take a lot at all, but I still had to jump through hoops
[14:44:14] <lynxlynxlynx> touring complete - can do anything with enough tape -> unlikely
[14:47:12] <fuzzie> and you'd be surprised how little you need to be turing-complete :)
[14:48:36] <Gekz> I dont understand what validity being turing complete adds
[14:48:47] <Gekz> I do not understand the tape analogy
[14:49:12] <-- fuzzie has left IRC (Remote host closed the connection)
[14:49:45] --> fuzzie has joined #GemRb
[14:50:43] <tomprince> Well, being turing complete doesn't *add* anything. It just means that you can do anything you can do in any other programing language.
[14:56:59] <-- fuzzie has left IRC (Ping timeout: 276 seconds)
[14:57:28] <-- tomprince has left IRC (Remote host closed the connection)
[15:00:08] --> tomprince has joined #GemRb
[15:04:13] --> fuzzie has joined #GemRb
[16:22:11] <wjp> tomprince: is the .inl stuff more understandable now, or should I spend some more time on documenting it?
[16:22:46] <tomprince> Let me have a look at the latest version.
[16:24:14] <wjp> cleaning it up a bit did reveal a missing '&mask' in one of the blending macros :-)
[16:24:53] <wjp> fuzzie: that broken colourkeying that you mentioned turns out to be somewhat more annoying than I first thought
[16:25:36] <wjp> fuzzie: we're currently storing colourkeyed tiles with SDL_RLEACCEL, and that's not something our own renderer can handle
[16:27:41] <fuzzie> :nod:
[16:28:08] <wjp> (options: disable SDL's RLE or don't store it as an SDL_Surface at all)
[16:28:41] <fuzzie> Well, there's that bg2 area where the holes in our current strategy are showing anyway: the colour key should be only a mask for blitting, and it isn't, or similar?
[16:28:57] <wjp> what do you mean?
[16:30:17] <fuzzie> I'm not sure what we do right now.
[16:30:43] <fuzzie> Isn't it just blitting the 'real' tile on top of the overlay, using the colour-keying in that tile?
[16:31:14] <tomprince> One thing that would clean it up is to at least give the macros ALPHA TINT and HALFAPLHA numerical values, and then you could write BLENDPIXEL as a single bit of C++ code with conditionals, that the compiler should optimize away.
[16:32:05] <wjp> fuzzie: I'm not at all sure about how the TileOverlay side of things works
[16:32:31] <fuzzie> Well, "not correctly". :)
[16:32:52] <fuzzie> So I mean, it is maybe not worth trying to fix that code until it actually works for all cases.
[16:33:06] <wjp> fuzzie: but the video driver has no masking support (other than the wall cover stuff), so the only rendering it does is regular blitting and colourkeyed blitting
[16:34:55] <fuzzie> I wonder if we can fix it just using those.
[16:35:46] <tomprince> Well, if it doesn't work in all cases, it might be easier to get it to work once the code is cleaned up.
[16:35:47] <fuzzie> The trick is that we have one "real tile", one tile with the green mask, and one tile with the overlay. We want the real tile to be drawn, except where the mask is present, and there we want the overlay. Possibly we could just stomp over the real tile at load time? I'm not sure.
[16:36:26] <wjp> aha
[16:36:54] <-- Nomad010 has left IRC (Remote host closed the connection)
[16:37:01] <tomprince> I know for a lot of the other stuff I've done, as I clean stuff up, it makes it easier to fix other things.
[16:37:03] <fuzzie> But I mention it because I think it's something which we can't do with the interface as-is.
[16:37:12] <wjp> fuzzie: correct
[16:37:23] <wjp> fuzzie: unless we combine the mask and overlay tiles
[16:37:45] <wjp> fuzzie: is there a reason that isn't done? I'm guessing a single overlay tile can be used with multiple masks?
[16:38:11] <fuzzie> Yes, and they're animated, etcc.
[16:39:55] <fuzzie> tomprince: Converting to the C++ code seems non-trivial.
[16:40:05] <wjp> ugh. So without any preprocessing we'd need a masked blit
[16:40:19] <wjp> sounds like we might just want to get rid of storing things as SDL surfaces
[16:40:34] <wjp> since in practically any case we want 'fancy' blitting options
[16:41:43] <tomprince_loki> I think it would only be useful, if most of the fancy stuff we want to do is doable by SDL.
[16:41:49] <fuzzie> I'm not sure. I also have in the back of my head that the tilemap should be on-demand.
[16:42:17] <tomprince_loki> How much of the tilemap is dynamic?
[16:42:29] <lynxlynxlynx> "There is a new optimization pass that attempts to change prototype of functions to avoid unused parameters, pass only relevant parts of structures and turn arguments passed by reference to arguments passed by value when possible." <-- ot, but how is the last part an optimisation? :s
[16:42:29] <fuzzie> dynamic?
[16:43:01] <tomprince_loki> No pointer dereference in the called function.
[16:43:38] <lynxlynxlynx> but it makes a copy instead
[16:43:47] <fuzzie> Copies of most things are cheap, though.
[16:44:00] <tomprince> And it may already have a copy laying around.
[16:44:28] <lynxlynxlynx> so why does everyone use pass-by-ref?
[16:44:39] <tomprince> Large structs?
[16:44:54] <lynxlynxlynx> yes
[16:45:10] <lynxlynxlynx> but now the compiler would do the same
[16:45:15] <fuzzie> Making a copy of something like an STL vector involves heap allocation, too.
[16:45:28] <fuzzie> I mean, I think it is implied that the compiler will only do it when it is actually an optimisation.
[16:45:40] <lynxlynxlynx> "when possible"
[16:45:48] <lynxlynxlynx> "when reasonable"
[16:46:16] <fuzzie> "when reasonable" would just lead to the same kind of arguments about what reasonable is, I would guess. :) Which compiler is this?
[16:46:29] <lynxlynxlynx> gcc
[16:47:52] <tomprince> For the STL vector case, it might actually be faster to pass it as struct, rather than by reference, *except for the copy constructor*. But if the compiler can see that the function doesn't actually modify the struct itself (just the stuff pointed to), it can change the pass-by-ref to a pass-by-value *without* the copy, and without changing the semantics.
[16:48:20] <fuzzie> You'd have to have a terribly clever compiler, though.
[16:50:12] <wjp> is that even decidable? :-)
[16:50:22] <tomprince> Not necessarily. If you compile down the C++ to an IR, then the IR optimizer just sees a pointer being passed, and can look to see if anything actaully changes the values directly pointed to, and if not promote it to a by-val.
[16:51:50] <tomprince> You would need some alias analysis, to make sure the struct doesn't change under you, i.e, that no one you call has a reference to the struct, but other than that, I don't think it is to hard in principle.
[16:52:19] <fuzzie> It sounds like the kind of thing which might quickly break existing code (eg, threading).
[16:52:35] <fuzzie> Like all the clever attempts by people to ref-count STL objects.
[16:52:42] <wjp> re. tiles: I'm thinking we might want a separate tile renderer that does masking and tinting, but nothing else
[16:54:26] <wjp> ah well, dinner first. I'll think about it some more :-)
[16:54:35] <wjp> back (potentially much) later tonight
[17:42:02] <fuzzie> tomprince: you really want that silly s/BMPImp/BMPImporter/ patch?
[17:46:01] <tomprince_loki> I wouldn't do it if I was going in there and mucking things, but I think it makes sense to have unabreviated names, so as I touch things, I fix the names.
[17:46:16] <tomprince_loki> That way too, the name matches the directory, which I think is sensible.
[17:46:59] <fuzzie> Well, that rename patch, the 'remove useless function', the 'add doxygen comments' and the 'make GetImageFactory non-virtual' commits are all harmless non-behaviour-changing changes?
[17:48:03] <tomprince_loki> Yes.
[17:48:48] <fuzzie> I would prefer the BMPWriter one be in a "break things" commit and only then a "refactor" one, but I hope there aren't any more hidden bugs..
[17:51:38] <tomprince_loki> I think that I could probably do the other way even.
[17:52:02] <CIA-74> GemRB: 03tom.prince * r3869392efb6c 10gemrb/gemrb/plugins/BMPImporter/ (BMPImporter.cpp BMPImporter.h):
[17:52:02] <CIA-74> GemRB: BMPImporter: Use full name for class.
[17:52:02] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[17:52:03] <fuzzie> I don't think it's worth the bother.
[17:57:16] <fuzzie> Are there any other logic changes in it, other than the (correct) switch to GetImage() and the whole ImageWriter thing?
[17:58:24] <tomprince_loki> There shouldn't be, other than the bogus init.cpp in the CMakeList.txt
[17:59:23] <fuzzie> Well, BMPWriter isn't built by cmake anyway by that patch, right?
[18:00:11] <tomprince_loki> That too would be a bug. :)
[18:00:29] <tomprince_loki> Perhaps why it never got noticed. :)
[18:00:34] <fuzzie> But just wondering if there's anything else less obvious I should be testing. :)
[18:01:32] <CIA-74> GemRB: 03tom.prince * r33247bbe50f6 10gemrb/gemrb/plugins/ (BMPImporter/BMPImporter.h PNGImporter/PNGImporter.h):
[18:01:32] <CIA-74> GemRB: BMP/PNGImporter: Remove useless function.
[18:01:32] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:02:41] <tomprince_loki> As far as I can tell, no. The only thing that calls PutImage/OpenFromImage is SaveGameIterator, and that is changed over.
[18:06:00] <fuzzie> Just comparing the two.. you remove the NULL check, you force autoFree, that is all that is new.
[18:06:57] <fuzzie> But both of those are fine. Okay.
[18:19:14] <tomprince_loki> How about the cmake changes changes. I just pushed an updated version that splits off the RPATH changes.
[18:19:52] <fuzzie> I'm not sure how those changes affect the build-directory layout.
[18:19:54] <tomprince_loki> The layout one now just changes where things are installed (and forces GUIScripts and override to be in the same base directory).
[18:20:26] <fuzzie> Do they, at all?
[18:22:07] <tomprince_loki> The RPATH patch might, I don't know, the others should change anything in the build layout.
[18:22:31] <tomprince_loki> I was actually planning a patch at somepoint to make cmake drop the plugin .so in plugins directly.
[18:22:45] <fuzzie> Directly?
[18:23:01] <fuzzie> Oh, in builddir/gemrb/plugins/?
[18:23:12] <tomprince_loki> yes.
[18:24:14] <fuzzie> Seems reasonable.
[18:25:00] <fuzzie> At the moment, it is a huge mess re-running plugins-prepare.sh every time this stuff changes.
[18:25:21] <fuzzie> It would be nice for Makefile.am to be patched up to force a run, at least for now.
[18:26:24] <fuzzie> As it is, gemrb just crashes, because you didn't check that it gets a PLUGIN_IMAGE_WRITER_BMP back.
[18:30:01] <CIA-74> GemRB: 03tom.prince * rd2a4cf98d768 10gemrb/ (18 files in 7 dirs):
[18:30:01] <CIA-74> GemRB: BMPImporter: Split off BMPWriter.
[18:30:01] <CIA-74> GemRB: Only BMPImporter supported writing images.
[18:30:01] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:30:03] <CIA-74> GemRB: 03fuzzie * r6b89306170e0 10gemrb/gemrb/plugins/Core/Video.cpp: endian-fix SpriteScaleDown again, now that BMPImporter isn't doing bad things
[18:30:06] <CIA-74> GemRB: 03tom.prince * rddc68663d709 10gemrb/gemrb/plugins/Core/ImageMgr.h:
[18:30:06] <CIA-74> GemRB: ImageMgr: Add doxygen comments.
[18:30:06] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:30:07] <CIA-74> GemRB: 03fuzzie * rf5cb3d114293 10gemrb/gemrb/plugins/Core/SaveGameIterator.cpp: check for missing BMPWriter before using it
[18:34:27] <fuzzie> I modified both of those commits, I hope I didn't miss anything.
[18:36:02] <tomprince_loki> Pushed a cmake patch to drop .so in gemrb/plugins.
[18:40:42] <CIA-74> GemRB: 03tom.prince * r7ea7e2d29b39 10gemrb/gemrb/plugins/ (7 files in 4 dirs):
[18:40:42] <CIA-74> GemRB: ImageMgr: Make GetImageFactory non-virtual.
[18:40:42] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:44:51] <tomprince_loki> Patches diffs look fine.
[18:58:51] <-- tomprince has left IRC (Ping timeout: 245 seconds)
[18:59:41] <-- tomprince_loki has left IRC (Ping timeout: 245 seconds)
[19:05:42] --> tomprince has joined #GemRb
[19:05:54] <fuzzie> Hm, I didn't look over some of these old patches so well.
[19:06:11] <fuzzie> You scattered abort()s all over when you moved to ImageMgr::ID.
[19:08:20] <tomprince> It was abort/segv, and I wasn't sure what the proper way to recover was.
[19:08:34] <fuzzie> Well, it would have been nice to fix those before offering the patch..
[19:12:19] <tomprince> I think my thinking at the point was that an abort was unequivocally better than a SEGV, and I was nowhere near as familiar with the codebase at that point.
[19:12:28] <fuzzie> *nod*
[19:12:33] <tomprince> I can have a look and see how to clean them up now.
[19:12:34] <fuzzie> Previously, it was neither, though. :)
[19:13:26] <fuzzie> I am patching it up, I'll post a patch.
[19:13:43] <fuzzie> Just an expected surprise to get an abort() in a common case.
[19:18:00] <tomprince> I don't know, looking a the original code, it seems that if it failed to open the file, bad things would happen. I guess perhaps not a SEGV, at least not right away.
[19:18:16] <tomprince> But, you are right, it should be fixed.
[19:18:34] <fuzzie> Thereotically bad things could happen, so I patched that up a bit.
[19:30:50] <CIA-74> GemRB: 03fuzzie * ra9800a072456 10gemrb/gemrb/plugins/Core/MapControl.cpp: fix MapControl to cope with missing smallmap
[19:30:56] <fuzzie> I didn't really think too hard about those, other than making sure bg2 didn't lead quickly to an abort().
[19:30:58] <CIA-74> GemRB: 03fuzzie * rcaa8dd0fd3be 10gemrb/gemrb/plugins/AREImporter/AREImporter.cpp: don't abort() on missing files in AREImporter
[19:35:24] <fuzzie> The MapControl patch is unnecessary afaik, but better to fix that while I'm thinking about it.
[19:47:57] <fuzzie> I seem able to speed-run bg2 a bit without anything breaking, after that.
[19:49:19] <tomprince> :)
[19:49:45] --> raevol has joined #GemRb
[19:50:19] <fuzzie> Meh, things looked so much better with that night tinting patch applied. :)
[19:53:42] <fuzzie> That first bg1 cutscene has so many annoying other issues, though!
[19:54:20] <fuzzie> Problems with projectiles, problems with stances, problems with animations, bad centering, missing message sync.. :|
[20:14:21] <tomprince> fuzzie: Could I bother you to apply the first two cmake patches.
[20:16:34] <fuzzie> Update the first?
[20:20:28] <tomprince> Done.
[20:22:38] <fuzzie> Is the third one no good?
[20:23:02] <tomprince> I think the third one is good.
[20:23:33] <tomprince> But it is the second one that I am more concerned with. After that, I can actually build and *test* with cmake.
[20:23:55] <tomprince> Since I install before using, and don't have plugindir/override/guiscript setup in my cfg files.
[20:24:30] <tomprince> So, I am not saying don't applythe later ones, just *do* apply the earlier ones.
[20:24:33] <tomprince> Please. :)
[20:25:28] <fuzzie> ok. easy to revert..
[20:27:28] <tomprince> And if you are building with cmake, you might want to apply the last one, so that you need not run plugin-prepare.sh.
[20:32:51] <fuzzie> I am not, because I can never work out how to make it work.
[20:35:20] <fuzzie> But it builds for me, so I will push as requested.
[20:35:51] <CIA-74> GemRB: 03tom.prince * ra3982e1b45b3 10gemrb/ (39 files in 39 dirs):
[20:35:51] <CIA-74> GemRB: cmake: Move installation of plugins to macro.
[20:35:51] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[20:35:54] <CIA-74> GemRB: 03tom.prince * r20dbcee0417d 10gemrb/ (10 files in 10 dirs):
[20:35:54] <CIA-74> GemRB: cmake: Add LAYOUT option to control install paths.
[20:35:54] <CIA-74> GemRB: - home: current layout.
[20:35:54] <CIA-74> GemRB: - fhs: (mostly?) Filesystem Hierarchy Standard compliant.
[20:35:54] <CIA-74> GemRB: - opt: modified fhs, without gemrb subdirectories.
[20:35:54] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[20:36:05] <CIA-74> GemRB: 03tom.prince * r0c1931e1bb75 10gemrb/ (CMakeLists.txt gemrb/CMakeLists.txt): cmake: Change RPATH settings to be more consistent over platforms.
[20:37:02] <tomprince> Thanks. :)
[20:40:33] <CIA-74> GemRB: 03tom.prince * r33387a07ecc4 10gemrb/CMakeLists.txt: cmake: Build plugins in plugin dir, obviating the need for plugins-prepare.sh.
[20:41:40] <fuzzie> I would suggest convincing Edheldil and wjp if you really want autotools out of the tree.
[20:42:25] <tomprince> K.
[20:42:40] <tomprince> I'll run cmake exclusively for a bit, and see how things work before pushing that.
[20:45:33] <fuzzie> Linux/amd64 perhaps not being the most useful platform to test with, mind :)
[20:46:17] <tomprince> Yes. But all I have access to, other than /i686.
[20:46:46] <lynxlynxlynx> + SET( MAN_DIR ${CMAKE_INSTALL_PREFIX}/man/man6 ) <-- prefix/share/...
[20:47:51] <lynxlynxlynx> or just ${CMAKE_INSTALL_PREFIX} since it is for home
[20:48:07] <lynxlynxlynx> not like we'll have more than one
[20:48:23] <tomprince> Either of those would be fine with me.
[20:49:18] <tomprince> All I care about is the fhs, more or less. Although I actually am using the opt one locally.
[20:51:02] <tomprince> Feel free to change them.
[20:51:07] <lynxlynxlynx> i care for the fhs one as a packager/release dude, but for development i don't bother with installing
[20:51:23] <lynxlynxlynx> i will, but i'm still waiting for my gcc to recompile
[20:51:49] <lynxlynxlynx> i want to compare it to the previous one, so i shouldn't update the code
[21:05:35] <tomprince> Patch queue is emptying out nicely. Thanks fuzzie. :)
[21:15:58] <fuzzie> why is gemrb not matching Xan with [PC] :(
[21:17:58] <lynxlynxlynx> because it knows him?
[21:25:14] <-- cfchris6 has left IRC (Ping timeout: 246 seconds)
[21:27:05] --> cfchris6 has joined #GemRb
[21:29:07] <fuzzie> hum, apparently i broke it
[21:31:02] <fuzzie> deliberately, too
[21:32:21] <fuzzie> Wah.
[21:34:58] <fuzzie> I wonder if I'm missing something.. I'm looking at ttxan.bcs (Tutorial Xan), and it checks SpellCast([PC],0), but the script runs on *him*, and as far as my checking went, IDS targetting doesn't match self.
[21:40:52] <fuzzie> devSin says "specs will never target the caller", too.
[21:41:07] <fuzzie> I guess the trigger matching is probably different..
[21:42:18] <fuzzie> oh, no, we shouldn't be taking that path at all. i'm confused and tired. don't mind me.
[21:51:04] --> Nomad010 has joined #GemRb
[22:07:48] <CIA-74> GemRB: 03fuzzie * r61ceb8d132d3 10gemrb/gemrb/plugins/Core/GameScript.cpp: add some sanity checks to DecodeObject
[23:29:11] --> ratpor has joined #GemRb