#gemrb@irc.freenode.net logs for 9 Apr 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:14:48] --> Gekz has joined #GemRb
[00:38:59] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[00:59:18] --> Gekz has joined #GemRb
[02:47:52] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[04:17:02] <-- nomad__ has left IRC (Ping timeout: 246 seconds)
[05:12:01] --> nomad__ has joined #GemRb
[06:17:09] <-- nomad__ has left IRC (Ping timeout: 258 seconds)
[06:53:59] --> lynxlynxlynx has joined #GemRb
[06:54:00] --- ChanServ gives channel operator status to lynxlynxlynx
[07:13:30] <-- raevol has left IRC (Quit: Leaving.)
[07:13:49] <-- |Cable| has left IRC (Remote host closed the connection)
[07:14:39] <Edheldil> hello!
[07:17:15] <Edheldil> as I was working on the Lua patch, I start to think that we should perhaps switch the OpenAL/SDL/Python/... checks to pkg-config. The only reason ATM is that it does not hurt eyes like content of acinclude.m4 :)
[07:28:35] <tomprince> Well, python-2 doesn't seem to have pkg-config, at least here. The other question is whether it would work on win32?
[07:28:45] <tomprince> But anyway, I am going to bed, much to late. :)
[07:30:13] <tomprince> I good idea.
[07:54:57] <Edheldil> does anybody use autoconf on windows?
[07:55:22] <Edheldil> good night
[07:56:37] <lynxlynxlynx> mingw/cygwin
[07:57:56] <lynxlynxlynx> not sure if it was actually used for our builds thought, it might have been cmake
[08:13:45] <fuzzie> checking logs, Gekz was using cmake, after the usual "trying to hack acinclude.m4 to work" game
[08:13:49] <fuzzie> also g'morning
[08:19:21] <Edheldil> morning
[09:49:58] <Gekz_> cmake is made of dreams and pie
[09:50:05] <Gekz_> you have to lie to it a little to get it to work
[10:04:35] --> raevol has joined #GemRb
[10:46:31] --- Gekz_ is now known as Gekz
[12:04:11] --> nomad__ has joined #GemRb
[12:56:07] <-- raevol has left IRC (Quit: Leaving.)
[13:08:04] <tomprince> Not recently, but I have build gemrb on wine/mingw with autotools.
[13:38:38] <tomprince> But, I am leaning toward cmake. On my desktop, I get about a 3x speed boost compiling w cmake
[13:52:59] <tomprince> CMake:
[13:53:01] <tomprince> 51.11user 5.54system 0:23.93elapsed 236%CPU (0avgtext+0avgdata 601792maxresident)k
[13:53:03] <tomprince> 0inputs+0outputs (0major+2366403minor)pagefaults 0swaps
[13:53:25] <-- nomad__ has left IRC (Ping timeout: 264 seconds)
[13:53:33] <tomprince> Autotools:
[13:53:35] <tomprince> 118.40user 10.24system 1:04.84elapsed 198%CPU (0avgtext+0avgdata 888096maxresident)k
[13:53:37] <tomprince> 0inputs+0outputs (11major+5216944minor)pagefaults 0swaps
[13:54:21] <wjp> hm, is libtool building everything twice for you?
[13:54:42] <wjp> a factor two is rather a lot
[13:54:45] <wjp> two+
[13:55:26] <tomprince> This on triple core, configure+make vs cmake+make.
[13:55:30] <tomprince> I don't think so.
[13:55:50] <tomprince> I think it will when I install it, which will add to the autotools time.
[13:58:20] <tomprince> No. It isn't.
[13:58:40] <tomprince> Libtool is a rather large shell script, which cmake doesn't use.
[13:59:42] <tomprince> And that is with making the plugins directory be non-recursive, to get better paralellism
[14:02:31] <tomprince> autotools, just make
[14:02:33] <tomprince> 116.10user 8.52system 0:53.70elapsed 232%CPU (0avgtext+0avgdata 888048maxresident)k
[14:02:35] <tomprince> 0inputs+0outputs (22major+4032452minor)pagefaults 0swaps
[14:07:37] --> Nomad010 has joined #GemRb
[16:19:50] --> Cable_ has joined #GemRb
[17:08:28] <fuzzie> automake produces some impressively horrible makefiles.
[17:09:15] <tomprince_loki> I remember looking at a project called quagmire a while ago, that does everything with GNU Makefiles.
[17:10:01] <tomprince_loki> I am working on a series of patches to bring the cmake build up to par with the autotools one right now.
[17:10:04] <fuzzie> i was wondering why the subdirectories didn't get parallelised; turns out that the Makefile it gives me just has a 'while' loop in shell.
[17:10:59] <tomprince_loki> I have read that there is no plans to change that. Since people depend on the fact that it serializes it.
[17:11:34] <fuzzie> Which is fair enough, but I do wish autotools came with a "this is stuck in the 1980s, please don't use it" warning sign somewhere.
[17:12:05] <tomprince_loki> I also have a couple of patches on top of or.cz/core that turns the plugins directory parallel, by not using recursive make.
[17:12:27] <fuzzie> Without making a monolithic Makefile.am?
[17:12:47] <tomprince_loki> Yes, automake can have include directives.
[17:13:07] <tomprince_loki> So, the end result is a monolithic make, but the Makefile.ams aren't.
[17:13:19] <fuzzie> Those might be a nice idea to apply anyway..
[17:14:59] <fuzzie> (Is the cmake build missing much? I thought it was okay, apart from the missing search path bits.)
[17:16:12] <tomprince_loki> That an the install directories don't match the FHS.
[17:16:20] <fuzzie> Ah.
[17:17:59] --> Edheldil_ has joined #GemRb
[17:18:04] <fuzzie> I wonder how you'd do that nicely..
[17:20:57] <tomprince_loki> Have a variable LAYOUT, that you set when running cmake, that selects the layout.
[17:21:46] <fuzzie> Well, you'd think cmake would have some module which provided some reasonable platform defaults..
[17:22:13] <fuzzie> But it seems not, at a glance.
[17:22:37] <tomprince_loki> Well, the defaults are $PREFIX/{bin,lib,share/doc,share/man,etc} ...
[17:22:49] <tomprince_loki> On unix like anyway.
[17:23:05] <tomprince_loki> And there really isn't anything elsewhere that I know of. OSX I guess.
[17:23:06] <fuzzie> Define 'unix like', though..
[17:24:43] <fuzzie> Just seems like manually checking for WIN32 and APPLE and whatever anyone wants next is .. ridiculous :)
[17:25:10] <tomprince_loki> Well, when I am done, I'll show what I have. I think it will make sense.
[17:29:08] <fuzzie> ok :)
[17:31:57] <tomprince_loki> or.cz/core has the parallel automake stuff I have.
[17:32:23] <tomprince_loki> Just so you can see.
[17:33:34] <fuzzie> seems pretty harmless?
[17:33:58] <tomprince_loki> Yes.
[17:34:16] <tomprince_loki> But I don't want to maintain both.
[17:34:30] <tomprince_loki> So, if we are dropping autotools, no reason to apply it.
[17:34:35] <fuzzie> ok. but if you want that merged, just say :)
[17:35:03] <tomprince_loki> The core bits yes, but not the parallel automake, unless we keep autotools.
[17:41:21] <fuzzie> what's the 'init.cpp' in your BMPWriter patch?
[17:44:42] <fuzzie> we also lose at least one comment in there
[17:45:29] <fuzzie> and also some logic changes so i guess i can't apply it right now.
[17:46:18] <tomprince_loki> Have a look at the new one. I cleaned somethings up since I first posted it.
[17:46:37] <fuzzie> this is the new one, no?
[17:46:56] <fuzzie> 5fbce9d7
[17:47:59] <tomprince_loki> Yes.
[17:48:08] <tomprince_loki> I don't see any init.cpp there.
[17:48:15] <fuzzie> it's in the CMakeLists.txt.
[17:48:35] <tomprince_loki> Oh, yes that is just left over from rebasing.
[17:49:04] <fuzzie> ok. switching to GetPixel() on the Sprite2D might well break things, i'll have to check.
[17:49:11] <tomprince_loki> That is why I want one build system. I did test all that series with autotools, but not cmake.
[17:50:36] <tomprince_loki> I think that actually deals with the FIXME that was in OpenFromImage.
[17:51:15] <fuzzie> it discards alpha, no?
[17:52:18] --> Avenger has joined #GemRb
[17:52:29] --- ChanServ gives channel operator status to Avenger
[17:52:37] <Avenger> hello everyone
[17:52:56] <fuzzie> hi :)
[17:53:01] <tomprince_loki> Doesn't look like it.
[17:53:30] <tomprince_loki> Or, do you mean the BMPWriter discards alpha?
[17:53:45] <fuzzie> Avenger: if you didn't see in logs: gemrb's DestroyAllEquipment() and similar destroy fists! where/how should I fix?
[17:53:59] <fuzzie> tomprince_loki: yes, the writer is discarding alpha
[17:54:10] <Avenger> oh fun, is that a problem?
[17:54:16] <tomprince_loki> So, should we change it to output 32bit bmp?
[17:54:27] <tomprince_loki> Will the original engine handle those?
[17:54:36] <fuzzie> tomprince_loki: no, but there should at least be a note there
[17:54:51] <Avenger> well, if the fist is never destructible, you simply skip slot #0
[17:55:01] <Avenger> thats the easiest and cheapest way
[17:55:08] <fuzzie> Avenger: well, there is a comment in the drop things about the FIST and MAGIC slots
[17:55:28] <Avenger> magic slot is surely good if destructible by script
[17:55:31] <fuzzie> i don't understand anything about the slot system, so i don't know whether i just copy that to DestroyItem
[17:55:46] <Avenger> well, wanna me fix it then?
[17:56:00] <fuzzie> an easy test case is the bg2 tutorial :)
[17:56:10] <Avenger> the fist slot is always #0, in all cases
[17:56:15] <fuzzie> and, yes, if you could
[17:56:21] <Avenger> just to make it easy to handle
[17:56:28] <fuzzie> i just didn't know whether scripts were meant to be able to destroy the fist slot
[17:57:30] <Avenger> using while(slot-->0) { instead of while(slot--)
[17:57:32] <tomprince_loki> Well, the new code doesn't do anything different than the old code, other than (I think) being more robust about the sprites it can handle. But yes, a FIXME in the loop about dropping alpha makes sense.
[17:57:46] <Avenger> hmm, dropping fist is always a no-no, right?
[17:58:00] <fuzzie> tomprince_loki: well, it is also switching to a whole new GetPixel mode, i forget if that is a problem
[17:58:17] <Avenger> well, i can't hack that easily, so ignore my previous question
[17:58:19] <fuzzie> i will pull it now and try.
[17:58:48] <fuzzie> Avenger: i have no idea about slots, really, so no idea whether you can drop fists or not :)
[18:00:30] <fuzzie> Avenger: i would also like to know why you broke all the encumbrance text labels, if you can remember!
[18:00:46] <Avenger> well, i'm happy i could be of any use... Did i break them?
[18:00:49] <tomprince_loki> It works for me^TM, and the old code would fall down on BAM Sprites.
[18:01:02] <CIA-43> GemRB: 03avenger_teambg * rd594fd8b4bff 10gemrb/gemrb/plugins/Core/Inventory.cpp: hardcoded inability to destroy the fist slot under any circumstances
[18:01:07] <fuzzie> you changed the height on all of them from 20 to 15, including some patches
[18:01:13] <tomprince_loki> Looking at it more closely, it did handle other SDL sprites fine.
[18:01:39] <Avenger> i think i just wanted to reposition them, iirc
[18:01:49] <fuzzie> i just wondered if i am missing some bug, before i change them all back! but it was a long time ago
[18:01:49] <Avenger> i had problem with their position not their height, that's sure
[18:02:17] <Avenger> this is in the guiscript of inventory?
[18:02:27] <fuzzie> also of store and world
[18:02:56] <Avenger> it is a createlabel
[18:03:05] <Avenger> i think 15 was just some random value
[18:03:19] <Avenger> if it is 20 in the real game, then so be it
[18:03:25] <fuzzie> well, i don't know how to see :)
[18:03:38] <Avenger> but i would like some more flexible code there
[18:03:40] <fuzzie> i also changed override/bg1/guils.chu to move the 'game loading' text
[18:03:50] <Avenger> it is just an ugly hack to force it work somewhat
[18:04:04] <fuzzie> i thought maybe i would add a 'AddEncumbranceLabels' function, which takes some control and some optional offsets
[18:04:50] <Avenger> the encumbrance already has some guicontrol in the resource, no? It is just not too useful for us, iirc
[18:05:09] <fuzzie> yes, but it has the position/size, i hope :)
[18:05:23] <Avenger> yes, i hope that too
[18:05:29] <fuzzie> hm, what else is on my "to ask Avenger" list..
[18:05:30] <Avenger> it would be better to convert it
[18:05:41] <fuzzie> oh, we don't darken outside areas at nighttime
[18:05:43] <Avenger> that would keep its position/size
[18:06:09] <fuzzie> There is a Game::GetGlobalTint() but we don't use it.
[18:06:15] <fuzzie> Should we use it? :)
[18:06:20] <Avenger> yes, somehow
[18:06:31] <Avenger> i think i coded everything except the visual display
[18:06:36] <fuzzie> yep
[18:06:37] <Avenger> it is also set by weather stuff
[18:06:51] <Avenger> i hoped wjp can make it optimally
[18:06:52] <fuzzie> yep, you did that too :)
[18:07:52] <Avenger> maybe the globaltint is better stored in the video driver
[18:08:08] <Avenger> or at least mirrored
[18:08:20] <fuzzie> we also use it for hide-in-shadows, apparently?
[18:08:28] <Avenger> yes we do
[18:08:47] <fuzzie> but yes, we could copy it when the tint changes.
[18:08:49] <Avenger> it could still be stored in the common! part of the video driver
[18:09:01] <Avenger> not in sdlvideo but in videomgr
[18:09:35] <Avenger> not like we'll have a non-sdl driver soon
[18:09:51] <fuzzie> well, i hope someone will come along and make it work for opengl :)
[18:10:38] <Avenger> so, i did those CreateLabels before i implemented any control conversion code
[18:10:56] <fuzzie> i think we have to keep the control, because it has the image
[18:11:10] <fuzzie> oh, there is another question: it appears in the wrong place in the DLTCEP preview!
[18:11:20] <fuzzie> i mean, in the bg2 inventory window
[18:11:27] <Avenger> since then i got ConvertEdit, maybe we just need a similar conversion stuff
[18:11:29] <fuzzie> i wondered if i missed a checkbox
[18:11:51] <Avenger> hmm, really? then it is crap
[18:12:05] <Avenger> are you sure dltcep is wrong, or probably the .chu
[18:12:44] <fuzzie> the .chu is fine, i think
[18:13:06] <Avenger> ok, you talk about guiinv.chu in bg2
[18:13:32] <Edheldil_> hmm, are we switching to cmake???
[18:13:37] <Edheldil_> hi all
[18:13:45] <Avenger> which control is the label?
[18:13:59] <fuzzie> Avenger: it is a button, id67.
[18:14:20] <Avenger> what's wrong with it
[18:14:26] <Avenger> i see it in the bottom left corner
[18:14:54] <Avenger> aligned to the top of the first inventory slots
[18:15:12] <fuzzie> in-game, it is further down
[18:15:21] <fuzzie> perhaps my copy is just broken?
[18:15:48] <Avenger> not sure what's wrong
[18:15:57] <fuzzie> compare to http://img36.imageshack.us/img36/1769/bg22d43s.jpg
[18:16:34] <Avenger> that's the original ie?
[18:16:48] <fuzzie> yes
[18:17:09] <Avenger> i guess i know how they do it, they render the text in the button, with the <text><bitmap><text> format
[18:17:27] <Avenger> i'm almost sure...
[18:17:49] <fuzzie> the position is fine in gemrb, though
[18:17:50] --> CIA-74 has joined #GemRb
[18:18:09] <Avenger> the bitmap is smaller than the control it is in
[18:18:13] <-- CIA-43 has left IRC ()
[18:18:28] <fuzzie> so i thought, some DLTCEP bug that it displays bitmaps at the wrong place?
[18:18:28] <Avenger> bitmap's height is 61
[18:18:33] <fuzzie> and then i thought, i will ask Avenger :)
[18:18:37] <Avenger> it always puts them on top
[18:19:05] <Avenger> i guess our engines (ie/gemrb) render them in middle
[18:19:09] <Avenger> if there are no flags set
[18:20:14] <fuzzie> http://img704.imageshack.us/img704/2096/bgbug2.png makes the positions more obvious, is that just at the top/bottom of the control?
[18:20:47] <fuzzie> if so, i guess it is even easier to work out
[18:21:23] <Avenger> i think those are the top/bottom of the bitmap
[18:21:33] <Avenger> the bitmap is 61 pixels hight, the control is 80 pixels
[18:21:44] <Avenger> the 19 pixels are surely enough for the small texts
[18:21:54] <Avenger> well, maybe not
[18:23:01] <Avenger> this ugly screenshot is also old ie with 3d acceleration on on an nvidia?
[18:23:06] <fuzzie> yes
[18:23:14] <Avenger> never thought it will be useful :D
[18:25:05] <Avenger> so, the encumbrance text should better use the original control, or if that's not easy, somehow align them to the button control
[18:25:21] <Avenger> the constant values are crappy for sure
[18:25:37] <Avenger> i'm pretty sure there are gui mods that would be broken by our constants
[18:25:46] <fuzzie> yes, that was my thought too
[18:26:05] <fuzzie> i'm just trying to tidy up the GUI - i fixed the map, the bg2 ai buttons and the flickering 'continue' in dialogues so far.
[18:26:23] <Avenger> hmm, the flickering was caused by what?
[18:26:46] <fuzzie> the animation in the bottom-left was redrawing the window
[18:26:59] <fuzzie> because that is required for the transparent iwd2 paperdoll animations
[18:27:13] <fuzzie> i mean, that is the ai buttons.
[18:27:14] <Avenger> oh you don't close the window, just when you absolutely needed?
[18:27:23] <fuzzie> the continue was just stupid guiscript code, yes.
[18:27:48] <tomprince_loki> I was thinking that it would make sense to have a file format to describe GUIs. That points to the CHU, and describes all the controls, and give them meaningful names, rather than numbers. Which would make it easier to share code between games.
[18:28:09] <fuzzie> you could do that in a 2da, no?
[18:28:16] <tomprince_loki> Yes.
[18:28:35] <Avenger> you could also have a new fileformat to replace .chu's ;)
[18:28:41] <fuzzie> that seems ok.
[18:28:43] <Avenger> this .chu is a hacked mess
[18:29:49] <tomprince_loki> It would make sense to have a new format, but that wouldn't be compatible with the original games. Unless we just want to provide replacements for everything?
[18:29:59] <tomprince_loki> I wouldn't be oppsosed to that.
[18:30:04] <Avenger> i thought of that, for new games
[18:30:14] <Avenger> a new set of importers, with cleaner formats
[18:30:45] <wjp> Avenger: globaltint? What should that do exactly, and how is it used in games?
[18:30:53] <fuzzie> wjp: it tints the whole game area
[18:30:54] <wjp> (feel free to answer later :-) )
[18:31:01] <fuzzie> for dusk, darkness, fog, dreams, etc
[18:31:01] <Avenger> it is to 'tint' the game area
[18:31:14] <tomprince_loki> Yes. Definitely. That was part of my motivation for the new plugin system. To make it easy to support both the old format and new formats.
[18:31:23] <wjp> hm, the current half-implementation suggests blending more than tinting
[18:32:15] <Avenger> i'm not entirely familiar with the terms :) it is all tinting for me when it changes rgb, and all blending when changing the alpha :D
[18:32:50] <wjp> should a globaltint of pure red make everything shades of red, or should it make everything a bit red?
[18:33:08] <wjp> (i.e., should it zero the green and blue components)
[18:33:30] <Avenger> good question
[18:33:44] <Avenger> and i would be damned if i know
[18:33:51] <fuzzie> Avenger: fist slot is not 0, it seems
[18:34:08] <Avenger> that's impossible..........
[18:34:32] <fuzzie> it's 10 in 'slottype.2da'
[18:35:14] <fuzzie> 10: fist - (1 0 0) 20a9 Wt: 1 x 0Lb
[18:35:20] <fuzzie> some different set of slot numbers?
[18:35:25] <Avenger> hmm
[18:35:39] <Avenger> then it is core->QuerySlot(0) ???
[18:36:15] <fuzzie> yes. which is in SLOT_FIST, which works. let me apply that.
[18:36:39] <Avenger> or GetFistSlot()or Inventory->GetFistSlot()
[18:36:51] <Avenger> hmm
[18:37:01] <Avenger> sucks, it is not so nice then
[18:37:49] <Avenger> looks like i forgot all the permutations :)
[18:37:58] <Avenger> there are some 3 or 4 different orders of slots
[18:38:11] <CIA-74> GemRB: 03fuzzie * r0c17a4e8539e 10gemrb/gemrb/plugins/Core/Inventory.cpp: apparently slot number to ignore here is SLOT_FIST
[18:38:15] <fuzzie> it's so confusing
[18:38:19] <Avenger> yes
[18:38:30] <Avenger> we inherited this from the IE :(
[18:39:08] <Avenger> and yeah, now i see it is used in Inventory::DropItemAtLocation already
[18:39:25] <Avenger> -->//these slots will never 'drop' the item
[18:39:48] <Edheldil_> about the gui metaformat... something like Glade XML? :)
[18:40:06] <fuzzie> tomprince_loki: we accidentally fix the "various directories" thing from the TODO, i guess :)
[18:40:37] <tomprince_loki> Yes.
[18:40:41] <tomprince_loki> :)
[18:41:31] <tomprince_loki> Edheldil: Something like that. It occured to me yesteday or the day before, but I havent looked to see what is out there.
[18:42:59] <Avenger> xml sucks --> bloated, slow. But for optional plugins, it is probably fine.
[18:43:17] <Avenger> it would also let someone to write a 'nice' portable game editor
[18:43:32] <fuzzie> yes, for new plugins it doesn't really matter
[18:43:49] <tomprince_loki> Is it bloated in slow, necessarily?
[18:44:01] <Avenger> it matters somewhat, no new game for those mini palmtops or whatever
[18:44:24] <fuzzie> for UIs as a one-time hit with a lightweight parser, i would imagine it's irrelevant
[18:44:27] <Avenger> the game files in xml will be bloated, if you don't use binary xml
[18:44:51] <tomprince_loki> Well, just used zlib compressed xml.
[18:44:58] <fuzzie> but all this slow load-time stuff which i've been trying to avoid, it is a *lot* more annoying on slow ARM etc
[18:45:43] <Avenger> yes, it will be a bad thing on those weak machines, but unnoticeable on new ones. And easier to edit
[18:46:05] <fuzzie> but i think for the UIs it's not so bad, for things like items it would be murderous
[18:46:38] <Avenger> hmm, well, maybe we can do it selectively, yes
[18:46:39] <tomprince_loki> Well, there is so much nowadays that is xml, and efficent parsers, that it won't in practice be slow.
[18:46:55] <fuzzie> you'd be surprised..
[18:47:32] <tomprince_loki> Well, I don't have any experience, so I can't comment.
[18:47:38] <fuzzie> i mean, you can build the better parsers in very slimline modes, but you still take a hit if you load a lot
[18:48:09] <tomprince_loki> Well, then we would just need to implement caching.
[18:48:16] <Avenger> no if we go all xml it will be sluggish. a number in binary format, even if you mess with the endian stuff is easier to read than parsing the field name, then converting the numeric text
[18:48:39] <fuzzie> binary xml surprisingly doesn't really help.
[18:48:52] <Avenger> it is just smaller files
[18:49:24] <Avenger> zlibbed xml will need to decompress, wholly? or you can stream it somehow
[18:49:29] <fuzzie> i mean, it helps avoid the hits like parsing numbers, but it is no magic.
[18:49:50] <fuzzie> but, i mean, for a UI, i don't think you'd notice, still, given you get a whole new game to play with.
[18:50:16] <fuzzie> and you can stream, but i think of a lot of small files where it doesn't matter..
[18:50:20] <Avenger> yep, there are not many ui files, and they are not loaded many at a time
[18:50:25] <tomprince_loki> Is it any worse the dealing with 2Da files?
[18:50:37] <fuzzie> yes.
[18:50:50] <tomprince_loki> We store that data as strings, and parse the numbers everytime I think.
[18:51:06] <fuzzie> it is a bug if we're parsing that much 2da data..
[18:51:27] <Avenger> except when we preload the 2da's we indeed parse them every time
[18:51:30] <fuzzie> the intention is that anything significant per-frame should be pre-loaded
[18:51:43] <fuzzie> as in, loaded into arrays, out of the 2DA objects
[18:51:47] <Avenger> only the core preloads them
[18:51:55] <tomprince_loki> On the other hand, this is all moot, since we don't have any other games to deal with right now, and no other formats.
[18:52:09] <fuzzie> well, i think if you build the plugins, they will come.
[18:52:27] <fuzzie> especially some different map model so people can do isometric tile maps.
[18:53:09] <tomprince_loki> Well, and profiling has shown that SDL is the big hit, not anything else. And then file searching, which is being worked on.
[18:53:32] <fuzzie> well, my profiles are only of in-game time, but yes.
[18:53:43] <fuzzie> i mean, other than when i was staring at the madness of strncpy.
[18:53:57] <tomprince_loki> Yes, that is madness.
[18:54:01] <fuzzie> i still can't believe it does that :(
[18:54:08] <Avenger> file searching is to fix the case sensitivity problems?
[18:54:43] <fuzzie> Avenger: to stop it from being slow when CaseSensitive=1, yes
[18:55:03] <fuzzie> that is quite a lot better now
[18:55:23] <tomprince_loki> With some room for improvement.
[18:55:26] <Avenger> well, i just guess it won't affect me then, i play with =0
[18:55:33] <Avenger> i mean casesensitive = 0
[18:56:23] <Avenger> see you later!
[18:56:23] <fuzzie> we can maybe help that a bit by adding some flag which caches file locations
[18:56:25] <fuzzie> bye!
[18:56:40] <-- Avenger has left IRC (Quit: bye!)
[18:59:50] <fuzzie> i wonder where you'd put that .. i guess in the ResourceManager?
[19:01:03] <tomprince_loki> Or DirectoryImporter.
[19:01:32] <fuzzie> well, i mean, most resources are in the KEYImporter, at the end of the search..
[19:01:49] <fuzzie> i guess if you don't mind about picking up new files, though, it doesn't matter
[19:01:55] <tomprince_loki> Or, if you don't care about the memory hit, both?
[19:02:10] <tomprince_loki> Would need option to turn it off, for the cache.
[19:03:17] <tomprince_loki> I'd be curious to know which is more of a time hit, searching each path, or searching in a given path.
[19:03:59] <fuzzie> well, if you don't hit the disk at all when searching a given path, you're not going to be using any time.
[19:04:16] <fuzzie> i mean, 'hit the disk' in the sense of making a syscall/etc
[19:04:46] <tomprince_loki> True, but if you have a list of all the files in a directory, in DirectoryImporter, you won't need to hit the disk.
[19:04:51] <fuzzie> i seem to remember the whole opendir thing is pretty fast on Linux, just one syscall which grabs the contents all in one go
[19:05:54] <Nomad010> why are you optimising at such a low level?
[19:06:02] <Nomad010> for embedded devices?
[19:06:05] <fuzzie> Nomad010: where would you suggest?
[19:06:20] <fuzzie> 50,000 file searches is not something to ignore :)
[19:06:28] <Nomad010> well surely it's not that slow
[19:06:29] <Nomad010> ahh
[19:07:01] <tomprince_loki> Prehaps it might be better to not do 50,000 file searches. :)
[19:07:05] <Nomad010> yeah
[19:07:13] <Nomad010> :p
[19:07:20] <fuzzie> well, hence trying to cache where the files *are*.
[19:08:23] <fuzzie> if you can say at the start "ah, this one is in the BIF", we can avoid the 14 pointless searches for every file.
[19:08:31] <tomprince_loki> Although, I suspect that we can also decrease the number of times we call in to ResourceManager, by smart caching at a higher level.
[19:08:39] <Nomad010> ya
[19:09:11] <fuzzie> Yes. And we can keep BIF files open while loading, surely also a gain
[19:11:31] <Nomad010> are BIF files large?
[19:11:59] <fuzzie> they contain all the game data :)
[19:12:06] <fuzzie> but we only read the header, and the data we need
[19:13:13] <fuzzie> I think the biggest win would still be not loading whole areas at once, though.
[19:14:14] <Nomad010> what about memory mapped files?
[19:14:27] <Nomad010> although i have no clue how portable that would make your code :p
[19:14:43] <fuzzie> there are occasional rumours of people wanting to play from CDs
[19:15:08] <Nomad010> lol
[19:15:09] <fuzzie> not sure if anyone actually cares any more. it certainly doesn't work atm. nice to have though.
[19:15:56] <Nomad010> about the tiling?
[19:16:41] <tomprince_loki> Well, our data structures don't map onto the fileformat directly, so we could probably wrap it mostly transparently, so that in the CD case, things don't get mapped.
[19:16:55] <tomprince_loki> Or, even unmap them when we need to switch CDs?
[19:16:57] <fuzzie> in any case, we'd run out of address space quickly
[19:17:04] <Nomad010> yeah
[19:17:35] <Nomad010> is it bad to mmap a file on a slow medium?
[19:17:47] <tomprince_loki> True. Specially with all the mods.
[19:18:46] <tomprince_loki> Although, on 64bit, we proably won't be hitting address space limitations.
[19:19:18] <fuzzie> sure, but gemrb is surely more than fast enough on any amd64 machine
[19:19:36] <Nomad010> if you are planning to have it run on embedded systems then you are gonna have a lot more problems
[19:20:34] <fuzzie> Nomad010: 'embedded systems' in the sense of 300mhz/128mb RAM devices with a full os :)
[19:20:51] <Nomad010> lol yeah
[19:20:52] <tomprince_loki> On the other hand, with the rate things are going, we will be no match even for embedded machines shortly.
[19:20:53] <Nomad010> mobiles
[19:21:19] <fuzzie> tomprince_loki: your 'images' branch has GetPalette still in MOSImporter.h.
[19:22:15] <fuzzie> and the BMPWriter change does indeed break it.
[19:22:40] <tomprince_loki> :( and :(
[19:22:52] <tomprince_loki> What breaks?
[19:23:13] <fuzzie> the Sprite2D you're passed is in the wrong byteorder
[19:23:31] <fuzzie> BMPImporter just copying the pixels over works, but calling GetPixel() on it breaks
[19:24:02] <fuzzie> i had a fix for this (on the SDL side) that i didn't check in because it broke things, i'll dig it out later
[19:27:22] <fuzzie> oh, i checked it in and then reverted it, even easier.
[19:27:35] <fuzzie> See 3bda35d7.
[19:28:36] <fuzzie> Seems to work fine with that added to the mix.
[19:29:23] <fuzzie> Will just have to remember to apply it at the same time.
[19:33:35] <tomprince_loki> I hate SDLVideoDriver.inl. Hate hate hate.
[19:36:54] <fuzzie> Write an OpenGL driver? :-)
[19:37:46] <tomprince_loki> Well, if I even knew what the different parts were supposed to do, I could write a cleaner version of SDLVideo, without SDLVideoDriver.inl.
[19:38:07] <tomprince_loki> But I tried simplifying the login in SDLVideo, and things broke.
[19:38:12] <tomprince_loki> Graphics, that is.
[19:38:44] <fuzzie> Well, this is why I was pondering it would be better to write a new plugin: you could build things up bit-by-bit.
[19:40:00] <fuzzie> But I don't know whether that would be less effort.
[19:40:06] <tomprince_loki> Well, if people know what all the flags are supposed to do ... that might not be to bad.
[19:40:45] <fuzzie> I imagine trying to refactor any of that code would be a huge black time-sucking hole with little return atm.
[19:41:24] <tomprince_loki> Yes. It is. I speak from experience. :)
[19:45:09] <tomprince_loki> Well, if people know what all the flags do, or are willing to help me track down what they do, then I could have a go at a new plugin.
[19:45:40] <tomprince_loki> First, I'd have to refactor enough that the SDL specific parts of Sprite2D are in SDLVideo. But that isn't all that hard.
[19:46:44] <fuzzie> You mean, actual SDL-specific bits?
[19:47:56] <fuzzie> Oh, there's sneaky bad things in that palette code.
[19:47:56] <tomprince_loki> Well, just that enough of the logic of Sprite2D is tied to the SDLVideo driver, I think.
[19:48:20] <fuzzie> But I hope that would be easy to fix.
[19:48:24] <tomprince_loki> Yes. The Sprite2D should probably be pure virtual, and opaque to core.
[19:48:36] <fuzzie> Well, *then* you move non-SDL code into SDLVideo.
[19:50:06] <tomprince_loki> Well, I think the BAM stuff is an implementation detail of SDLVideo.
[19:50:15] <tomprince_loki> Or, if not, it still needs to be refactored.
[19:50:16] <fuzzie> it isn't, though.
[19:50:25] <fuzzie> but yes, it is not going to be nice for all drivers.
[19:50:56] <fuzzie> hence this SupportsBAMSprites() call on Video; perhaps you could just move the logic into some subclass which SDLVideo could inherit from?
[19:51:15] <Edheldil_> Sprite2D opaque to core is the current situation, no?
[19:51:23] <tomprince_loki> That is more or less what I mean, that we shouldn't force a representation of sprites on Drivers.
[19:51:31] <tomprince_loki> Except all the code in Sprite2D.cpp
[19:51:44] <wjp> BAM is kind of forced on us already
[19:52:02] <fuzzie> well, an opengl driver would have no use for the BAM data
[19:52:11] <wjp> and it's not such a bad format to store the data in for a software renderer
[19:52:21] <tomprince_loki> I think about the only thing that is forced on us is the handling of shadows.
[19:52:39] <fuzzie> well, it is forced on us in the sense that the incoming data is BAM.
[19:52:52] <fuzzie> and software renderers should be able to get that data.
[19:53:11] <tomprince_loki> Even if we want to keep BAM in core, then it should still be a derived class of Sprite2D, and not this conditional mess that we have.
[19:53:14] <wjp> but indexed RLE is a very natural format given what it needs to do fast
[19:53:30] <fuzzie> i'm not entirely convinced that a hardware renderer wouldn't want BAM around, but if you're happy reimplementing the Sprite2D functions..
[19:53:55] <fuzzie> Certainly BAMImporter doesn't hand BAM-compressed Sprite2Ds over to backends which don't support it?
[19:54:27] <fuzzie> It just calls CreateSprite8 on the decompressed frames.
[19:54:33] <tomprince_loki> Right now we assert if we can't get a BAM. And sprite support in SDLVideo isn't orthogonal.
[19:54:42] <fuzzie> Where do we assert?
[19:54:58] <wjp> but I've held off on refactoring sprite support because there was no second model of renderer to design things against
[19:55:12] <tomprince_loki> GetAnimationFactory.
[19:55:14] <fuzzie> I'm confused as to where you'd be getting BAM data, as a non-SDLVideo backend.
[19:55:18] <wjp> and I really don't like doing redesigns based on some hypothetical future thing
[19:55:47] <fuzzie> Oh, why do we do that?
[19:55:52] <Edheldil_> so write an OpenGL Video first ;-)
[19:56:15] <wjp> Edheldil_: I've started that a couple of times :-)
[19:56:20] <tomprince_loki> Because SDLVideo doesn't support all the options we need for sprites coming from BAMs on non Bam sprites?
[19:56:32] <tomprince_loki> wjp: Do you still have any code around?
[19:56:39] <fuzzie> I think you can safely remove that assert.
[19:56:51] <wjp> tomprince_loki: my own attempts never got past the design phase
[19:57:14] <wjp> tomprince_loki: someone else did an OpenGL renderer that actually worked at some point (not with 100% functionality)
[19:57:35] <tomprince_loki> Well, if you change that assert, and change SDLVideo to return false for SupportBAM, then things go crazy.
[19:57:46] <fuzzie> tomprince_loki: Sure, SDLVideo doesn't support you doing that.
[19:57:56] <Edheldil_> and is not there (or was not there) DirectX renderer?
[19:57:59] <wjp> tomprince_loki: but the author never responded to my more recent emails
[19:58:02] <fuzzie> Edheldil_: long-gone
[19:58:10] <tomprince_loki> IS the code around?
[19:58:36] <wjp> tomprince_loki: in an advanced state of bit-rot
[19:58:40] <fuzzie> I imagine looking at that code would mean you shouldn't be committing anything to do with it, though.
[19:58:54] <wjp> the license situation is very unclear
[19:59:12] <fuzzie> I don't see any code paths which would be a problem for a new backend reporting SupportBAM as false.
[19:59:17] <tomprince_loki> Well then, I won't bother with it then.
[19:59:45] <Edheldil_> wjp: how so? The files' license is unclear, author unknown or what?
[19:59:45] <fuzzie> You could just clone SDLVideo and start with it from scratch, I guess, although that is not the most helpful of things.
[20:00:42] <fuzzie> The default Video backend should already be setup for that; default do-nothing implementations for BAM.
[20:01:28] <wjp> Edheldil_: it was unclear to begin with (I got a preview of the code after I asked for it, but it was never publically released), and the author didn't reply to emails if I could put it online or use it
[20:01:55] <Edheldil_> ahhh, the OpenGL one
[20:03:33] <wjp> the basic idea was to have a GLSprite which was a BAMSprite rendered to a texture with a specific palette.
[20:04:22] <tomprince_loki> Do you know if it had hardware acceleration of any of the rendering flags?
[20:04:38] <wjp> that's one bit I did work one myself
[20:05:01] <fuzzie> The opengl_test.c?
[20:05:10] <wjp> http://www.math.leidenuniv.nl/~wpalenst/bg2/opengl_test.png
[20:05:11] <wjp> fuzzie: yes
[20:05:26] <wjp> http://www.math.leidenuniv.nl/~wpalenst/bg2/opengl_test.c
[20:05:34] <wjp> disclaimer: that was my first opengl code ever
[20:06:09] <wjp> (and in fact my only opengl code ever, but that's unrelated :-) )
[20:10:11] <wjp> re. the SDL .inl: it's a way to have optimized special cases without rewriting the BAM rendering logic a dozen times
[20:10:37] <wjp> a similar thing might be doable with templates
[20:11:34] <fuzzie> without partially specializable templates it might not be too tidy, though
[20:11:43] <tomprince_loki> That was one of my thoughts, if I could actually understand what it is trying to do everywere.
[20:11:52] <tomprince_loki> Should need partial specialization.
[20:12:18] <tomprince_loki> Just have a single dumb code path, but have the tests be template paramaters, and the compiler should optimize the tests away.
[20:12:47] <wjp> that's basically what the current code does, but with macros
[20:19:00] <wjp> there are four main cases which affect things globally: with or without cover, and with or without RLE
[20:19:37] <wjp> the rest is more local (flipping of the image, different blending/transparency modes)
[20:20:05] <wjp> and clipping has a special role too
[20:20:42] <tomprince_loki> I think part of the difficulty I had was that some of the logic was in the .inl, and some was in the .cpp, and in .inl, some of the logic was at the top in the preprocessor, and some was inline with the code itself.
[20:20:56] <wjp> it "evolved" a bit
[20:21:40] <wjp> it would probably already help to indent the block of #ifdef at the top of the .inl
[20:24:24] <tomprince_loki> What would be nice to see, to be able to understand the code, is a dumb, straight line version, that doesn't do anything fancy with macros or anything. You could probably even take that, dump it into a template and have the same effect.
[20:25:49] <fuzzie> and there is all the work :p
[20:26:18] <tomprince_loki> I know. :) I tried and failed a couple of times.
[20:27:29] <wjp> a more useful thing to refactor IMHO is SwapBuffers which contains a ton of actual logic
[20:29:17] <fuzzie> scummvm's implementation of that is interesting, some crazy hashing attempts for dirty tiles etc
[20:29:31] <fuzzie> i mean, the a ctual buffer swapping :)
[20:29:43] <wjp> things like frame limiting, console logic, cursor changes shouldn't be in SDLVideo I think
[20:29:50] <wjp> tooltips
[20:30:11] <wjp> it's completely unclear what ::SwapBuffers should actually be doing
[20:31:27] <fuzzie> that is kind of difficult, because you don't want any busy-looping in there..
[20:31:34] <tomprince_loki> Anybody have any idea why cmake seems to be ignoring PREFIX or CMAKE_INSTALL_PREFIX 9 out of 10 times.
[20:31:47] <fuzzie> tomprince_loki: where are you setting it?
[20:31:48] <wjp> fuzzie: what do you mean?
[20:32:20] <lynxlynxlynx> -Dwhatever
[20:32:21] <fuzzie> wjp: nm, i guess you could simply pull the sleeping into the core.
[20:33:03] * wjp nods
[20:33:17] <tomprince_loki> That is what I am trying, but it seems to ignore that most of the time.
[20:33:24] <fuzzie> -D only changes the default value.
[20:33:38] <lynxlynxlynx> maybe some paths don't have it as a prefix
[20:33:38] <tomprince_loki> At least, with CMAKE_CXX_COMPILER set as well.
[20:33:49] <fuzzie> if you already have a CMakeCache.txt, it's too late for -D.
[20:34:11] <fuzzie> Edit the CMakeCache.txt instead, or delete it first.
[20:34:26] <tomprince_loki> Is there no way to force cmake to delete the cache?
[20:34:45] <fuzzie> 'cmake' is just intended to be a first-run tool, I think.
[20:35:07] <lynxlynxlynx> ccmake to the rescue
[20:35:07] <fuzzie> I'm sure there's some way to force it to start from scratch every time, but I don't know ity.
[20:36:13] <tomprince_loki> Well, when I also try have -DCMAKE_CXX_COMPILER=g++, the first time it works, and then when I run it again, with the exact same options, it reverts to CMAKE_INSTALL_PREFIX=/usr/local
[20:37:13] <fuzzie> That is stranger. But, check what's in the CMakeCache.txt?
[20:37:48] <fuzzie> The script in sf HEAD overwrites CMAKE_INSTALL_PREFIX with the contents of PREFIX, mind.
[20:39:28] <tomprince_loki> I think it must be a cmake bug, because it only happens when I set CMAKE_CXX_COMPILER, and only if there *is* a cache.
[20:39:43] <tomprince_loki> I was using PREFIX to start, and the same thing happened
[20:40:31] <fuzzie> The PREFIX variable is overwritten?
[20:41:19] <tomprince_loki> No, but it gets ignored.
[20:41:55] <fuzzie> I mean: -D only works the first time.
[20:42:45] <fuzzie> If -DCMAKE_CXX_COMPILER=g++ breaks it later but other -D definitions don't, that does seem like a bug.
[20:43:33] <tomprince_loki> It does break it.
[20:43:42] <fuzzie> But changing that variable is going to make cmake re-evaluate the whole script, which is going to stomp over CMAKE_INSTALL_PREFIX with PREFIX.
[20:44:29] <fuzzie> But shouldn't be any different to changing ZLIB_LIBRARY, for example.
[20:45:33] <tomprince> I first noted the problem using PREFIX.
[20:46:35] <-- tomprince_loki has left IRC (Read error: No route to host)
[20:46:37] <fuzzie> And your problem is not that your '-D' is being ignored, but that on subsequent runs, CMAKE_INSTALL_PREFIX is reverting anyway?
[20:47:19] --> tomprince_loki has joined #GemRb
[20:47:25] <-- tomprince_loki has left #GemRb
[20:47:29] --> tomprince_loki has joined #GemRb
[20:48:06] <tomprince> Well, the problem is that CMAKE_CXX_COMPILER seems to cause cmake to restart, and at that point it ignores any -D on the command line, or anything from the cache.
[20:49:00] <fuzzie> Ah. Yes. "You have changed variables that require your cache to be deleted."
[20:50:13] <fuzzie> However, it seems to work fine for me as long as I use -D to reset the PREFIX after that point, even with an existing cache.
[20:50:23] <wjp> tomprince: http://www.usecode.org/gemrb/blit.cpp
[20:50:28] <fuzzie> That is not a nice bug.
[20:50:49] <fuzzie> But it does *say* the stupid thing it's doing, for me.
[20:52:01] --> ratpor has joined #GemRb
[20:52:32] <fuzzie> I guess this is their attempt to work around -D only working the first time, but you'd think they should take notice of any passed -D parameters after they delete the cache.
[20:53:02] <fuzzie> Is it more broken than that?
[20:53:47] <tomprince> I don't think so.
[20:53:59] <tomprince> I guess I am just used to configure.
[20:54:10] <fuzzie> Well, no, it is completely non-obvious what it's doing there.
[20:54:38] <fuzzie> I don't think it's about being used to anything; I was about to suggest that it might be an idea to note this sort of thing on the wiki.
[20:56:37] <fuzzie> I just thought you were hitting a different set of madness, sorry.
[20:57:48] <tomprince> Well, at least I know what is going on now, and I know it isn't my changes that are breaking things.
[21:00:01] <tomprince> wjp: Thanks.
[21:01:35] <wjp> tomprince: I left in some macros of the 'readable' type (e.g., "if (ISTRANSPARENT(p))"), but took out all the flipping, and forced covers to enabled
[21:05:08] <tomprince> Are those the only two things left out? Because I think it wouldn't be too hard to add those back in, and turn it into a template.
[21:05:59] <tomprince> I don't know, but I think that would be easier to understand, since there would only be one code path, with the compiler taking care of optimizing it for all the special cases.
[21:06:22] * tomprince goes for supper.
[21:06:57] <fuzzie> If the compiler actually does, but that sounds fairly likely.
[21:07:19] <wjp> well, the number of code paths in the .inl is the same
[21:09:32] <CIA-74> GemRB: 03tom.prince * rca4eec055024 10gemrb/gemrb/plugins/ (3 files in 2 dirs):
[21:09:32] <CIA-74> GemRB: SaveGame: Switch to using DirectoryImporter, instead of opening files directly.
[21:09:32] <CIA-74> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[21:11:14] <fuzzie> The long march towards tidier GUIScripts.
[21:18:04] <lynxlynxlynx> nice
[21:18:33] <lynxlynxlynx> i always like commits that improved stuff while removing more lines than adding them
[21:21:44] --> cfchris6 has joined #GemRb
[21:22:45] <-- cfchris6_ has left IRC (Read error: Operation timed out)
[21:23:19] <fuzzie> i think tomprince already won the prize there, with the plugin reorganisation.
[21:24:38] <tomprince> Yes. +590/-6501 :)
[21:24:58] <tomprince> I think my commits do tend to skew to removing code...
[21:25:36] <tomprince> I was looking through the diffstats, and the blew me away.
[21:27:43] <tomprince> wjp: It is the same. All I know is that I can't understand or reason about the code in the .inl.
[21:28:43] <tomprince> I knew that SDL is the largest thing in the profile, and I was wondering if there was anything I could do to speed it up, but I couldn't tell, because I couldn
[21:28:51] <tomprince> t udnerstand the code.
[21:29:13] <fuzzie> I suspect dirty-rectangling would be the largest win there. But wjp would know better.
[21:30:06] <lynxlynxlynx> well, i topped that by killing entire branches of gametypes, but that was simpler
[21:32:54] <fuzzie> meh, if I try that tinting thing, I just get fog everywhere.
[21:35:41] <fuzzie> i guess the flag check is bad.
[21:39:34] <wjp> fuzzie: yes, quite possibly
[21:39:52] <fuzzie> whee, the area flags are zero
[21:40:40] <fuzzie> oh, no, wrong file. 7 = outdoor + day/night + weather. wierd, then.
[21:41:29] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[21:48:24] <wjp> I doubt rewriting it with templates will make it significantly easier to grasp, though. (Of course the time spent rewriting it will, but only for whoever does it :-) )
[21:48:55] <wjp> but there's definitely room for improvement
[21:49:58] <wjp> the main code block should be pretty readable in any case, with only the conditional flipping being a bit annoying
[21:50:27] <wjp> (or if that part isn't, it's not because of the macros :-) )
[21:50:34] <wjp> (but rather the lack of comments)
[21:52:40] <wjp> re. dirty rectangles: there's a chance the expensive parts of the blitting (actors, effects) will be dirty almost all of the time
[21:52:52] <tomprince_loki> No, the main block isn't really the problem. It is trying to figure out what all the macros do, and how they relate to the function/parameters that are passed.
[21:53:32] <tomprince_loki> At least, for me.
[21:53:36] <wjp> I should document the 'input' macros
[21:54:00] * wjp will do so right now
[21:54:44] <fuzzie> wjp: the SDL_BlitSurface from the backBuf to the disp is fairly expensive, I think.
[21:55:28] <wjp> fuzzie: hm, right
[21:59:36] <fuzzie> I guess the tints are just not so trivial as a full-surface blit.
[22:00:51] <fuzzie> I guess the timestop should've been a hint there.
[22:08:37] <wjp> a full-surface blit can't really tint, but only blend
[22:10:49] <wjp> (where with 'tint' I mean a multiplicative change to the colours, and by 'blend' an additive change)
[22:11:56] <CIA-74> GemRB: 03wjpalenstijn * r12b16c0b79aa 10gemrb/gemrb/plugins/Core/ (8 files): Fix whitespace
[22:11:58] <CIA-74> GemRB: 03wjpalenstijn * rb3302190eac2 10gemrb/gemrb/plugins/SDLVideo/SDLVideoDriver.inl: Add some macro docs to SDLVideoDriver.inl
[22:12:08] <fuzzie> yes. was just hoping for a better result without needing real work!
[22:12:26] <wjp> :-)
[22:17:06] <wjp> making BlitGameSprite use an extra tint shouldn't be too hard actually. You'd just have to force the tint flag on, and multiply the old tint with the global one for already tinted sprites
[22:21:43] <fuzzie> Well, if you want to peer at it, http://fuzzie.org/nfs/gemrb/attempted_global_tint_hack.txt is what it says; I imagine only the first file is useful.
[22:23:24] <wjp> is there an easy location to test it?
[22:25:10] <fuzzie> Any outside area between 20:00 and 04:00, for example. I've been using the first bg1 cutscene, maybe not so convenient.
[22:37:13] <tomprince_loki> or.cz/cmake: Use sane defaults for directory structure, and nuke autotools.
[22:37:27] <wjp> hm, now if I only remembered how the background tiles were drawn...
[22:38:25] <fuzzie> BlitSprite from TileOverlay?
[22:39:28] <wjp> oh, I'm just blind; right :-)
[22:41:39] <wjp> a bit annoying that those take are rendered entirely differently
[22:41:42] <wjp> s/take //
[22:42:56] <wjp> hm, at night in the Windspear hills (BG2) the global tint is 224,128,128,64
[22:43:00] <fuzzie> they're still not doing the blending right
[22:43:02] <wjp> which is decidedly red
[22:43:37] <wjp> probably fine for the actors, but should the background also be tinted that way?
[22:43:38] <fuzzie> "dark, reddish", says the comment.
[22:44:22] <fuzzie> i seem to remember the blending theory here is that it should only darken the colours, or somesuch.
[22:45:09] <fuzzie> tomprince_loki: you have removed the INSTALL_RPATH?
[22:45:35] <fuzzie> Oh, right, you're pointing it at plugin directory up there.
[22:45:51] <tomprince_loki> That should actually point to LIB_DIR.
[22:46:25] <Edheldil_> can cmake do conditional compilation?
[22:46:34] <fuzzie> 'conditional'?
[22:46:36] <tomprince_loki> Yes.
[22:47:06] <tomprince_loki> We do, look at PNGImporter.
[22:47:22] <fuzzie> We don't support *nix-type installs on OS X, so it shouldn't be fhs.
[22:47:29] <fuzzie> Not really awake enough to comment on the rest.
[22:47:33] <wjp> http://www.usecode.org/gemrb/global_tint_hack2.png http://www.usecode.org/gemrb/global_tint_hack2.txt
[22:49:36] <wjp> but I guess those colours are just rough first attempts
[22:49:48] <tomprince_loki> What type of installs do we do on osx?
[22:50:23] <fuzzie> tomprince_loki: I think we *don't*, but we build for bundle deployment.
[22:51:56] <tomprince_loki> Well, it doesn't look like there is any support for it in cmake. Unless it should default to home
[22:53:12] <tomprince_loki> And it looks like that patch does break rpath. Will debug.
[22:53:53] <fuzzie> it is a stupid bug where you must set the rpath per binary, i think
[23:04:21] <fuzzie> wjp: my motivation is mostly the background tiles, so maybe back to the drawing board on that side..
[23:08:33] <Edheldil_> brb
[23:08:37] <-- Edheldil_ has left IRC (Quit: Really?)
[23:09:58] --> edheldil_ has joined #GemRb
[23:12:50] <wjp> fuzzie: http://www.usecode.org/gemrb/global_tint_hack3.png
[23:12:56] <wjp> (don't mind the broken clipping)
[23:17:23] <wjp> broken patch: http://www.usecode.org/gemrb/global_tint_hack3.txt
[23:20:55] <wjp> hm, maybe I should just make BlitSprite call BlitGameSprite in that special case
[23:21:37] <wjp> oh, never mind, won't work
[23:21:48] <wjp> !BAM...
[23:22:26] <tomprince_loki> :)
[23:23:09] <wjp> that's one of the "TODO"s in BlitGameSprite :-)
[23:25:37] <wjp> not hard to do, though, since the 8-bit, non-RLE SDL surface case is identical to the BAM, non-RLE case
[23:26:31] <fuzzie> sorry, 1am apparently time for phone calls
[23:32:50] <wjp> bed time; good night
[23:34:02] <tomprince_loki> Night.
[23:44:54] <fuzzie> wjp: that tint looks ok to me, in bg1
[23:59:05] <tomprince_loki> or.cz/cmake: rpath works now.