#email@example.com logs for 18 Jan 2014 (GMT)Archive Today Yesterday Tomorrow
[00:04:25] <-- raevol has left IRC (Quit: Leaving.)
[00:33:09] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[00:49:17] <-- |Cable| has left IRC (Ping timeout: 252 seconds)
[00:53:33] --> edheldil_ has joined #gemrb
[00:56:20] <-- Coriander has left IRC (Read error: Connection reset by peer)
[01:02:23] --> |Cable| has joined #gemrb
[01:23:51] <-- edheldil_ has left IRC (Ping timeout: 260 seconds)
[01:55:23] --> brada has joined #gemrb
[02:28:09] --> Canageek has joined #gemrb
[02:29:31] <-- Canageek has left #gemrb
[03:11:33] <-- |Cable| has left IRC (Ping timeout: 248 seconds)
[03:18:00] <-- Eli2_ has left IRC (Quit: Ex-Chat)
[03:30:46] --> |Cable| has joined #gemrb
[04:51:59] <-- |Cable| has left IRC (Ping timeout: 260 seconds)
[04:59:45] <-- brada has left IRC (Quit: brada)
[05:00:30] --> Beholder_ has joined #gemrb
[05:04:55] --> |Cable| has joined #gemrb
[06:31:23] <-- Beholder_ has left IRC (Ping timeout: 252 seconds)
[06:45:17] --> Eli2 has joined #gemrb
[08:48:12] --> edheldil_ has joined #gemrb
[09:30:30] --> Yoshimo has joined #gemrb
[09:31:49] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[09:42:51] --> Beholder_ has joined #gemrb
[09:57:18] <mrugiero> Xan's sword doesn't work. Everytime I try to move it in the inventory it tells it can't be wielded by anyone but Xan. I can't even drop it. Regardless of who has it, even if it's Xan. The only way I found to remove it was to open a container and put it there (I had to do exactly that to remove from Garrick and give it to Xan).
[10:00:12] <fuzzie> this is quite possibly an item sanitising/flags issue again
[10:00:20] <fuzzie> since the undroppable flag is different in bg1
[10:00:23] <lynxlynxlynx> no, more likely to do with my pst changes
[10:00:35] <fuzzie> oh well then I will go back to my code :p
[10:00:47] <lynxlynxlynx> if you try ~100 revisions back, do you have the same problem?
[10:01:12] <mrugiero> Do I need to pick up the item again, or just using my savegame with the older revision will do?
[10:01:26] <lynxlynxlynx> 9c37e8afe6911edea7d49d190213d972927a55d1
[10:01:42] <lynxlynxlynx> in this case, you can reuse the save
[10:01:59] <lynxlynxlynx> i'll check what flags we put in there in the meanwhile
[10:02:57] <lynxlynxlynx> ok, only non-equippable for others is set
[10:04:57] <mrugiero> Building.
[10:07:00] <lynxlynxlynx> it looks like it is my fault indeed
[10:07:42] <mrugiero> Works.
[10:07:52] <mrugiero> Yes, it looks it was that commit.
[10:10:40] --> Eli2_ has joined #gemrb
[10:11:09] <lynxlynxlynx> on it
[10:13:07] --> edheldil has joined #gemrb
[10:13:17] --- ChanServ gives channel operator status to edheldil
[10:13:28] <-- Eli2 has left IRC (Ping timeout: 245 seconds)
[10:23:04] <mrugiero> OK.
[10:23:22] <mrugiero> I got distracted reading a forum anyway :P
[10:47:06] <edheldil> btw, just to advertise a bit, creating an iesh script that finds all 24b bmps with green pixels was really easy
[10:49:11] <fuzzie> did you work out what the problem is?
[10:49:19] <fuzzie> I mean, on the gemrb side
[10:59:51] <edheldil> I think the whole problem is that BMP importer does not use colorkey for 24b BMPs
[11:00:34] <fuzzie> but it does, right?
[11:01:12] <fuzzie> oh, it doesn't
[11:01:24] <fuzzie> because it gets alpha set on it..
[11:01:44] <fuzzie> so what happens if you or the colorkey with (0xff << 24)?
[11:02:36] <fuzzie> that works
[11:03:15] <fuzzie> - true, green_mask );
[11:03:15] <fuzzie> + true, green_mask|(0xff<<24) );
[11:03:16] <fuzzie> ^-
[11:10:49] <edheldil> compiling ...
[11:12:11] <-- mrugiero has left IRC (Remote host closed the connection)
[11:18:19] <edheldil> seems to work, I hope it has no adverse effects elsewhere
[12:39:56] --> WingedHussar has joined #gemrb
[12:48:19] <-- Beholder_ has left IRC (Ping timeout: 252 seconds)
[12:55:45] <-- Yoshimo has left IRC (Read error: Connection reset by peer)
[13:34:01] --> Yoshimo has joined #gemrb
[13:45:36] --> Beholder_ has joined #gemrb
[13:47:33] <-- Eli2_ has left IRC (Remote host closed the connection)
[13:55:13] --> PKodon has joined #gemrb
[14:17:07] <-- edheldil has left IRC (Ping timeout: 260 seconds)
[14:54:44] --> brada has joined #gemrb
[15:04:58] <Beholder_> hi
[15:16:48] <Beholder_> i get a memory leaks if i call glUniform every frame....
[15:17:19] <Beholder_> dont understand why
[15:39:58] --> Beh0lder has joined #gemrb
[15:41:58] <brada> we are being overrun by beholders!
[15:43:17] <Beholder_> oops
[15:44:39] <-- Beh0lder has left IRC (Client Quit)
[15:45:00] <-- Beholder_ has left IRC (Quit: Leaving)
[15:45:24] --> Beholder_ has joined #gemrb
[15:48:23] <Beholder_> I cant kill firs Beholder
[15:48:28] <Beholder_> first
[15:49:35] <-- Beholder has left IRC (*.net *.split)
[15:49:35] <-- lynxlynxlynx has left IRC (*.net *.split)
[15:52:11] --> lynxlynxlynx has joined #gemrb
[15:54:58] <Beholder_> wjp, please try gemrb from my repo. I get leaks in my PC, but this is a very abnormal
[15:56:04] <Beholder_> load the game (or start new) and stay in place
[15:56:12] <-- lynxlynxlynx has left IRC (*.net *.split)
[15:58:39] --> lynxlynxlynx has joined #gemrb
[16:06:05] <wjp> hm, compile error; let's see
[16:09:27] <wjp> ok, built
[16:15:22] <Beholder_> i can use attribs and varyings instead uniforms, but there is less effective and causes more duplicate data production
[16:16:34] <wjp> hm, valgrind is giving up after 10 million errors :-)
[16:18:14] <Beholder_> errors per each frame
[16:18:20] <Beholder_> i think
[16:18:28] <Beholder_> drawEllipse?
[16:18:47] <Beholder_> SetUniformValue?
[16:19:24] <Beholder_> i asked question in a forum
[16:20:34] <Beholder_> may be i cant understand essence of uniforms
[16:21:18] <Beholder_> uniform is a constant variable for all mech (sprite in gemrb)
[16:23:11] <fuzzie> I assume I can leave this to wjp
[16:23:41] <wjp> on a train at the moment, so valgrind is a bit painful
[16:23:46] <wjp> but we shall see :-)
[16:25:53] <wjp> I'm getting a lot of errors in the movie player at the start of bg2
[16:25:59] * wjp scrolls past those
[16:29:15] <wjp> I don't see any memory leaks in the GL code
[16:29:26] <Beholder_> damn
[16:29:42] <Beholder_> may be it is a proble of intel drivers
[16:29:50] <Beholder_> problem
[16:30:01] <wjp> (this is in linux with Intel HD 4400)
[16:31:05] <fuzzie> no more Shader.cpp?
[16:31:14] <wjp> yes, and a new .cpp
[16:32:05] <fuzzie> GLSLProgram?
[16:32:07] <fuzzie> ok
[16:32:22] <wjp> http://www.usecode.org/gemrb/build.txt
[16:32:36] <fuzzie> thankyo
[16:32:58] <wjp> (quick'n'dirty build fixes)
[16:37:55] <Beholder_> no info about glUniform's?
[16:38:26] <fuzzie> uniforms are the right thing here, right?
[16:41:26] <wjp> I don't see any leaks related to graphics
[16:41:52] <wjp> (from starting bg2, loading a savegame and moving around a little bit before quitting)
[16:42:49] <fuzzie> yes, I see no leaks here and no relevant errors
[16:43:16] <wjp> do you also get a ton of errors in the movie player?
[16:43:31] <wjp> (this is the first time I'm running valgrind with the opengl driver)
[16:43:36] <wjp> s/the/this/
[16:44:08] <fuzzie> no
[16:44:19] <fuzzie> I get one complaint from deep inside nvidia's libGL somewhere
[16:44:24] <wjp> ugh
[16:44:39] <fuzzie> but that's brada's non-gl-specific code anyway I think
[16:45:20] <wjp> I hope I don't have to start debugging this intel driver then :-)
[16:45:21] <brada> it is
[16:47:36] <Beholder_> wait a several minutes after loading
[16:48:43] <fuzzie> we're checking the exact leak summaries in valgrind
[16:48:52] <fuzzie> so even 1 byte lost would show up
[16:48:58] <fuzzie> although I must admit I didn't check for 1 byte lost
[16:49:40] <Beholder_> :(
[16:50:06] <Beholder_> i need a new laptop
[16:50:10] <fuzzie> you're sure it's only glUniform?
[16:50:18] <Beholder_> sure
[16:50:54] <Beholder_> no leaks if not using uniforms
[16:51:17] <fuzzie> right, but it's not something else in your GLSLProgram class for example?
[16:52:31] <fuzzie> your uniforms map uses const char * as the key which is a bit scary
[16:53:06] <fuzzie> since that will go wrong if the compiler doesn't merge the strings..
[16:53:13] <fuzzie> why not use std::string there?
[16:53:33] <wjp> with string constants?
[16:53:43] <wjp> that is a bit scary yes
[16:54:06] <Beholder_> right
[16:54:29] <Beholder_> if no problems with uniforms i do some polish to class
[16:54:37] <fuzzie> that isn't 'polish' :)
[16:56:12] <fuzzie> if you pass /GF to the compiler (or /ZI) then I guess it should be ok for you though
[16:58:09] <Beholder_> people say that glUniform not cause leaks...
[16:58:28] <fuzzie> yes, I can't find anyone reporting problems with it
[16:58:35] <fuzzie> which is why I started looking at your other GLSLProgram code
[16:59:17] <fuzzie> oho
[16:59:20] <fuzzie> which game are you trying?
[16:59:25] <Beholder_> i don't know what can i do with leaks on my PC(
[16:59:29] <Beholder_> bg1
[16:59:35] <fuzzie> your code is a lot more unhappy in bg1
[16:59:39] <wjp> (bg2 here)
[16:59:55] <wjp> (that's all I have here on my laptop)
[17:00:16] <fuzzie> let me check that in valgrind
[17:01:56] <fuzzie> oh wonderful, it doesn't complain with track origins enabled
[17:05:00] <wjp> huh, is that expected?
[17:05:11] <fuzzie> I hope coincidence
[17:08:02] <fuzzie> yes. ugh.
[17:09:17] <Beholder_> if no ellipses displayed i have no leaks (no uniforms setting)
[17:09:59] <fuzzie> did you try fixing the map?
[17:10:19] <fuzzie> and it doesn't leak in drawColoredRect?
[17:10:26] <-- WingedHussar has left IRC (Ping timeout: 264 seconds)
[17:10:59] <Beholder_> drawColored rect uses glClear by default
[17:11:11] --> WingedHussar has joined #gemrb
[17:12:04] <Beholder_> if i do it with shader, i get leaks too
[17:18:16] <fuzzie> and if you comment out the SetUniformValue calls, it's fine?
[17:53:06] <-- brada has left IRC (Quit: brada)
[18:11:55] --> brada has joined #gemrb
[18:23:28] <-- brada has left IRC (Quit: brada)
[18:34:19] --> edheldil has joined #gemrb
[18:34:19] --- ChanServ gives channel operator status to edheldil
[18:34:40] --> brada has joined #gemrb
[18:46:49] <-- Beholder_ has left IRC (Ping timeout: 246 seconds)
[18:56:02] <-- brada has left IRC (Quit: brada)
[18:58:23] --> Beholder_ has joined #gemrb
[19:04:02] <-- chiv has left IRC (Ping timeout: 272 seconds)
[19:22:58] <Beholder_> right, if i do not call glUniform every frame, no leaks
[19:29:27] <wjp> do you only disable the glUniform call itself, or also the code surrounding the call?
[19:39:22] <fuzzie> right, what wjp said :)
[19:39:47] <fuzzie> I tried -fno-merge-constants but I'm not sure it actually took
[19:40:14] --> brada has joined #gemrb
[19:40:29] <fuzzie> well, I'm sure it didn't, rather, since I still end up with only one of each string in the final binary
[19:46:52] <wjp> getUniformLocation would be failing entirely if it doesn't merge them though
[19:47:11] <fuzzie> yes
[19:48:03] <fuzzie> pretty sure /ZI is default in vc++ debug land
[19:48:59] <fuzzie> but the fact I can't get gcc to cooperate is bugging me :)
[19:52:14] <-- brada has left IRC (Quit: brada)
[19:54:43] <fuzzie> Beholder_: you aren't doing anything special? just sitting around at start of bg1?
[20:21:34] <fuzzie> I see very little special about the Intel driver
[20:26:00] <Beholder_> i googled about driver
[20:26:18] <Beholder_> people say that a driver problem
[20:26:39] <Beholder_> and not only uniforms cause leaks
[20:27:17] <Beholder_> now i go to internet shop to select a new laptop with nvidia
[20:27:37] <Beholder_> no intel anymore
[20:28:14] <-- Beholder_ has left IRC (Quit: Leaving)
[20:31:16] --> Beholder has joined #gemrb
[20:34:40] <fuzzie> hm, well, users probably stuck with these drivers too :/
[20:35:39] <Beholder> there is a two way
[20:35:45] <Beholder> new pc or
[20:35:49] <Beholder> linux
[20:40:21] <-- Beholder has left IRC (Quit: Leaving)
[20:42:29] --> Beholder has joined #gemrb
[20:44:57] <-- Beholder has left IRC (Client Quit)
[20:46:16] <edheldil> anyone did something with containers recently?
[20:47:28] <fuzzie> what kind of thing?
[20:48:31] <edheldil> when I open a container in bg2demo, I get bg1's container window background
[20:48:41] <fuzzie> ooh. no idea.
[20:49:16] <edheldil> but now that I think of it, I am not sure it ever used to work correctly, I only played that part in IE
[20:56:49] <lynxlynxlynx> probably demo assets
[20:57:20] <lynxlynxlynx> bg2 includes all the bg1 stuff, so it looks like they changed incrementally
[21:09:07] <-- PKodon has left IRC (Quit: The Rodent Tracker 8000, just like on TV ... Because household pests never build up an immunity to bullets. (Tex Murphy))
[21:12:33] --> Beholder has joined #gemrb
[21:13:22] <edheldil> lynxlynxlynx: bg2 (or at least bg2demo) contains not only bg1 stuff, but also some development versions of screens
[21:16:28] <edheldil> and e.g. the mosaic plaqus in bg2demo are unfinished versions of those in bg2, as they are not clipped yet and their colorkey if not finished
[21:31:44] <-- Beholder has left IRC (Ping timeout: 252 seconds)
[21:32:52] --> Canageek has joined #gemrb
[21:33:27] <-- Canageek has left IRC (Client Quit)
[21:33:35] <edheldil> ... you can find a lot of mos files in bg2 for a rather different look
[21:36:51] --> Lightkey has joined #gemrb
[21:39:49] <-- Darklock has left IRC (Ping timeout: 248 seconds)
[21:45:12] <-- Yoshimo has left IRC (Quit: Yoshimo)
[21:51:12] <lynxlynxlynx> and that default win95 desktop background :)
[22:02:52] --> brada has joined #gemrb
[22:17:58] --> Canageek has joined #gemrb
[22:20:33] --> mrugiero has joined #gemrb
[22:23:14] <-- mrugiero has left IRC (Client Quit)
[22:27:46] <edheldil> hmmm ... surprisingly, the reason bg2demo shows wrong container window background, is not a deficiency in python scripts
[22:29:24] <edheldil> for some reason, when gemrb searches for window bg resource, it looks for mos file only after it tries bmp file
[22:34:48] <lynxlynxlynx> some reason? Most windows use mos for backgrounds, but you can actually dig some data to prove it either way
[22:44:13] <edheldil> meaning? are there windows where bmp is really the first resource to try?
[22:45:30] <lynxlynxlynx> i thought that was what you were suggesting for the demo case
[22:46:04] <edheldil> nope, I was wondering why we search first for bmp
[22:46:33] <lynxlynxlynx> right, i misread
[22:46:56] <edheldil> can you give me a pointer where we load the bg? I can't find it for some reason
[22:47:19] <lynxlynxlynx> i would start with loadwindow and go from there
[22:47:27] <lynxlynxlynx> you'll probably end up in the chuimporter
[22:52:56] <fuzzie> it's in the core
[22:53:03] <fuzzie> if you want the bmp preference
[22:54:15] <-- brada has left IRC (Quit: brada)
[22:55:30] <edheldil> quite the opposite, I need to try mos first, at least for windows backgrounds
[22:57:37] <fuzzie> dbb8138a5c1a6132bc08ad289d35da3b91f969f9 is probably responsibl
[23:00:57] <fuzzie> several ways to deal with it, all of them icky I guess
[23:10:20] <edheldil> thanks. I would readd the explicit mos load first and only if it fails default to ImageMgr
[23:11:41] <fuzzie> unfortunate for modding though
[23:11:45] <fuzzie> since a png is probably far more convenient
[23:40:16] <edheldil> right now the preference is dictated by the order plugins are loaded (more or less sorted by name), and data source order
[23:51:44] <edheldil> so, for the time being, the "solution" is to use DelayPlugin=BMPImporter.so