[00:01:10] --> duckpunch has joined #gemrb
[00:57:36] <-- duckpunch has left IRC (Quit: Lost terminal)
[03:28:19] <-- nutron has left IRC (Quit: I must go eat my cheese!)
[04:21:16] --> edheldil_ has joined #gemrb
[04:45:47] <-- edheldil_ has left IRC (Ping timeout: 260 seconds)
[07:15:10] --> lynxlynxlynx has joined #gemrb
[07:15:10] <-- lynxlynxlynx has left IRC (Changing host)
[07:15:10] --> lynxlynxlynx has joined #gemrb
[07:15:10] --- ChanServ gives channel operator status to lynxlynxlynx
[07:31:54] --> edheldil has joined #gemrb
[07:31:54] --- ChanServ gives channel operator status to edheldil
[07:34:28] --> WingedHussar has joined #gemrb
[08:29:36] <-- fuzzie has left IRC (Read error: Operation timed out)
[08:30:33] --> fuzzie has joined #gemrb
[08:59:06] <-- DrMcCoy has left IRC (Ping timeout: 256 seconds)
[11:04:58] <-- PixelScum has left IRC (Read error: Connection reset by peer)
[11:06:00] --> Drakkar has joined #gemrb
[11:24:56] --> DrMcCoy has joined #gemrb
[11:29:14] --- ermo^ is now known as ermo
[14:06:56] --> brada has joined #gemrb
[14:07:07] <brada> is anybody opposed to this: http://paste.debian.net/10373/
[14:07:08] <Pepelka> debian Pastezone
[14:12:07] <wjp> it has superfluous ()'s, but otherwise it seems sensible
[14:15:43] <brada> thats just the style i prefer :p
[14:16:24] <brada> i like comparisons inside ()
[14:16:56] <wjp> it looks weird
[14:17:51] <brada> i shall remove im not married to them
[14:20:23] <fuzzie> it's not used anywhere performance-sensitive except the silly CreateAlpha code, right?
[14:21:42] <brada> not that i know of
[14:21:46] <brada> but i didnt profile it
[14:21:51] <fuzzie> looks like only in Button::IsPixelTrasparent otherwise, so should be fine
[14:22:44] <fuzzie> although to ask the obvious question, does it actually work?
[14:22:55] <brada> as far as i can tell
[14:22:58] <wjp> it looks ok
[14:23:02] <fuzzie> since it looks incorrect for the non-BAM case
[14:23:07] <wjp> it does?
[14:23:09] <brada> how?
[14:23:10] * wjp looks again
[14:23:29] <brada> return core->GetVideoDriver()->GetPixel(vptr, x, y)==0;
[14:23:32] <wjp> ah, hrm
[14:23:46] <fuzzie> brada: but your new code checks alpha instead
[14:24:02] <brada> and thats not good enough?
[14:24:07] <fuzzie> no, because alpha won't be set
[14:24:21] <fuzzie> so you'll always get 0xff in that component
[14:25:49] <fuzzie> I'm not sure the existing code works either though
[14:26:40] <fuzzie> since the colour keys are always green, no?
[14:26:45] <brada> afik
[14:27:06] <brada> running some tests
[14:27:48] <wjp> I wonder if it's ever used for non-BAM at all
[14:27:50] <fuzzie> so it would break only in the GetFrameInternal case which returns a non-BAM sprite from a BAM
[14:28:18] <fuzzie> and that's only used for the animation factories
[14:28:38] <fuzzie> i mean, by that code
[14:28:52] <fuzzie> so I think it's not actually used for non-BAM sprites in the existing code.
[14:29:06] <brada> well this is all for simpifying my refactor
[14:29:17] <brada> and after that it ought to not be broken i suppose :p
[14:29:25] <wjp> which refactor is that?
[14:29:32] <brada> the sprite subclasses
[14:29:35] <fuzzie> well, you really don't want to add alpha
[14:29:37] <brada> bamsprite
[14:29:39] <fuzzie> to sprites which don't need it
[14:29:43] <brada> sdlsurfacesprite
[14:29:50] <brada> sdltexturesprite
[14:31:02] <fuzzie> but it seems clearly incorrect for the non-BAM-sprite case right now, so it's harmless refactor as long as you keep the BAM GetPixel or equivalent w/alpha I guess
[14:32:17] <brada> ill just commit this to my dev branch and we can examine the final result
[14:32:28] <brada> when im done
[14:32:37] <fuzzie> it seems fine to commit to master
[14:32:48] <brada> ok
[14:32:59] <fuzzie> i guess you're kind of stuffed here
[14:33:15] <fuzzie> since you can't GetPixel on an opengl texture without it being horrible performance doom anyway
[14:35:13] <fuzzie> so it's just as well that code isn't used anywhere performance-sensitive :)
[14:36:23] <brada> it certainly doesnt seem to get called for non-bam currently
[14:36:36] <fuzzie> conveniently, after tomprince's Image refactor, there's very few Sprite2D::GetPixel calls anyway
[14:37:18] <brada> good
[14:37:51] <brada> one step at a time anyway :p
[14:37:56] <fuzzie> yes I'm just thinking
[14:38:51] <brada> always a good thing
[14:39:30] <brada> ill at least add a note about not working for non-bam
[15:12:07] <-- WingedHussar has left IRC (Quit: WingedHussar)
[15:47:35] <-- GoGi has left IRC (*.net *.split)
[15:52:37] --> GoGi_ has joined #gemrb
[16:05:55] --> vampi-the-frog has joined #gemrb
[16:29:50] <brada> psch: does the android build have iconv support?
[16:35:45] --> fizzle has joined #gemrb
[17:39:58] <fizzle> hi fuzzy
[17:40:06] <fizzle> hi fuzzie
[17:40:10] <fizzle> :P
[17:40:15] <fizzle> is it tomorrow yet?
[17:48:27] <-- lynxlynxlynx has left IRC (Ping timeout: 252 seconds)
[17:57:52] <fuzzie> not at all
[18:00:30] <fizzle> hm
[18:00:57] <fizzle> you're no longer sleeping, though, so any bright new ideas?
[18:02:09] <fuzzie> no, haven't looked at annoying bits further, but I can answer questions about jaheira thing I assume
[18:03:24] <fizzle> ok
[18:03:58] <fizzle> I've changed the code so the intitial state is only calculated once
[18:04:15] <fizzle> seems to fix that particular scene as well
[18:04:37] <fizzle> you mentioned that the action wipes the action queue right away, too, though
[18:05:11] <fizzle> but that would seem to break Dialogue() SetGlobal(), wouldn't it?
[18:06:17] <fuzzie> no
[18:06:56] <fuzzie> the first time DialogChoose runs (with a new speaker), it wipes the action queue
[18:07:11] <fizzle> so not the action itself, then
[18:07:13] <fuzzie> no :)
[18:07:27] <fuzzie> let me check the detail
[18:07:29] <fizzle> alright, no more questions regarding this one, then
[18:18:22] <fuzzie> ok, i have no clue at a glance where the queue clear is
[18:21:21] <fizzle> would this look about right for what we discussed, though: http://paste.debian.net/hidden/009d9b2b/
[18:21:22] <Pepelka> Debian Pastezone
[18:24:53] <fuzzie> well, that doesn't fix the state thing?
[18:25:21] <fuzzie> also there should be a TODO about how it should also happen on switching speakers, I guess..
[18:25:44] <fizzle> yes, the state fix is a different commit
[18:28:07] <fizzle> doesn't switching speakers start a new dialog?
[18:29:38] <fuzzie> no
[18:30:49] --> edheldil_ has joined #gemrb
[18:33:43] <-- edheldil_ has left IRC (Read error: Connection reset by peer)
[18:40:20] <fizzle> you may remember I still had a number three item on my list
[18:40:28] <fizzle> this is it: http://paste.debian.net/hidden/8bb9601f/
[18:40:29] <Pepelka> Debian Pastezone
[18:46:40] --> kingron has joined #gemrb
[18:49:46] --> Yoshimo has joined #gemrb
[19:08:53] <brada> i assume we want to avoid copying bam pixel data around...
[19:09:26] <brada> it seems somebody went to great lengths to avoid it anyway
[19:12:52] <brada> specifically im referring to DuplicateSprite, MirrorSpriteHorizontal, and MirrorSpriteVertical
[19:15:15] <brada> totally not a problem so i dont know why im talking :p
[19:25:03] <fuzzie> well, you don't mean copying it around, you mean making extra long-lived copies, right?
[19:26:07] <fuzzie> it should be pretty harmless to just memcpy or whatever if that's helpful
[19:30:02] <brada> well i mean i figure there is a reason to do the flipping logic at blit time rather than at "copy" time. i assume its because you are sharing pixel data with multiple sprite objects
[19:35:28] <brada> its fine anyway. that is how the SDL2 renderer will behave anyway
[19:35:54] <brada> using SDL_RenderCopyEx
[19:39:38] <fuzzie> you can't do the BAM sprite using SDL2, though, can you? I thought it didn't support shading
[19:40:58] <brada> i wasnt talking about using BAM with SDL2 i meant i think its fine to add a renderFlags field to the sprite base class
[19:41:07] <fuzzie> ah okay
[19:41:46] <brada> but yes the SDL2 renderer will return false for supporting BAMs
[19:41:47] <fuzzie> just obviously for the non-BAM non-SDL2 case you do have to make the copy :)
[19:42:03] <brada> sure
[19:43:57] <wjp> doing flipping at blit time is quite possibly easier than flipping the RLE data too
[19:43:59] <fuzzie> but, sorry, yes, it's sharing pixel data.
[19:44:27] <fuzzie> and, yes, that :)
[19:44:46] <fuzzie> but indeed you can avoid the whole thing if you just reject the RLE data immediately
[19:44:56] <fuzzie> just that's not going to be much fun
[19:45:17] <fuzzie> since you'll waste a lot of RAM that way, I guess
[19:45:24] <brada> yeah
[19:45:27] <brada> but oh well
[19:45:48] <fuzzie> might want to work out how much..
[19:46:57] <brada> i should be able to just compare current usage with disabling bam support on the video driver, no?
[19:47:20] <fuzzie> yes, if you'll keep them paletted only
[19:48:52] <fuzzie> my massif log has a typical game load as being <10mb of BAM so probably it's not a big deal
[19:48:54] <brada> it calls CreateSprite8 if bams arent supported
[19:49:23] <brada> there is only one use of SupportsBAMSprites
[19:49:45] <fuzzie> oh, maybe slightly above 10mb. anyway that kind of range.
[19:50:24] <brada> im not too worried about it
[19:50:55] <fuzzie> much much worse is TIS.
[19:51:18] <brada> exactly
[19:51:26] <brada> er i thought it was MOS
[19:52:01] <fuzzie> no
[19:52:19] <fuzzie> I mean, MOS is using silly amounts of RAM (like 10mb) but that's just because our loader is doing the worst-case naive loading.
[19:52:44] <fuzzie> It takes a paletted 8bpp file format and expands it to 32bpp.
[19:52:56] <fuzzie> probably you can't possibly make that worse, so :)
[19:53:09] <brada> challenge accepted :p
[19:53:31] <fuzzie> but TIS just uses huge amounts of RAM because the TIS files are huge
[19:55:24] <fuzzie> if you expand it to 32bpp then I guess you could end up needing 200mb there
[19:55:26] <fuzzie> so, fun!
[19:55:34] <brada> yuck
[19:57:30] <fuzzie> if it's a problem then bug me, we had some thoughts about smart caching in the past
[19:59:22] <fuzzie> but honestly I will be super impressed (again) if you just get some prototype working
[20:01:20] <brada> so far so good. still have my confidence anyway :D
[20:02:41] <brada> tho i did break soething :/
[20:04:42] <brada> i remember you saying the same thing about TTF fonts too ;)
[20:27:28] <fizzle> fuzzie: any comments on the MultiPlayerSync patch?
[20:27:58] <-- vampi-the-frog has left IRC (Quit: Leaving)
[20:28:04] <-- kingron has left IRC (Remote host closed the connection)
[20:39:14] --> nutron has joined #gemrb
[20:48:29] <brada> is there no way to call a derrived class copy constructor when working strictly with baseclass pointers?
[20:48:52] <brada> i ended up writing a copy method… seems hacky
[20:54:14] <brada> the only answers on stack overflow seem to agree with my aproach
[20:54:25] <brada> id like to think maybe in c++11
[21:01:05] <Lightkey> reminds me, the Debian changelog to gcc 4.8.1 said, it now has all major C++11 features
[21:30:27] <-- Yoshimo has left IRC (Quit: Yoshimo)
[21:49:18] --> lynxlynxlynx has joined #gemrb
[21:49:18] <-- lynxlynxlynx has left IRC (Changing host)
[21:49:18] --> lynxlynxlynx has joined #gemrb
[21:49:18] --- ChanServ gives channel operator status to lynxlynxlynx
[21:59:09] <lynxlynxlynx> fizzle: looks fine to me, at worst i think it could break some cases with instants
[21:59:19] <lynxlynxlynx> but it's not really my area at all
[22:07:33] <fizzle> lynx: got a question for you too
[22:07:55] <fuzzie> i didn't see a patch
[22:08:41] <fizzle> fuzzie: couple of lines after the first one
[22:09:07] <fizzle> lynx: where do the values in dmgtypes.2da come from?
[22:09:09] <fuzzie> oh in the middle
[22:09:21] <fuzzie> patch looks fine
[22:09:24] <fuzzie> no idea what original does
[22:09:28] <lynxlynxlynx> depends on the column
[22:09:37] <fizzle> and shouldn't they match dmgtype.ids?
[22:09:59] <fizzle> the VALUE
[22:10:22] <fizzle> I get "Unhandled damagetype" errors because they don't match
[22:10:57] <lynxlynxlynx> which one doesn't match?
[22:11:05] <lynxlynxlynx> they're from the effect description
[22:11:17] <fizzle> all of them except crushing which is 0
[22:11:36] <lynxlynxlynx> huh
[22:11:37] <fizzle> all the values are shifted in the ids
[22:11:48] <lynxlynxlynx> which codepath is this?
[22:11:53] --- ermo is now known as ermo^
[22:12:04] <fizzle> ApplyDamage()
[22:12:17] <lynxlynxlynx> an action?
[22:12:21] <fizzle> yes
[22:13:17] <lynxlynxlynx> i guess the system needs to change then
[22:13:25] <lynxlynxlynx> i added it all purely for combat
[22:13:45] <-- nutron has left IRC (Quit: I must go eat my cheese!)
[22:14:49] <lynxlynxlynx> shouldn't be much of a change, we use shifted values too, since you can't detect 0 easily otherwise
[22:22:43] --> nutron has joined #gemrb
[22:25:19] <lynxlynxlynx> 8+14 uses in total, no wonder nobody noticed it yet
[22:25:56] <lynxlynxlynx> most from watcher's keep
[22:26:15] <fizzle> translation looks fairly simple, just mask out the lowermost bits
[22:28:44] <lynxlynxlynx> g'night
[22:28:55] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:28:55] <fizzle> gn
[23:30:34] <-- Coriander has left IRC (Read error: Connection reset by peer)
[23:37:39] <-- fizzle has left #gemrb