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

Archive Today Yesterday Tomorrow
GemRB homepage

[00:05:50] <-- raevol has left IRC (Quit: Leaving.)
[00:14:53] <tomprince_loki> I didn't see anything worth saving in the tracker. Other than open items of course.
[00:15:03] <tomprince_loki> Having reaad through all of it. :)
[00:31:32] <Edheldil_> good night
[00:31:36] <-- Edheldil_ has left IRC (Quit: Really?)
[01:24:25] <-- Nomad010 has left IRC (Ping timeout: 240 seconds)
[04:04:12] <-- Gekz has left IRC (Read error: Connection reset by peer)
[04:04:29] --> Gekz has joined #GemRb
[07:10:10] --> lynxlynxlynx has joined #GemRb
[07:10:10] --- ChanServ gives channel operator status to lynxlynxlynx
[07:12:14] --> Gekz_ has joined #GemRb
[07:13:55] <-- Gekz has left IRC (Read error: Connection reset by peer)
[07:17:30] --> Gekz has joined #GemRb
[07:18:23] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[07:41:58] <-- Gekz has left IRC (Ping timeout: 252 seconds)
[07:42:27] --> Gekz has joined #GemRb
[07:53:19] --> Gekz_ has joined #GemRb
[07:53:29] --> raevol has joined #GemRb
[07:53:59] <-- Gekz has left IRC (Read error: Connection reset by peer)
[08:01:20] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[08:01:36] --> Gekz has joined #GemRb
[08:04:18] <-- Gekz has left IRC (Read error: Connection reset by peer)
[08:04:36] --> Gekz has joined #GemRb
[08:25:50] <-- |Cable| has left IRC (Remote host closed the connection)
[08:49:28] --> Gekz_ has joined #GemRb
[08:49:33] <-- Gekz has left IRC (Read error: Connection reset by peer)
[08:56:55] <-- raevol has left IRC (Quit: Leaving.)
[09:08:55] <-- Edheldil has left IRC (Remote host closed the connection)
[09:13:33] --> edheldil has joined #GemRb
[09:35:12] --> Gekz has joined #GemRb
[09:36:21] <-- Gekz_ has left IRC (Ping timeout: 260 seconds)
[09:40:15] --> Gekz_ has joined #GemRb
[09:40:40] <-- Gekz has left IRC (Ping timeout: 268 seconds)
[10:26:35] --> Nomad010 has joined #GemRb
[10:28:09] --> Brendan__ has joined #GemRb
[10:29:58] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[10:31:27] <-- Nomad010 has left IRC (Ping timeout: 258 seconds)
[10:36:33] --- Brendan__ is now known as Gekz
[10:36:42] <-- Gekz has left IRC (Changing host)
[10:36:42] --> Gekz has joined #GemRb
[11:05:14] <-- Gekz has left IRC (Read error: Connection reset by peer)
[11:05:24] --> Gekz has joined #GemRb
[12:15:36] --> Nomad010 has joined #GemRb
[12:41:46] <tomprince> Morning..
[12:42:05] <wjp> hi
[12:49:35] <edheldil> hi
[13:24:08] --> kettuz has joined #GemRb
[14:43:25] <-- Gekz has left IRC (Read error: Connection reset by peer)
[14:43:59] --> Gekz has joined #GemRb
[15:23:51] <fuzzie> tomprince: Did you have time to work out how to fix the mingw build, yet?
[15:24:45] <tomprince_loki> No, no more than I had yesterday morning.
[15:29:57] <tomprince_loki> I was wondering if the proper fix might be to use _WIN32 instead of WIN32.
[15:32:57] <fuzzie> I think _WIN32 is more standard, but does -ansi really just cause that single define to be removed?
[15:33:45] <tomprince_loki> Well, I haven't tested the _WIN32 thing yet ... working on other stuff.
[15:34:16] <tomprince_loki> But _* is reserved for compilers/implementions by ansi, where as WIN32 isn't.
[15:34:52] <tomprince_loki> That means that a legal ansi program could use WIN32 for whatever it wanted, but not _WIN32. Hence WIN32 going away with -ansi.
[15:38:49] <fuzzie> *nod*, I see that in the documentation now.
[15:39:33] <fuzzie> Thankyou. :)
[15:51:49] <Gekz> how odd
[15:52:13] <tomprince_loki> ?
[16:17:38] <Gekz> it's a self-evident truism
[16:18:41] <tomprince_loki> ??
[16:24:30] <Gekz> you're just dragging on with the emphasis
[16:24:59] <fuzzie> it occurs to me that 'gekz' is really a fairly appropriate name
[16:25:39] <Gekz> why so
[16:54:00] --> ratpor has joined #GemRb
[16:58:34] <tomprince_loki> fuzzie: nice. :)
[17:04:04] --> |Cable| has joined #GemRb
[17:04:24] <-- Gekz has left IRC (Read error: Connection reset by peer)
[18:38:21] <tomprince> Apparently "3e8749defd61 Rework plugin interface to Core." Broke MSVC6, since it tries to instantiate std::vector<ResourceDesc> in PluginMgr.h, but ResrouceDesc is only forward declared there. :/
[18:40:04] <tomprince> Easy enough to fix, but I'd rather drop support. :)
[18:40:29] <tomprince> And it is only worth fix if we end up needing to continue support MSVC6.
[18:40:44] <fuzzie> Dropping the compiler of the largest contributor by an order of magnitude? :)
[18:41:09] <tomprince> Well, exepct it obviously isn't the only compiler he uses.
[18:41:21] <fuzzie> No, but it's the one he usually uses.
[18:43:25] <tomprince> Well, like I said, I'd like to drop it, if possible, would like to hold off workarounds for things that are already in the tree, until ....
[18:43:57] <fuzzie> We'll just end up reverting months of refactoring in the end.
[18:44:51] <fuzzie> Because there's not much point having a nicely refactored gemrb if the only coder we have who actually understands half the engine can't work on it any more.
[18:45:24] <tomprince> Well, like I said the other day, I'll asking him about next time he shows up ...
[18:45:47] <fuzzie> Sure, but you know he puts a large amount of effort into fixing MSVC6 support in the tree?
[18:46:07] <fuzzie> Any large commit I've made has usually broken something subtle, like the fact that 'for' statements aren't their own scope in MSVC6.
[18:46:14] <fuzzie> It's not like he's just using it because it's the easiest option.
[18:47:01] <tomprince> Yes.
[18:50:46] <fuzzie> (And I've wanted to use more modern functionality all over the place, so I tried this already a year ago.)
[18:53:09] <fuzzie> If that's really the only msvc6 problem, though, it doesn't seem like it would be difficult to fix, even if you don't want to do it right now.
[18:54:05] <-- tomprince has left IRC (Ping timeout: 265 seconds)
[18:54:09] <fuzzie> I've been more concerned about having to revert large amounts in three months time, once people already applied bugfixes etc on top.
[18:54:41] --> raevol has joined #GemRb
[19:06:05] --> tomprince has joined #GemRb
[19:17:34] <wjp> hm, git question: is there an automatic way to locally clean up the branches from or.cz that are gone?
[19:18:07] <fuzzie> see 'git remote prune'
[19:18:55] <wjp> thanks
[19:31:04] <tomprince> Apparently "http://ftp.linuxfoundation.org/pub/lsb/lsbdev/released-all/binary/ia32/lsb-build-base-4.0.9-2.i486.rpm
[19:31:44] <tomprince> Apparently "dbb8138a5c1a6132b also breaks MSVC6".
[19:32:32] <fuzzie> The templated CreateResource?
[19:32:47] <fuzzie> Or the empty TypeID struct?
[19:33:04] <tomprince> The second. Although maybe also the first.
[19:34:52] <tomprince> The fact that it has been broken on msvc6 since the end of December leads me to believe that it might be reasonable to drop support.
[19:35:05] <fuzzie> No.
[19:35:25] <fuzzie> I mean, I know you keep pushing this, but you have the version control logs, you can see that Avenger takes long breaks.
[19:35:58] <tomprince> Like I said, I'll ask him about it next time he shows up.
[19:36:14] <fuzzie> If you get him to agree it's fine, but it's not like he's been working on gemrb recently, and he's said as much when he's been here.
[19:36:46] <fuzzie> And you can always email him about it.
[19:37:18] <tomprince> No, I wasn't suggesting unilateraly dropping support.
[19:37:32] <fuzzie> We'll have to fix the empty struct anyway.
[19:37:37] <tomprince> Obviously, that wouldn't be acceptable.
[19:37:41] <tomprince> How come?
[19:38:06] <fuzzie> Modern MSVC (well, v8) doesn't seem to like them either.
[19:38:15] <tomprince> Although, my idea about caching in gamedata might make the non-empty anyway.
[19:39:11] --> edheldil_ has joined #GemRb
[19:44:18] <fuzzie> *nod*, I don't know how you'd design that.
[19:45:27] <tomprince_loki> Simplest thing off the top of my head, a member in TypeID, which is the length of the LRU cache to keep for that type.
[19:45:40] <tomprince_loki> Would need to make Resource ref-counted.
[19:45:56] <fuzzie> Well, for the tiles, you'd want to force anything on-screen to stay in memory.
[19:46:21] <fuzzie> But they're not Resources anyway, I suppose.
[19:46:29] <fuzzie> Dum de dum. Annoying.
[19:46:59] <tomprince_loki> Well, won't the tiles stick around as long as the Map object does?
[19:47:08] <fuzzie> You don't want them all loaded at once.
[19:47:16] <fuzzie> At least, not if we're going to be pulling 32bpp tiles out of your TIZImporter.
[19:47:26] <fuzzie> But this is a seperate issue.
[19:47:33] <Lightkey> ...
[19:48:14] <fuzzie> Just wondering what would gain from the LRU cache and still need refcounting.
[19:48:49] <fuzzie> That VC++ thing with the empty structs is just weird, it clearly works in some circumstances.
[19:49:14] <tomprince_loki> Well, everything expects to be able free plugins right now.
[19:49:22] <fuzzie> Oh, right, you're instantiating it as ImageMgr::ID. Drat.
[19:50:01] <tomprince_loki> The LRU cache would hold a reference, and would drop things if they are due to be evicted and have refcount == 1.
[19:50:11] <fuzzie> *nod*
[19:50:21] <tomprince_loki> Or something like that.
[20:04:27] <fuzzie> It seems very silly to read things repeatedly from disk, certainly.
[20:08:51] <-- raevol has left IRC (Quit: Leaving.)
[20:10:00] <fuzzie> Wonderful, I seem to have copies of VS6 .. in German and French.
[20:25:54] <fuzzie> I just spent a while fighting another bug which turned out to be the fault of that viewport-resizing code.
[20:29:58] <fuzzie> We need to be able to get the viewport size from the GameControl, but since the GUI is hidden at that point, the viewport information is incorrect.
[20:36:28] <tomprince> So, there are two types of windows. Those that affect the size of the viewport, and those that don
[20:36:53] <fuzzie> Well, not really. There are specific windows which affect the size of the viewport.
[20:36:53] <tomprince> 't. Is the center of the screen ever obscured by a window that should resize the viewport?
[20:37:28] <tomprince> Well, I was think of those specific windows as the type that affect the size ...
[20:37:45] <fuzzie> Well, yes, but they're not really a different *type*.
[20:38:07] <tomprince> Well, to use a wm term, I'd call them docked windows.
[20:38:53] <fuzzie> *nod*
[20:39:28] <tomprince> And if a docked window never obsucres the center, then we just find the edge of each docked window nearest the center, and take the min/max over all docked windows.
[20:39:38] <fuzzie> Yes.
[20:39:42] <fuzzie> Which fixes your problem, but alas, not mine. :)
[20:39:59] <tomprince> On display, we just need to check the new window, but on hide, all of them.
[20:40:13] <tomprince> Why doesn't it fix yours?
[20:40:17] <fuzzie> The windows are not hidden/shown enough to bother with that optimisation, imo.
[20:40:30] <fuzzie> Because my problem is that the viewport is affected by the hiding at all.
[20:41:01] <fuzzie> It is, I think, an entirely seperate one.
[20:43:00] <fuzzie> The best way to handle it is probably to start by stopping the engine from playing tricks with hard-coded window lists, which is related.
[20:44:11] <tomprince> Yeah, I was looking at that code, and using the variables to pass information about window positioning out of band isn't nice. :)
[20:44:22] <fuzzie> I assume it's very old code.
[20:44:51] <fuzzie> It's a little involved to fix, since other code has evolved to abuse those variables, but I don't see any problems with doing so.
[20:47:12] <fuzzie> The difficulty is just fixing the GUIScript code for the games, I guess.
[20:47:49] <fuzzie> Whoever does that is probably in the best position to fix the Core side.
[20:51:35] <lynxlynxlynx> it's a trap, don't look at me :)
[21:09:03] <fuzzie> a whole bunch of this iwd2 code can't possibly work.
[21:12:02] <lynxlynxlynx> probably just got copied over at some point from bg2
[21:12:14] <lynxlynxlynx> long time ago
[21:12:48] <fuzzie> iwd2-specific code..
[21:12:51] <fuzzie> .. which could never have worked
[21:16:58] <lynxlynxlynx> ;)
[21:22:34] <-- ratpor has left IRC (Quit: Get used to disappointment.)
[21:27:17] <-- cfchris6_ has left IRC (Ping timeout: 246 seconds)
[21:29:00] --> cfchris6 has joined #GemRb
[21:29:33] <CIA-74> GemRB: 03fuzzie * ra67b9920cf73 10gemrb/gemrb/GUIScripts/iwd2/GUIMA.py: try to patch up the iwd2 map guiscript to cope with being closed
[21:30:27] <fuzzie> I can now play iwd2 for a few minutes without the GUI failing on me, which is a start.
[21:45:07] <fuzzie> ok, why does iwd2 let me speak to kegs?
[21:46:18] <wjp> drank too much? :-)
[21:46:29] <wjp> anyway, good night
[21:46:35] <fuzzie> ninight
[21:51:28] <fuzzie> Hm, that GUI not failing doesn't last too long :)
[21:52:58] <fuzzie> This time it really is just copied from bg2, drat.
[22:14:24] <fuzzie> That SDLVideo compile certainly seems rather slower now.
[22:17:47] <fuzzie> And that Bitmap change breaks on the first area I tried.
[22:24:40] <fuzzie> A s/y*Height/y*Width/ later, it seems okay.
[22:28:00] <fuzzie> But I guess it needs a bit more testing than that glance at it, will do tomorrow.
[22:36:17] <fuzzie> And I found a really weird bug in that new overlay code.
[22:52:55] --> raevol has joined #GemRb
[23:03:29] <edheldil_> good night
[23:03:47] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:09:17] <-- edheldil_ has left IRC (Ping timeout: 265 seconds)