[00:53:06] --> brada has joined #gemrb
[01:24:38] <-- raevol has left IRC (Quit: Leaving.)
[01:56:16] <-- brada has left IRC (Quit: brada)
[01:58:25] --> brada has joined #gemrb
[01:58:25] <-- brada has left IRC (Client Quit)
[02:20:35] --> brada has joined #gemrb
[03:10:29] <-- brada has left IRC (Quit: brada)
[03:42:30] --> brada has joined #gemrb
[04:49:16] <-- brada has left IRC (Quit: brada)
[05:17:29] --> Eli2_ has joined #gemrb
[05:20:11] <-- Eli2 has left IRC (Ping timeout: 245 seconds)
[07:10:06] --> lynxlynxlynx has joined #gemrb
[07:10:06] --- ChanServ gives channel operator status to lynxlynxlynx
[09:31:46] --> Yoshimo has joined #gemrb
[09:56:48] <-- Yoshimo has left IRC (Ping timeout: 246 seconds)
[10:16:43] <-- Coriander has left IRC (Quit: Nettalk6 - www.ntalk.de)
[10:17:57] --> Coriander has joined #gemrb
[11:08:12] <edheldil> I have found out that gemrb handles BAM transparency wrong
[11:18:55] <lynxlynxlynx> in what way?
[11:20:13] <edheldil> I think gemrb is confusing transparent color index and compressed color index
[11:20:46] <edheldil> so some cursors I created in bam_composer have green bg in gemrb, but work in the original engine
[11:21:08] <edheldil> work=don't have that bg
[11:23:37] <edheldil> although, strangely, when ps:t displays a forced cursor over something, it displays it desaturated, but with a (desaturated) bg, so either it's more complicated, or IE got confused by lack of cursor frames. Or both
[11:24:21] <edheldil> my reading of gemrb code confirms that, but I have not tried it to fix it yet
[11:25:51] <lynxlynxlynx> bleh
[11:26:11] <lynxlynxlynx> and then there's bamv2 from bgee, though not with many changes
[11:27:18] <edheldil> If I stumble over it, I will add a support for it :)
[11:29:16] <lynxlynxlynx> it's described on the forum, but not in iesdp yet
[11:36:44] <fuzzie> in the original engine, the way the transparency worked depended somewhat on the renderer
[11:38:16] <fuzzie> but you'd think there's one-right-way to do it :)
[11:42:05] <fuzzie> you would expect that way to be a palette entry.
[11:45:21] <fuzzie> in gemrb in the GetFramePixels case it will return the compressed color index and not 'transparent'
[11:46:45] <fuzzie> and the cursor do go through that cas
[11:46:46] <fuzzie> e
[11:48:34] <fuzzie> no, wait, they don't. confused.
[12:34:42] --> WingedHussar has joined #gemrb
[12:38:14] <-- |Cable| has left IRC (Ping timeout: 240 seconds)
[12:44:12] <edheldil> in iesdp it says that transparent is either first palette color 00ff00, or 0 if green was not found
[12:45:10] <edheldil> while it seems to me that gemrb maybe just uses compressed color, but I have not looked much into it yet
[12:46:14] <edheldil> (or gemrb just uses 0 as transparent color index)
[12:52:00] --> |Cable| has joined #gemrb
[12:55:35] <wjp> eh?
[12:56:01] <wjp> separating those two in RLE rendering would be ... interesting
[12:56:20] <wjp> as in, pretty much a full rewrite of the render loop
[12:57:28] <wjp> ("those two" = transparent and compressed)
[13:01:03] <edheldil> you can experiment w/ http://www.eowyn.cz/gemrb/x2.bam - I might have done a mistake
[13:07:50] <wjp> can't right now, unfortunately
[13:10:41] <fuzzie> I thought the RLE path is always compressed
[13:10:59] <fuzzie> is it RLE, edheldil?
[13:12:32] <edheldil> I don't think so, but I haven't checked
[13:13:52] <wjp> this file's palette doesn't have a 00FF00, does it?
[13:13:54] <fuzzie> if you want to check if the file is good then you can toggle the 'transparent blt' option in the original engine
[13:16:02] <edheldil> wjp: does, 28
[13:16:51] <wjp> ff c0 c2 ?
[13:17:26] <wjp> um, or c4 c4 c4, I may be counting wrong
[13:17:51] <wjp> oh, and typing wrong too
[13:18:03] <wjp> but I still don't see a 00 ff 00
[13:19:38] <edheldil> I see it as entry 0x1c in palette
[13:20:29] <fuzzie> are you viewing it using bam workshop 2? :p
[13:20:37] --> brada has joined #gemrb
[13:21:39] <fuzzie> at a glance it looks like the cursors should be using the first palette entry for transparency
[13:21:44] <fuzzie> but I should probably run now
[13:22:23] <wjp> I'm viewing it using hexedit :-)
[13:23:51] <edheldil> I use iesh and now dltcep
[13:24:00] <fuzzie> dltcep should view it right.
[13:24:29] <edheldil> it says transparent offset is 0, but sees palette 0x1c as 0ff00
[13:25:05] <wjp> but I apparently have serious trouble typing today, as trying again I agree that it's at 0x1c :-)
[13:25:15] <wjp> *cough*
[13:25:24] <fuzzie> from memory, for icons/etc the transparent index is always zero, but for RLE it doesn't always matter
[13:25:44] <fuzzie> and at a glance the cursor code is the same path in bg but I might be crazy
[13:26:50] <edheldil> I will fix the code to move the transparent color to 0 in bam_composer, was planning to do it anyway
[13:27:13] <fuzzie> you should be able to break this in the original engine though
[13:27:49] <fuzzie> I mean, by means of twiddling the blt options
[13:28:04] <fuzzie> if not, then it's gemrb's fault, you'd assume
[13:28:11] <fuzzie> and would be nice to fix that :p
[13:28:13] <wjp> their software and hardware blitters behave differently?
[13:28:16] <fuzzie> yep
[13:28:56] <wjp> but what should we change in gemrb?
[13:29:10] <wjp> does the non-RLE path need to look for transparent colour in a different way?
[13:29:20] <fuzzie> that would be my assumption
[13:29:41] <wjp> (I really really hope that in the RLE path they're the same)
[13:29:50] <fuzzie> right now it writes CompressedColorIndex into the buffer, right?
[13:29:56] <fuzzie> and then passes 0 as the colorkey
[13:30:10] <fuzzie> oh, I mean, this is the RLE path
[13:30:17] <fuzzie> in gemrb for non-bam-backend
[13:30:30] <fuzzie> which is not what edheldil is seeing (I guess) but needs fixing anyway :-)
[13:30:47] <wjp> I think you lost me
[13:31:19] <fuzzie> the code right now is crazy inconsistent for the non-RLE case.
[13:31:34] <fuzzie> the BAMSprite2D gets CompressedColorIndex as the colorkey.
[13:31:36] <edheldil> maybe the bam has frames that says rle encoded, but are unencoded ... I am not sure what is the correct flag value
[13:32:06] <fuzzie> there's another case where the video backend doesn't support RLE at all, and that calls GetFramePixels, and that also seems flawed.
[13:32:25] <fuzzie> I have a meeting in 13 minutes, though, so I should probably look into that.
[13:34:44] <brada> is this something i broke?
[13:34:46] <edheldil> toggling 'Software transparency' did not change how the cursor is rendered in ps:t, but I run it under wine, so ...
[13:36:10] <edheldil> brada: sure, now go and fix it ;-)
[13:36:19] <fuzzie> there's maybe some global 'software bitting' option for the RLE case
[13:36:23] <fuzzie> don't know
[13:36:42] <brada> nah. didnt you read what i said the other day about breaking something so some of you would get back to work ;)
[13:37:36] <edheldil> if it's indeed broken, it's for quite a long time
[13:37:50] <edheldil> probably
[14:43:38] <-- WingedHussar has left IRC (Read error: Connection reset by peer)
[15:13:14] <-- brada has left IRC (Quit: brada)
[15:47:07] --> brada has joined #gemrb
[16:40:16] --> Yoshimo has joined #gemrb
[16:47:16] <-- Yoshimo has left IRC (Ping timeout: 245 seconds)
[17:07:45] --> raevol has joined #gemrb
[17:44:38] <-- raevol has left IRC (Quit: Leaving.)
[17:45:12] <-- brada has left IRC (Quit: brada)
[17:45:45] --> brada has joined #gemrb
[17:56:17] --> raevol has joined #gemrb
[19:43:29] <-- brada has left IRC (Quit: brada)
[20:13:40] --> edheldil_ has joined #gemrb
[20:19:06] --> brada has joined #gemrb
[20:21:55] --> Yoshimo has joined #gemrb
[21:19:16] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:12:52] <-- Yoshimo has left IRC (Quit: Yoshimo)