#gemrb@irc.freenode.net logs for 23 May 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:19:57] <tomprince> The MSVC6 debuger may be the cat's meow with unoptimized code, but it seems to fall to pieces with optimized builds.
[00:51:06] <tomprince> And the tile rendering code is broken on msvc6, as you predicted.
[00:56:54] <-- Gekz has left IRC (Read error: Connection reset by peer)
[00:58:18] --> Gekz has joined #GemRb
[02:20:24] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[02:26:05] --> Gekz_ has joined #GemRb
[02:39:22] --- Gekz is now known as Lulz
[02:39:30] --- Lulz is now known as GivesMeLulz
[02:39:54] --- GivesMeLulz is now known as cryingspaniard
[02:56:55] --> Gekz has joined #GemRb
[02:57:01] <-- Gekz has left #GemRb
[02:57:52] --> Gekz has joined #GemRb
[02:58:05] <-- Gekz has left IRC (Changing host)
[02:58:05] --> Gekz has joined #GemRb
[03:00:43] <-- cryingspaniard has left IRC (Quit: Leaving)
[03:00:52] --> cryingpsniard has joined #GemRb
[05:03:08] --> raevol has joined #GemRb
[05:15:38] <tomprince> Well, I don't get any crashes on the holder-v2 branch on msvc6 (once I got it to compile). Except one that happens on unix as well, do to python being torn down after GameData.
[05:17:18] <tomprince> I am not entirely sure what is going on there yet, but it is caused by the change to GUIClasses.py:40.
[05:17:36] <tomprince> Also, the savegame branch seems to work just fine on msvc6.
[05:17:43] <tomprince> Slowly ... :)
[05:24:59] <-- Gekz_ has left IRC (Quit: Leaving)
[05:38:48] <tomprince> A simple fix to the python thing is to change _GemRB to GemRB on line 40, and and 'import GemRB'. But I don't know *why* that works.
[05:44:35] <Gekz> then how did you work it out
[05:44:36] <Gekz> lol
[05:52:17] <tomprince> Because I changed it the other way when I split _GemRB off from GemRB.
[05:54:12] <Gekz> I see
[05:54:12] <Gekz> haha
[06:25:24] <-- cryingpsniard has left IRC (Read error: Connection reset by peer)
[06:25:31] --> Gekz_ has joined #GemRb
[06:25:39] <-- Gekz has left IRC (Read error: Connection reset by peer)
[06:26:18] --> cryingpsniard has joined #GemRb
[07:14:56] --> cubathy has joined #GemRb
[07:38:21] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[07:38:28] --> Gekz has joined #GemRb
[08:01:26] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[09:09:13] <fuzzie> tomprince: cool
[09:09:51] <fuzzie> assuming you actually tried saving and loading :-)
[09:10:31] <fuzzie> i guess you might as well commit it then, my commentary was just minor bits i think?
[09:10:50] <tomprince> Yes.
[09:11:06] <fuzzie> i worry we might have problems with the templates across library boundaries on embedded platforms, but we can just manually instantiate things if necessary
[09:11:27] <fuzzie> and i don't have access to anything to test on atm
[09:13:57] <fuzzie> and too lazy to grab some toolchains and look at it manually, i guess :)
[09:18:20] <fuzzie> i wish the id fixes were a bit more obvious, they're just kinda sitting around here because i'm really not sure if they're good or not
[09:26:03] <CIA-24> GemRB: 03tom.prince * rf8b97f1f762d 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp:
[09:26:03] <CIA-24> GemRB: GUIScript: Make ConstructObject take C++ classname, rather than GUIScript classname.
[09:26:03] <CIA-24> GemRB: This will make it easier for programmatic calling of ConstructObject.
[09:26:03] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:26:04] <CIA-24> GemRB: 03tom.prince * r0131306e46ef 10gemrb/gemrb/ (11 files in 9 dirs):
[09:26:04] <CIA-24> GemRB: SaveGame: Properly handle naming savegames using strrefs. (IWD2)
[09:26:04] <CIA-24> GemRB: Untested.
[09:26:04] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:26:07] <CIA-24> GemRB: 03tom.prince * r5c05a3ca231b 10gemrb/gemrb/ (3 files in 2 dirs):
[09:26:07] <CIA-24> GemRB: SaveGame: Factor out GameDate parsing code into SaveGame.
[09:26:07] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:26:09] <CIA-24> GemRB: 03tom.prince * r74c9e57af4ab 10gemrb/gemrb/core/SaveGameIterator.cpp:
[09:26:09] <CIA-24> GemRB: SaveGameIterator: Factor some code out of CreateSaveGame.
[09:26:09] <CIA-24> GemRB: CreateSaveGame is going to be split. Factor out the common code first.
[09:26:09] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:26:12] <CIA-24> GemRB: 03tom.prince * re9116960a011 10gemrb/gemrb/core/ (SaveGameIterator.cpp SaveGameIterator.h): SaveGame: Store name of slot.
[09:26:14] <CIA-24> GemRB: 03tom.prince * r89d9e8feeb7c 10gemrb/gemrb/core/Holder.h:
[09:26:14] <CIA-24> GemRB: Holder: Add intrusive smart pointer.
[09:26:14] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:26:17] <CIA-24> GemRB: 03tom.prince * r66b3920caaf9 10gemrb/gemrb/core/ (Sprite2D.cpp Sprite2D.h): Sprite2D: Add TypeID.
[09:26:20] <CIA-24> GemRB: 03tom.prince * rc35b237bc3fe 10gemrb/gemrb/plugins/GUIScript/ (GUIScript.cpp PythonHelpers.h): GUIScript: Add helper for creating python CObjects easily.
[09:26:22] <CIA-24> GemRB: 03tom.prince * rbe98078f6e84 10gemrb/gemrb/ (12 files in 7 dirs):
[09:26:22] <CIA-24> GemRB: GUIScript: Pass Portraits/Previews to python as Sprite2D objects.
[09:26:22] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:26:24] <CIA-24> GemRB: 03tom.prince * rff8f1f310225 10gemrb/gemrb/core/ (SaveGameIterator.cpp SaveGameIterator.h):
[09:26:25] <CIA-24> GemRB: SaveGameIterator: Change std::list to std::vector.
[09:26:25] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:26:27] <CIA-24> GemRB: 03tom.prince * r771c39af3cb0 10gemrb/gemrb/ (4 files in 2 dirs):
[09:26:27] <CIA-24> GemRB: SaveGame: Make RefCounted.
[09:26:27] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:26:32] <CIA-24> GemRB: 03tom.prince * rb069b734aa1e 10gemrb/gemrb/ (4 files in 2 dirs):
[09:26:32] <CIA-24> GemRB: SaveGameIterator: Only rescan savegames when asked for count.
[09:26:32] <CIA-24> GemRB: The way this works is that the count is asked for only on opening
[09:26:32] <CIA-24> GemRB: the Load or Save screen, or deleting a save game, so that is the
[09:26:32] <CIA-24> GemRB: only time it is needed.
[09:26:33] <CIA-24> GemRB: 03tom.prince * r2d3af4c79790 10gemrb/gemrb/core/ (SaveGameIterator.cpp SaveGameIterator.h):
[09:26:33] <CIA-24> GemRB: SaveGameIterator: Create SaveGame objects at Rescan time.
[09:26:33] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:26:36] <CIA-24> GemRB: 03tom.prince * r097be69e6f07 10gemrb/gemrb/ (12 files in 6 dirs):
[09:26:36] <CIA-24> GemRB: GUIScript: Split GetSaveGameAttrib into separate functions.
[09:26:36] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[09:26:36] <CIA-24> GemRB: 03tom.prince * rba796199e9c3 10gemrb/gemrb/ (25 files in 8 dirs): GUIScript: Expose SaveGame object to python.
[09:26:49] <CIA-24> GemRB: 03tom.prince * rd049abc744c4 10gemrb/gemrb/ (37 files in 16 dirs): Merge branch 'savegame'
[09:26:56] <tomprince> :)
[09:32:27] <tomprince> Any reason that you still have casts to Actor* before calling GetGlobalID?
[09:50:16] <fuzzie> you're looking at the old branch, or sf HEAD?
[09:51:52] <fuzzie> the old branch was just a lack of tidying up at that point, i think
[09:59:59] <tomprince> I was looking at your github branch.
[10:02:54] <fuzzie> oh, oops, it's not even a branch. silly on my part.
[10:03:20] <fuzzie> those are the bits i am worried about though. the rest is just tidying up and then adding functionality, lookup tables, etc.
[10:07:15] <fuzzie> (it is probably better to stuff the Type in the high bits of the id or something, but also orthogonal to the point)
[10:09:17] <-- tomprince has left IRC (Ping timeout: 265 seconds)
[10:12:37] --> tomprince has joined #GemRb
[10:13:23] --- cryingpsniard is now known as Gekz_
[10:13:27] <-- Gekz_ has left IRC (Changing host)
[10:13:27] --> Gekz_ has joined #GemRb
[10:16:01] <tomprince> Well, the question would be, does anything depend on the actuall value of the id.
[10:16:49] <fuzzie> i'm pretty sure the answer is no; they are discarded at load time in the original engine
[10:17:36] <fuzzie> there's maybe some magic involving the way they're stored in effects or somewhere, but i'm hoping that could be fixed later
[10:17:55] <fuzzie> but maybe i'm wrong :)
[10:18:11] <fuzzie> maybe i should ask Taimon or devSin
[10:19:38] <tomprince> I wonder if the original game kept an array of actors for each map, indexed by the localid?
[10:20:14] <fuzzie> well, i don't see why the localid at all
[10:20:51] <fuzzie> but yes, i imagine so - i think actors were never actually removed while a map was loaded, hence the start of a RemovalTime patch which is also on github (but got merged into sf)
[10:21:11] <fuzzie> but i don't really care about the actors :-) they work atm, even if they're slow
[10:21:56] <fuzzie> but maybe the original globalid format was just some reference to the map and the localid? but then you have to store all scriptables.
[10:23:58] <fuzzie> hm, i guess actually localids get removed when single actors move between maps, etc.. so not so simple
[10:24:06] <fuzzie> but you can tell i don't really know what i'm talking about here
[10:24:19] <fuzzie> which is why i didn't think about merging what i have :)
[10:28:49] <tomprince> Well, looking at blame on Actor.h, the localid/globalid was introducted to replace pointers.
[10:29:10] <fuzzie> sure, this has to work across machines for multiplayer, etc
[10:29:18] <fuzzie> so no lazy weak_ptr solution
[10:29:48] <fuzzie> but the localid/globalid split itself is just taken directly from the original engine
[10:29:51] <tomprince> :)
[10:30:59] <tomprince> Is multiplayer 'planned'?
[10:31:28] <fuzzie> well, i think it's not too hard, as we have things now
[10:32:40] <fuzzie> so it's definitely in my mind as i think about this, but i don't know if it'll ever happen..
[10:34:12] <tomprince> I guess I am not one for multiplayer games, but it never did seem like multiplayer was a particularly good fit for the ie games.
[10:34:42] <fuzzie> did you play much iwd/iwd2?
[10:34:55] <tomprince> Some iwd, not iwd2.
[10:35:53] <fuzzie> i imagine it wouldn't work too well over the internet, but i had fun playing LAN games with people, where you could chat out loud and lean over to someone's machine and watch, etc
[10:38:26] <tomprince> Well, if I was coding it, I wouldn't want to hand code the serialization ...
[10:38:50] <fuzzie> well, this is done using this 'messaging' system i've discussed before
[10:39:45] <fuzzie> you serialize those over the network for the scripting, and this means you don't have to share much state
[10:40:09] <fuzzie> i imagine it would be all kinds of not-fun to make it actually work reliably, but that is multiplayer sync for you :(
[10:40:19] <tomprince> :)
[10:41:36] <tomprince> Well, using weak_ptrs doesn't mean you can't have a non-pointer ID as well.
[10:42:04] <fuzzie> well, keeping to the IDs means we're forced to get rid of all the pointer 'hacks'
[10:42:24] <tomprince> hacks?
[10:42:36] <fuzzie> where references to pointers are kept outside the action queue
[10:44:09] <fuzzie> a bad thing for numerous reasons :) but because IDs don't work for non-actors right now, there are a few of them, and there should be none
[10:44:55] <fuzzie> you could use weak_ptr for some GUI bits usefully, though
[10:47:11] <fuzzie> (the GameControl, and the python side)
[10:47:51] <-- raevol has left IRC (Quit: Leaving.)
[10:53:08] <fuzzie> i have a rather horrifying profile from another project atm which has it spending about 20% of CPU time copying/dereferencing smart/weak_ptrs because we just passed them around, so i am a bit wary right now, but i'm pretty sure gemrb would never be in that position :-)
[10:55:22] <tomprince> I certainly hope not.
[11:01:27] <tomprince> I am curious how that happends.
[11:06:28] <fuzzie> things like iterating over vectors of objects and then passing them to a 'needsExecution' type function: do it naively and you pass a 'shared_ptr<T> obj', which means the function turns into a copy, even though it should really be a cheap single pointer deref..
[11:10:22] <fuzzie> and obviously similar applies for weak_ptr when the code should really be lock()ing it once somewhere high in the call tree
[11:11:39] <Gekz> do you know what saddens me
[11:11:46] <Gekz> I do ICT Engineering
[11:11:50] <fuzzie> nothing inherent, they just make it really easy to add huge amounts of useless code without noticing, because it's too easy to think in terms of passing pointers around, when you're not :)
[11:11:54] <Gekz> and none of the subjects available covers that topic
[11:12:02] <Gekz> pointers are not taught until embedded C
[11:12:04] <Gekz> and that's where it stops
[11:12:05] <Gekz> lol
[11:12:47] <tomprince> I wonder if intrusive shared pointers would help.
[11:13:38] <fuzzie> tomprince: http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/smarttests.htm
[11:13:54] <fuzzie> (summary: "yes")
[11:15:34] <fuzzie> Gekz: i don't think this kind of thing is taught anywhere at my uni's CS department, it's just the kind of thing you have to pick up to avoid going mad
[11:15:58] <Gekz> I hate uni fuzzie
[11:16:01] <Gekz> I've learnt very little
[11:16:09] <Gekz> and they wont let me take initiative to learn new things
[11:16:09] <Gekz> >_>
[11:16:24] <Gekz> I lost marks for using a break in a while loop instead of a boolean ...
[11:16:35] <fuzzie> the lecturer teaching C++ just runs away at any mention of templates, actually, so i wrote him a nice fully-templated genetic algorithm engine for my last AI assignment.
[11:18:47] <fuzzie> am fairly sure i just would give up on a course which gave that little freedom :|
[11:20:39] <tomprince> That is why the only CS course I have taken is a compiler course. :)
[11:21:58] <fuzzie> thankfully, all the lecturers here are pretty easygoing, i can just hand in assignments and take the exams
[11:22:00] <Gekz> fuzzie: I cant give up on such a course
[11:22:04] <Gekz> it's a REQUIRED subjetc
[11:22:13] <Gekz> Australian universities are shit
[11:22:18] <Gekz> I'm studying in France for 2013
[11:22:27] <Gekz> and I might apply for permanent residence haha
[11:22:44] <fuzzie> there are generally about 5 people in the CS lectures when i poke my head in the doors, to give an idea of what the faculty is like at undergrad level :-)
[11:23:45] <fuzzie> so you should learn Dutch, come here!
[11:24:52] <fuzzie> draw UML diagrams with the help of lego!
[11:34:07] <Gekz> I've missed like 4 integration lectures
[11:34:11] <Gekz> relearning it really fast
[11:34:12] <Gekz> haha
[11:38:11] <tomprince> Would const shared_ptr& help?
[11:39:31] <Gekz> omg
[11:39:34] <Gekz> the answer in the book was wrong
[11:42:20] <fuzzie> tomprince: that is what i ended up doing, for function parameters; haven't looked to make sure it helps, but presumably it would
[11:44:05] <tomprince> Although, I guess you probably pay for it with an extra indirection.
[11:49:55] <fuzzie> i am assuming the optimiser is clever enough to avoid that when inlining, and also clever enough to inline enough to help :)
[11:54:50] <-- fuzzie has left IRC (Ping timeout: 240 seconds)
[12:47:19] --> fuzzie has joined #GemRb
[13:07:56] --> kettuz has joined #GemRb
[13:08:36] <-- kettuz has left IRC (Client Quit)
[13:23:58] <-- budlust has left IRC (Remote host closed the connection)
[13:24:14] --> budlust has joined #GemRb
[14:23:31] <-- tomprince has left IRC (Ping timeout: 265 seconds)
[15:12:13] <-- Gekz_ has left #GemRb ("Leaving")
[15:12:18] --> Gekz_ has joined #GemRb
[15:12:21] <Gekz_> wrong button rage
[16:22:38] --> lynxlynxlynx has joined #GemRb
[16:22:39] --- ChanServ gives channel operator status to lynxlynxlynx
[16:23:47] --> tomprince has joined #GemRb
[16:45:49] <lynxlynxlynx> nice job tomprince
[16:51:21] --> cubathy has joined #GemRb
[17:04:56] <tomprince> :)
[17:53:54] <tomprince> I am curious what people thing of the updated holder branch.
[18:04:01] <lynxlynxlynx> i don't know enough to comment on that, but i like the added caching
[18:06:53] <fuzzie> well, i'm concerned that the caching is dumb and it will end up all complicated to make it clever
[18:08:49] <fuzzie> and sabotaging deallocation-in-libraries seems designed to annoy Avenger even more, but i discussed that before..
[19:02:18] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[19:06:39] <tomprince> Well, I did test it against vc6.
[19:09:20] <tomprince> And we can always add operator new/delete to Held, and have all allocation in core.
[19:10:19] <fuzzie> well, then you have to redirect all the already-buggy malloc/new/etc calls in plugins into core too
[19:10:35] <fuzzie> i don't care, i just know that it's code he's vaguely tried to maintain, and hasn't wanted removed
[19:11:02] <fuzzie> as discussed before, it doesn't seem to make sense, i just worry that every time Avenger comes in here recently, it's because gemrb broke for him again, and he can't even run it
[19:11:53] <tomprince> es.
[19:12:00] <tomprince> s/es/Yes/
[19:12:31] <tomprince> I have the same worry.
[19:18:46] <tomprince> I am not sure what to do about that though.
[19:19:18] <fuzzie> well, from other projects, it is often an inevitable consequence of refactoring
[19:20:16] <fuzzie> so maybe nothing.
[19:27:07] <-- budlust has left IRC (Ping timeout: 248 seconds)
[19:48:33] --> Maighstir has joined #GemRb
[19:51:11] <-- Maighstir has left #GemRb
[19:51:25] --> Maighstir has joined #GemRb
[20:19:17] <tomprince> or.cz/driver: Allow proper selection of Video/Audio driver from config file.
[20:30:58] <fuzzie> um
[20:31:04] <fuzzie> you disabled the DelayPlugin code?
[20:31:43] <fuzzie> i'm confused as to what you do here
[20:31:54] <fuzzie> oh, you just hardcode the default drivers. don't do that? :)
[20:32:34] <fuzzie> shipping some override config file with a list of defaults might make sense
[20:32:49] <fuzzie> but moving from not hardcoded defaults to hardcoded defaults doesn't seem like good refactoring..
[20:34:00] <fuzzie> at least not for the audio driver, given openal is not universal
[20:35:30] <fuzzie> (another recent discovery on my part is that openal soft does all internal mixing in floating-point 5.1 surround sound, making it completely sodding useless as a use-everywhere driver)
[21:17:20] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[21:27:32] <-- Gekz has left IRC (Quit: Leaving)
[21:28:00] <-- Maighstir has left #GemRb
[21:31:04] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[21:38:28] --> Maighstir_laptop has joined #GemRb
[21:49:43] --> budlust has joined #GemRb
[21:52:04] <tomprince> Well, where are you going to code the default?
[21:52:57] <tomprince> You could just leave the default empty, then it would pick the alphabetically first one.
[21:54:30] <tomprince> Part of why I did it that way is that I want to be able to run with a minimal config. Probably just the game type and game path.
[21:57:18] <tomprince> My thinking was, if the default isn't hard-coded, then it must be read from somewhere. What if it isn't there? Do you need a default for the default, or what?
[21:59:15] <tomprince> And I agree that where I coded the default isn't ideal.
[21:59:37] <tomprince> Maybe it shoud just go into load config, and check for empty driver?
[22:02:46] <-- budlust has left #GemRb
[22:05:05] --> budlust has joined #GemRb
[22:16:25] <Lightkey> 15:35:09 <@fuzzie> huh, maybe little-endian is the format which desktop hw is still flaky with? i forget
[22:16:39] <Lightkey> I have a deja vu ^^
[22:19:11] <-- budlust has left IRC (Ping timeout: 260 seconds)
[22:27:34] <fuzzie> tomprince: i don't think hardcoding a single default is a good idea in any circumstance
[22:27:42] --> budlust has joined #GemRb
[22:28:06] <fuzzie> but i mean, we have to pull in gemrb-specific config anyway, we ought to be able to put a global defaults file somewhere, but this is the subject of things on sf already, i think
[22:29:44] <tomprince> Well, I just think that we should be able to run without a config file.
[22:30:27] <tomprince> The only thing we *really* need is the gamedata path.
[22:31:30] <tomprince> Note: one thing about the default as i implemnted it, is that it is just a hint.
[22:31:34] <fuzzie> well, you also have to hardcode resolution
[22:31:47] <tomprince> Do we?
[22:31:58] <fuzzie> well, it's a hint which is going to lead to NullSound being the next sound plugin loaded
[22:32:07] <fuzzie> i guess that is my real objection, you sabotage the example config
[22:32:21] <fuzzie> so that it breaks if you don't take the hardcoded path
[22:32:38] <fuzzie> we can always fix the default to do something more sensible later
[22:32:52] <tomprince> I was thinking about that, and if the gemrb.ini knew about the resolutions supported by each game.
[22:33:40] <tomprince> Then we could pick a resonable default resolution from that.
[22:33:57] <fuzzie> but you surely can't have a gemrb.ini, because that's just as much global config as some plugin default in those directories would be
[22:34:04] <fuzzie> so i have misunderstood what you want
[22:34:06] <tomprince> I'm not sure what you mean about sabatoging the example config.
[22:34:12] <fuzzie> you want some config files to be available, but others not?
[22:34:36] <tomprince> Well, I don't consider the gemrb.ini files to be config, I consider them to be program data.
[22:34:51] <fuzzie> ok, so, add a program data file with the default config in it :)
[22:35:35] <fuzzie> and when i looked, you removed the DelayPlugin lines from the example config files, so it would break when you didn't take the hardcoded option
[22:36:46] <fuzzie> that wasn't intended?
[22:36:54] <tomprince> It will happily load both plugins now, and then pick the one you want to use by name.
[22:37:11] <fuzzie> sure, but i want a sane fallback method
[22:37:31] <fuzzie> so i set the default to openal, and then it fails to initialise, and it should go for sdlsound next..
[22:38:24] <fuzzie> i don't actually understand your patch, i guess
[22:38:53] <tomprince> Well, I don't have anything to handle that yet. But right now, if the openal plugin fails to dlopen, then it will fallback to the other driver.
[22:39:09] <fuzzie> sure, but it seems like a bad thing to commit, in this state
[22:39:27] <fuzzie> because the DelayPlugin is meant as a "try this last" thing, but you provide no subsitute?
[22:39:44] <tomprince> Obviously, it isn't clear enough what it is doing.
[22:40:01] <fuzzie> well, ok, the comments are dumb, but the 'Delay' is obvious enough :)
[22:40:27] <tomprince> Well, only "try this last" in terms of dlopening. It only tries something else if one fails to dlopen.
[22:40:42] <tomprince> My code tries to dlopen *all* of them.
[22:40:50] <fuzzie> well, that is a bad idea
[22:40:58] <fuzzie> because you initialise libraries as side effects
[22:41:15] <fuzzie> but that is kinda an aside which is a bug in the existing one anyway, i think
[22:41:29] <fuzzie> as is the fact that DelayPlugin doesn't check for a driver being 'good'
[22:41:58] <tomprince> And then from the ones that it succesfully loads, it tries to find find one that registered the specified driver, and if it doesn't, it grabs a random (first alphabetically) driver.
[22:42:22] <fuzzie> but, i mean: i want an opengl driver and an sdlsound driver, so if you're going to change this method, it should really fallback the right way.
[22:42:34] <fuzzie> which could either be DelayPlugin, or a list of default drivers.
[22:43:20] <fuzzie> but then the dlopen() thing is a problem, because you don't want to initialise opengl on some platforms unless you're going to *use* it, but maybe that is too complicated to worry about
[22:44:00] <fuzzie> i suspect all of those platforms are going to be predictable enough that you know what will be used at packaging time..
[22:44:03] <fuzzie> so never mind that
[22:44:08] <fuzzie> just the fallback thing worries me :)
[22:44:31] <tomprince> I would think that most sane libraries don't initialzie themselves at static intialization time.
[22:44:40] <tomprince> I might be misaken.
[22:44:49] <fuzzie> sure, but 'sane libraries' means Linux.
[22:45:39] <fuzzie> you have hacks built into the *shell* on Windows to cope with libraries initialising themselves like that, people suck :) but like i said, never mind, surely manageable
[22:46:56] <fuzzie> (and if not, it is surely possible to dlopen() or equivalent inside the plugin)
[22:48:12] <fuzzie> i should really go ahead and write useless versions of those drivers to get them in the tree, maybe
[22:49:20] <fuzzie> anyone have objections to doing that?
[22:49:29] <tomprince> Not me.
[22:49:48] <fuzzie> you should probably just merge the holder thing (after correcting the spelling in commit messages), btw
[22:49:57] <fuzzie> if you didn't do so already and i missed it
[22:50:13] <tomprince> No.
[22:50:17] <tomprince> I haven't yet.
[22:50:21] <fuzzie> ('SoungMgr')
[22:50:25] <tomprince> And I won't commit the LRU thing yet.
[22:50:41] <fuzzie> well, it seems that merging things slowly is not helping on the regressions front, so..
[22:55:10] <fuzzie> is there anything else which is to be reviewed?
[22:55:26] <tomprince> No. Not right now.
[22:59:08] <Maighstir_laptop> If you're not too busy or tired.... I'm having trouble compiling on Windows/MinGW. Supplying two logs, one default (Werror on), and one with CMakeLists.txt edited to not pass Werror (Werror off): http://ops-area.net/annat/GemRB/Werror-on.txt http://ops-area.net/annat/GemRB/Werror-off.txt
[23:01:30] <fuzzie> you should just comment out that #pragma
[23:02:29] <fuzzie> i don't have a new enough tree to look at the OGGReader thing though
[23:02:59] <tomprince> Try including Interface.h there.
[23:03:10] <tomprince> That has to do with the logging stuff.
[23:03:23] <fuzzie> but the hConsole extern should surely be in win32def.h :-)
[23:03:58] <tomprince> Right now it is Interface.h.
[23:04:33] <-- budlust has left IRC (Ping timeout: 240 seconds)
[23:05:13] <CIA-24> GemRB: 03tom.prince * r9ea50696acaf 10gemrb/gemrb/ (GUIScripts/GUIClasses.py core/GameScript.cpp): Fixes.
[23:05:17] <tomprince> Do you have any thoughts on how to make it clearer what is going on with the driver change.
[23:09:47] <tomprince> I agree that a more intelligent fallback system would be good, but I think that this is a reasonable first step.
[23:10:18] <tomprince> And I think that the final version might end up using the multiple configs, as you suggested.
[23:11:07] <fuzzie> well, it would make a lot more sense if you had a seperate commit for changing the driver model, i think
[23:11:59] <CIA-24> GemRB: 03tom.prince * r0a54bd831fde 10gemrb/gemrb/ (5 files in 5 dirs):
[23:11:59] <CIA-24> GemRB: ZLibManager: Specify compression type in PluginID.
[23:11:59] <CIA-24> GemRB: Anything that depends on this depends on zlib in particular.
[23:11:59] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[23:20:48] <tomprince> or.cz/driver: Now split up.
[23:22:14] <tomprince> The first commit will break everybodies config, as the DelayPlugin no longer stops NullSound from loading, and 'n' < 'o'.
[23:23:00] <fuzzie> you should maybe have a 'DelayPlugin no longer prevents driver loading' in the commit msg?
[23:23:18] <tomprince> Yes.
[23:23:58] <fuzzie> also does this code actually work?
[23:24:06] <fuzzie> it seems like it should be ' = value;' for the config settings
[23:24:41] <fuzzie> oh, i guess you didn't test that. well, there's a bug report :)
[23:26:22] <fuzzie> seems fine otherwise though, given my comments on the fallback issues
[23:27:23] --> budlust has joined #GemRb
[23:35:39] <CIA-24> GemRB: 03tom.prince * r0682b2ed078f 10gemrb/gemrb/ (core/SaveGameIterator.cpp includes/iless.h): iless: Factor this out.
[23:35:43] <CIA-24> GemRB: 03tom.prince * r9dcd23dcb265 10gemrb/gemrb/ (12 files in 5 dirs):
[23:35:43] <CIA-24> GemRB: Drivers: New driver model.
[23:35:43] <CIA-24> GemRB: Audio and Video drivers are registered separately by class, and
[23:35:43] <CIA-24> GemRB: chosen by name now.
[23:35:43] <CIA-24> GemRB: Note: DelayPlugin no longer prevents driver loading. The next commit has an
[23:35:43] <CIA-24> GemRB: alternate config mechanism for handling this.
[23:35:44] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[23:35:44] <CIA-24> GemRB: 03tom.prince * r62cb282fa009 10gemrb/gemrb/ (4 files in 2 dirs):
[23:35:45] <CIA-24> GemRB: Drivers: Add config file support to new driver model.
[23:35:45] <CIA-24> GemRB: This hardcodes the default drivers. When we have more drivers and multiple
[23:35:46] <CIA-24> GemRB: config file loading, this should be changed.
[23:35:46] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[23:42:20] <Maighstir_laptop> Commenting out the pragma and including that Interface.h in OGGReader.cpp worked wonders. As for the first one, it should only be enabled in MSVC6, right? isn't there some ifdef to check for in that specific case, so that it doesn't crop up elsewhere in win32?
[23:43:12] <tomprince> Well, that pragma already exists in win32def.h
[23:43:33] <tomprince> At some point, the header dependency graph changed, and no one has tracked that down yet.
[23:54:10] <-- budlust has left #GemRb