#gemrb@irc.freenode.net logs for 24 Jun 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:11:24] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[01:44:03] --> brad_a has joined #gemrb
[03:18:04] <-- brad_a has left IRC (Read error: Connection reset by peer)
[03:18:04] --> brad_a_ has joined #gemrb
[03:43:47] <-- Drakkar has left IRC (Quit: The beer is meal.)
[03:54:30] <-- brad_a_ has left IRC (Quit: brad_a_)
[03:55:53] --> brad_a has joined #gemrb
[04:48:12] <-- brad_a has left IRC (Quit: brad_a)
[05:16:08] --> Drakkar has joined #gemrb
[06:40:44] <-- Drakkar has left IRC (Quit: The beer is meal.)
[07:06:50] --> lynxlynxlynx has joined #gemrb
[07:06:50] --- ChanServ gives channel operator status to lynxlynxlynx
[07:19:41] --> Drakkar has joined #gemrb
[07:20:43] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[07:31:07] --> adominguez has joined #gemrb
[08:14:56] --> lynxlynxlynx has joined #gemrb
[08:14:56] <-- lynxlynxlynx has left IRC (Changing host)
[08:14:56] --> lynxlynxlynx has joined #gemrb
[08:14:56] --- ChanServ gives channel operator status to lynxlynxlynx
[08:15:15] --> barra_home has joined #gemrb
[08:59:18] <-- |Cable| has left IRC (Remote host closed the connection)
[10:16:49] --> Maighstir has joined #gemrb
[10:52:42] <-- lynxlynxlynx has left IRC (Ping timeout: 240 seconds)
[10:59:37] <-- raevol has left IRC (Quit: Leaving.)
[11:26:30] --> SiENcE has joined #gemrb
[11:34:15] --> lynxlynxlynx has joined #gemrb
[11:34:15] <-- lynxlynxlynx has left IRC (Changing host)
[11:34:15] --> lynxlynxlynx has joined #gemrb
[11:34:15] --- ChanServ gives channel operator status to lynxlynxlynx
[12:22:46] <-- adominguez has left IRC (Quit: Saliendo)
[13:31:03] <-- lynxlynxlynx has left IRC (Ping timeout: 240 seconds)
[13:36:37] --> lynxlynxlynx has joined #gemrb
[13:36:38] <-- lynxlynxlynx has left IRC (Changing host)
[13:36:38] --> lynxlynxlynx has joined #gemrb
[13:36:38] --- ChanServ gives channel operator status to lynxlynxlynx
[13:57:18] --> |Cable| has joined #gemrb
[15:01:24] --> brad_a has joined #gemrb
[15:14:33] <brad_a> so just FYI updating python from 2.7 to 2.7.2 DID actually fix the iOS spellbook crash.
[15:15:46] <lynxlynxlynx> did you try with a release build yet?
[15:17:22] <brad_a> hmm no i havent
[15:17:33] <brad_a> you think that somehow could be the cause?
[15:27:01] <brad_a> a release build in the simulator works fine not that that means much
[15:27:33] <-- |Cable| has left IRC (Remote host closed the connection)
[15:29:15] --> |Cable| has joined #gemrb
[15:32:24] <-- lubos has left IRC (Quit: Leaving.)
[15:48:01] --> Cable_ has joined #gemrb
[15:48:01] <-- |Cable| has left IRC (Read error: Connection reset by peer)
[15:49:35] --> budlust has joined #gemrb
[16:00:02] <-- SiENcE has left IRC (Quit: @all: cya)
[16:02:03] <-- budlust has left IRC (Quit: Lost terminal)
[16:17:27] <lynxlynxlynx> it could - it has before
[17:04:04] <brad_a> figured out the unknown pixel format error SDL 1.3 throws when using rgba masks
[17:04:19] <fuzzie> it only supports them in one order?
[17:04:33] <brad_a> the problem is we are passing an alpha mask of 0 instead of 0x000000FF
[17:04:46] <fuzzie> oh, that would *not* be using rgba masks, surely :P
[17:04:58] <brad_a> exactly
[17:05:01] <fuzzie> if you look at the SDL HG source then it does cope with an alpha mask of 0
[17:05:12] <brad_a> sdl 1.3 does not
[17:05:14] <fuzzie> but only if you specify the red/green/blue masks in exactly the right way
[17:05:42] <brad_a> so hopefully i can now fix this blue sprite business
[17:05:59] <fuzzie> but since alpha is really slow, adding an alpha mask is not much of a solution
[17:06:44] <brad_a> :(
[17:06:47] <fuzzie> although if it's the only option you find, can always #ifdef it
[17:06:53] <fuzzie> go try!
[17:06:54] <brad_a> sure
[17:10:40] <brad_a> lol it does indeed fix the blue paper doll but changing all the 0 amasks to 0x000000FF breaks many other things. so ill have to find the specific call to createsprite that is responsible for the paper doll
[17:11:39] <brad_a> time to load up gdb...
[17:11:55] <fuzzie> bg2? PLT maybe?
[17:12:03] <brad_a> what?
[17:12:13] <brad_a> yes bgs but i dont know what plt is
[17:12:15] <lynxlynxlynx> pallete
[17:12:17] <brad_a> bg2
[17:12:19] <brad_a> oh
[17:12:24] <fuzzie> PLTImporter/PLTImporter.cpp
[17:13:09] <brad_a> MOSImporter::GetSprite2D is where the call comes from
[17:13:31] <fuzzie> oh, that is spectacularly inconvenient
[17:13:36] <brad_a> ill bet
[17:13:47] <fuzzie> i mean, it isn't
[17:14:18] <fuzzie> just change the "*startpixel = RevCol[*bp].a;" line in MOSImporter.cpp to "*startpixel = 0;" or 255 depending on which alpha is the one you want, i guess?
[17:14:20] <brad_a> oh nevermind i think you were right
[17:14:39] <fuzzie> oh well I'll leave you to it for now then :)
[17:14:42] <brad_a> the doll is about 128x160 px right
[17:17:36] <lynxlynxlynx> yes, if that was a question
[17:18:50] <brad_a> yes :P
[17:19:23] <brad_a> success! [:)
[17:19:37] <brad_a> feels a bit hacky tho...
[17:22:53] <lynxlynxlynx> it seems we're not missing effects, something just goes wrong somewhere
[17:23:20] <lynxlynxlynx> bisecting lead me to ca18cbf6d8792fdc1a034e9514f2689ad9bb0a44
[17:23:45] <lynxlynxlynx> reverting that fixes it, but the queues are the same in both anyway
[17:23:48] <fuzzie> what's missing?
[17:24:03] <lynxlynxlynx> the bounce overlay
[17:24:34] <lynxlynxlynx> the actor does have IE_BOUNCE set to 1, but handle_overlay never got called
[17:24:39] <fuzzie> for items?
[17:24:45] <lynxlynxlynx> yes, cloak of reflection
[17:26:42] <lynxlynxlynx> the pcf gets called only on unequip, not when equipping
[17:26:46] <fuzzie> yes
[17:26:48] <fuzzie> it must be pcf issue
[17:26:53] <lynxlynxlynx> there's some shortcut somewhere
[17:27:00] <fuzzie> maybe this is being called from inside the fxqueue?
[17:27:56] <lynxlynxlynx> i tried changing the selftarget check, so these would be handled by the other branch, but it had no effect
[17:28:20] <fuzzie> huh, it should really work if you add it to the fxqueue :-/
[17:28:21] <lynxlynxlynx> on load, the pcf was called before the equipment was on
[17:28:37] <lynxlynxlynx> so it was 0 vs 0, then 1 vs 0 on unequip
[17:28:44] <lynxlynxlynx> old vs new
[17:28:53] <fuzzie> i mean, the SourceFlags changed too in that commit, but then it'd never get applied at all, right?
[17:29:08] <lynxlynxlynx> i'll retry, i hope i didn't forget to recompile ;)
[17:30:30] <lynxlynxlynx> nope, but let me try something silly
[17:31:21] <lynxlynxlynx> yes, always adding to the queue works
[17:31:33] <lynxlynxlynx> for some reason fx->Duration == FX_DURATION_INSTANT_WHILE_EQUIPPED was false :s
[17:32:28] <fuzzie> well i forget how this works, but this is applying an effect *without* going via the actor code
[17:32:47] <fuzzie> so you miss the opportunity for a PCF call from the actor code
[17:33:07] <lynxlynxlynx> should it be more like in spell, with a selfqueue?
[17:34:05] <fuzzie> afaik that still does ApplyEffectQueue which means it's still avoiding the actor PCF call..
[17:34:40] <fuzzie> the IE_BOUNCE is set with STAT_BIT_OR which disables the internal PCF calls
[17:34:52] <fuzzie> STAT_BIT_OR_PCF will do an internal PCF call
[17:34:55] <lynxlynxlynx> it does, yes, just checked
[17:35:09] <fuzzie> i don't understand why we avoid internal calls by default though
[17:35:33] <fuzzie> well, i guess because you can have both an enable+disable in the same effect queue, but clearly that doesn't work properly
[17:35:41] <lynxlynxlynx> nice catch
[17:38:29] <fuzzie> sometimes i can't believe i can keep all this stuff in my head
[17:40:25] <brad_a> no kidding!
[17:41:24] <fuzzie> i can't see any obvious harm in changing it..
[17:42:24] <fuzzie> although, looking, handle_overlay is trying to handle INVIS too, and i guess that is not going to pay attention to state changes
[17:48:41] <lynxlynxlynx> mnja
[17:49:20] <lynxlynxlynx> would be messy to call all these pcfs manually just for that
[17:52:07] <lynxlynxlynx> i guess it should all be in Draw anyway
[17:59:59] <brad_a> you may have been right about the debug vs release build thing.
[18:00:38] <brad_a> but it is a python related crash
[18:08:39] <brad_a> PyObject_CallObject in pythonhelpers.cpp is the last call in gemrb before crashing later on in the python lib
[19:05:47] <brad_a> so heres an odd one
[19:06:47] <brad_a> the main surface setup fails when [passing the non 0 masks but the error sdl give isnt the "invalid pixel format" junk its an invalid window error
[19:07:00] <brad_a> how would the masks make any diffrence in the window
[19:07:48] <brad_a> or maybe it isnt actually failing and that error is from something else
[19:11:12] <brad_a> is there a reason we cant use 0s here instead?
[19:52:26] <CIA-40> GemRB: 03lynxlupodian * r54f516686f27 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp:
[19:52:26] <CIA-40> GemRB: run the pcf for bounce effects or the underlay doesn't get shown
[19:52:26] <CIA-40> GemRB: broken since ca18cbf6d8792fdc1a034e9514f2689ad9bb0a44
[19:53:41] <-- brad_a has left IRC (Read error: Operation timed out)
[20:00:12] --> brad_a has joined #gemrb
[20:54:01] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:23:21] <-- Drakkar has left IRC (Quit: The beer is meal.)
[22:57:06] <-- brad_a has left IRC (Quit: brad_a)
[23:19:06] --> brad_a has joined #gemrb
[23:36:04] --> Drakkar has joined #gemrb
[23:42:22] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)