#gemrb@irc.freenode.net logs for 21 May 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:03:31] <-- budlust has left #GemRb
[02:43:37] --> Gekz has joined #GemRb
[03:11:59] <Lightkey> O HAI
[03:13:25] <Lightkey> Gekz: congrats, seems like there can be another continent with a registered PP added to the list soon
[03:13:36] <Gekz> yes
[03:13:43] <Gekz> I also hate our president
[03:13:49] <Gekz> he sent out a release without clearing it with the party
[03:13:54] <Gekz> we'll likely get knocked back by the AEC
[03:14:00] <Gekz> and it'll cause embarrassment
[03:14:01] <Gekz> lol
[03:14:20] <Lightkey> oh, so he was the one you were talking about
[03:14:26] <Gekz> yes
[03:14:27] <Lightkey> knocked back?
[03:14:27] <Gekz> he's a cunt
[03:14:30] <Gekz> yeah
[03:14:35] <Lightkey> as in?
[03:14:36] <Gekz> we submit about 520 membvers
[03:14:40] <Gekz> if they check 10 of htem
[03:14:44] <Gekz> and some of them have wrong details
[03:14:46] <Gekz> or whatever
[03:14:48] <Gekz> we can get declined
[03:16:30] <Lightkey> man, reading about the different procedures to get registered around the world, I can often just shake my head
[03:16:57] <Lightkey> here you just send a letter to the federal returning officer that you eist and that's that
[03:17:07] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[03:17:29] <Lightkey> :<
[03:21:28] --> Gekz has joined #GemRb
[03:23:36] <Lightkey> I'm sorry, did I scare you?
[03:28:48] * Lightkey bitchslaps Gekz
[03:28:55] <Lightkey> DID I SCARE YOU
[03:29:36] <Gekz> no
[03:29:54] <Lightkey> oh, and I'm not really sorry either
[03:30:09] <Gekz> I dont know what you last said
[03:30:12] <Gekz> I'm in a lecture
[03:30:20] <Lightkey> eh
[03:31:11] <Lightkey> forget it then and get you share of sleep
[03:31:31] <Gekz> lolo
[03:31:42] <Lightkey> ferrari?
[03:32:01] <Lightkey> she's dead, man
[04:19:15] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[04:29:19] --> raevol has joined #GemRb
[04:51:45] <tomprince> It looks like Video::CreateSprite can be change to take a Color* instead of a void*.
[04:51:56] <tomprince> And no masks.
[05:29:40] --> Gekz has joined #GemRb
[06:11:55] <-- CIA-13 has left IRC (Ping timeout: 248 seconds)
[06:12:19] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[06:27:01] --> CIA-24 has joined #GemRb
[06:37:59] --> Gekz has joined #GemRb
[06:44:21] <-- raevol has left IRC (Quit: Leaving.)
[06:53:13] <-- |Cable| has left IRC (Remote host closed the connection)
[06:59:30] --> lynxlynxlynx has joined #GemRb
[06:59:30] --- ChanServ gives channel operator status to lynxlynxlynx
[07:56:21] <-- Gekz has left IRC (Read error: Connection reset by peer)
[07:57:09] --> Gekz has joined #GemRb
[08:12:07] <-- Gekz has left IRC (Read error: Connection reset by peer)
[08:16:21] <fuzzie> tomprince: doesn't that require the caller do byteswapping?
[08:16:57] <fuzzie> i mean, i've been ignoring all that on the basis that we can simply fix the Image class or whatever to pass masks around, but if you sabotage the backend I think you break that?
[08:19:29] --> Gekz has joined #GemRb
[10:27:50] --> Gekz_ has joined #GemRb
[10:28:51] <-- Gekz has left IRC (Ping timeout: 276 seconds)
[11:01:06] <lynxlynxlynx> ar3101 of iwd has one of those trap segfaults
[11:17:54] <CIA-24> GemRB: 03lynxlupodian * rcb3f5e98ea9c 10gemrb/gemrb/plugins/IWDOpcodes/IWDOpcodes.cpp: actually use the specified damage type in the two burning blood effects
[11:34:00] <fuzzie> trap segfaults?
[11:35:06] <lynxlynxlynx> when i was playing iwd i hit a few of these and added a hack, then avenger removed it :)
[11:35:27] <lynxlynxlynx> iirc they're missing the owner when trying to apply the effect
[11:37:04] <fuzzie> ah. meh. i thought he had a solution for that.
[11:38:40] <fuzzie> oh, *i* have a fix for that. drat.
[11:38:49] <lynxlynxlynx> i'll check it later
[11:39:35] <fuzzie> i have this mess of code which assigns global ids to all scriptables, removing all the actor-specific hacks for that, but i never found the time to work out whether it did the right thing or not
[11:42:05] <lynxlynxlynx> if you have ideas for test cases, ask the forum
[11:42:18] <lynxlynxlynx> we can direct the testers there too
[11:50:54] --> budlust has joined #GemRb
[11:55:57] <-- budlust has left IRC (Ping timeout: 276 seconds)
[11:59:52] <lynxlynxlynx> do you know how i can make an aoe spell?
[12:00:34] <lynxlynxlynx> i tried setting the projectile to one from other spells or a few choices from our override, but neither worked
[12:01:24] <lynxlynxlynx> the spell is set to target an area
[12:01:50] <lynxlynxlynx> only the caster gets hit though
[12:04:36] <lynxlynxlynx> the crash was my own fault :)
[12:08:36] <CIA-24> GemRB: 03lynxlupodian * r8285d690d31e 10gemrb/gemrb/core/Actor.cpp: don't crash on null hitter in ModifyDamage
[12:15:30] --> budlust has joined #GemRb
[12:33:01] <lynxlynxlynx> judging from the effect durations, how also has 7s rounds
[12:34:05] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[12:43:30] --> Gekz has joined #GemRb
[12:43:37] --> Gekz_ has joined #GemRb
[12:49:56] <tomprince> Don't think so.
[12:51:07] <tomprince> fuzzie: With the stuff on the image branch, the only callers to CreateSprite are ImageMgr, PLTImporter, and three in Video.cpp
[12:51:31] <fuzzie> sure, because your image branch breaks the masking, no?
[12:51:51] <fuzzie> am i thinking of the wrong thing?
[12:52:21] <fuzzie> i mean this blue_mask/green_mask/etc stuff that was removed from your branch last time i looked
[12:53:44] <tomprince> Don't think it breaks it.
[12:53:47] <fuzzie> so you require everything be in Color order, which is little-endian
[12:54:02] <fuzzie> so you break all callers which provide big-endian data
[12:54:18] <tomprince> How is it little endian?
[12:54:51] <fuzzie> you manually construct it all now?
[12:55:08] <tomprince> It is only little endian if you think of a pixel as being a single integer, rather than 4 separate bytes.
[12:55:40] <fuzzie> which PNG and SDL do.
[12:56:11] <fuzzie> because that's how they're decoded and come out of video memory, respectively.
[12:56:44] <fuzzie> and, indeed, that's why the masks in the first place: because you're handing integers to SDL.
[12:57:53] <fuzzie> i mean, i haven't really thought about this, perhaps i'm missing something
[12:58:19] <tomprince> Well, I was planning to generate the masks like I do right now in image, but in SDLVideo instead.
[12:58:39] <fuzzie> sure, but then you require everything always be in Color format, which is little-endian integers.
[12:58:47] <fuzzie> unless i am missing something.
[12:59:28] <tomprince> Or, 4 consecutive bytes.
[12:59:46] <fuzzie> yes, but then you're requiring byte-swapping.
[13:01:33] <fuzzie> and you force future big-endian backends into byteswapping everything internally, too
[13:02:02] <fuzzie> i mean, i see it's a horrible situation, because you'd rather ignore the fact that you're passing integers to SDL, but that is what you're doing :)
[13:13:28] <tomprince> Looking at the code for libpng, it actually treats pixels a sequence of bytes, so the current code is probably actually broken on big-endian there.
[13:15:02] <tomprince> So really, as far as I can tell, the only place that treats pixels as a single int is in SDL, so why not hide all that knowledge there.
[13:17:12] <fuzzie> well
[13:17:27] <fuzzie> i guess it depends on whether you think there will be any serious number of 32bpp images in use.
[13:17:49] <tomprince> ?
[13:17:55] <fuzzie> well, byteswapping is slow
[13:18:26] <fuzzie> and you disable any hardware acceleration this way
[13:19:29] <fuzzie> but afaik anything which is re-rendered every frame is paletted anyway?
[13:20:47] <fuzzie> so it's just the CreateLight which would seem to matter
[13:21:07] <fuzzie> and we could move that back inside SDL.
[13:21:51] <tomprince> Any reason why CreateLight couldn't be done in terms of Color, rather than int?
[13:22:19] <fuzzie> i mean, CreateLight is the only thing which might be a performance issue.
[13:23:00] <fuzzie> the other calls seem to be for things like screenshots/etc.
[13:24:14] <fuzzie> i mean, i guess we could do something completely ridiculous like byte-swap it when created and then byte-swap again inside CreateSprite
[13:24:55] <fuzzie> oh, right, you could indeed do the first bit using Color trivially
[13:25:22] <fuzzie> having to do this inside every backend seems a trifle ridiculous, but *shrug*
[13:26:20] <fuzzie> it also means a huge potential future performance mess with things like TIZImporter, but i don't care about that :)
[13:28:13] <tomprince> I am not entirely sure why there should be any performance hit.
[13:28:26] <fuzzie> because this stuff has to be byte-swapped *somewhere*.
[13:28:38] <tomprince> Why?
[13:28:49] <fuzzie> because drivers/hardware/etc take this stuff in their native endianism.
[13:29:35] <fuzzie> if you want to hand it to opengl, for example.
[13:30:14] <fuzzie> and you can hand SDL any masks you want, but none of the accelerated paths get taken if it's not one supported by the driver.
[13:30:24] <fuzzie> to be honest i'm not sure our code is going to take any accelerated SDL paths anyway, though.
[13:31:11] <fuzzie> (and, yes, some desktop hardware will cope with textures in both endianisms, but even for the latest desktop hardware, not all)
[13:35:09] <fuzzie> huh, maybe little-endian is the format which desktop hw is still flaky with? i forget
[13:35:51] <fuzzie> that seems kinda unlikely, i shall stop reading google results and go get some wor kdone
[14:16:16] --> barra_library has joined #GemRb
[14:43:23] --> raevol has joined #GemRb
[14:49:04] <CIA-24> GemRB: 03lynxlupodian * rf0f992e34873 10gemrb/gemrb/GUIScripts/ (4 files in 4 dirs): added sounds for turning on modal actions
[14:54:46] <tomprince> I think I understand the possible performance issue. But, if it is an issue, then the current code already suffers from it. Since we do lay everything out as RGBA in memory, regardless of endianness.
[14:55:49] <fuzzie> we don't.
[14:56:10] <tomprince> No?
[14:56:25] <fuzzie> i mean, is there any existing 32bpp code which matters at all for performance, except CreateLight?
[14:56:39] <tomprince> Then why do we have different masks for le/be?
[14:56:47] <fuzzie> but that *doesn't* lay things out as RGBA.
[14:56:57] <fuzzie> right?
[14:58:00] <fuzzie> i mean, your point is "gemrb doesn't use 32bpp images much, so it doesn't matter", and my point is "sure, and you're making sure that i'm going to want it to stay that way".
[14:58:32] <fuzzie> but since in the recent past you're expressed a desire to use more 32bpp images..
[15:00:30] <fuzzie> you're also removing the possibility for 24bpp images in your design, so that would also be an issue there
[15:05:18] <tomprince> Well, mostly I am trying to avoid calling into SDL to generate Bitmap/Images in ImageMgr.
[15:08:11] <tomprince> As you suggested, which I think is a good idea.
[15:08:26] <tomprince> I am not at all tied to the design that I have right now in the image branch.
[15:09:16] <fuzzie> it is difficult
[15:09:39] <fuzzie> i can sympathise with the desire to just make everything a Color* in an Image
[15:11:55] <tomprince> Well, we could have a structure that has the fields in the right byte-order, and use that.
[15:13:02] <tomprince> I think it would have to be distinct from color, because palettes are expected in RGBA always? It seems.
[15:18:13] <-- raevol has left IRC (Quit: Leaving.)
[15:20:31] <tomprince> Mostly, it is my ignorance, since it hadn't occured to me that byteorder would be a performance issue.
[15:27:05] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[15:27:19] <-- Gekz has left IRC (Quit: Leaving)
[15:30:21] --> Gekz_ has joined #GemRb
[15:31:17] <fuzzie> well, there's also the fact that, given the ps3 shutting off linux support, the wii might be the only big-endian platform with more than a single person wanting to run gemrb on it
[15:31:36] <Gekz_> pwned.
[15:32:15] <fuzzie> i'm pretty sure it's all little-endian arm targets
[15:32:34] <fuzzie> given it's just not viable to run gemrb on the older stuff
[15:34:43] <tomprince> There was a similiar comment on the llvm irc about big-endian machines going away.
[15:35:03] <fuzzie> well, for desktop machines :)
[15:36:13] <fuzzie> makes you wonder what all the next-generation consoles will end up using
[15:36:46] <tomprince> Although, I think the code I was contemplating would hit the fast path on bigendian not little endian machines, the opposite of what we have now.
[15:37:01] <fuzzie> probably not optimal :-)
[15:37:18] <fuzzie> the most performance-sensitive targets are the little-endian ARM devices with <256mb RAM, i think
[15:37:31] <tomprince> Maybe? I am not sure. I am not particularly familiar with this stuff. Just from my reading this morning.
[15:38:01] <fuzzie> today is unfortunately not the best day for me to look at it :(
[15:38:51] <Gekz_> hmm
[15:38:56] <Gekz_> do any of you have a wii to test this on?
[15:39:31] <fuzzie> i got it to start on one
[15:39:54] <fuzzie> but unfortunately the fuzzie budget does not reach to having one of my own
[15:55:42] --> Gekz has joined #GemRb
[15:56:43] <-- Gekz_ has left IRC (Ping timeout: 260 seconds)
[15:57:18] <-- budlust has left IRC (Ping timeout: 260 seconds)
[16:19:51] <-- barra_library has left IRC (Read error: Connection reset by peer)
[16:30:11] <-- Gekz has left IRC (Quit: Leaving)
[17:49:27] --> barraAway has joined #GemRb
[17:49:49] <CIA-24> GemRB: 03tom.prince * r7f1938e066ce 10gemrb/gemrb/core/ (SaveGameIterator.cpp SaveGameIterator.h):
[17:49:49] <CIA-24> GemRB: SaveGame: constification.
[17:49:49] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[17:49:52] <CIA-24> GemRB: 03tom.prince * rf3c4e04eb58d 10gemrb/gemrb/core/ (Plugin.h TypeID.h):
[17:49:52] <CIA-24> GemRB: TypeID: Move it to its own header.
[17:49:52] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[17:49:54] <CIA-24> GemRB: 03tom.prince * rdef29c5c56cc 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp:
[17:49:54] <CIA-24> GemRB: GUIScirpt: Use FreeSprite instead of decrementing RefCount directly.
[17:49:54] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[17:49:57] <CIA-24> GemRB: 03tom.prince * r249e60239a70 10gemrb/gemrb/ (3 files in 2 dirs):
[17:49:57] <CIA-24> GemRB: SaveGame: Rename GetScreen to GetPreview to match python naming.
[17:49:57] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[17:52:31] <lynxlynxlynx> - manager.AddSource(path, Name, PLUGIN_RESOURCE_DIRECTORY);
[17:52:33] <lynxlynxlynx> + manager.AddSource(Path, Name, PLUGIN_RESOURCE_DIRECTORY);
[17:52:38] <lynxlynxlynx> this was a bug before?
[17:56:09] <tomprince> Don't think so. Actually, looking at it further. I could probably have just propagted the const to ResourceManager.
[17:56:29] <tomprince> I had just remembered that it originally modified it. But it doesn't now.
[17:58:57] <CIA-24> GemRB: 03tom.prince * r1a61d090f109 10gemrb/gemrb/core/ (ResourceManager.cpp ResourceManager.h):
[17:58:57] <CIA-24> GemRB: ResourceManager: Add a const.
[17:58:57] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:02:54] <CIA-24> GemRB: 03tom.prince * r13124f45fa98 10gemrb/gemrb/core/ (7 files):
[18:02:54] <CIA-24> GemRB: Sprite2D: Add an acquire method to increase RefCount.
[18:02:54] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[18:04:14] --> budlust has joined #GemRb
[18:19:52] --> cubathy has joined #GemRb
[18:48:53] --> |Cable| has joined #GemRb
[19:01:56] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[19:29:42] --> cubathy has joined #GemRb
[19:56:02] --> cubathy_ has joined #GemRb
[19:56:07] --> kettuz has joined #GemRb
[19:56:18] <-- cubathy has left IRC (Read error: Connection reset by peer)
[19:56:48] <-- budlust has left IRC (Ping timeout: 252 seconds)
[19:59:13] --> cubathy has joined #GemRb
[19:59:38] <-- cubathy_ has left IRC (Read error: Connection reset by peer)
[20:09:47] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[20:50:47] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[20:56:55] <-- kettuz has left IRC (Quit: Leaving)
[21:36:04] <-- barraAway has left IRC (Ping timeout: 272 seconds)
[21:37:11] --> barraAway has joined #GemRb
[21:42:03] <-- barraAway has left IRC (Ping timeout: 248 seconds)
[21:53:38] --> barraAway has joined #GemRb
[22:04:08] --> budlust has joined #GemRb
[23:48:52] <-- barraAway has left IRC (Quit: Verlassend)