#gemrb@irc.freenode.net logs for 10 Dec 2009 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:35:05] <-- |Cable| has left IRC (Read error: 110 (Connection timed out))
[00:38:35] --> |Cable| has joined #gemrb
[01:13:28] <-- Forgetful_Lion has left IRC (Read error: 113 (No route to host))
[01:43:52] <tomprince> Is there some order to function in a class definition. In particular Interface.h
[01:43:55] <tomprince> ?
[02:35:56] --> Forgetful_Lion has joined #GemRB
[08:25:32] --> lynxlynxlynx has joined #gemrb
[08:25:32] --- ChanServ gives channel operator status to lynxlynxlynx
[09:20:44] <wjp> tomprince: related functions are often grouped together, but I think there's no particular order in Interface.h
[09:31:43] <-- |Cable| has left IRC (Remote closed the connection)
[10:04:17] --> [1]Forgetful_Lio has joined #GemRB
[10:08:05] --> Taimon has joined #gemrb
[10:14:22] <-- Forgetful_Lion has left IRC (Read error: 113 (No route to host))
[10:14:22] --- [1]Forgetful_Lio is now known as Forgetful_Lion
[10:47:36] --> kettuz has joined #gemrb
[11:12:44] --> Gekz_ has joined #GemRB
[11:14:18] <Gekz_> hi.
[11:14:24] <Gekz_> I had catastrophic hard disk failure
[11:14:28] <Gekz_> :<
[11:14:36] <fuzzie> eep
[11:14:43] <Gekz_> 500GB of failure
[11:14:44] <Gekz_> haha
[11:18:49] <-- Forgetful_Lion has left IRC (Read error: 104 (Connection reset by peer))
[11:19:22] --> Forgetful_Lion has joined #GemRB
[12:33:15] <CIA-28> gemrb: 03avenger_teambg * r7441 10/gemrb/trunk/gemrb/plugins/KEYImporter/KeyImp.cpp: look for unpacked files in the CD directories too (needed for some iwd2 movies)
[12:40:09] <-- Forgetful_Lion has left IRC (" HydraIRC -> http://www.hydrairc.com <- Would you like to know more?")
[12:41:17] <CIA-28> gemrb: 03avenger_teambg * r7442 10/gemrb/trunk/configure.in: added BIKPlayer plugin
[12:42:47] * wjp hopes the actual plugin is also going to show up :-)
[12:43:00] <Gekz_> lol
[13:23:08] <CIA-28> gemrb: 03avenger_teambg * r7443 10/gemrb/trunk/gemrb/plugins/2DAImporter/2DAImp.h: simplified 2da code
[13:24:47] <CIA-28> gemrb: 03avenger_teambg * r7444 10/gemrb/trunk/gemrb/plugins/ (19 files in 2 dirs): added BIKPlayer code (still broken)
[13:24:54] <Gekz_> wjp: :<
[14:46:29] <-- tombhadAC has left IRC (Remote closed the connection)
[15:04:19] --> Avenger has joined #gemrb
[15:04:22] --- ChanServ gives channel operator status to Avenger
[15:04:28] <Avenger> hi
[15:05:11] <Avenger> wjp, fuzzie take a look at the bink player?
[15:05:49] <Avenger> i tested it with wotc.mve it looks like GetBitContext is working perfectly, i don't see where is the bug
[15:07:24] <Avenger> i compiled ffmpeg with the bink patch on linux, and added debug printf's to all get_bits calls. I get the same bits, so the input is perfect. The only code i didn't look deeper into is dct.cpp
[15:08:20] <Avenger> well i'll come back later
[15:08:22] <-- Avenger has left IRC (Client Quit)
[15:58:14] <fuzzie> oh
[16:16:55] --> Avenger has joined #gemrb
[16:17:00] --- ChanServ gives channel operator status to Avenger
[16:17:09] <Avenger> hello
[16:18:57] <fuzzie> hi
[16:19:18] <fuzzie> did you try just dumping the audio bits to disk in both BIKPlayer and ffmpeg and comparing the two?
[16:19:31] <fuzzie> i mean, the output ones
[16:19:49] <Avenger> i added printfs into points, like power = get_bits(5) in get_float
[16:20:04] <Avenger> the float values were all the same too
[16:20:20] <Avenger> and the quant/width values a bit below that
[16:20:32] <fuzzie> well, get_float seems way too early
[16:20:35] <Avenger> the reported_size values were almost always correct too
[16:20:40] <Avenger> but it is in a loop
[16:20:49] <Avenger> i checked multiple loops
[16:21:24] <Avenger> it might go wrong at one point, though, because the reported_size was not always correct
[16:21:43] <Avenger> but i didn't check if the original is fine at that point or not
[16:21:59] <Avenger> i should just dump all calculated out buffer sizes
[16:22:32] <Avenger> and of course, i could dump the values of the outbuffer too :)
[16:22:40] <Avenger> i forgot that, hehe
[16:22:46] <fuzzie> that is what i was meaning :)
[16:23:55] <Avenger> well, i worked on this for a long time, i wouldn't mind if someone else looks at it :)
[16:24:27] <fuzzie> i'll have to work out how it all works; eg, i'm not sure what that overlap code is doing
[16:24:50] <Avenger> it modifies a window of outbuffer more than once
[16:26:15] <Avenger> i don't really understand sound compression techniques, but as far as i know it is combination of waves.
[16:31:06] <wjp> yeah, pretty much. The rough idea is that after a Fourier transform, the sound data has 'easier' patterns and is easier to compress, and it's also easier to throw away data that doesn't affect the sound itself much
[16:35:24] <Avenger> btw, i added 3 transform modules: dct, fft, rdft. I'm not sure, but i think we need only 2
[16:35:30] <Avenger> or maybe only one
[16:35:38] <Avenger> if it is one, then we need only dct
[16:35:50] <Avenger> it depends on the files in iwd2
[16:36:34] <wjp> the overlap thing seems to be for reducing audible artifacts between compression blocks. Instead of separate blocks, slightly overlapping blocks are compressed. After decompression, the overlapping area is interpolated between the two decompressed versions
[16:36:37] <Avenger> i just added it because at one point the compiler complained
[16:37:13] <Avenger> ahh yes, the closer to the own block, the bigger the effect of the value
[16:37:31] <Avenger> i saw that, but i wasn't sure why :)
[16:37:33] <fuzzie> wjp: that makes sense
[16:37:35] <wjp> yes, it's something of a 'fade' between blocks
[16:37:51] <Avenger> so the separate waves don't have ugly edges
[16:37:58] <wjp> exactly
[16:41:01] <Avenger> wjp did you patch your own ffmpeg with the bink patch source?
[16:41:32] <Avenger> it is doable with minimal effort on linux. Maybe you can spot where i bugged it
[16:42:32] <wjp> no time today unfortunately
[16:42:42] <wjp> (Christmas dinner tonight)
[16:44:49] <Avenger> 2 weeks early?
[16:45:15] <Avenger> well, i will do some debugging too, after i regained sanity :)
[16:53:47] --> Maighstir has joined #gemrb
[17:00:14] <Taimon> you programmed your own bik demuxer/decoder?
[17:03:13] <Avenger> no it is from ffmpeg
[17:03:53] <Avenger> or rather, a patch submitted to ffmpeg, i don't think it is already in the main branch
[17:04:44] <Avenger> the video part is there too, so we will be able to playback the iwd2 movies soon, before xmas for sure
[17:05:40] <Taimon> from what it looks like the patch is only for audio decoding
[17:06:13] <Avenger> yes, my code is
[17:06:43] <Taimon> does mplayer have bink support?
[17:06:52] <Avenger> because i didn't add all from the original patch (which wasn't for our project, but ffmpeg). It takes a lot efforts to cut it out from the original code
[17:07:08] <Taimon> yeah, must be one hell of a job
[17:07:12] <Avenger> well, mplayer uses ffmpeg, so, the possibility is there
[17:07:29] <Avenger> but as i said, this is only a patch submitted to it, not in the main code tree yet
[17:08:09] <Avenger> i just begged to the ffmpeg authors to continue their reverse engineering :)
[17:08:14] <Taimon> :))
[17:08:36] <Taimon> i hate reversing video stuff
[17:08:41] <Taimon> it's really ugly
[17:09:11] <Avenger> yep, i told him (Kostya), that i read bg2 engine code almost fluently, but the bink player burned my brain
[17:09:39] <Avenger> i got the complete linux disassembly for the bink player, but it is unreadable to me
[17:10:02] <Taimon> did they share any reversing notes with you?
[17:10:12] <Avenger> it is on the net
[17:10:23] <wjp> algorithmic code is typically completely unreadable after compiler optimizations
[17:10:36] <Avenger> http://wiki.multimedia.cx/index.php?title=Main_Page
[17:10:43] <Taimon> thanks
[17:11:05] <Avenger> http://wiki.multimedia.cx/index.php?title=Bink_Video
[17:11:17] <Avenger> this is the video part, but they got a container/audio part too
[17:11:26] <Avenger> i understood only the container part fully
[17:11:26] <Taimon> wjp: definitely, I usually use the x86 emulator to roughly find out what it does
[17:11:36] <Avenger> i think i even fixed a bug in the original submission :)
[17:12:07] <Taimon> that's the most funny part about reversing: seeing bugs in the original code
[17:12:55] <fuzzie> it becomes a bit tiring trying to work out whether it's a bug or whether you missed some fix-up/sanity-check/etc earlier in the code
[17:13:22] <Avenger> ahh that shows that i need to keep dct and rdft, and it seems fft is what we don't need.
[17:13:29] <Avenger> http://wiki.multimedia.cx/index.php?title=Bink_Audio
[17:13:47] <wjp> dinner time; I'll be back tomorrow :-)
[17:14:03] <Avenger> bye wjp
[17:14:10] <Taimon> have a nice dinner :)
[17:14:16] <wjp> thanks :-)
[17:14:38] <Avenger> fuzzie: i think it is better to add debug code into both versions and compare numbers
[17:15:00] <Avenger> it will be quite obvious where is the problem, i just forgot to do it with the output buffer
[17:15:22] <Avenger> i did it with the intermediate data coming from get_bits functions
[17:15:41] <Avenger> actually, i found 2-3 problems with that :)
[17:17:22] <fuzzie> i usually find that optimised vc++ output is many times 'nicer to read' than optimised gcc output, too
[17:18:38] <fuzzie> vc++ reorders code, has pointers at offsets into structs, etc, but it seems fairly predictable in the generated code - maybe i only find this because i am generally reversing code where I have versions from both compilers.
[17:19:58] <Avenger> i think i agree, some iwd2 optimisations actually make the code more readable :)
[17:20:00] <Taimon> i agree, i find vc++ code much easier to read than gcc code
[17:20:34] <Taimon> especially the stack pointer stuff from gcc is misleading / hard to read
[17:20:40] <Avenger> for example, if there is an s->x=1, s->y=2. then the optimized code reads s only once
[17:21:06] <Taimon> depends on what s actually is (for c++)
[17:21:11] <Avenger> well, stack is destroyed by iwd2's optimisation too. there is no call stack listing :(
[17:21:18] <Taimon> hu?
[17:21:21] <Avenger> structure :)
[17:21:32] <Avenger> pointer
[17:21:48] <fuzzie> reusing the registers?
[17:22:21] <Taimon> i meant the iwd2 call stack destruction
[17:22:39] <Avenger> fuzzie like this:004BAD2F 66 FF 8E A6 09 00 00 dec word ptr [esi+9A6h] ;;damage mod
[17:22:41] <Avenger> 004BAD36 66 FF 8E 38 09 00 00 dec word ptr [esi+938h] ;;tohit bonus
[17:22:43] <Avenger> 004BAD3D 66 FF 8E 3C 09 00 00 dec word ptr [esi+93Ch] ;;saving throws
[17:22:45] <Avenger> 004BAD44 66 FF 8E 3E 09 00 00 dec word ptr [esi+93Eh]
[17:22:46] <Avenger> 004BAD4B 66 FF 8E 40 09 00 00 dec word ptr [esi+940h]
[17:22:52] <Avenger> this is much easier to read than the equivalent in bg2
[17:23:19] <Avenger> it just reads s into esi, then does all the stuff
[17:24:01] <Taimon> while in bg2 it always reloads it into eax|ecx|edx after each access
[17:24:18] <Avenger> taimon: it might be that the call stack is usable by some other debugger, but the msvc debugger doesn't see the call stack correctly
[17:24:30] <Avenger> yep, that's it
[17:24:46] <Taimon> does it use the ebp frame setup?
[17:24:59] <Avenger> no frames
[17:25:07] <Taimon> so esp addressing?
[17:25:16] <Taimon> of local vars
[17:25:47] <Taimon> you can past a sample function if you like :)
[17:25:50] <Taimon> paste
[17:26:14] <Avenger> it starts like this: 004BAE10 55 push ebp
[17:26:16] <Avenger> 004BAE11 56 push esi
[17:26:18] <Avenger> 004BAE12 8B 74 24 0C mov esi,dword ptr [esp+0Ch]
[17:26:20] <Avenger> 004BAE16 57 push edi
[17:26:22] <Avenger> 004BAE17 8B F9 mov edi,ecx
[17:26:24] <Avenger> no stack frames
[17:26:32] <Taimon> yeah
[17:26:41] <Avenger> ends like this: 004BAF78 5F pop edi
[17:26:43] <Avenger> 004BAF79 5E pop esi
[17:26:44] <Avenger> 004BAF7A B8 01 00 00 00 mov eax,1
[17:26:46] <Avenger> 004BAF7F 5D pop ebp
[17:26:47] <Avenger> 004BAF80 C2 04 00 ret 4
[17:27:08] <Avenger> luckily most of the code has the same source as in bg2
[17:27:21] <Taimon> ollydbg/ida should be able to give you a call stack
[17:27:34] <Avenger> yes, i suspected that much :)
[17:27:37] <Taimon> :)
[17:28:17] <Taimon> man, i haven't done some reversing for quite some time now
[17:28:18] <Avenger> but i think i understood most of the iwd2 stuff i looked at, so far
[17:28:38] <Taimon> i thought the iwd2 engine was really different from the rest
[17:29:05] <Avenger> no, they all the same, with almost 'minor' hacks :)
[17:29:30] <Avenger> even if they do something differently, it is usually just a minor hack inside
[17:29:43] <Avenger> and lots of cut&paste from the original code :)
[17:29:50] <Taimon> like changing the complete ruleset? :)
[17:29:53] <Avenger> for example, the projectiles
[17:30:08] <Avenger> well, do you realise, the ruleset is about 10 lines of code :P
[17:30:15] <Taimon> sure :)
[17:30:25] <Taimon> in CInfGame
[17:30:57] <Taimon> i think about 10 functions or some such
[17:31:25] <Avenger> i looked most at: projectiles, gamescript, opcodes
[17:31:54] <Avenger> opcodes implement some of the ruleset differences. Ac/saving throws, etc
[17:32:03] <Avenger> but they are not much of a difference
[17:32:09] <Taimon> yeah that surely must be equivalent to the other games (maybe some changes in the script)
[17:32:36] <Avenger> they even kept the saving throw bits, just dropped 2 from the 5
[17:32:57] <Avenger> they moved around how luck affects stuff
[17:33:54] <Taimon> btw luck is surely the uber stat in the game
[17:34:12] <Avenger> yep, by reading the bg2 code i found that out too :)
[17:34:21] <Avenger> i didn't know it is so good
[17:34:52] <Taimon> it doesn't feel like that ingame however
[17:34:54] <Avenger> considering i always try to optimise thaco/damage, i always ignored luck
[17:35:10] <Taimon> iirc fatigue influences luck
[17:35:11] <Avenger> yep, i didn't notice it in play
[17:35:34] <Taimon> and i always pushed my guys to the limits when it comes to fatigue
[17:35:43] <Avenger> yes me too
[17:35:46] <Taimon> :)
[17:36:38] <Taimon> it's strange that i actually lost interest in playing the game when i started reversing it
[17:40:00] <fuzzie> a lot of the differences people claim with the iwd2 engine are just people not understanding how things worked in bg2, i think
[17:40:17] <fuzzie> especially the scripting and messaging
[17:41:01] <Taimon> is the script engine the same?
[17:41:41] <fuzzie> I haven't done any IE reversing, but in just testing by scripts, I see none of the differences I've seen claimed.
[17:42:17] <Avenger> yes, lots of the scripting empirical info is bogus :)
[17:42:40] <Avenger> you may have seen quite a few stuff in gemrb that implemented a false claim
[17:43:30] <Avenger> that's what i said, in the deep they are very similar, even if there is a difference, it is a minor change in code
[17:44:21] <Avenger> it is easy to spot the equivalent parts, and that helps greatly when reading multiple engine code
[17:44:36] <Taimon> yeah, human brains are great pattern matchers
[17:45:04] <Taimon> at least my brain is, i think :)
[17:47:13] <Taimon> btw does the "follow actor into different area" thingie still require research?
[17:48:12] <fuzzie> well, we implemented it simply by following any actor that we still had a reference to, and that seems to match original behaviour..
[17:48:52] <Taimon> good
[17:53:58] <fuzzie> when I last had time to work on gemrb, I was trying to implement some of the more subtle scripting/messaging things
[17:54:23] <fuzzie> like the ClearActions(Self) which seems to pop up occasionally
[17:55:09] <fuzzie> and effect applications (eg, Kill(Myself)) not being instant
[17:56:22] <fuzzie> but I hope just a lightweight global queue is sufficient for reproducing that
[17:58:26] <Avenger> taimon: if you got some up to date structure/function definitions in plain text, i would like them
[17:58:54] <Avenger> i found some new stuff not in your file
[17:58:56] <fuzzie> still not using ida? :)
[17:59:30] <Avenger> for example: 0x2E82 (vid cell/AB9890) [0xD6] (sanctuary)
[17:59:43] <Avenger> you didn't say it is 'sanctuary'
[18:00:11] <Avenger> those vid cells are: sanctuary, grease, minor globe, shield globe, entangle and web
[18:00:15] <Avenger> in that order
[18:01:40] <Avenger> i don't want to learn how to use IDA when i can use that time otherwise :) maybe i do a lot of redundant stuff, dunno. But i guess i learn more this way
[18:02:11] <Taimon> avenger: havent' done any reversing lately
[18:02:32] <Avenger> did you lose motivation?
[18:02:45] <fuzzie> well, no-one seems to have had good questions recently
[18:02:56] <Taimon> time is more of a problem -- but i also needed a break
[18:03:16] <Taimon> I think i already have those btw
[18:03:22] <Taimon> and some more stuff too
[18:03:48] <Avenger> well fuzzie, if it is just a question of questions: i need the door/container/trap structs broken down by fields :P
[18:04:18] <Avenger> i have some of the fields, but not all
[18:04:22] <Taimon> i'll first fix that stupid repeated eff bug before touching anything else
[18:04:48] <Taimon> problem with structure reversing is that it's boring most of the time :)
[18:04:52] <Avenger> what bug is that? something in the original game?
[18:04:56] <Taimon> yeah
[18:05:09] <Taimon> let's see if i find it on g3
[18:05:11] <Avenger> structure reversing is helpful in understanding the code using that struct
[18:05:35] <Avenger> it is usually enough to know what fields are used in a given code, and you know what it does
[18:05:43] <Avenger> or at least, get a good clue
[18:06:12] <Avenger> the list you gave me was very helpful
[18:07:23] <Taimon> which one? the structures or the function names?
[18:15:25] <Taimon> http://forums.gibberlings3.net/index.php?showtopic=17833&st=60&p=157623&#entry157623
[18:15:32] <Taimon> and following (for the bug)
[18:17:07] <Avenger> the structures mostly
[18:17:19] <Avenger> the function list was rather useless, always missing the one i needed ;)
[18:18:08] <Avenger> i compiled a list of the messages
[18:18:16] <Avenger> THAT would have been useful
[18:18:44] <Avenger> like: 0AA6934h ;;BanterBlockTime
[18:19:00] <Avenger> i think i got almost all by now
[18:19:07] <Taimon> i think i had some of them in the names list
[18:19:10] <Avenger> at least, as an entry in my list
[18:19:19] <Taimon> like msg_send_trigger and so on
[18:19:29] <Avenger> some are quite cryptic
[18:19:40] <Avenger> 0AA5C84h ;;send trigger message
[18:19:50] <Taimon> (the funny thing with IDA is to come up with meaningful names for all the functions/classes/etc.)
[18:19:52] <Avenger> you say this is in some of your lists you gave me?
[18:20:08] <Taimon> not sure if I gave you a list of names
[18:20:32] <Taimon> or rather exported them
[18:21:23] <Avenger> yep, i don't think so
[18:21:35] <Avenger> i could use that list, even if just to confirm my findings
[18:21:38] <Avenger> i could send you mine
[18:22:05] <Avenger> i also have most of the message code disassembled, and annotated
[18:22:18] <Taimon> sure, but i'm afraid i can't check them right now
[18:22:22] <Avenger> well, annotated is a big word, i mean, some marks :)
[18:22:27] <Taimon> :)
[18:23:12] <Avenger> Like in the apply_effect message:
[18:23:14] <Avenger> 008F7FCF 8B 45 B4 mov eax,dword ptr [ebp-4Ch]
[18:23:16] <Avenger> 008F7FD2 05 F2 0D 00 00 add eax,0DF2h ;;cre type protection
[18:24:32] <Avenger> ok, i dive back into the bink decoder
[18:24:39] <Taimon> good luck
[18:25:51] <Taimon> oh before i forget: i was trying to build gemrb and autogen.sh failed to determine the correct libtoolize version (mine was 226b)
[18:26:25] <Taimon> added s/[a-z]//; somewhere in the sed call
[18:31:21] <Avenger> hmm
[18:31:26] <Avenger> i don't know where
[18:32:06] <Avenger> version=`$file --version | sed -n '1 { s/^[^ ]* (.*) //; s/ .*$//; s,\.,,g; p; }'`
[18:32:11] <Avenger> this one?
[18:32:40] <Avenger> ahh this one: libtool_version=`$file --version | sed -n '1 { s/^[^ ]* (.*) //; s/ .*$//; s,\.,,g; p; }'`
[18:32:59] <Taimon> yep
[18:33:19] <Taimon> but add something more careful than my silly hack
[18:33:20] <Taimon> :)
[18:33:36] <Avenger> i'm not THAT good with regexps
[18:33:52] <Taimon> no one is - they are evil
[18:33:54] <Avenger> i don't even know what ^[^ ] means
[18:34:12] <Taimon> start + no whitespace
[18:34:24] <Avenger> and why it failed for you
[18:34:39] <Taimon> the regexp doesn't fail
[18:34:44] <Taimon> the check afterwards fails
[18:35:11] <Avenger> 226b is greater than 15
[18:35:23] <Taimon> shell says 226 is no integer
[18:35:27] <Taimon> 226b
[18:35:47] <Avenger> ooh
[18:35:49] <Taimon> :)
[18:35:59] <Avenger> it was b as in beta?
[18:36:13] <Taimon> no idea
[18:36:24] <Taimon> I'm on archlinux and this is the current version in repos
[18:36:45] <Avenger> so we could use ^[^ a-z] ?
[18:37:28] <Avenger> or hmm no
[18:37:30] <Taimon> nope, rather s/[a-z]$// ;
[18:38:07] <Avenger> maybe: libtool_version=`$file --version | sed -n '1 { s/^[^ ]* (.*)[a-z]* //; s/ .*$//; s,\.,,g; p; }'`
[18:38:20] <Avenger> i added [a-z]* at the end
[18:38:51] <Taimon> do it in a separate s/..//; statement
[18:39:01] <Taimon> and at the end is probably the best
[18:39:15] <Taimon> (but before p;)
[18:39:57] <Avenger> i would rather let someone who knows sed syntax more than I do
[18:40:30] <Taimon> well, the whole parsing version string is fragile per definition
[18:40:44] <Avenger> yes
[18:40:59] <Avenger> this whole gnu make system sucks :)
[18:41:03] <Taimon> ;)
[18:42:12] <Taimon> openal, sdl + python is all i need, right?
[18:42:20] <Avenger> 15 is 1.5, i guess?
[18:42:24] <Taimon> jep
[18:42:34] <Avenger> and we strip the . from the number
[18:42:40] <Avenger> so 10.5 will be 105
[18:42:41] <Taimon> it looks like
[18:43:08] <Avenger> and 1.4.0 is 140
[18:43:17] <Taimon> yeah it's pretty pointless
[18:43:22] <Avenger> this seems to be useless
[18:43:36] <Taimon> (pun not intended)
[18:43:43] <Avenger> :)
[18:44:09] <Avenger> but its true
[18:44:57] <Avenger> maybe we should parse for major/minor
[18:45:24] <Taimon> is the autogen.sh from an external party?
[18:45:35] <Avenger> no
[18:45:38] <fuzzie> lynxlynxlynx maintains it, I think.
[18:45:56] <Avenger> i guess he got it from some other project, and modified it to our needs
[18:46:13] <Taimon> well, i say don't bother modifying it if it works for you
[18:46:31] <Taimon> just thought i let you know about it :)
[18:46:51] <Avenger> he even uses it: libtool_version_major=`echo "libtool_version" | cut -c1`
[18:47:57] <Avenger> well, cut -c1 would just cut the first letter?
[18:48:19] <Taimon> yep (character)
[18:48:22] <Avenger> so 10.5 would be 1 :)
[18:48:26] <Avenger> same bug
[18:48:28] <Taimon> hehe
[18:48:34] <Avenger> should go for the points
[18:49:04] <Avenger> cut -d. ?
[18:49:47] <Avenger> cut -d. -f1
[18:49:52] <Avenger> that would do the trick
[18:50:05] <Taimon> yeah
[18:51:02] <Avenger> ok, why is version 2 handled differently
[18:51:20] <Avenger> --no-warn is added if version=2
[18:52:13] <Taimon> no idea, libtoolize doesn't even have a man page on my system
[18:52:44] <Taimon> but an info entry
[18:53:13] <Taimon> probably "deprecated libtool macros" or "stylistic issues" :)
[18:53:41] <fuzzie> Avenger: i think --no-warn doesn't work before v2
[18:53:57] <Taimon> how old is 1.5 anyway?
[18:53:58] <Avenger> what versions are available nowadays?
[18:54:18] <Avenger> it would be really helpful if we handle only 2.0 and above
[18:54:32] <fuzzie> lynx changed it to just use the v2 features
[18:54:35] <Avenger> at least when i edit this autogen.sh script :)
[18:54:37] <fuzzie> and then several people complained it didn't work any more
[18:54:43] <Avenger> meh
[18:54:46] <fuzzie> hence the checks :(
[18:55:21] <Avenger> ok, how do i add an OR operator in this condition : if [ "$libtool_version_major" -gt 1 ];
[18:55:29] <Avenger> i want it to work after 1.5
[18:55:40] <Avenger> i already got major/minor
[18:55:58] <Taimon> || ?
[18:56:29] <Taimon> help [
[18:56:33] <Avenger> if [ "$libtool_version_major" -gt 1 ] || [ "$libtool_version_minor" -gt 5 ];
[18:56:35] <Avenger> ?
[18:56:44] <Avenger> it will allow 0.xx through
[18:56:48] <Avenger> but i don't care :)
[18:57:32] <Taimon> the latest 1.5 is from 02/2008
[18:57:36] <Taimon> not that old
[18:57:49] <Avenger> oh
[18:58:13] <Avenger> and since when we have the luck to use 1.0 and above
[18:58:41] <fuzzie> the oldest 1.5 is years ago, so i think it would be safe to assume that, even
[18:58:53] <Avenger> if [ "$libtool_version_major" -gt 1 || "$libtool_version_minor" -gt 5 ];
[18:59:00] <Avenger> maybe this is the right syntax?
[18:59:21] <Taimon> inside of [ you have to use -o
[18:59:39] <Taimon> but the one you posted earlier should also work
[18:59:41] <Avenger> oh so either ] || [ or -o ?
[19:00:08] <Taimon> your choice
[19:01:48] <Avenger> huh, this doesn't work: echo "libtool_version" | cut -d. -f1
[19:01:56] <Avenger> it will echo the text literally, not the variable :)
[19:02:08] <Avenger> so, hmm, how did it work originally
[19:02:56] <Avenger> needs a $ i think
[19:03:30] <Taimon> yep
[19:05:38] <Taimon> compiled fine with g++ 4.4.2, btw
[19:08:53] <Avenger> btw, i should have cut \. from a different part :)
[19:09:05] <Avenger> it is sed -n '1 { s/^[^ ]* (.*) //; s/ .*$//; s,,,g; p;
[19:09:15] <Avenger> now i finally got 1.5.26
[19:09:28] <Taimon> hehe
[19:09:50] <Taimon> didn't you want to look at bink player code instead?
[19:11:09] <Avenger> yes i did
[19:11:23] <Avenger> but i got the 'easily sidetracked' achievement in DA too
[19:11:33] <CIA-28> gemrb: 03avenger_teambg * r7445 10/gemrb/trunk/autogen.sh: correctly detect libtool versions (use major/minor)
[19:11:48] <Avenger> consider this a minor quest :)
[19:13:06] <Avenger> i hope i didn't break anything
[19:17:29] <Avenger> heh, the outbuffer is significatly different
[19:18:00] <Avenger> we got lots of -32768 (out of scale value)
[19:18:35] <Avenger> i look at the float values, then
[19:20:23] <Taimon> considering r7445: you can remove the entire s,,,g (it's like a noop) :)
[19:22:28] <lynxlynxlynx> back
[19:22:30] <Avenger> i will let lynx do his job
[19:23:48] <lynxlynxlynx> let me check the backlog
[19:23:49] <Avenger> cool
[19:23:53] <Avenger> the floats are the same!
[19:24:04] <Avenger> the floats are the same, but the ints not
[19:24:31] <Avenger> so ff_float_to_int16_interleave_c is the bad part
[19:24:58] <Avenger> i'm really relieved
[19:25:13] <Avenger> it would have been a hell of a debug if i have to dive into the dct.cpp code
[19:25:16] <fuzzie> :)
[19:25:35] <Taimon> signal processing ftw
[19:25:40] <Taimon> i hate it :)
[19:25:58] <fuzzie> so is it just the float_to_int16_one?
[19:26:29] <Avenger> float_to_int16_one
[19:26:31] <Avenger> yes
[19:26:36] <Avenger> it is weird
[19:26:42] <Avenger> it has nothing 'special'
[19:26:52] <Avenger> i would expect more from a float to int conversion
[19:26:56] <Avenger> no rescaling
[19:27:16] <Avenger> it seems i missed some layer of code
[19:27:25] <Avenger> it cannot be this simple
[19:27:32] <Taimon> which file?
[19:27:54] <Avenger> in the original?
[19:27:57] <fuzzie> i did wonder about that :) but if the floats are the same, victory, i guess!
[19:28:04] <Avenger> BIKPlay.cpp
[19:31:22] <Avenger> haha, i guess it shouldn't be 'unsigned'
[19:32:05] <Avenger> wow
[19:32:11] <fuzzie> works?
[19:32:17] <Avenger> now the sound is recognisable in middle of noise
[19:32:21] <fuzzie> :-)
[19:32:21] <Avenger> but definitely there
[19:32:30] <Avenger> cool
[19:33:01] <Avenger> this is like tuning an old radio
[19:34:15] <CIA-28> gemrb: 03avenger_teambg * r7446 10/gemrb/trunk/gemrb/plugins/BIKPlayer/BIKPlay.cpp: tuning on...
[19:35:32] --> barra_desktop has joined #gemrb
[19:35:57] <Avenger> hmm odd, the outbuffer is still full of -32768 values
[19:37:28] <-- kettuz has left IRC ("Leaving")
[19:39:54] --> |Cable| has joined #gemrb
[19:40:22] <-- |Cable| has left IRC (Client Quit)
[19:40:46] --> |Cable| has joined #gemrb
[20:45:18] --> tombhadAC has joined #gemrb
[20:50:25] <-- Gekz_ has left IRC ("Leaving")
[21:21:37] <Avenger> well, if i simply convert tmp from float to int, the noise is almost bearable
[21:22:07] <Avenger> i don't know what's that 0x43c0ffff doing there
[21:22:16] <Avenger> i guess it is x86 specific anyway
[21:22:38] <-- barra_desktop has left IRC ("Verlassend")
[21:22:45] <Taimon> gotta go, see you
[21:22:59] <-- Taimon has left IRC ("leaving")
[21:28:57] <CIA-28> gemrb: 03avenger_teambg * r7447 10/gemrb/trunk/gemrb/plugins/BIKPlayer/BIKPlay.cpp: straight float to int16 conversion ... (almost good)
[21:29:22] <Avenger> the original ffmpeg code uses sse, not even that routine i found
[21:30:06] <fuzzie> no portable alternative?
[21:30:18] <Avenger> the current code is 'portable'
[21:30:30] <fuzzie> i mean, in the original ffmpeg code
[21:30:33] <Avenger> i think it doesn't handle the border cases perfectly
[21:30:46] <Avenger> the ffmpeg 'portable' code is the one i used, but that is simply wrong
[21:30:55] <Avenger> and well, probably not portable
[21:31:13] <Avenger> that 0x43c0ffff value seems like some internal representation
[21:32:35] <Avenger> there is now some jerky sound and occasional cracks
[21:32:47] <Avenger> but it is much better than before
[21:33:31] <Avenger> i guess it needs some rounding, and handling of the border cases or probably the buffer size is not always calculated correctly
[21:33:52] <Avenger> probably the openal resource management is buggy too
[21:34:10] <Avenger> i see lots of 'unable to queue buffer' messages, even when the sound is playing
[21:34:33] <Avenger> could be the cause of the jerky sound
[21:36:01] <Avenger> hmm, it could also be the timing between frames
[21:36:13] <Avenger> the original ffmpeg code used rational numbers
[21:36:27] <Avenger> i simply use the code you had with mveplayer
[21:37:08] <Avenger> tomorrow i will look at the video part
[21:37:10] <fuzzie> you're waiting between frames?
[21:37:15] <Avenger> yes i do
[21:37:38] <fuzzie> the 'unable to queue buffer' stuff is not good, i think
[21:37:49] <Avenger> well, this whole code is wrong :)
[21:38:15] <fuzzie> probably you're not waiting for long enough and there is too much audio to buffer..
[21:38:20] <Avenger> it could be that even the original code has the cracking artifacts, but the jerky sound is our problem
[21:39:25] <lynxlynxlynx> i don't remember problems
[21:39:30] <Avenger> well, i guess you are right, maybe the waiting code is simply without effect
[21:39:38] <fuzzie> lynxlynxlynx: original code as in ffmpeg
[21:39:49] <Avenger> lynx: you surely don't remember, you never tried ffmpeg's experimental bink player :D
[21:40:08] <Avenger> i think i'm in the first 10 people who tried it
[21:40:49] <lynxlynxlynx> ah
[21:41:15] <Avenger> this is not the interplay mve we already have
[22:01:11] <-- Avenger has left IRC ("bye!")
[22:27:39] <-- lynxlynxlynx has left IRC (Remote closed the connection)