[01:19:34] <-- nickdaly has left IRC (Remote host closed the connection)
[01:29:20] <pupnik> good ol nickdaly
[01:59:21] <-- |Cable| has left IRC (Read error: Operation timed out)
[02:00:35] --> |Cable| has joined #GemRb
[02:27:08] --> MikeChelen has joined #GemRb
[02:27:19] <MikeChelen> where does autotools put the final binary?
[02:33:01] <edheldil_> MikeChelen: if they still work, without installation they leave it in gemrb/ dir.
[02:33:47] <MikeChelen> edheldil_: hmm there doesn't seem to any executable created there
[02:33:53] <MikeChelen> *seem to be
[02:39:04] <edheldil_> there used to be, but the autotools might be broken. Actually, it's not a binary but a shell script, the binary is in gemrb/.libs/lt-gemrb or something like that
[02:51:56] <-- edheldil_ has left IRC (Ping timeout: 255 seconds)
[02:56:28] <MikeChelen> oh yeah, but there doesn't seem to be that script either
[05:04:20] <tomprince> MikeChelen: can you pastebin the output of make (with autotools)? My buildbot is generating gemrb/gemrb and gemrb/.libs/gemrb with autotools.
[06:02:49] <-- |Cable| has left IRC (Read error: Connection reset by peer)
[06:04:15] --> |Cable| has joined #GemRb
[06:25:12] --> edheldil_ has joined #GemRb
[07:10:19] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[07:56:57] --> Bo_Thomsen has joined #GemRb
[08:04:33] --> lubos has joined #GemRb
[08:17:32] --> lynxlynxlynx has joined #GemRb
[08:17:32] --- ChanServ gives channel operator status to lynxlynxlynx
[08:17:51] <fuzzie> morning
[08:18:19] --> adominguez has joined #GemRb
[08:19:05] --> Demitar has joined #GemRb
[08:20:28] <lynxlynxlynx> oj
[08:27:44] <fuzzie> fixing this update stuff is a bit horribly intermixed
[08:28:01] <fuzzie> but it is blue sky outside today :)
[08:39:36] <edheldil> indeed
[08:47:56] <edheldil> tomprince, are you still here?
[08:49:51] <fuzzie> he is usually asleep by this time
[08:51:36] <edheldil> anyone cares to comment on https://github.com/edheldil/gemrb/tree/textareacolor ?
[08:51:52] <fuzzie> i like the sound of the commit name
[08:53:13] <fuzzie> it looks simple enough
[08:54:04] <fuzzie> but i guess it isn't really right?
[08:54:15] <edheldil> what do you mean?
[08:54:40] <fuzzie> let me look a moment
[08:55:50] <fuzzie> hmm it just confuses me :( but if you think it's right, looks good
[08:56:31] <fuzzie> it's just strange that this stuff isn't represented by the three colours provided by the data
[08:56:43] <fuzzie> but i don't understand what the three colours are, i guess?
[08:57:17] <fuzzie> IESDP helpfully documents as 'Colour #1', 'Colour #2' and 'Colour #3', i see
[09:00:00] <edheldil> from the ctor args and my tests the colors are text hi, initial, text lo
[09:00:22] <fuzzie> yes, but i mean, i have no clue what that means :-P
[09:00:24] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[09:01:08] <edheldil> from text hi and text lo you get normal text color - it's a 2 color palette or whatever the CreatePalette() call does
[09:01:42] <edheldil> initial presumably is for initial letters, but I did not care to cheeck
[09:02:21] <edheldil> there are not colors for selection and hover (at least I do not know them), so they were hardcoded
[09:03:57] <fuzzie> the initial letters aren't coloured and i think aren't supported for this anyway
[09:04:54] <fuzzie> i guess this is a UIControlTextDisplay
[09:05:32] <edheldil> do you mean the function in the original engine?
[09:05:44] <fuzzie> what it represents in the original engine
[09:07:12] <edheldil> Sorry, I do not copy you :)
[09:07:35] <fuzzie> that is the 'TextArea which can select stuff' class, in the original engine
[09:07:43] <edheldil> ah
[09:07:44] <fuzzie> i have no idea, which function is responsible :)
[09:09:29] <edheldil> when I tested with how GUIMOVIE in wine, the Color2 was not seen anywhere
[09:11:18] <fuzzie> original engine's ppc code for doing that is unreadable, so i will not try working it out now :)
[09:16:29] <edheldil> btw, I had an idea ... would it be useful to have some table or chart who has what original game/version/lang? So that you would know whom to ask for testing
[09:17:26] <fuzzie> it would probably be nice to have something on the wiki, along with how long ago someone checked it, but i'm not sure we have enough users to make it worth the effort?
[09:19:52] <edheldil> users or developers?
[09:21:54] <fuzzie> sorry, i mean: people who would actually test things
[09:25:18] <fuzzie> huh, walking in the original engine is based on whether stance is SEQ_WALK or not..
[09:25:35] <edheldil> if you are willing to give the info, I will make the effort :)
[09:27:01] <fuzzie> well i personally am very useless because i just have original English-language of everything :) but we can ask forums etc
[09:27:48] <lynxlynxlynx> there's already a page up that contains info on what needs to be tested
[09:27:58] <lynxlynxlynx> testing maybe
[09:28:42] <lynxlynxlynx> edheldil: does this fix the journal headers? :)
[09:28:42] <fuzzie> we really have to rewrite a lot of important bits of the code, soon :/
[09:28:57] <fuzzie> so some kind of organised testing would be good
[09:29:02] <lynxlynxlynx> (currently we hardcode the red, so you'd have to remove that)
[09:29:48] <lynxlynxlynx> fuzzie: once you're done with it, i will play through bg2 again
[09:29:58] <fuzzie> that would be great
[09:30:27] <edheldil> no, it concerns texttareas serving as listboxes. And bestiary uses different set of colors (white and gray)
[09:31:51] <edheldil> ahh, sorry, I meant pst
[09:32:35] <lynxlynxlynx> i see
[09:41:52] <edheldil> fuzzie, since you have the en versions - can you sometime test what do the iwd/how movie subtitles look like in the original engine? is it NORMAL or REALMS2 font?
[09:51:01] <fuzzie> can't run original :P
[09:51:36] <edheldil> the journal header color is set in GUIJRNL.py:187, so it is not hardcoded :)
[09:51:49] <edheldil> in bg2
[09:52:21] <edheldil> at all?
[09:54:55] <fuzzie> well, i can run the original, but it is a bit of a pain when i have time
[09:54:58] <fuzzie> i will look at it
[09:56:54] <edheldil> np, no worries
[09:58:09] <-- |Cable| has left IRC (Remote host closed the connection)
[10:21:04] <lynxlynxlynx> edheldil: it's hardcoded by us
[10:22:06] <lynxlynxlynx> i think the previous discussions on this topic resulted in the thinking we are missing some pallete
[10:22:27] <lynxlynxlynx> it's very ugly now, since not everything gets recolored
[10:23:50] <edheldil> I am trying one solution atm
[10:27:31] <edheldil> Yayy, it works!
[10:27:55] <fuzzie> we need it to look like the original for some case i forget - a worldmap, maybe?
[10:28:11] <edheldil> I have found the source of ugliness :)
[10:28:22] <fuzzie> and i thought our previous discussions concluded that the palette-making function was broken in an obvious manner
[10:28:50] <fuzzie> but i thought edheldil was the one who worked that out, so maybe my memory is bad :P
[10:29:22] <fuzzie> but it was CreatePalette doing something really dumb, i thought.
[10:30:40] <lynxlynxlynx> yeah, the worldmap has the same issue
[10:31:29] <fuzzie> oh right, last time we discussed getting rid of the BAM hack in the Font entirely
[10:33:06] <fuzzie> edheldil: you leave us in suspense :)
[10:34:44] <edheldil> This produces much better output (it's a hack, though) https://github.com/edheldil/gemrb/tree/fontcolortag
[10:35:37] <fuzzie> ah
[10:35:43] <fuzzie> nice
[10:35:46] <fuzzie> we can probably fix that properly
[10:36:27] <fuzzie> but you could add '// TODO: hack' to it and commit
[10:38:23] <fuzzie> but the use of 'palette' makes me worry about why Font::FinalizeSprite checks if palette is non-null
[10:38:59] <fuzzie> it is not ok to use 'pal' there?
[10:39:13] <fuzzie> as usual i'm not sure what 'hicolor' is..
[10:39:39] <edheldil> uncommittable, it screws pst's worldmap icons and does nothing for pst worldmap font, as expected
[10:40:11] <fuzzie> meh
[10:41:39] <edheldil> possibly the bugs are in the wmap code - it probably creates wrong palette
[10:41:53] <fuzzie> yes
[10:42:08] <fuzzie> well, i don't find it a priority, because it doesn't break the game at any point
[10:43:17] <fuzzie> and that font code needs rewriting due to bugs
[10:43:37] <fuzzie> but if you could find some way to hack it for now so that it looks pretty, i'm sure many would appreciate :)
[10:44:45] <lynxlynxlynx> indeed
[10:57:14] <edheldil> well, I see pst wmap looks ugly even without my path :)
[10:57:21] <edheldil> patch
[10:57:27] <fuzzie> hehe
[10:57:31] <fuzzie> i think bg1 one is the interesting one
[10:57:40] <fuzzie> i am too lazy to try applying it right now because my tree is in little pieces
[11:02:14] <edheldil> I would say it's the same, which was expected - it does not use the [color] tag
[11:03:09] <fuzzie> cool
[11:04:51] <lynxlynxlynx> go go go :)
[11:05:18] <edheldil> but if I change the background color in WorldMap.cpp, it starts to look nice, so it's the matter of unhardcoding it somehow
[11:22:42] <edheldil> I will try this approach: all controls will have guiscript-settable background color. If they print a text, they will pass it as a new argument to Font::Print*(), so it can be used for [color] tag. They will be also responsible for creating palettes with that color for untagged text
[11:37:24] <fuzzie> this sounds reasonable
[11:37:45] <fuzzie> although the background colour for the controls should be in the data somewhere?
[11:47:23] <lynxlynxlynx> is there any nontextured background anywhere at all?
[11:48:32] <fuzzie> at a glance the original engine does seem to simply take two colours to construct the font, and then render that naively
[11:48:47] <fuzzie> but i will look at some point to make sure it's not secretly blending
[12:13:53] <edheldil> naively == the same way we do?
[12:21:07] <-- MikeChelen has left IRC (Ping timeout: 240 seconds)
[12:25:35] <fuzzie> yes
[12:28:51] <edheldil> yes, it would be nice if you will be able to find out
[12:29:27] --> MikeChelen has joined #GemRb
[12:29:34] <edheldil> I bet on blending :)
[12:30:57] <fuzzie> 493afc: bl 4b6fe0 <IDirectDrawSurface_ReleaseDC(IDirectDrawSurface *, OpaqueGrafPtr *)>
[12:31:01] <fuzzie> ^- somehow i don't believe a word
[12:32:27] <-- ar has left IRC (Ping timeout: 248 seconds)
[12:32:33] --> ar has joined #GemRb
[12:32:37] <-- ar has left IRC (Changing host)
[12:32:37] --> ar has joined #GemRb
[12:34:51] <edheldil> believe whom? IDA? :)
[12:35:13] <fuzzie> that is objdump output from bg2 mac
[12:35:35] <fuzzie> presumably the mac porters faked that bit :)
[12:36:28] <edheldil> ah
[12:37:14] <edheldil> probably they wrote their DirectDraw api layer
[12:37:31] <edheldil> similar to what wine does
[12:37:49] <fuzzie> probably not quite that nice, it has mac calls in here too
[12:39:40] <fuzzie> the font render code just creates a palette and does a blit, no surface lock for blending
[12:44:55] <edheldil> does it create the palette the same way we do? i.e. ramp from one color to the other
[12:44:58] <edheldil> ?
[12:45:34] <fuzzie> i didn't look, but it does take two colours
[12:47:11] <fuzzie> i am not at all used to ppc asm
[12:49:43] <fuzzie> it sets entry 0 to 0/255/0
[12:49:56] <edheldil> as we do
[12:50:49] <fuzzie> and the rest to (100*back + i*100*(color-back)/256)/100
[12:51:12] <fuzzie> which is close enough
[12:51:26] <fuzzie> it does store the colours though :-)
[12:52:25] <edheldil> I think the [color] tag is our own, so perhaps it would be better (for tagged text) to allow it to define background color as well. This way there's no need to change Font::Print*() api
[12:52:31] <fuzzie> not in the palette, but in the font
[12:53:31] <edheldil> to avoid calculating the palette if the colors do not change, probably
[12:54:39] <edheldil> but does it mean there are more copies of a font in memory?
[12:55:27] <fuzzie> well, i assume the fonts in the original engine don't go through stupid loops to avoid relying on BAMs
[12:55:36] <fuzzie> so there's not much of a problem having more fonts around
[12:55:59] <fuzzie> i really have no idea why we have this hack around
[12:56:08] <edheldil> maybe we could create a simple cache of (color,color) -> palette
[12:56:27] <fuzzie> but we have worse performance issues than palettes honestly :)
[12:56:47] <fuzzie> so i would just not worry about caching, if you work on this
[12:56:59] <edheldil> not at the moment, work ;-)
[12:57:09] <fuzzie> i'm not sure having to put background color into all the [color] is nice though
[12:57:36] <edheldil> so do you think they have a separate copy of a font for each label?
[12:58:07] <fuzzie> they do seem to
[13:00:05] <edheldil> well there are about 10 lines matching 'color=%' in gemrb, so I think it would not be so bad
[13:00:17] <fuzzie> well
[13:00:29] <fuzzie> the only thing which is on-screen usually is the message window
[13:00:37] <fuzzie> and that is often full of colours
[13:01:28] <edheldil> ah, there are more matching '[color'
[13:03:28] <fuzzie> but we can do something efficient there
[13:03:37] <fuzzie> maybe the [color] tag idea is just not clever
[13:03:56] <edheldil> IMO it's reasonable - if you specify foreground, you can specify the background as well. If you will not specify, it will default to black
[13:04:11] <fuzzie> but the background will *always* be in the same, right?
[13:04:42] <edheldil> always for the same part of window pixmap
[13:04:45] <fuzzie> i mean, for some given call
[13:05:19] <edheldil> yeah, probably
[13:09:59] <edheldil> the only problem I see with that would be text which would not have fixed position on a screen *and* having the tag embedded (e.g. in TLK)
[13:11:28] <edheldil> but as long as you append the tag on the same spot where you decide what to put as a background color in Font::Prin*(), there should not be a problem, imho
[13:26:13] <fuzzie> well, maybe i'm misunderstanding
[13:27:19] <fuzzie> it seems like you have an option between some only-one-call-needed 'background colour' variable, and having to add stuff every time you add a string, and you pick the second :)
[13:30:44] <fuzzie> i suppose if the background really is almost always black..
[13:32:17] <fuzzie> but this brings me back to how i don't understand the CHU font settings, since it looks like lowtextcolor would be a moddable background colour
[13:41:03] <edheldil> hmm, true, it is
[13:42:05] <edheldil> I have got lost in my own reasoning :).
[13:42:22] <edheldil> OTOH there is not such color in Buttons
[13:43:22] <fuzzie> well i have no idea what is 'nice' design, just don't want something which breaks mods which modify the message window UI
[13:43:47] <fuzzie> even if they all seem spectacularly hideous
[13:44:05] <fuzzie> will have to see if they actually make it work, but can't run anything now
[13:53:53] <edheldil> it's the problem caused by the fact that some UI elements and parameters are iin CHUI files and some are not :(
[13:54:08] <fuzzie> yes. bioware were crazy.
[13:54:20] <fuzzie> putting it all in the UI would have been much nicer
[13:54:28] <fuzzie> unfortunately the UI is much more hard-coded than i'd have thought
[13:54:52] <edheldil> something new?
[13:55:13] <fuzzie> for example there is a CUIControlScrollBarCharacterLevelUpProficiencies and a CUIControlScrollBarCharacterProficienciesScroll
[13:55:39] <fuzzie> each implementing OnPageDown, OnPageUp, OnScrollDown, OnScrollUp, OnScroll, InvalidateItems..
[13:55:54] <fuzzie> and this applies to *every UI element*
[13:56:36] <edheldil> i.e. each widget is in a separate class?
[13:56:41] <fuzzie> yep
[13:57:45] <edheldil> and if there are 6 buttons on e.g. PST main menu, would they each be their own class as well?
[13:59:26] <fuzzie> well i don't know about pst :)
[13:59:33] <fuzzie> interestingly, maybe InfScreenStart is less silly
[14:00:04] <fuzzie> it has CUIControlButtonStartFirstToB and CUIControlButtonStartFirstSoA and CUIControlButtonStartFirstQuit and etc, for the bg2 first screen
[14:00:49] <fuzzie> but i don't see anything for the newgame/loadgame/etc stuff
[14:01:36] <fuzzie> so maybe they were sane with that main menu :-P
[14:04:31] <fuzzie> http://fuzzie.org/nfs/gemrb/ui_controls_tob.txt <- i guess it is not *so* bad a list, but you see how much is hardcoded
[14:05:22] <fuzzie> imo it makes our UI seem like a shining star of sensible design :P
[14:06:21] <edheldil> heh.
[14:06:49] <edheldil> maybe they just preferred to have widget handlers in controls instead of windows as we do
[14:34:21] --> pupnik_ has joined #GemRb
[14:37:07] <-- pupnik has left IRC (Ping timeout: 240 seconds)
[14:54:54] --> Maighstir has joined #GemRb
[15:00:26] <-- MikeChelen has left IRC (Ping timeout: 252 seconds)
[15:15:20] --> MikeChelen has joined #GemRb
[15:33:34] <-- MikeChelen has left IRC (Read error: Operation timed out)
[16:52:56] <-- lubos has left IRC (Quit: Leaving.)
[16:54:00] <-- Demitar has left IRC (Quit: Burn the land and boil the sea, you can't take the sky from me!)
[17:03:27] <fuzzie> yes, i'm sure they did, but that doesn't stop it from being insane
[18:04:01] <-- adominguez has left IRC (Remote host closed the connection)
[18:32:45] --> |Cable| has joined #GemRb
[19:27:54] --> spike411 has joined #GemRb
[19:42:14] <lynxlynxlynx> http://asset.soup.io/asset/1640/9261_ba93_960.jpeg :)
[19:42:37] <fuzzie> hehe
[19:42:52] <fuzzie> where's that from?
[19:45:34] <spike411> PST vs. DA?
[19:46:03] <pupnik_> o/'s everyone
[19:49:59] <lynxlynxlynx> or da2, dunno
[21:13:51] --> Boriskr has joined #GemRb
[21:36:11] --> mysticX has joined #GemRb
[21:44:04] <-- Boriskr has left IRC ()
[21:49:15] <fuzzie> ok, tomprince's win32 build tells me that gemrb.cfg isn't found
[21:50:06] <fuzzie> so that would be 'not working' :P
[21:54:50] <fuzzie> it does not however explode on startup.
[21:59:35] <fuzzie> well, the "return (file == INVALID_HANDLE_VALUE);" possibly doesn't help i suppose
[22:28:56] --> kettuz has joined #GemRb
[22:37:45] <-- kettuz has left IRC (Quit: Leaving)
[23:10:52] --> edheldil_ has joined #GemRb
[23:11:17] <edheldil_> evening!
[23:16:54] <-- Maighstir has left IRC (Read error: Connection reset by peer)
[23:20:16] <fuzzie> evening
[23:22:03] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:32:30] <tomprince> fuzzie: yes, that seems very stupid. New build with that fixed at http://gemrb.hocat.ca/buildbot/builders/mingw32%20g%2B%2B-4.5.0/builds/26 (in about 8 minutes) if you still have a win32 around.
[23:33:16] <fuzzie> i don't, but will check in morning if no-one else beats me to it
[23:45:58] --> MikeChelen has joined #GemRb
[23:46:04] <MikeChelen> has anyone tried making a gemrb ppa?
[23:46:30] <fuzzie> no
[23:46:57] <MikeChelen> it might be helpful to make the latest versions available for more people
[23:47:13] <fuzzie> we discussed it and figured it would probably be just as good to build debs using the opensuse farm
[23:47:25] <fuzzie> but we don't have any official debian packaging yet, afaik..
[23:47:32] <MikeChelen> .deb would be fine too
[23:48:00] <MikeChelen> maybe that would be a good thing to work on?
[23:50:54] <MikeChelen> there are probably alot of debian/ubuntu users that would be happy to help
[23:51:24] <fuzzie> well, maybe
[23:51:40] <fuzzie> i have not much hurry about it because after the release we'll probably be breaking gemrb for a while :)
[23:51:56] <tomprince> If somebody provides me with a debian VM setup to build gemrb debs, along with instructions, I could hook it up to my buildbot. (or if somebody simply wanted to setup a buildslave for it)
[23:52:32] <fuzzie> yes, but the 'making it work' is the tricky bit :P
[23:53:42] <pupnik_> hmm debian has no gemrb eh
[23:54:12] <fuzzie> lubos has some packaging in pkg-games svn, the playdeb people have some packaging, there's some ubuntu packaging
[23:54:32] <fuzzie> but like all the distro packaging, none of it was very good last time i looked, it is difficult
[23:56:09] <pupnik_> https://bugs.launchpad.net/debian/+bug/148427 might be the person to contact (Oliver Sauder)
[23:56:35] <pupnik_> http://revu.ubuntuwire.com/p/gemrb
[23:56:52] <fuzzie> well, i tend to have no patience for packagers who don't even try and work out why their packages are broken..
[23:57:12] <pupnik_> indeed
[23:59:11] <pupnik_> also note: http://maemo.org/packages/view/gemrb/