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

Archive Today Yesterday Tomorrow
GemRB homepage

[00:07:08] --> edheldil has joined #GemRb
[00:28:36] --> raevol has joined #GemRb
[00:53:02] <-- edheldil has left IRC (Ping timeout: 260 seconds)
[00:57:47] --> ratpor has joined #GemRb
[02:30:44] <-- Maighstir_laptop has left #GemRb
[04:02:04] --> ratwind has joined #GemRb
[04:02:05] --- ratwind is now known as ratwars
[04:04:22] <-- ratpor has left IRC (Ping timeout: 258 seconds)
[07:26:42] <-- raevol has left IRC (Quit: Leaving.)
[07:39:00] <-- Gekz has left IRC (Ping timeout: 276 seconds)
[08:01:41] --> lynxlynxlynx has joined #GemRb
[08:01:42] --- ChanServ gives channel operator status to lynxlynxlynx
[08:16:57] --> edheldil has joined #GemRb
[08:59:01] <-- edheldil has left IRC (Ping timeout: 265 seconds)
[09:44:18] <fuzzie> wjp: any idea if there's anything to scummvm-on-android beyond what's on the sf patch tracker?
[09:46:37] --> edheldil has joined #GemRb
[09:47:25] <fuzzie> (morning edheldil, lynx)
[09:48:20] <lynxlynxlynx> gmornin
[09:50:35] <fuzzie> is it just the bg2 ui with the flickering?
[09:52:57] <lynxlynxlynx> the ai buttons?
[09:53:18] <fuzzie> well, any flickering redraw issues :)
[09:53:47] <lynxlynxlynx> i think dialogs are affected in some games too
[09:54:45] <fuzzie> the problem with the bg2 buttons is two-fold: the draw order is sometimes wrong, but in any case, the animation in the bottom-left causes the whole action bar to re-draw on top every frame
[09:55:50] <lynxlynxlynx> you mean the gears?
[09:55:54] <fuzzie> yes
[09:56:14] <lynxlynxlynx> why isn't just the button control redrawn?
[09:56:25] <fuzzie> because that breaks iwd2's transparent animation s
[09:56:51] <fuzzie> i wrote some more intelligent redraw code, just wondering if there's anywhere else i should be looking to test it.
[09:57:36] <edheldil> morning, fuzzie
[09:57:40] <lynxlynxlynx> can't think of anything else
[09:57:45] <edheldil> lynx, and all
[09:59:58] <fuzzie> i do like iwd2's animated paperdolls :)
[10:01:39] <-- ratwars has left IRC (Quit: Get used to disappointment.)
[10:45:17] <lynxlynxlynx> tomprince: http://repo.or.cz/w/gemrb.git/commit/951e4b looks ok, you can commit it if you've tried it
[10:48:15] <-- edheldil has left IRC (Ping timeout: 265 seconds)
[10:48:45] <fuzzie> lynxlynxlynx: any idea about http://repo.or.cz/w/gemrb.git/commitdiff/d98f4fe2a365e2af0b5106e3e8468a83b5dfaa6d ?
[10:50:24] <lynxlynxlynx> way over my head
[10:56:24] <fuzzie> and i guess we're waiting on replies to comments about NickDaly's patch
[10:59:37] <fuzzie> and the keymap.ini thing is not done.
[11:01:12] --> edheldil has joined #GemRb
[11:01:50] <fuzzie> edheldil: any idea about http://repo.or.cz/w/gemrb.git/commitdiff/d98f4fe2a365e2af0b5106e3e8468a83b5dfaa6d ?
[11:17:15] <-- edheldil has left IRC (Ping timeout: 265 seconds)
[11:32:37] <-- Nomad010 has left IRC (Ping timeout: 246 seconds)
[11:32:43] --> Nomad010 has joined #GemRb
[11:45:05] --> Maighstir_laptop has joined #GemRb
[11:45:07] --> edheldil has joined #GemRb
[11:58:38] <edheldil> fuzzie, I am not really sure that all the changes are ok, but my autotools knowledge is a bit rusted and I have no FreeBSD handy at the moment to at least check it there
[12:00:11] <edheldil> things like replacing @PNG@ with -lpng seem a bit suspicious, though
[12:04:43] <Gekz_> fuzzie: is the 'feature' where you can kill required npcs fixed in BG1 in GemRB?
[12:04:48] <Gekz_> for example, nashkel mines
[12:04:56] <Gekz_> if you kill the prospector, you can never go into the mines
[12:10:25] <-- edheldil has left IRC (Ping timeout: 265 seconds)
[12:31:27] --> edheldil has joined #GemRb
[12:41:37] <fuzzie> Gekz_: i think you could mod it to set the flags..
[13:03:02] <tomprince> The reason that I switched @LIBPNG@ to -lpng is that that we set LIBPNG unconditionally in configure anyway.
[13:03:53] <tomprince> It would perhaps make sense to have somthing more refined in configure.ac and the correspongin change in the Makefile.ams.
[13:14:34] <tomprince> I have tested http://repo.or.cz/w/gemrb.git/commit/951e4b
[13:17:14] <fuzzie> want it applied?
[13:17:49] <tomprince> Sure.
[13:18:27] <CIA-43> GemRB: 03tom.prince * rcc8d9376ae6d 10gemrb/ (Makefile.am gemrb/docs/en/Release.txt):
[13:18:27] <CIA-43> GemRB: Update release instructions.
[13:18:27] <CIA-43> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[13:19:09] <tomprince> Should we also change the AC_INIT to at least 0.6.0-git?
[13:20:25] <fuzzie> a question for lynx, i guess
[13:48:52] --- Gekz_ is now known as Gekz
[13:49:53] <lynxlynxlynx> what good would that be?
[14:07:12] <tomprince> No big deal, just in case 'make dist' gets into the wild or something. Not that that is likely.
[14:10:13] <tomprince> And, logfiles would make it clear whether it was a release, or a git version.
[14:10:20] <lynxlynxlynx> well, we can change it at release time when you don't notice the change, since you have to rebuild anyway
[14:10:47] <lynxlynxlynx> (two consecutive changes)
[14:51:18] <edheldil> porting the LUA plugin to current gemrb and lua5.0 is not as hasslefree as I had hoped
[14:54:44] <tomprince> Which is the hassle? Lua or gemrb?
[14:58:39] <fuzzie> wouldn't be surprised if it were both, a lot changed since our last discussion of the possibility
[14:59:00] <fuzzie> and that was not so long ago itself
[15:02:15] <tomprince> I would be willing to forward port the gemrb side, since I am responsible for most of the structural changes on the gemrb side.
[15:09:04] <edheldil> the answer is both ... there's something virtual in ScriptEngine and Lua's API is surprisingly rather volatile
[15:09:20] <edheldil> but I will fix it
[15:17:28] <-- edheldil has left IRC (Ping timeout: 265 seconds)
[15:18:16] <tomprince> I have got the impression that 5.0 was a major jump, at least API wise.
[15:35:34] --> edheldil has joined #GemRb
[15:37:27] <-- Maighstir_laptop has left #GemRb
[15:46:07] <-- Nomad010 has left IRC (Read error: Network is unreachable)
[15:46:21] --> Nomad010 has joined #GemRb
[17:13:46] <-- edheldil has left IRC (Read error: Operation timed out)
[17:45:24] --> Maighstir_laptop has joined #GemRb
[18:14:58] --> edheldil has joined #GemRb
[19:03:50] --> guidoj has joined #GemRb
[19:10:12] <fuzzie> hi, guidoj
[19:30:48] <guidoj> hi all
[19:38:23] <tomprince_loki> Hello.
[19:58:03] <fuzzie> http://pastebin.com/ZC3VzUWy <- this helps, but not as much as i'd hoped.
[20:01:02] <fuzzie> (i'm pretty ill today, so pending commits are going to say pending until the code stops blurring in front of my eyes)
[20:03:45] <lynxlynxlynx> get off the computer, you gibberling
[20:04:25] <fuzzie> i am sitting in a corner watching DVDs on it while people feed me tea :)
[20:14:18] <tomprince_loki> That looks not bad.
[20:14:44] <tomprince_loki> A further cleanup would be to move the CaseSensitive check into FindInDir, and change it so that it doesn't allocate.
[20:16:01] <fuzzie> that is a good idea.
[20:16:21] <tomprince_loki> Also, in SearchIn, you can just check the return of FileStream::Open, rather than calling exists.
[20:18:27] <fuzzie> also a good point :)
[20:20:01] <tomprince_loki> That is about what I had in mind talking about Path objects, but you managed to do it with out adding another layer of abstraction.
[20:20:05] <tomprince_loki> Much simpler. :)
[20:20:10] <tomprince_loki> Yours, that is.
[20:20:34] <fuzzie> i would prefer the Path objects eventually
[20:23:11] <fuzzie> lots of improvements which could be hidden in the VFS, anyway, like the caches. but this is a simple change for now :)
[20:23:53] <tomprince_loki> Yes. VFS shouldn't be exposing the posix api. ;)
[20:28:55] <tomprince_loki> I don't like the strcpy, but I suspect that we are sloppy enough already, that it doesn't matter.
[20:29:28] <tomprince_loki> I mean, in terms of assuming that file paths and stuff are sanely sized.
[20:32:31] <fuzzie> Oh, that was just in that tree already.
[20:34:03] <fuzzie> I am not sure what the best solution is for that. It's annoying that it's called so much, but perhaps unavoidable.
[20:34:58] <tomprince_loki> I meant in DirectoryImporter. It used to be strncpy( ..., 8) but that would break MUSImporter using DirectoryImporter on relative paths, rather than filenames.
[20:35:17] <fuzzie> Sorry, I meant, it's in the diff because I made the modification locally.
[20:35:30] <tomprince_loki> Ah.
[20:38:34] <tomprince_loki> I don't think in practice the strcpy would be a problem.
[20:43:39] <fuzzie> I can't think that it must be inefficient for KEYImporter to open the BIF file again everytime it needs a file, assuming I am reading that code correctly.
[20:45:41] <tomprince_loki> It probably is a bit inefficent. I don't know how expensive fopen is, or BIFmporter. The only subtlety to that is the GameOnCD case.
[20:49:58] <fuzzie> I also imagine changing the constants at the top of ZLibManager.cpp from 4096 to something more sensible (65536?) would be a good thing, but again it is just a thought.
[20:52:33] <fuzzie> It is funny to be able to waste so much stack space without thinking. :)
[21:04:32] <tomprince_loki> I don't know if that would be a win. I'd want to see numbers before making that change. I suspect that stdio would break it into smaller reads, and that zlib is about as efficent on lots of small blocks as a single large block.
[21:07:20] <tomprince_loki> I'm not saying that it would be.
[21:10:01] <fuzzie> If I make that change, strace shows it reading 61440 bytes every read() call; not very efficient at all, since most of the files are tiny, so it is discarding most of that.
[21:10:38] <edheldil> stupid lua does not have extern"C" {} in its headers, that explains part of my problems
[21:10:58] <fuzzie> I hadn't realised that BIFImporter didn't pass the compressed size on.
[21:12:17] <tomprince_loki> Apparently the reason for that is that lua is written in the intersection of standard C and standard C++, so lua can be compiled as C++, and then extern "C" would be wrong.
[21:12:22] <tomprince_loki> Or so the faq says. :)
[21:13:39] <edheldil> ah, but the one in Ubuntu is compiled with C
[21:18:35] --> cfchris6_ has joined #GemRb
[21:21:58] <-- cfchris6 has left IRC (Ping timeout: 264 seconds)
[21:33:55] <tomprince_loki> fuzzie: You could pretty well even when the code is blurring in front of you. :)
[21:46:18] <tomprince_loki> s/could/code/ of course.
[21:58:59] <-- guidoj has left IRC (Remote host closed the connection)
[22:10:52] <-- Nomad010 has left IRC (Ping timeout: 252 seconds)
[22:22:29] --> Nomad010 has joined #GemRb
[22:30:16] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:00:56] <edheldil> night
[23:13:34] <-- edheldil has left IRC (Ping timeout: 264 seconds)