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

Archive Today Yesterday Tomorrow
GemRB homepage


[00:19:40] <-- tomprince has left IRC (Read error: 54 (Connection reset by peer))
[00:51:20] --> raevol has joined #GemRB
[01:07:47] --> Gekz has joined #GemRB
[02:08:23] --> barra_away has joined #gemrb
[02:15:51] <-- CIA-31 has left IRC (kornbluth.freenode.net irc.freenode.net)
[02:15:51] <-- anji has left IRC (kornbluth.freenode.net irc.freenode.net)
[02:18:46] --> CIA-31 has joined #GemRb
[02:18:46] --> anji has joined #GemRb
[02:25:15] <-- barra_desktop has left IRC (Read error: 113 (No route to host))
[02:26:13] <-- barra_away has left IRC (Read error: 60 (Operation timed out))
[05:57:06] <-- Gekz has left IRC (Read error: 60 (Operation timed out))
[07:18:26] --> tomprince has joined #gemrb
[07:47:11] --> Gekz has joined #GemRB
[10:41:01] --> Forgetful_Lion has joined #GemRB
[10:44:19] --> Maighstir has joined #gemrb
[10:49:47] <-- raevol has left IRC ("Leaving.")
[11:05:20] --> lynxlynxlynx has joined #gemrb
[11:05:21] --- ChanServ gives channel operator status to lynxlynxlynx
[11:17:48] <-- Maighstir has left IRC (Read error: 110 (Connection timed out))
[11:30:56] <tomprince> Avenger: The most significant cross-module allocation is the pixel data for a Sprite2D, which is usually allocated in a plugin, and then freed in Core. Everything I have read indicates that cross-module allocation isn't problematical, and the fact that we allocate/free so many sprites without issue, leads me to believe that there isn't a problem.
[11:32:31] <tomprince> Now, I wouldn't extend that to third-party libs, since they might link the C/C++ runtime statically, which would be a problem; but we can control that for GemRB.
[11:33:25] <tomprince> It just seems to me that the code would be clearer and simpler if we didn't need to worry about avoiding cross-module allocation.
[11:33:36] <fuzzie> yes, but there have been crashes due to it
[11:33:50] <fuzzie> i thought we specifically have some call in the SDL driver to avoid the deletes
[11:36:06] <fuzzie> the most sensible solution is just to use mingw for all builds, imo
[11:36:46] <tomprince> That seems sensible.
[11:37:38] <tomprince> Do you have any references to the crashes, or more information on them?
[11:38:10] <tomprince> If at some point, GemRB was compiled with C/C++ runtime statically, then there would be a problem with the allocation.
[11:38:18] <fuzzie> i have never produced them myself
[11:38:41] <fuzzie> i imagine the problem is either static runtime, or different runtimes with different modules (i can reproduce with mixed debug/release, for example)
[11:39:14] <fuzzie> as i said, people occasionally report issues, but no-one ever hangs around for long enough to debug why after it's fixed..
[11:40:45] <fuzzie> perhaps the project files in svn are broken in such a way.
[11:45:07] <tomprince> Does it make sense to keep worrying about tha allocation, when we have a major example of it working (images)?
[11:46:07] <tomprince> It would be easy enough to avoid cross-module allocation, just have gem_{malloc|free} in Core that call malloc/free. It justs seems wasteful.
[11:46:17] <fuzzie> where are you seeing images being cross-freed?
[11:46:22] <fuzzie> i'm intrigued
[11:47:10] <fuzzie> if it's really in a path which happens every time and isn't recently introduced..
[11:49:23] <tomprince> The pixel data is allocated and read in BMPImp/PLTImp/MOSImp/PNGImp, and then freeed in SDL..->FreeSprite.
[11:50:23] <tomprince> I can't guarantee that it is called in trunk, since I have about at dozen patches here, but I don't think touched the code paths calling FreeSprite
[11:51:13] <fuzzie> right, spr->pixels
[11:51:26] <tomprince> Yes.
[11:53:15] <tomprince> Speaking of history, is there any other IRC log than http://log.usecode.org/gemrblog.php
[11:53:27] <tomprince> It seems only to go back part of a year.
[11:53:37] <lynxlynxlynx> only personal logs
[11:53:56] <fuzzie> there was some amount of nervousness about setting up a public log due to private conversations etc
[11:54:24] <lynxlynxlynx> before that year there were so few conversations that it wasn't deemed necessary
[11:55:11] <fuzzie> the GetImage -> CreateSprite -> FreeSprite thing seems pretty obviously cross-module..
[11:55:25] <fuzzie> so i wonder if it's simply a exe<->dll problem
[11:55:44] <fuzzie> with differing runtime settings or somesuch
[11:56:35] <tomprince> My understanding is that is that each malloc has to be freeed by the same instance of the same runtime.
[11:57:01] <tomprince> So, if the runtime is static, you get multiple copies. And similarily with debug/release.
[11:58:46] <fuzzie> yes, which is why it's so strange that anyone would have a problem
[11:58:54] <fuzzie> since it's not as if anyone is going to build gemrb in pieces
[11:59:00] <fuzzie> sigh.
[12:01:13] <fuzzie> re BMPWriter patch: is that a good idea? does it fit nicely into plugin system?
[12:02:36] <fuzzie> I guess the original code was more of a mess.
[12:03:01] <tomprince> Well, the writer bit doesn't fit in as a subclass of Resource.
[12:03:31] <tomprince> The SClass_ID should probably be changed to something like PLUGIN_WRITER_BMP, or some such.
[12:04:00] <tomprince> I just hadn't got that far when I posted the patch.
[12:04:14] <fuzzie> the patch has some other fixes in there too
[12:04:57] <tomprince> I'd actually like to eventually split the identification of plugins from the BIF id of the underlying file type.
[12:05:15] <fuzzie> having a lookup between the two?
[12:05:58] <tomprince> I think the only fix is to use that Resource code for loading savegame BMPs, so that I could reuse IE_BMP_CLASS_ID.
[12:06:13] <tomprince> I don't think that would be needed (the lookup).
[12:06:53] <tomprince> Once everything is ported ro Resource, the plugin will know what bif ids to use.
[12:07:47] <tomprince> The ResourceDesc has the BIF id.
[12:08:18] <tomprince> And I think that should probably be the only things that needs to care.
[12:08:57] <fuzzie> :nod:
[12:10:32] <tomprince> So does the direction I am going with the plugin system seem reasonable?
[12:11:04] <tomprince> Not all the details. I have found a number of things to improve, as I look at more and more case. But the general idea?
[12:12:07] <fuzzie> it seems universally an improvement, so i don't think anyone can complain :)
[12:12:24] <fuzzie> GameData.cpp: In member function ‘Resource* GameData::GetFile(const char*, const TypeID*, bool) const’:
[12:12:27] <fuzzie> GameData.cpp:251: error: ‘class ResourceMgr’ has no member named ‘GetFile’
[12:12:35] <fuzzie> ^- trying 0001-Add-flexible-plugin-handling-of-resource-files.patch; did I do something stupid?
[12:13:58] <fuzzie> the only mentions of GameData in the patch I have (maybe I have the wrong one again?) are in GameData
[12:14:02] <fuzzie> erm, of GetFile.
[12:14:21] <tomprince> No, I think that is me.
[12:15:53] <tomprince> I must not have tested that patch in isolation.
[12:16:05] <tomprince> That bit should be in the next patch. :(
[12:17:04] <fuzzie> I can copy-and-paste it manually, if it's just GetFile.
[12:18:00] <tomprince> It should be. The definition in ResourceMgr, and the implementation in KEYImporter.
[12:18:23] <tomprince> Or you can get rid of the use in GameData, since it isn't used until the next patch.
[12:20:39] <tomprince> GetFile is a bit of a hack until I split up the searching through directories, and searching bifs in KEYImporter.
[12:22:49] <tomprince> One thing about the patches, I don't know if I updated all the CMakefiles as I went.
[12:27:17] * tomprince goes to sleep.
[12:29:24] <fuzzie> sorry, trying to work out why the patch doesn't run :) i'll be sure to try with cmake, ninight
[12:29:48] <-- Forgetful_Lion has left IRC (" HydraIRC -> http://www.hydrairc.com <- IRC with a difference")
[12:39:33] <fuzzie> re cmake: BIKPlayer has no cmakefile either? so no-one is paying attention
[12:42:37] <CIA-31> gemrb: 03fuzzie * r7478 10/gemrb/trunk/gemrb/plugins/BIKPlayer/CMakeLists.txt: add CMakeLists.txt for BIKPlayer
[14:59:34] <-- tombhadAC has left IRC (Connection timed out)
[14:59:35] --> tombhad-AC has joined #gemrb
[15:48:31] <-- tombhad-AC has left IRC (Remote closed the connection)
[16:57:05] <tomprince> fuzzie: Any luck?
[17:02:27] <fuzzie> well, i'm seeing some very odd output
[17:02:43] <fuzzie> but don't think it's your patch
[17:03:35] <fuzzie> is this '// FIXME: Display extension or something' from a previous patch of yours, or an existing bug?
[17:04:21] <fuzzie> oh, i guess it's from the first patch.
[17:04:27] <fuzzie> that makes things .. difficult to debug
[17:09:50] <tomprince> At that point we don't know what extension we are looking for, since we are probably looking for more than one.
[17:10:13] <fuzzie> sure, but now gemrb is failing to find files and I have no way of knowing what it's looking for..
[17:10:42] <tomprince> Well, you should at least know the base name.
[17:10:50] <fuzzie> which is entirely unhelpful, unfortunately
[17:10:57] <fuzzie> am building a copy of svn now
[17:11:26] <Nomad010> hmm fml
[17:11:29] <tomprince> Well, which patches have you applied?
[17:11:47] <Nomad010> ubuntu + gemrb = complex lol
[17:11:49] <fuzzie> the debug info is better in the lastest ones?
[17:11:54] <tomprince> No.
[17:12:01] <fuzzie> i mean, i don't think it's your patches causing my failures
[17:12:22] <tomprince> But if you are hitting that code path, it could only be a couple of filetypes.
[17:12:23] <fuzzie> but the fact i can't work out what's going with your patch applied makes me think i'd better come up with some better ouput there
[17:13:44] <tomprince> You could make TypeID contain a string describing the type, and then pass that down to KEYImporter, so it can print the class of file.
[17:17:52] <Nomad010> yay i got gemrb to work
[17:17:55] <Nomad010> i am a winner
[17:18:03] <fuzzie> it would be nice if we could just say "Couldn't find blah (tried blah.bmp, blah.png)"..
[17:18:24] <tomprince> That wouldn't be to hard.
[17:18:33] <fuzzie> can you trust ResourceDesc's GetExt()?
[17:19:40] <tomprince> What do you mean?
[17:20:00] <fuzzie> Well, I don't know what you changed in the later patches right now.
[17:20:29] <fuzzie> Going by this first patch, it just tries types[j]->GetExt(), so gemrb could just print those.
[17:20:36] <tomprince> Yes.
[17:20:42] <tomprince> It always does.
[17:20:47] <fuzzie> Okay, neat.
[17:23:34] <tomprince> If you are doing that, it would make sense to do it as a static function (not member), that takes a std::vector&.
[17:25:14] <tomprince> Also, I wasn't very good a verifying that the debug ouput is as it should. There should probably be a print before each return in GetResource and GetFile.
[17:26:45] <fuzzie> The 'found' path should ideally print the found extension anyway, so it probably wants reorganising a bit.
[17:27:03] <tomprince> Do you want me to code it up?
[17:28:09] <fuzzie> If you have the time!
[17:28:58] <fuzzie> one of those paths in GetResource returns NULL if resource unavailable, one continues searching
[17:30:50] <fuzzie> don't mean that's bad, just wondering about that too..
[17:31:26] <tomprince> I think I change that later.
[17:31:59] <tomprince> The logic was that if we found a file with the right extension, but wouldn't load, we shouldn't keep looing.
[17:32:14] <tomprince> I ran in to problems in that .wav could refer to multiple file types.
[17:41:27] --> Maighstir has joined #gemrb
[17:52:08] <fuzzie> all the strange bugs are indeed present in current svn..
[17:52:58] <tomprince> http://pastebin.ca/1728614 ... just compiling now. against 0002
[17:53:33] <tomprince> Strange bugs?
[17:54:08] <fuzzie> gemrb searching for the wrong files, mostly
[17:59:08] <tomprince> What files?
[18:00:10] <fuzzie> some bad scripts/2das and bitmaps which don't exist. nothing related to your patches.
[18:00:47] <fuzzie> just things i hadn't noted in my notes before.
[18:06:44] <-- Maighstir has left IRC (Read error: 110 (Connection timed out))
[18:09:14] <tomprince> That patch I just posted seems to work.
[18:10:04] <fuzzie> I have modified it a little (to display extensions when finding files).
[18:10:31] <tomprince> That sounds sensible.
[18:14:25] <fuzzie> public:
[18:14:25] <fuzzie> + static const TypeID ID;
[18:14:25] <fuzzie> +public:
[18:14:30] <fuzzie> ^- this is modified in a later patch?
[18:15:32] <fuzzie> (sorry, with context: ImageMgr)
[18:16:53] <tomprince> No...
[18:17:17] <tomprince> You can get rid of it.
[18:17:37] <tomprince> I was just seperting it out from the rest of the class.
[18:17:54] <tomprince> Using public: as a divider.
[18:21:14] <tomprince> I'll be back later ... unless you have any other questions before I go.
[18:21:51] <fuzzie> I think it's fine, I'm just trying to work out what the 'convert' was meant to do.
[18:22:22] <tomprince> convert?
[18:22:58] <fuzzie> the last parameter to Open().
[18:24:01] <fuzzie> I keep finding new bugs .. eg, the text entry in the save dialog of bg2 is off-centre, that is new(ish).
[18:24:34] <tomprince> It was used for getting the heightmap and searchmap.
[18:24:57] <tomprince> Since they need/ed full byte pixel data.
[18:25:10] <tomprince> I actually end up changing that later.
[18:25:16] <fuzzie> Oh?
[18:25:58] <fuzzie> Any idea which patch?
[18:26:09] <fuzzie> I seem to remember the heightmap/searchmap are somewhere depressingly high in profiling.
[18:26:28] <tomprince> 0009
[18:28:54] <fuzzie> so that Bitmap optimisation is a good one.
[18:29:41] <tomprince> Well, I didn't think of it as an optimization, just a cleanliness issue.
[18:30:09] <fuzzie> well, it needs an optimisation so it can be one :-)
[18:30:42] <fuzzie> hm
[18:31:27] <tomprince> That patch depends on 0008, which I think is a somewhat broken.
[18:32:30] <fuzzie> having a Bitmap class which has indexes and not values is a bit unclean, maybe :)
[18:32:39] <tomprince> The fix for 0008 would be to move AnimationFactory::GetPaperdollImage to BAMImp.
[18:33:10] <tomprince> Well Bitmap is really an image, it is an array of numbers.
[18:33:23] <tomprince> It is the indexes that are significant, not the values.
[18:33:29] <fuzzie> well, i'm not so sure of that
[18:33:44] <tomprince> The original code assumed that.
[18:34:30] <tomprince> Maybe the original engine used the color values that just happened to corespond to the indexes.
[18:34:58] <fuzzie> that might be the case; you can see a comment in Actor::Draw about how there are 8bpp lightmaps and I couldn't conclusively work out what was going on with them, for example.
[18:36:48] <tomprince> Heightmap you mean, at least according to where that comment is.
[18:36:57] <fuzzie> um, yes. sorry.
[18:37:23] <fuzzie> It is kind of frustrating to try and spot the (small) heightmap differences in the original engine, and I didn't really have the patience/time at the time.
[18:39:26] <fuzzie> I have no idea if vc++6's templating is going to like taking the address of a templated function, but we'll see.
[18:44:43] <CIA-31> gemrb: 03fuzzie * r7479 10/gemrb/trunk/gemrb/plugins/ (37 files in 10 dirs):
[18:44:43] <CIA-31> gemrb: modified version of a patch by tomprince:
[18:44:43] <CIA-31> gemrb: Add flexible plugin handling of resource files.
[18:44:43] <CIA-31> gemrb: So far, only Images are implemented.
[18:44:47] <fuzzie> i'll leave the rest until Avenger has a chance to see/check that one. hopefully I didn't break anything myself - probably shouldn't be doing this while ill but better it all be committed with bugs than rot away, i think.
[18:45:50] <fuzzie> (that is just 0001 with GetFile removed - both GetFile and the pastebinned fixes can be bundled with 0002)
[18:46:17] <fuzzie> am grateful someone is doing this kind of thankless backend work.
[18:47:10] <tomprince> I just find a lot of the code crufty, which annoys me.
[18:47:33] <tomprince> To a certain extent, I find it more interesting than more visible stuff.
[18:47:50] <Nomad010> i can has question?
[18:47:57] <fuzzie> Yes, the rest of us have kind of given up on anything except "making things work", as you can see from the mess of the code.
[18:48:27] <tomprince> Probably in part, that is because I am not familiar with the original engine, and so can't contribute all that much to that side of making things work.
[18:48:41] <tomprince> Nomad010: Yes. Answers .... maybe.
[18:48:42] <fuzzie> Nomad010: sure
[18:49:18] <Nomad010> it's a bit in-depth, let me do a bit more source code reading first
[18:50:20] <Nomad010> it involves Core/Polygon.cpp and SDLVideo/SDLVideoDriver.cpp
[18:51:57] <fuzzie> You might be best trying to get wjp's attention.
[18:53:17] <Nomad010> hmm i'll wait for wjp then
[18:59:57] <tomprince> Updated 0002, for later.
[19:00:39] <tomprince> And apparently it isn't thankless. :)
[19:12:54] <wjp> hi
[19:13:21] <Nomad010> hey wjp
[19:16:43] <Nomad010> so, i'm just looking at how Trapezoid's are drawn
[19:18:44] <wjp> ok
[19:19:11] <wjp> line by line currently
[19:19:19] <Nomad010> ya i get that
[19:19:44] <Nomad010> but the four points you keep to store the two lines
[19:20:11] <Nomad010> a, b, c and d
[19:21:13] <Nomad010> a and c are the starting points, b and d are the ending points of the two edges of the trapezoid
[19:21:44] <Nomad010> but well you calculate you calculate what d is, is where i am confused
[19:27:00] <wjp> a,b,c,d are in the order TL, BL, BR, TR
[19:27:29] <Nomad010> ok that makes sense
[19:27:35] <wjp> the edge numbered n is always given by points[n], points[n+1]
[19:28:16] <Nomad010> so, i suppose you make the flip in Core/Polygon.cpp then
[19:28:30] <wjp> it's not so much a 'flip'
[19:28:34] <Nomad010> oh wait, you don't need to flip
[19:29:05] <Nomad010> ah, ok the active edge list implementation would require a 'flip'
[19:29:32] <wjp> it would?
[19:29:43] <wjp> and what do you mean by flip exactly?
[19:29:45] <Nomad010> well the way i would implement it would
[19:29:57] <wjp> you mean you need to know which of the points is the top one?
[19:30:09] <Nomad010> yeah
[19:30:54] <wjp> just check the y coordinates of the points, I guess
[19:30:56] <Nomad010> because the points are 'sorted' by y
[19:31:14] <Nomad010> that won't work in a concave polygon
[19:31:26] <Nomad010> i think
[19:31:59] <Nomad010> but it's ok, i just gotta remember to flip the points in mine
[19:32:22] <wjp> I haven't thought about this in years, by the way :-)
[19:32:41] <Nomad010> lol
[19:33:31] <wjp> (after the initial implementation and bugfixing it has always "Just Worked")
[19:33:39] <Nomad010> lol!
[19:33:50] <lynxlynxlynx> got a crash in iwd2, but can't reproduce :(
[19:34:53] <Nomad010> also i noticed that you merge continuation trapezoids
[19:35:19] <wjp> yes
[19:35:31] <Nomad010> i think this step can be removed by deleting collinear points in the input polygon
[19:35:47] <wjp> not if you have a concave polygon
[19:36:10] <Nomad010> hmm, whats the case that breaks it?
[19:36:52] <wjp> for example in the case where you have a long vertical bar at the left, and then some random lines to the right of that
[19:37:17] <wjp> the 'continuation' is for joining together the parts into which the long vertical bar will be sliced
[19:38:14] <wjp> now that I look at it, this is rather inefficient currently: keeping track of 'active' trapezoids could also help here
[19:38:46] <wjp> (i.e., ones that were created in the previous horizontal pass)
[19:38:51] <Nomad010> yeah
[19:40:52] <wjp> I don't know which of these asymptotic improvements would really help in our case, though
[19:41:16] <Nomad010> this is all incorporated into the loading time right?
[19:41:38] <wjp> yes
[19:42:42] <Nomad010> well, it would make that significantly lower i think
[19:43:21] <Nomad010> that is if there are lots of complicated polygons
[19:47:28] * wjp adds some debugging printf's to see how large 'typical' polygons are
[19:49:02] <Nomad010> i'm going try haxx0r the drawing things to trace out the polygons as well
[19:49:37] <wjp> there are already some debugging keys for displaying most or all of them
[19:50:00] <Nomad010> ahh
[19:50:23] <wjp> e.g., ctrl-4 for the spritecovers
[19:50:50] <Nomad010> thanks
[19:51:32] --> Avenger has joined #gemrb
[19:51:36] --- ChanServ gives channel operator status to Avenger
[19:51:47] <Nomad010> do i need to compile with anything specific, i don't see anything
[19:51:53] <Avenger> hello everyone
[19:52:08] <fuzzie> hi Avenger
[19:52:21] <wjp> hm, you have to set some .ini var
[19:52:30] <lynxlynxlynx> EnableCheatKeys
[19:52:35] <Avenger> i just came in because i saw the lively conversation :) don't mind me
[19:53:01] <Nomad010> thanks
[19:53:55] <fuzzie> Avenger: well, if you're here, I wonder if current svn builds fine for you
[19:54:02] <Avenger> builds
[19:54:07] <Avenger> on linux
[19:54:09] <wjp> while loading the bg2 starting area, 724 polygons are trapezoided, with an average of 11 points per polygon
[19:54:11] <Avenger> i already tried
[19:54:44] <wjp> over 250 of them have 4 vertices
[19:54:48] <Nomad010> yeah
[19:55:05] <Nomad010> although some of them look like there are curved quite a bit
[19:55:16] <wjp> yes, some are quite complex
[19:55:42] <wjp> there's one with 162
[19:55:46] <Nomad010> lol
[19:55:54] <Nomad010> which area is this
[19:56:03] <wjp> the starting dungeon
[19:56:07] <wjp> in BG2
[19:56:09] <Nomad010> ok
[19:56:14] <Nomad010> i don't have bg2 :(
[19:56:58] <Nomad010> i have everything else though
[19:57:39] <Avenger> of all things you got no bg2 :)
[19:58:59] <Nomad010> lol
[19:59:29] <Nomad010> i borrowed it from a friend once, i never really got into the game, too much work at the time
[20:06:52] <Avenger> hmm, bad code placement strikes back on me
[20:07:09] <Avenger> TLKImporter has some calendar functions which shouldn't be there
[20:08:27] <Avenger> i wonder where it should be, it would be used by TLKImporter and GameScript
[20:10:50] <Nomad010> how do i get awesome debugging text?
[20:11:31] <Avenger> i just use printf...
[20:11:45] <Nomad010> guess it'll work lol
[20:39:05] <-- tomprince has left IRC ()
[21:08:39] --> tomprince has joined #gemrb
[21:14:46] <-- Avenger has left IRC ("bye!")
[21:18:34] --> tombhadAC has joined #gemrb
[21:26:00] <-- tomprince has left IRC (Read error: 54 (Connection reset by peer))
[21:30:55] --> tomprince has joined #gemrb
[21:40:04] <tomprince> fuzzie: Minor nitpick about the commit message. It would be nice if the first line was a description of patch... it makes it nice for gitk and git shortlog.
[21:45:41] <fuzzie> hm, that does look kind of silly in gitk! i tend to just 'git log', not thinking
[21:47:04] <fuzzie> it's a pity we're not natively using git so i could just apply your patches without log credit needed
[21:50:13] <lynxlynxlynx> you can apply and then just ammend the message
[21:50:45] <fuzzie> yes, but then apparently i end up screwing up the message :)
[22:06:11] --> raevol has joined #GemRB
[22:07:25] <tomprince> fuzzie: Anything in particular you would like me to clean up first?
[22:09:13] <fuzzie> After the plugin work?
[22:11:33] <fuzzie> The important things are maybe not possible to do without knowing how the original engine works, since our code is often flawed..
[22:12:47] <tomprince> After, or in parallel.
[22:13:05] <lynxlynxlynx> (rendering) optimisation is one area that doesn't need much or any such knowledge
[22:13:39] <tomprince> I do plan to move everything that can over to resources over to it that eventually.
[22:13:48] <lynxlynxlynx> don't know if you like that kind of stuff though
[22:14:12] <tomprince> But as far as I know, everything that has multiple implementations is already moved.
[22:14:30] <fuzzie> making a VVCImporter for ScriptedAnimation is an obvious candidate for that, i suppose.
[22:14:32] <tomprince> I have an idea or two on how to handle the opcodes and the sound drivers.
[22:14:38] <Nomad010> "(rendering) optimisation is one area that doesn't need much or any such knowledge" - lol
[22:15:12] <fuzzie> did you add some kind of WAV abstraction?
[22:15:52] <fuzzie> hm, i guess it doesn't really need more abstracting, just some destupiding
[22:16:01] <tomprince> I just have 2 ResourceDesc for SoundMgr with ".wav" as the extension.
[22:16:44] <tomprince> That happens in 0005.
[22:16:57] <tomprince> I just split them p
[22:17:20] <tomprince> up to make the patches smaller and more obvious.
[22:18:10] <fuzzie> I guess there are a lot of candidates. Interface is still a mess. wjp was working on moving relevant things to GameData, I don't know how far that got.
[22:19:27] <tomprince> I do plan to go through most everything, and cleanup what I can.
[22:19:43] <lynxlynxlynx> Nomad010: what's so funny about that?
[22:19:53] <tomprince> I am working on patches to get rid of the hand coded hash tables right now.
[22:19:53] <Nomad010> nothing
[22:20:26] <Nomad010> :p
[22:20:27] <fuzzie> I never did find a reason to use Variables rather than map, but I didn't do any profiling, which is maybe important.
[22:21:27] <tomprince> I just thought if there was anything in particular that would make it easier for the things you guys are doing...
[22:22:31] <fuzzie> Oh, seeing if the hand-coded ini reading code can be replaced with INIImporter might be nice.
[22:25:38] <fuzzie> These kind of things never go on my todo list because there's so much logic to fix..
[22:27:44] <tomprince> Where is the hand coded ini reading code?
[22:27:55] <fuzzie> Interface::LoadINI
[22:30:00] <tomprince> Well, the reason for Variables is to be able to support more than one kind of value.
[22:30:01] <fuzzie> We probably want to be able to write those variables to a .ini file anyway, so we probably want to preserve a lot more details (so writing it into Variables and losing the spaces is not really ideal, for example) anyway.
[22:30:51] <fuzzie> mm.
[22:32:06] <tomprince> I was planning to reimplement Variables with map internally.
[22:32:11] <fuzzie> this brings back nightmares of boost::variant, but I guess if you stick to char* then you could do something smarter.
[22:32:48] --- Nomad010 is now known as nomad__
[22:33:08] <fuzzie> oh, Variables::LoadInitialValues is a candidate for moving somewhere else too
[22:33:28] <fuzzie> i put it there solely because i was being incredibly lazy at the time
[22:35:04] <fuzzie> anyway, reimplementing Variables with map internally makes sense, although I would have to look at profiling since you'd presumably be using 'string' as the map and be doing rather a lot of copying around to deal with the spaces?
[22:35:49] <fuzzie> I seem to remember Variables showing up in profiling as it is, although perhaps it's not very efficient right now anyway, I daren't work out how it works.
[22:38:31] <fuzzie> ok, bbiab.
[22:55:09] <-- lynxlynxlynx has left IRC (Remote closed the connection)
[23:31:59] --- nomad__ is now known as Nomad010
[23:36:37] <Nomad010> fuzzie: you heard of tries?
[23:41:52] <Nomad010> or should that be tomprince
[23:44:01] <tomprince> Vaguely
[23:44:28] <Nomad010> we used them in one of university projects
[23:44:38] <Nomad010> they are pretty fast and simple to implement
[23:45:03] <tomprince> The point is I don't want to implement.
[23:45:12] <Nomad010> lol
[23:45:29] <Nomad010> you could have our implementation if you want
[23:45:39] <tomprince> If there is a good STL-like implementation, and they let me get away with adding a depedency ....
[23:46:08] <tomprince> I am not sure how bad the performance issue is.
[23:46:33] <Nomad010> tries are probably overkill, but they are much better than maps for strings
[23:46:36] <tomprince> I am trying to clean up the code, and get rid of things being implemented by hand, when there are prefectly good implentations around.
[23:46:43] <Nomad010> ahh, true
[23:47:48] <tomprince> Right now it is using a hand coded hash table. Of which there are three distinctg implementations.
[23:47:54] <Nomad010> lol
[23:48:17] <tomprince> I have coded sitting here to clean up two of them so far, and have a third on my todo list.
[23:48:47] <Nomad010> for our project we needed an arithmetic coder, switching from map<string, int> to Trie<int> sped up our code by 2 to 5 times, although i'm guessing there is no performance issue in this case
[23:49:03] <Nomad010> more a ease of reading priority
[23:51:19] <Nomad010> tomprince: how long has this project being going?
[23:51:39] <tomprince> Which? GemRB, or me cleaning up the tree.
[23:51:52] <Nomad010> gemrb
[23:54:33] <tomprince> I don't know about GemRB, the initial commit in svn is 2003, but that was an import of an existing code base.
[23:54:48] <tomprince> I just started working on GemRB about a month ago.
[23:55:18] <Nomad010> ahh, ok
[23:55:30] <Nomad010> i'd like to work more on this project
[23:55:55] <Nomad010> university chows a lot of my time though
[23:58:16] <Nomad010> gmote