#gemrb@irc.freenode.net logs for 10 Jan 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:06:42] <chiv> finally, found the bugger: 安姆阴影 is what it should look like
[00:08:00] <chiv> the sad thing about chinese glyphs, they are easy enough to write, they are excruciating to try and get them into a computer from meatspace...
[00:10:14] <-- brada has left IRC (Quit: brada)
[00:10:50] <-- chiv has left IRC (Quit: Page closed)
[00:12:47] --> brada has joined #gemrb
[00:14:07] <-- brada has left IRC (Client Quit)
[00:31:28] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[00:36:15] --> brada has joined #gemrb
[00:36:25] <brada> well double byte support is pretty much done
[00:36:41] <brada> now the hard part of interpreting diffrent encodings :/
[00:48:02] <-- edheldil__ has left IRC (Ping timeout: 255 seconds)
[01:01:46] <brada> fuzzie will be happy to learn that i have switched to FT_Select_Charmap instead of specifying ranges in fonts.2da
[01:02:08] <brada> we still need a way of specifying the encoding to use, however
[01:02:27] <brada> ill make a similar change to bam fonts
[01:02:37] <brada> and just go off the frame count or something
[01:07:18] <traveler__> http://img59.imageshack.us/img59/1932/201301100205411440x900s.png
[01:07:39] <traveler__> rest interrupted by greater doppelanger
[01:08:06] <traveler__> problem is, i'm have a bit too large view e.g i'm seeing area _behind_ closed hidden doors
[01:08:21] <traveler__> and poor creature got spawned _in_ the locked doorframe
[01:08:32] <traveler__> *i'm having
[01:09:13] <traveler__> so problem is- fog of war is not correct with hidden passages?
[01:09:35] <brada> i dotn think anybody is awake right now that can answer that...
[01:09:44] <traveler__> yeah, i know
[01:10:12] <traveler__> just logging it because it's pretty corner case
[01:10:27] <traveler__> but confirming my suspicions about fog of war
[01:12:00] <traveler__> fwiw he is immobile, as well as un-attackable
[01:44:39] <-- Cuvieronius has left IRC ()
[01:55:45] --> nutron has joined #gemrb
[02:49:00] <-- Cable__ has left IRC (Ping timeout: 255 seconds)
[02:50:07] --> |Cable| has joined #gemrb
[02:52:05] --> Cable_ has joined #gemrb
[02:55:23] <-- |Cable| has left IRC (Ping timeout: 244 seconds)
[02:56:34] <-- Cable_ has left IRC (Ping timeout: 240 seconds)
[02:58:31] --> |Cable| has joined #gemrb
[03:00:50] --> Cable_ has joined #gemrb
[03:02:54] <-- |Cable| has left IRC (Ping timeout: 240 seconds)
[03:05:38] <-- Cable_ has left IRC (Ping timeout: 255 seconds)
[03:46:07] <-- CamDawg has left #gemrb
[03:49:47] --> CamDawg has joined #gemrb
[04:16:12] <-- brada has left IRC (Quit: brada)
[04:42:14] --> brada has joined #gemrb
[05:02:41] <-- brada has left IRC (Quit: brada)
[05:10:25] --> brada has joined #gemrb
[05:17:23] --> |Cable| has joined #gemrb
[05:57:07] <-- brada has left IRC (Quit: brada)
[06:05:34] --> brada has joined #gemrb
[06:41:55] <-- brada has left IRC (Quit: brada)
[06:53:04] --> edheldil_ has joined #gemrb
[07:28:44] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[07:31:38] --> miha has joined #gemrb
[07:55:04] <fuzzie> brada: don't know if you read logs, but i'm impressed, nice. :)
[08:30:35] --> edheldil_ has joined #gemrb
[08:33:23] --> lynxlynxlynx has joined #gemrb
[08:33:23] <-- lynxlynxlynx has left IRC (Changing host)
[08:33:23] --> lynxlynxlynx has joined #gemrb
[08:33:23] --- ChanServ gives channel operator status to lynxlynxlynx
[08:33:50] <-- kamui has left IRC (Read error: Operation timed out)
[08:34:13] --> kamui has joined #gemrb
[08:39:18] --> WingedHussar has joined #gemrb
[08:40:23] <-- edheldil_ has left IRC (Ping timeout: 252 seconds)
[09:39:35] <edheldil> sigh .... iesh is able to read and display chinese/korean/japanese dialog.tlk :(
[09:41:02] <lynxlynxlynx> you still need a good font though
[09:43:22] <edheldil> the one in ubuntu should work, should not it?
[09:51:27] <edheldil> e.g.: http://imgur.com/47mHQ . I can't be sure, but the structure looks ok to me
[09:51:28] <Seniorita> imgur: the simple image sharer
[09:52:17] <lynxlynxlynx> no idea
[09:52:51] <lynxlynxlynx> i use dejavu, which has good coverage afaik, but sometimes oriental websites are still missing glyphs
[09:55:25] <edheldil> hehe, this is the google translation of the first strref of the chinese version os pst: "I'll be waiting for you in the halls of death, my love." She smiled, but the smile was only sadness. Issued dreamy sigh, she closed her eyes, and gradually disappeared.
[09:55:49] <edheldil> it's somehow TOO good not to be take literally from somewhere :)
[09:55:59] <edheldil> taken as a whole
[09:58:44] <edheldil> hmmm, other strings have reasonably good translations as well, maybe google is just good. And it shows that iesh converts the encoding correctly
[10:00:59] --> edheldil_ has joined #gemrb
[10:03:14] <lynxlynxlynx> :)
[10:05:20] <edheldil> heh, treacherous partial transparency, you can actually read text in the window behind the terminal in the screenshot I posted :)
[10:10:44] --> Coriander2 has joined #gemrb
[10:11:49] <-- Coriander has left IRC (Ping timeout: 246 seconds)
[10:14:05] <edheldil> ./ieparse.py -o format.tlk.encoding=cp950 -o encoding=utf8 /home/benkovsk/w/pst_cn_files/Dialog.tlk |less
[10:18:12] <-- Coriander2 has left IRC (Quit: Nettalk6 - www.ntalk.de)
[10:40:33] <-- |Cable| has left IRC (Ping timeout: 248 seconds)
[10:53:20] --> |Cable| has joined #gemrb
[11:54:07] <fuzzie> hi, btw.
[11:54:18] <edheldil> Hi
[11:56:19] <fuzzie> I am impressed that ieparse can do that.
[11:58:33] <fuzzie> Of course it no longer runs for me. :P
[11:58:52] <fuzzie> I shall have to catch up on the dependencies.
[11:59:06] <edheldil> no? I might have forgotten to push some changes
[11:59:12] <fuzzie> I'm just missing PIL, I think.
[11:59:30] <fuzzie> hm, it complains that the ascii codec can't decoe bla bla
[11:59:49] <edheldil> Ahh ... it was originally optional, but then I hacked in ugly hacks to get something working
[12:00:07] <fuzzie> ah, only if I pass it the wrong encoding :)
[12:00:33] <edheldil> there are some suggestions in infinity/defaults.py
[12:00:40] <fuzzie> (I don't have any Chinese files, so I'm trying with cp932 and the Japanese bg2 tlk.)
[12:01:48] <fuzzie> It seems to pass the Google Translate test fine, so nice.
[12:02:23] <fuzzie> Heh, it knows 'Copper Coronet'. :P
[12:02:33] <fuzzie> There's no way that can be a coincidence either.
[12:03:12] <fuzzie> So I remain impressed, really nice tool, edheldil
[12:03:13] <edheldil> also feel free to edit the relevant wiki page on encodings :)
[12:03:37] <edheldil> thank you :)
[12:50:25] --> kida has joined #gemrb
[13:21:31] <-- kida has left IRC (Remote host closed the connection)
[13:24:48] --> kida has joined #gemrb
[13:30:34] <-- CamDawg has left IRC (Quit: Leaving.)
[13:49:55] --> CamDawg has joined #gemrb
[13:50:05] <-- CamDawg has left #gemrb
[13:50:26] --> CamDawg has joined #gemrb
[13:56:29] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[13:59:19] --> lynxlynxlynx has joined #gemrb
[13:59:19] --- ChanServ gives channel operator status to lynxlynxlynx
[14:23:17] <traveler__> should i add to wiki what i've reported this night?
[14:29:38] <-- traveler__ has left IRC (Ping timeout: 245 seconds)
[14:32:39] <-- miha has left IRC (Quit: Lost terminal)
[15:16:20] --> miha has joined #gemrb
[15:17:29] --> edheldil__ has joined #gemrb
[15:18:10] <lynxlynxlynx> it's already there
[15:20:57] --> traveler has joined #gemrb
[15:21:17] <traveler> ah, good
[15:22:54] <traveler> no idea where, but i trust your judgement :)
[15:24:02] <lynxlynxlynx> it's a known issue in general, but there may be an entry in bg2, since we had a /corner/ case in the asylum
[15:24:39] <lynxlynxlynx> but, in this case, it could also just be a data bug if there's a gap
[15:24:56] <lynxlynxlynx> the spellhold one had nothing to do with doors
[15:27:14] --> brada has joined #gemrb
[15:27:53] <brada> i was hoping there was a good way to determine encoding from tlk, but i see you are passing it in
[15:28:02] <traveler> still, just uncovering (closed) hidden passages shouldn't enable pc to see a bit thought them?
[15:28:03] <-- Seniorita has left IRC (Remote host closed the connection)
[15:28:09] <traveler> *through
[15:28:13] <brada> i see language, but im not sure thats good enough
[15:28:24] <brada> so i guess we need a setting somewhere
[15:28:26] <fuzzie> traveler: hidden passages are just doors
[15:28:42] --> Seniorita has joined #gemrb
[15:28:53] <traveler> yes, that doesn't change my point?
[15:29:01] <traveler> you are expected to see through closed doors?
[15:29:19] <fuzzie> if there's a data bug, yes
[15:29:47] <brada> iirc that happens on occasion in original so...
[15:29:48] <traveler> and it would hit all closed/hidden doors?
[15:30:14] <traveler> oh, ty just the explanation i needed
[15:30:20] <fuzzie> oh this happens to *all* doors?
[15:30:28] <traveler> all hidden, yes
[15:30:28] <brada> well check it with the same door if you can
[15:30:36] <traveler> will check with other closed ones
[15:30:48] <brada> in original i mean
[15:30:56] <fuzzie> oh, sorry, that wasn't clear at all, it just seemed like you'd encountered a data bug with these doors
[15:31:03] <traveler> ah i don't have access to ms
[15:31:09] <brada> wine?
[15:31:13] <traveler> nope
[15:31:16] <edheldil> brada: were you talking about iesh?
[15:31:16] <brada> bg playes very nice in wine
[15:31:21] <brada> yes
[15:31:38] <brada> i need a way to determine tlk encoding for gemrb
[15:31:54] <traveler> brada: but wine _is_ a hassle in itself on amd64 freebsd
[15:32:13] <brada> why?
[15:32:14] <fuzzie> traveler: so which compiler/platform is this?
[15:32:29] <fuzzie> brada: because amd64 wine = 64-bit binaries only.
[15:32:44] <brada> ah
[15:32:49] <traveler> i'm on freebsd amd64
[15:32:51] <edheldil> you could do an analysis of which codes do/don't go together based on a language ...
[15:33:01] <brada> you cant run 32bit binaries on 64bit bsd?
[15:33:01] <traveler> moreover, i hacked off support for i386 from kernel
[15:33:13] <brada> oh
[15:33:13] <traveler> yeah, but that's just me
[15:33:17] <brada> ok
[15:33:18] <fuzzie> building the binaries is not much fun either, frankly
[15:33:23] <brada> no
[15:33:31] <traveler> indeed
[15:33:47] <fuzzie> wine is this single annoying has-to-be-32-bit thing lurking everywhere
[15:34:09] <brada> well i imagine that is for a good reason
[15:34:16] <edheldil> brada: the current encoding config var was a stopgap, you could expand it's meaning
[15:34:17] <fuzzie> I like how all the code I'm reading has conversations between myself and Avenger in the comments.
[15:34:39] <fuzzie> brada: yes, a bunch of lazy people haven't reimplemented all proprietary windows binaries as open-source yet! :)
[15:34:53] <brada> that would be exactly what i meant :p
[15:35:44] <brada> ed: just to be clear, there is not a good way of automatically determining this thought the tlk itself correct?
[15:35:56] <edheldil> btw, have you managed to run 32bit dx/opengl games on a 64bit linux under wine?
[15:35:57] <fuzzie> the tlk has no encoding field in a header or osmething, if that's what you mean.
[15:36:08] <fuzzie> edheldil: as long as you have a 32-bit opengl library it should be fine.
[15:36:08] <brada> i see a language one tho
[15:36:32] <edheldil> brada: you could use known strrefs and hope somebody did not mod them
[15:36:35] <fuzzie> brada: in IE?
[15:36:47] <brada> in tlk format
[15:36:51] <fuzzie> yes, but IE's tlk format?
[15:37:03] <brada> http://gemrb.org/iesdp/file_formats/ie_formats/tlk_v1.htm
[15:37:07] <fuzzie> hm, right, it's in iesdp
[15:37:07] <Seniorita> TLK File Format
[15:37:08] <fuzzie> interesting
[15:37:20] <brada> but is that good enough?
[15:37:26] <fuzzie> well, is it actually valid?
[15:37:35] <brada> thats also a good question
[15:37:51] <fuzzie> I would be suspicious that someone just copied that from the NWN docs.
[15:38:03] <fuzzie> but should be easy to check if you all have the relevant files..
[15:38:19] <brada> that and home rolled tlks like the chinese one prolly dont have a valid value set anyway
[15:38:25] <brada> so even if it was generally useable
[15:38:31] <brada> we would still need an override
[15:39:01] <brada> so may as well do what ed said
[15:39:15] <fuzzie> that field in a japanese tlk is 0x4, if it helps
[15:39:21] <brada> didnt even know gemrb char an encoding setting...
[15:39:40] <fuzzie> (and 0x0 in my english copy)
[15:41:43] <edheldil> brada: it's newly described , so probably fan made tlks did not use it
[15:41:55] <brada> right
[15:42:03] <brada> which is why im going with a setting
[15:42:04] <edheldil> czech and russian bg1 has it as 0
[15:43:52] <edheldil> chinese pst has 5, korean 63616, polish bg1 has 0 ...
[15:44:00] <brada> so im gonna use the Encoding settings...
[15:44:19] <brada> but we usu it as a language string...
[15:44:32] <brada> so
[15:44:45] <brada> maybe put the char encoding in the encoding ini
[15:44:46] <brada> ?
[15:45:22] <edheldil> japanese soa has 4
[15:45:53] <edheldil> that's one possibility
[15:46:17] <brada> well im looking for consensus if possible :p
[15:46:33] <fuzzie> hm
[15:46:46] <edheldil> what do you need it for? To choose a block in a ttf font?
[15:46:59] <brada> so far thats it yes
[15:46:59] <fuzzie> no, to choose the char encoding of the tlk
[15:47:08] <fuzzie> no?
[15:47:16] <brada> well yeah but ultimately its for choosing blocks from a font
[15:47:40] <fuzzie> right, but you don't need that for bam really
[15:47:44] <brada> no
[15:47:51] <fuzzie> but you still do need the encoding, right?
[15:47:52] <brada> i might need it elsewhere
[15:48:36] <fuzzie> since for example GBK and Big5 are going to need quite significant differences in the string handling unless I am missing something
[15:48:50] <edheldil> so far the encoding file serves only for upper / lower caps conversion and the question is whether there was such a thing in the original engine
[15:48:50] <brada> like i said might need it elsewhere
[15:48:57] <fuzzie> oh, bad example.
[15:48:58] <fuzzie> hmph.
[15:49:11] <fuzzie> edheldil: the original engine just used the system codepage I think?
[15:49:17] <brada> right now im working on ttf loading tho :p
[15:49:26] <edheldil> fuzzie: I doubt it
[15:49:27] <brada> getting rid of the range stuff
[15:49:38] <fuzzie> edheldil: well, that's what it seemed to do when I looked last
[15:49:44] <edheldil> don't forget the completely nonstandard polish encoding
[15:49:54] <fuzzie> oh, right, yes, I'm thinking of double byte only
[15:50:14] <fuzzie> no idea what it does for single, although I thought it still was toupper..
[15:50:36] <fuzzie> it does just call toupper which just calls windows codepage stuff
[15:50:54] <edheldil> maybe there actually is not uc/lc in the engine at all, just a confusion of a proper font size
[15:51:09] <fuzzie> apparently last time we discussed this you hadn't seen polish
[15:52:31] <fuzzie> but I can at least assure you that, in bg2's setbuttontext, original engine checks uppercase bit, then calls toupper, which calls (among other possibilities) mbsupr, which is MBCS uppercasing code
[15:53:02] <fuzzie> so it is no confusion about font sizes or anything, at least in bg2.
[15:53:06] <edheldil> the problem with polish that we did a conversion that, w/o special encoding table, did not work, so I came up w/ my patch. But later it was shown that there's actually no game that uppercases button text, I think
[15:53:19] <edheldil> really?
[15:53:32] <edheldil> I stand corrected, ....
[15:53:41] <fuzzie> we actually discussed this before :-)
[15:53:50] <fuzzie> I don't know if that flag is *used*.
[15:54:09] <fuzzie> But gemrb only does it in the case that the relevant flag is set, so..
[15:54:22] <edheldil> the polish encoding was used in bg1 only, I think, so that would work
[15:54:56] <fuzzie> brada: anyway I think it makes some sense to couple it to the encoding..
[15:55:04] <fuzzie> but it's unclear to me how any of this works still
[15:55:58] <brada> ok
[15:57:32] <traveler> * another see through doors http://img22.imageshack.us/img22/8990/201301101655151440x900s.png
[15:59:57] <traveler> oh, actually crashed gemrb. haven't seen that in a while. no idea what i have done
[16:01:15] <brada> bt?
[16:01:33] <-- WingedHussar has left IRC (Quit: WingedHussar)
[16:01:49] <traveler> i wasn't running in db
[16:01:53] <traveler> i have core though
[16:01:59] <brada> that wont help
[16:02:10] <brada> you built it so only you can realistically symbolize it
[16:03:01] <traveler> will see next time / bbl
[16:03:14] <brada> why not always run debug?
[16:03:28] <brada> i mean a debug build
[16:03:33] <brada> not run via gdb
[16:05:02] <traveler> stop
[16:05:30] <traveler> default build is not strippped
[16:05:41] <brada> so you do have a bt?
[16:05:43] <traveler> i mean default is debug
[16:05:53] <traveler> i do not have gdb at moment
[16:05:58] <traveler> wait a bit
[16:10:25] <traveler> http://pastebin.com/2P1YmgXL
[16:10:26] <Seniorita> Core was generated by `gemrb'. Program terminated with signal 11, Segmentation - Pastebin.com
[16:10:42] <brada> yeah thats a backtrace :p
[16:11:18] <traveler> i previously meant that i wasn't running via gdb, but i have core. and default build is not stripped.
[16:11:34] <brada> its teh "core" terminology that confuses me
[16:12:08] <brada> your build is optimizing values out tho
[16:12:19] <brada> which isnt good for determining the problem at a glance
[16:13:37] <traveler> it's default build, well sorry for optimization, will go back at building proper debug build
[16:13:50] <traveler> *go back to
[16:13:57] <traveler> i think it's relwithdebinfo
[16:13:58] <brada> we dont do -o0 by default?
[16:14:02] <brada> we probably should
[16:16:04] <traveler> well, now truly bbl.
[16:47:23] --> Coriander has joined #gemrb
[17:02:10] <brada> lynx: shouldnt the 2das that we extend be in override?
[17:04:31] <fuzzie> only if they should take priority over any user-provided files
[17:05:36] <fuzzie> no, wait, I'm confused
[17:05:44] <fuzzie> howso extend?
[17:07:33] <brada> right now im thinking of fonts 2da
[17:08:01] <brada> what is the order of precedence?
[17:08:22] <brada> original data -> unhardcoded -> original override -> gem override?
[17:08:31] <fuzzie> isn't fonts.2da ours though?
[17:08:40] <brada> well its in unhardcoded
[17:08:45] <brada> so i guess its ours
[17:08:52] <fuzzie> so why would you want it to be in override?
[17:08:52] <brada> but was hardcoded in original?
[17:09:00] <brada> so can you not override hardcoded tables then?
[17:09:17] <fuzzie> it was hardcoded in the original in the sense that it was only C++ code.
[17:09:19] <brada> im asking for understanding not because i want anything in particular
[17:09:39] <brada> i jsut figured if it would be moved then i may as well do it when i modify it to avoid 2 large commits :p
[17:09:53] <fuzzie> the precedence is unhardcoded -> original data -> original override -> gemrb shared override -> gemrb override
[17:10:30] <fuzzie> well I forgot the shared unhardcoded but you get the idea.
[17:10:34] <brada> yes
[17:10:51] <fuzzie> so there's no reason for new-in-gemrb stuff to be anywhere except unhardcoded.
[17:10:55] <brada> ok
[17:11:06] <fuzzie> it definitely should never be in gemrb override.
[17:11:36] <brada> thanks
[17:11:40] <fuzzie> gemrb override is 'this is really important to us, we need to always override this' afaik.
[17:11:46] <fuzzie> hoipefully that made some sense :)
[17:12:10] --> avenger has joined #gemrb
[17:12:10] --- ChanServ gives channel operator status to avenger
[17:12:15] <brada> yeah thats why i was asking because our modifications are important
[17:12:38] <brada> but since it was hardcoded then i guess that meeans that it couldnt have been modified by mods that werent made for gemrb
[17:12:45] <brada> without exe patch
[17:12:50] <brada> that means nothing to us
[17:13:22] <fuzzie> that is the theory
[17:13:34] --> Cuvieronius has joined #gemrb
[17:15:14] <avenger> hello
[17:15:16] <Seniorita> [commit] Avenger: safe bet on setting multij for exportable characters http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=c64b7eff099048d3346313d994e57d811a9e0cc3
[17:16:24] <-- brada has left IRC (Quit: brada)
[17:38:49] --> brada has joined #gemrb
[17:49:42] --> chiv has joined #gemrb
[17:49:53] <chiv> evening all
[17:51:07] <-- edheldil_ has left IRC (Read error: Operation timed out)
[17:59:41] <-- avenger has left IRC (Remote host closed the connection)
[18:01:11] <chiv> edheldil: pardon my ignorance, but I got all my ie tools years ago.. what is iesh and where can i get it?
[18:01:27] <fuzzie> it's in gemrb's ie_shell repo
[18:01:40] <fuzzie> git://gemrb.git.sourceforge.net/gitroot/gemrb/ie_shell
[18:01:58] <fuzzie> basically it's a python tool for manipulating IE files
[18:01:59] <-- |Cable| has left IRC (*.net *.split)
[18:01:59] <-- fireglow has left IRC (*.net *.split)
[18:02:15] --> fireglow has joined #gemrb
[18:02:22] --> |Cable| has joined #gemrb
[18:03:34] --> chiv_ has joined #gemrb
[18:03:57] --> Avenger has joined #gemrb
[18:03:58] --- ChanServ gives channel operator status to Avenger
[18:05:28] <-- chiv has left IRC (Ping timeout: 245 seconds)
[18:16:26] <brada> im just going to make some font subclasses
[18:17:02] <brada> i dont know how i let myself get talked out of it last time
[18:18:12] <fuzzie> what for?
[18:18:29] <fuzzie> oh, right, you made fonts not fonts
[18:18:32] <brada> well it woud be nice to eventually support kerning for example
[18:18:59] <fuzzie> that doesn't need a subclass :)
[18:19:01] <brada> but its also sooo easy with freeetype to get the character i need just by passing the char "code"
[18:19:26] <fuzzie> but what would you do in a subclass to render a glyph?
[18:19:34] <brada> for that to work with our current setup we would have an array with a huge amount of nulls
[18:19:54] <brada> have freetype create a bitmap if there isnt one cached
[18:20:13] <fuzzie> but still create Sprite2Ds underneath?
[18:20:33] <brada> either that or whatever you think
[18:20:39] <fuzzie> no, I'm just wondering
[18:20:46] <fuzzie> in scummvm we have a generic Font class but it just does single glyph rendering
[18:20:53] <fuzzie> then the higher-level code handles the actual string drawing
[18:21:26] <brada> and how would we do kerning without a subclass?
[18:21:31] <fuzzie> and every implementation of Font has to provide details such as the kerning offset between two chars (with the default being 0).
[18:21:31] <brada> that sounds really messy
[18:21:39] <brada> not that im going to do kerning :p
[18:21:43] <fuzzie> it's v.trivial
[18:21:44] <brada> you leave me out of that
[18:22:14] <fuzzie> https://github.com/scummvm/scummvm/blob/master/graphics/fonts/ttf.cpp <- see getKerningOffset implementation
[18:22:16] <Seniorita> scummvm/graphics/fonts/ttf.cpp at master · scummvm/scummvm · GitHub
[18:22:37] <brada> yeah but that if for a ttf font
[18:22:48] <brada> we have bitmaps being handled in the same calss
[18:22:52] <fuzzie> no
[18:22:57] <fuzzie> that's the *subclass*
[18:23:17] <fuzzie> like I said, the default implementation just returns 0
[18:23:18] <brada> right and im talking about sublclasses for gemrb
[18:23:34] <fuzzie> oh, right, sorry
[18:23:47] <fuzzie> sorry, definitely not arguing against subclasses
[18:23:52] <brada> ok then :)
[18:24:16] <fuzzie> just wondering if you had thoughts on how to do it
[18:24:41] <brada> i have diffrent thoughts depending on how likely it is that somebody will take things to the next level
[18:25:00] <fuzzie> since I guess it'd be quite easy to do right now if you just make the existing Font code call a method to request each glyph before drawing it
[18:25:25] <brada> which it does
[18:25:30] <brada> currently
[18:26:09] <fuzzie> mhm
[18:26:24] <fuzzie> honestly I hadn't really realised it wasn't a subclass
[18:26:33] <brada> it was in my origninal
[18:26:41] <brada> iirc tomprince talked me out of it
[18:26:48] <fuzzie> it might be more elegant to split into rendering and font classes
[18:27:53] <fuzzie> you discussed it with myself and wjp but you were talking about replacing the Print stuff entirely
[18:28:25] <brada> well our print code seems pretty bad
[18:28:39] <fuzzie> well, I mean, with ttf-specific code
[18:29:02] <brada> i was assuming use of sdl_ttf at that time
[18:29:10] <brada> we are free from that for the better
[18:29:30] <fuzzie> tomprince's point of view was that it'd be nice to have a font 'resource' class, but that's a lot trickier since you also want to pull things like kerning info out
[18:29:46] <fuzzie> so I think this is just things becoming clearer over time, really
[18:29:57] <brada> yeah
[18:30:51] <brada> using ttf for rendering the Chinese stuff was easy, but how are the bams organized?
[18:32:21] <fuzzie> well..
[18:32:26] <fuzzie> I'm not sure.
[18:32:34] <fuzzie> you changed the font code here
[18:32:52] <chiv_> i looked at them in dltcep, that bit does not look fun
[18:33:02] <brada> yeah i think ill ignore bam for the time being
[18:33:13] <fuzzie> but they're really simple if you read the bams correctly
[18:33:25] <brada> well i mostly jsut moved the bam reading code
[18:33:38] <fuzzie> just step through all the frames in all the cycles in order, and then glyph X is frame X
[18:33:53] <brada> and that will map it to a char code?
[18:34:03] <fuzzie> yes
[18:34:26] <brada> ok i can probably do that
[18:34:34] <fuzzie> it doesn't work as-is?
[18:35:05] <brada> well as is it jsut steps though the cycles and gets the first frame
[18:35:16] <brada> or something
[18:35:22] <brada> not looking at the code atm
[18:35:26] <fuzzie> yes
[18:36:39] <brada> so the thing that is blocking me atm is how to code the GetCharSprite method
[18:36:55] <brada> because i really want to jsut pass that the raw character
[18:36:58] <brada> and get a glyph
[18:37:09] <brada> the right glyph preferably :p
[18:37:46] <brada> it seems like for that to work ill end up with a huge array with many nulls
[18:37:50] <brada> the way it is now i mean
[18:38:13] <fuzzie> you should probably ignore what I said about cycles above, I don't think I remember it right
[18:38:17] <fuzzie> sorry
[18:38:19] <brada> its ok
[18:38:22] <fuzzie> but it's something along those lines, they're just ordered
[18:38:25] <brada> im not worried about bam atm
[18:38:40] <fuzzie> but yes, it sounded like you were considering caching for TTF anyway
[18:39:11] <brada> yeah i cant think of a good way to code GetCharSprite without going with subclasses
[18:41:23] <fuzzie> well
[18:41:31] <fuzzie> you can have a separate resource class
[18:41:36] <fuzzie> and then implement caching+fetching in Font
[18:41:56] <brada> true
[18:43:01] <brada> but why is that better than a subclass?
[18:46:40] <chiv_> just for reference, the font itself seems blank until you get to about frame 8600
[18:46:58] <brada> so i guess that is the huge array of nulls i was talking about :)
[18:47:12] <brada> which i certainly could do
[18:47:19] <brada> but its so wasteful!
[18:48:09] <chiv_> i dont really know how bam works, bit it seems to have a single blank pixel for every unused char...
[18:48:10] <brada> i guess i could extend font to have something like an AddCharTable method
[18:48:19] <brada> and add them in sections
[18:48:33] <brada> chiv: thats not at all what i mean
[18:49:15] <brada> right now we have an array of glyphs where the index corresponds to a char code
[18:49:26] <chiv_> sorry, i havent been paying attention well enough...
[18:49:44] <brada> and since we are now diealing with situations where there are huge amounts of emptyness that makes a huge mostly empty array
[18:50:42] <chiv_> i dont know if it sounds palatable to you, but since chinese and japanese are the only languages with zillions of glyphs, maybe it could be a special case?
[18:50:48] <brada> so i guss a stop gap would be to add blocks with offsets....
[18:51:57] <brada> so have an array of arrays...
[18:52:10] <brada> seems like it should work
[18:52:40] <chiv_> if it is any help, the bam seems to be split so that a block of glyphs corresponds to a particular animation cycle
[18:53:08] <chiv_> I dont know if they have done that specifically to reflect the encoding method, but it might be worth finding out
[18:53:23] <brada> well im pretty sure the bams are organized roughly like how our fonts currently works
[18:53:43] <brada> thats why there are all those blanks
[18:54:13] <fuzzie> it's definitely pretty much a one-to-one mapping
[18:54:23] <fuzzie> i'm just not sure if mapping directly to frames works or not
[18:54:31] <fuzzie> if it's mostly blank until frame 8600 then it sounds like it would
[18:55:07] <fuzzie> and if you just want to make it work, it doesn't sound disasterous to just allocate 64k bitmaps for now, just to get it working
[18:56:58] <brada> it wouldnt make any blank bitmaps
[18:57:18] <brada> our font would see the null and jsut map the pointer to a special balnk bitmap already created
[18:57:45] <brada> and yeah i can do that jsut to get it working
[18:58:05] <brada> as long as nobody will yell at me
[18:58:34] <brada> so thats what i will do for now i guess
[19:00:57] <brada> its only like 8k of emptyness :p
[19:04:17] <chiv_> to be honest, I think the ttf will be an immeasurable improvement over the chinese bam font anyway...
[19:04:22] <lynxlynxlynx> back
[19:04:35] <brada> chiv: why?
[19:04:47] <brada> i guess cuz you can control the size?
[19:04:57] <chiv_> because it is so small its barely legible...
[19:05:00] <brada> ah
[19:05:28] <chiv_> i guess if you are native, it doesn't hurt so much, but its like everything being in that tiny fixedsysfont at 5pt
[19:06:14] <brada> well ttf will allow for easier translations to non translated language
[19:06:19] <brada> since you dont need to make bams
[19:06:31] <brada> just a new tlk
[19:06:54] <chiv_> with the work you have done, will other languages be easy to support as well?
[19:07:08] --- chiv_ is now known as chiv
[19:07:46] <chiv> sorry, i did read what you said, i meant 'other existing official translations'
[19:08:04] <brada> i cant say for sure, but i assume
[19:08:17] <chiv> groovy
[19:12:05] <chiv> by the way, if this is any help: http://www.khngai.com/chinese/charmap/tblgbk.php
[19:12:07] <Seniorita> GBK Code Tables
[19:14:13] <chiv> i know ab60 maps to frame 10941
[19:15:27] <chiv> sorry, a glyph at ab60 i mean: 玥
[19:17:40] <chiv> and the frames immediately before and after it match the order on that page
[19:20:59] <chiv> you can probably throw any glyph at me and ill find out what frame index it should be
[19:23:00] <brada> im not touching bams until after ttf
[19:23:34] <brada> in fact strictly speaking im not working on any langue stuff atm
[19:23:48] <brada> im removing the char range crutch
[19:24:23] <chiv> no worries, just saying for reference
[19:24:56] <chiv> one of the few things I can do well is look up glyphs in the dictionary...
[19:25:26] <chiv> only 3000 to go and I should be able to read it :)
[20:02:46] <brada> ha ha ha my blank sprite has a ref count of 36934
[20:02:54] <brada> so many empty slots!
[20:18:26] <brada> chiv: can you tell me the first glyph of the SoA button?
[20:18:48] <brada> for the gbk
[20:23:11] <brada> bah i can already tell im doing something wrong
[20:24:04] <chiv> its b0b0 index 2
[20:24:25] <chiv> sorry, i was fighting with my sound setup, didnt realise you were asking me..
[20:24:45] <brada> no i mean the actual symbol :)
[20:24:58] <chiv> 2 secs
[20:25:55] --> chiv_ has joined #gemrb
[20:26:00] <chiv_> 安
[20:26:17] <chiv_> will take me a while to manually find the frame, if thats what you need
[20:26:28] <brada> nope not touching bams
[20:26:36] <chiv_> ok
[20:26:51] <chiv_> ill make a note of it though if i do
[20:33:23] <-- chiv has left IRC (Ping timeout: 245 seconds)
[20:34:43] <brada> well unicode works :/
[20:37:47] <fuzzie> you're using a ttf file with the relevant mapping in it?
[20:37:58] --> chiv has joined #gemrb
[20:38:13] <brada> im using a ttf that claimed that it did when i downloaded it
[20:38:22] <brada> either it lied or freetype thinks it did
[20:38:30] <fuzzie> format 2?
[20:39:45] * fuzzie peers at the freetype api
[20:40:26] <fuzzie> so what are you doing now, selecting FT_ENCODING_GB2312 with FT_Select_Charmap?
[20:40:43] <fuzzie> or rather FT_Set_Charmap I guess
[20:42:02] <brada> no im using select
[20:42:18] <brada> is that what my problem is?
[20:42:37] <fuzzie> I assume not.
[20:42:51] <fuzzie> just the docs have some confusing notes for whether it returns an error or not, but unicode only..
[20:43:20] <fuzzie> but it looks like you can check the error code for either
[20:43:47] <fuzzie> but the existing in-tree code uses FT_Set_Charmap so hence my 'or rather' :)
[20:43:57] <brada> well the error i get is "invalid argument"
[20:44:04] <brada> so im not sure what to make of it
[20:51:25] <brada> its proving difficult for me to find either a big5 or gbk font since i dont speak chinese
[20:51:51] <fuzzie> so it returns invalid argument if there's no charmap match, predictably
[20:51:58] <brada> thats what i assume
[20:52:08] <brada> but its not documented is it?
[20:52:17] <fuzzie> no, I went and checked the source
[20:52:20] <brada> ah
[20:52:25] <brada> thank you :)
[20:53:35] <fuzzie> It'll also return it if you pass FT_ENCODING_NONE to FT_Select_Charmap, or if you ask FT_Set_Charmap for a format 14 cmap which I guess is unicode stuff.
[20:54:16] <brada> so basically i dont actually have a font that works then :/
[20:54:16] <fuzzie> unfortunately no idea where you can get a suitable font. :/
[20:54:30] <brada> stupid lies on the internet!
[20:55:12] <brada> bah i say convert the tlk to unicode!
[20:55:15] <brada> :p
[20:55:29] <fuzzie> not an unreasonable idea
[20:55:40] <chiv> that actually sounds quite sensible
[20:55:46] <fuzzie> assuming you're a crazy evil genius who is out to murder us all
[20:56:04] <brada> well its the only thing that i have seen work
[20:56:06] <fuzzie> but for non-ttf we should really support original tlk :P
[20:56:15] <brada> for obvious reasons
[20:56:56] <fuzzie> so which font are you trying?
[20:57:24] <brada> simhei
[20:57:34] <brada> and simsun
[20:57:49] <chiv> do you want uming.ttf?
[20:57:57] <brada> sure
[20:58:01] <brada> im willing to try
[20:58:05] <fuzzie> simhei should be good really
[20:58:11] <chiv> 2 secs ill fish out the link
[20:58:17] <brada> but ft fails...
[20:58:31] <fuzzie> but a random simhei.ttf has only unicode
[20:59:05] <brada> ah
[20:59:16] <brada> well i dont know where to get a good one then
[20:59:47] <chiv_> http://archive.debian.net/etch/ttf-arphic-uming - this apparently has gb2312-80
[20:59:49] <Seniorita> Debian -- Details of package ttf-arphic-uming in etch
[21:00:57] <chiv_> and big5 too
[21:01:07] <brada> how do i download it?
[21:01:30] <chiv_> bottom of the page, link labeled 'all'
[21:01:52] <brada> but it 404s
[21:01:59] <chiv_> wierd
[21:02:19] <chiv_> http://archive.debian.net/etch/all/ttf-arphic-uming/download ?
[21:02:23] <Seniorita> Debian -- Package Download Selection -- ttf-arphic-uming_0.1.20060928-2_all.deb
[21:03:05] <chiv_> hah, some of the archives are broken
[21:03:07] <chiv_> http://archive.debian.org/debian/pool/main/t/ttf-arphic-uming/ttf-arphic-uming_0.1.20060928-2_all.deb
[21:03:16] <brada> thanks
[21:03:28] <chiv_> its probably on a newer page, thats just the first good hit I found on google
[21:04:06] <brada> i get failure for that too
[21:04:08] <brada> wtf
[21:05:59] <chiv_> you mean a download fail?
[21:06:59] <brada> no
[21:07:15] <brada> i mean FT failed to select a charmap for either big5 or gbwhatever
[21:08:04] <brada> its 2x the size of the other font i was trying tho
[21:08:11] <brada> not that that means anything special
[21:09:47] <chiv_> maybe thats not the right font :/ it says it coveres big5 and gb glyphs, but I don't know if that means what I think it means
[21:13:12] <fuzzie> so, I guess you want encoding 3/3
[21:14:44] <fuzzie> which is not present in any font I've seen
[21:16:17] <brada> surely one exists since FT_ENCODING_BIG5 exists...
[21:16:21] <fuzzie> yes
[21:16:59] <chiv_> http://babelfonts.blogspot.co.uk/2010/07/babelstone-han.html ?
[21:17:00] <Seniorita> BabelStone Fonts: BabelStone Han
[21:17:55] <fuzzie> nope
[21:18:47] <fuzzie> hmm
[21:19:27] <fuzzie> maybe this 477mb archive has one
[21:19:33] <brada> ha ha ha
[21:19:49] <fuzzie> this is finally a use for my 50mbps fiber!
[21:19:58] <brada> yay!
[21:20:01] <fuzzie> so far I've mostly used it for IRC.
[21:20:17] <miha> fuzzie: no torrent .. c'mon seed :)
[21:20:46] <chiv_> im not sure what is going wrong, but it seems to me that if the majority of fonts are wrong for bg1/2, maybe you do need to convert the encoding?
[21:21:12] <fuzzie> there should be fonts in a real chinese windows which should work fine
[21:21:45] <chiv_> well, when I run my chinese bgconfig, that prints out fine
[21:21:45] <brada> doesnt help me :)
[21:22:10] <fuzzie> ok, this is taking longer to unpack than it did to download
[21:22:29] <fuzzie> chiv_: bgconfig is using ucs2 I expect :)
[21:22:37] <chiv_> gah....
[21:22:42] <brada> not gah
[21:23:03] <brada> gah that they used non unicode to do the chinese hack
[21:23:56] <fuzzie> well, unicode was sort of untrustable until the late 90s
[21:24:16] <chiv_> the standard in prc is apparently GB18030 now
[21:24:36] <chiv_> http://www.pinyinjoe.com/pinyin/encoding.htm
[21:24:38] <Seniorita> Pinyin Joe - Chinese character encoding standards - Big 5, GB code, GB2312, GBK, Unicode
[21:25:07] <fuzzie> which does not work with ucs2 :)
[21:25:45] <chiv_> i wonder how they keep it all straight
[21:25:55] <fuzzie> ok, no useful fonts. hmph.
[21:26:00] <brada> :(
[21:26:09] <fuzzie> chiv_: mostly people just convert to unicode nowadays if they can possibly manage it.
[21:26:13] <brada> im honestly suprise that one is so hard to find
[21:26:19] <fuzzie> me too.
[21:26:37] <brada> must all be stuck behind the great firewall :p
[21:28:20] <brada> can we just use iconv...
[21:29:13] <fuzzie> for ttf? doesn't sound too crazy
[21:30:25] <brada> i mean we are planning on passing the encoding of tlk and unicode seems to be a safe target
[21:30:40] <fuzzie> just don't do ucs2 :P
[21:31:28] <fuzzie> chiv_: does the chinese translation leave the fonts untouched?
[21:32:29] <chiv_> which fonts... the system ones?
[21:32:34] <fuzzie> the ones with the game
[21:32:53] <chiv_> it replaces normal.bam and realms.bam, thats it
[21:33:04] <chiv_> it maps the other fonts to one of those
[21:33:06] <brada> well yeah then it patches everything to use those
[21:33:14] <brada> other then probably numeric fonts
[21:33:16] <brada> but anyway
[21:33:27] <fuzzie> so does it even stick to the right encoding anyway?
[21:33:32] <brada> we can just conditionally iconv
[21:33:39] <brada> thats a good question
[21:33:48] <chiv_> the dialog.tlk can be parsed by various online encoding tools
[21:34:05] <chiv_> so i guess so
[21:34:18] <fuzzie> the tlk itself, or the contents?
[21:34:20] <brada> i think she means the bam -> tlk map
[21:34:23] <chiv_> the contents
[21:34:36] <fuzzie> how do you dump the contents?
[21:34:38] <chiv_> eg, pulling out single strings with near infinity
[21:35:07] <fuzzie> the reason I ask is that I wouldn't be surprised to find that they're using some extra glyphs
[21:35:24] <fuzzie> but you wouldn't see that if you just pick random strings, probably
[21:35:40] <chiv_> i confirmed that the quit game string is correct, on http://zhongwen.com/zi.htm
[21:35:42] <Seniorita> Chinese Characters Dictionary Web
[21:36:02] <brada> fuzzie: is icov redily available?
[21:36:04] <brada> skdajfhakjl
[21:36:04] <brada> dsafjkhla
[21:36:09] <brada> stupid hands
[21:36:14] <traveler> haha
[21:37:06] <fuzzie> brada: well, you can ship it with apps, but it's kind of huge by default
[21:37:19] <fuzzie> i think
[21:37:37] <brada> its just available to me by including iconv.h
[21:37:45] <fuzzie> yes, on linux/mac it's fine
[21:37:47] <fuzzie> is it also on iOS?
[21:37:51] <brada> checking
[21:38:04] <fuzzie> looks like it
[21:38:06] <fuzzie> but not on android
[21:38:12] <brada> yes
[21:38:30] <brada> android makes me sad
[21:38:44] <fuzzie> vlc is using a bundled iconv for iOS too though..
[21:38:54] <brada> i wonder why
[21:40:15] <brada> so id want to keep the iconv bits de-coupled from anything important
[21:40:22] <brada> not sure how best to do that
[21:40:29] <brada> i guess i can weak link it
[21:40:57] <lynxlynxlynx> we can bundle it and disable it by default too
[21:41:13] <brada> well i was going to use it in the ttf plugin
[21:41:26] <brada> er not there
[21:42:12] <brada> i was thinking the sensible place to do the conversion was in tlkimporter
[21:42:18] <-- miha has left IRC (Quit: Lost terminal)
[21:42:37] <brada> just check at runtime if iconv is available and if we want to do conversion
[21:43:51] <brada> but if we want to package it im all for that
[21:44:13] <lynxlynxlynx> if it isn't available on the platform, the user would be screwed
[21:44:35] <brada> how?
[21:44:49] <brada> you meann to build not to run?
[21:44:51] <lynxlynxlynx> can't use the conversion
[21:45:04] <brada> so?
[21:45:20] <brada> we dont do conversion now so obviously they are getting by without it
[21:45:22] <lynxlynxlynx> so they're forced to use english or others
[21:45:34] <lynxlynxlynx> how is that a good thing?
[21:46:01] <brada> well its either that or nobody gets to use it
[21:46:31] <brada> i just dont see why we shoud screw everybody over just because we cant support it for everything
[21:47:04] <lynxlynxlynx> huh
[21:47:43] <lynxlynxlynx> i don't understand your binary logic
[21:47:51] <brada> clearly
[21:48:31] <chiv_> meh,whats wrong with just bundling it for android builds?
[21:48:59] <brada> aside from the fact nobody is building anything for android?
[21:49:03] <chiv_> heh
[21:49:59] <chiv_> but lets say there was, is that so bad an option?
[21:50:28] <brada> the problem is we dont want to *require* iconv
[21:50:34] <brada> which im not suggesting at all
[21:50:57] <chiv_> sure, you'd only need it for chinese right?
[21:51:13] <brada> need is a subjective term
[21:51:39] <brada> i was talking about using it to convers non-unicode compatible encodings to unicode
[21:51:51] <brada> for use with ttf fonts
[21:52:16] <chiv_> which does sound like a good thing to have anyway...
[21:52:24] <brada> right
[21:53:00] <brada> so i guess the best solution is to make a ttf font subclass and just let that silently use iconv when its both available and needed
[21:53:37] <brada> and if its not available then i guess you just cant use ttf plugin with chinese unless you have an old big5 font
[21:53:42] <lynxlynxlynx> we need a mailing list for all the platform maintainers
[21:54:04] <chiv_> is it beholder that does android builds?
[21:54:44] <lynxlynxlynx> the one on market, yes
[22:04:12] <-- lynxlynxlynx has left IRC (Ping timeout: 276 seconds)
[22:05:28] <-- traveler has left IRC (Ping timeout: 245 seconds)
[22:06:34] --> lynxlynxlynx has joined #gemrb
[22:06:34] <-- lynxlynxlynx has left IRC (Changing host)
[22:06:34] --> lynxlynxlynx has joined #gemrb
[22:06:34] --- ChanServ gives channel operator status to lynxlynxlynx
[22:08:24] <chiv_> do you have an android build bot?
[22:10:30] <brada> no
[22:11:01] <brada> we have bots that could work if somebody would provide build instructions and binaries for the deps
[22:11:53] <chiv_> so you could theoretically then always have an up to date android build?
[22:13:43] <lynxlynxlynx> yep
[22:13:59] <chiv_> is it a case of just no one has an android?
[22:14:11] <lynxlynxlynx> one of the android guys already tried making the slave
[22:14:42] <lynxlynxlynx> at least the sdl mess is better now
[22:15:00] <lynxlynxlynx> trivia: iwd2 plays the level up sound when you succesfully hide :s
[22:15:47] <lynxlynxlynx> each round
[22:16:25] <chiv_> meh? I never noticed that
[22:19:20] <lynxlynxlynx> could be the iwd2 levelup sound is different than the one in bg2
[22:20:04] <chiv_> the level up sound is the same, i just never heard it when hiding
[22:22:10] <lynxlynxlynx> could be triggered by the logging code
[22:22:35] <lynxlynxlynx> won't go check if any of those strings have it attached
[22:22:56] <lynxlynxlynx> definitely not something we would want to reproduce anyway
[22:32:05] --> traveler has joined #gemrb
[22:33:48] <chiv> there seems to be another transparency issue on the pause button in torment, shall i make a note of it on the wiki?
[22:35:05] <lynxlynxlynx> sure
[22:40:07] --> CamDawg1 has joined #gemrb
[22:41:36] <-- CamDawg has left IRC (Ping timeout: 276 seconds)
[22:48:58] <-- CamDawg1 has left #gemrb
[22:49:16] <-- Avenger has left IRC (Quit: bye!)
[23:02:14] <edheldil__> brada: chinese does not have bam, I think. Japanese does. Look at the page at our wiki. You can look at the JP organization with ieview from iesh, for example
[23:02:47] <chiv> chinese definitely has bam :)
[23:04:05] <chiv_> edheldil: try https://docs.google.com/open?id=0BzBo2zkBt4guN09RUGRrdjR5czg
[23:04:07] <Seniorita> BG CHINESE.zip - Google Drive
[23:04:47] <brada> bah enought with the bams!
[23:04:51] <brada> not interested in them
[23:05:01] <chiv> for bg2 it is quite simple, you just paste the files and edit baldur.ini to reflect the readme.txt
[23:06:33] <chiv> heh like i said, I think ttf is the better option, but just said for the sake of accuracy
[23:06:56] <chiv> the chinese bam fonts are really crappy pixelated...
[23:14:09] <chiv> edheldil__: can you tell me about your bam tool? there is something I want to create, and im not sure i am ready to face bamworkshop
[23:16:27] <edheldil__> sure
[23:17:02] <edheldil__> brada: I stand corrected - my memory is abysmal. Then it's perhaps PST that has weird *.dat files
[23:17:38] <chiv> actually, i remember something about that, i think its in the chinese forum thread
[23:18:12] <edheldil__> I am not at the comp where I have most of my ie stuff
[23:18:43] <edheldil__> what do you need to know about the bam_composer thingy?
[23:19:18] <chiv> just where to get it really
[23:19:36] <chiv> i can experiment in my own time
[23:20:00] <edheldil__> it's in ie_shell hit repo again
[23:20:03] <edheldil__> git
[23:20:25] <chiv> ah cool, ill check it all out
[23:24:36] <Seniorita> [commit] Laurie Chilvers: renaming the planescape setup 'action' window controls, because it is just the pause... http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=63a8f72d88069f8523b559cf25c904a1aa72f84c
[23:24:37] <Seniorita> [commit] Jaka Kranjc: TryToHide: shut up and more todos http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=e389836c7511f1a238fdf2138c60169da888cf8b
[23:24:39] <Seniorita> [commit] Jaka Kranjc: split out TryToHideIWD2 and implemented the first version of both skill checks http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=commitdiff;h=52c51caca2880262ecb204542f13142d321961b2
[23:25:52] <chiv> lynxlynxlynx: i am just going over that merge branch again one last time
[23:27:56] <lynxlynxlynx> ok
[23:28:03] <lynxlynxlynx> i committed the first one, since it was ok
[23:28:08] <chiv> i worked out how to rebase anyway
[23:28:40] <lynxlynxlynx> the interactive mode helps a lot
[23:28:48] <chiv> and i finally get the idea of branches, which has saved me a major headache...
[23:29:19] <lynxlynxlynx> you'll still have plenty of manual work though, since some problems span multiple commits and as soon as you fix one, the others probably won't apply anymore
[23:29:46] <chiv> thats ok, i dont really mind re doing the commits
[23:30:11] <chiv> i am working it all into the mergezone branch
[23:30:41] --> edheldil_ has joined #gemrb
[23:31:39] <edheldil_> interesting, I have just unpacked some TOB chinese patch and inside were binaries with http://fuzzie.org urls :)
[23:31:41] <Seniorita> Alyssa Milburn
[23:32:00] <chiv> heh
[23:32:15] <chiv> there are all the old familiar websites on that chinese rpg site
[23:32:23] <chiv> dltcep is there
[23:39:44] <lynxlynxlynx> chiv: redoing from scratch?
[23:39:52] <chiv> yeah
[23:40:22] <lynxlynxlynx> then also please fix any new whitespace issues and keep related changes together
[23:40:34] <chiv> thats what im focusing on
[23:41:11] <lynxlynxlynx> eg. one commit from the other branch moved a hp list to the toplevel gcw, but why became apparent only a few commits later when the rest of the code followed
[23:41:46] <lynxlynxlynx> git commit -p # and then 's' as needed can work wonders btw
[23:43:08] <chiv> i actually have been using git commit -p all this time btw :)
[23:45:43] <lynxlynxlynx> :)
[23:46:31] <lynxlynxlynx> add takes the same parameters btw (commit uses it internally) if you need more control
[23:53:50] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:55:58] <-- edheldil__ has left IRC (Ping timeout: 256 seconds)