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

Archive Today Yesterday Tomorrow
GemRB homepage


[01:11:50] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[01:20:06] <-- raevol has left IRC (Quit: Leaving.)
[02:57:55] <tomprince_loki> Update WIP-explore patch. Still has double, which should be removed, and the code needs some cleanup, but I think that the algorithm (i.e. what it marks visible is reasonable on the tip.
[03:17:58] <tomprince> s/Update/Updated/ :)
[03:54:20] <-- ratpor has left IRC (Quit: Get used to disappointment.)
[05:11:35] --> raevol has joined #GemRb
[06:17:02] --> lynxlynxlynx has joined #GemRb
[06:17:02] --- ChanServ gives channel operator status to lynxlynxlynx
[07:24:26] <Edheldil> bye, see you later, I hope
[07:24:40] <Edheldil> Easter visits ...
[07:24:44] <-- Edheldil has left IRC (Quit: Really?)
[08:42:15] <fuzzie> hmm, i patched up our bg1 load screen to not cut off the text, but is our bg1 load screen just the wrong image?
[08:45:05] <fuzzie> oh, no, i guess the other one is the 'loading area' one.
[08:57:37] <CIA-43> GemRB: 03fuzzie * r38e5b9ed352c 10gemrb/gemrb/override/bg1/guils.chu: move/resize the label on the bg1 load screen a bit
[09:01:35] <fuzzie> fixes "Loading title text (when loading/saving) is cut off at the bottom" from todo, i hope :)
[09:21:13] <fuzzie> tomprince: it's leaking through doors too much
[09:21:21] <fuzzie> leaking through walls too much, also.
[09:25:04] <fuzzie> (the bg2 start area is always a great place to test this stuff; i think it has pretty much all the annoying corner cases.)
[09:28:00] <fuzzie> obviously even the original engine leaks a little, but with your algorithm just one little leak ends up with the whole view distance revealed..
[12:13:29] <tomprince_loki> Does the algorithm we have now do the right thing?
[12:14:12] <fuzzie> it leaks much like the original engine.
[12:16:00] <tomprince_loki> It suspect that that can be fixed with some tweaking of the slopes.
[12:16:58] <tomprince_loki> Mine certainly behaves better the what we have now when you walk up to walls.
[12:18:12] <fuzzie> well, it seems worse for me, as i said.
[12:18:53] <fuzzie> but tweakable, i'm sure.
[12:19:43] <tomprince_loki> For me, I found that when I walk right up to the outside of the wall around the inner keep in the bg1 tutorial area, the current algorithm falls down and displays almost nothing.
[12:19:44] <fuzzie> http://www.peliplaneetta.net/images/articles/218/b_12.jpg shows how badly the original engine does it at times.
[12:20:16] <fuzzie> well, your algorithm goes through walls, the current algorithm doesn't show enough.
[12:20:30] <fuzzie> but the latter is not game-breaking.
[12:20:44] <fuzzie> just very annoying.
[12:24:23] <tomprince_loki> I guess I just tested where the current algorithm falls down.
[12:34:13] <tomprince_loki> Is this any better? And if not, do you have an area where I can test against?
[12:35:22] --> ratpor has joined #GemRb
[12:46:10] <lynxlynxlynx> bg2 intro is the best
[12:46:14] <lynxlynxlynx> truly nasty :)
[12:47:24] <-- raevol has left IRC (Quit: Leaving.)
[13:13:51] <tomprince_loki> Teleporting around the bg2 intro, I don't see anything that jumps out at me as seeing too much. There are a couple of places I found where I don't see enough.
[13:16:33] <lynxlynxlynx> try walking
[13:17:29] <lynxlynxlynx> http://lynxlynx.info/bugs/gemrb-see.through.door.frames.jpg <-- old screenshot, not sure if it still applies
[13:20:45] <tomprince_loki> I posted a new Field of View algorithm at WIP-explore.
[13:25:38] <lynxlynxlynx> i know
[13:25:59] <lynxlynxlynx> that screenshot isn't relevant anymore, i remember that now too
[13:35:57] --> Gekz has joined #GemRb
[13:50:43] <tomprince_loki> Not seeing anything walking around either.
[13:51:15] <Gekz> sup tomprince_loki
[13:51:41] <tomprince_loki> Trying to test a new FOV algorithm.
[13:51:55] <tomprince_loki> Hopefully faster, and more accurate.
[13:52:11] <lynxlynxlynx> it's odd how your and fuzzie's experience differs so greatly
[13:52:14] <lynxlynxlynx> -s
[13:53:43] <tomprince_loki> Yes.
[13:54:46] <Gekz> it's good
[13:54:49] <Gekz> because you both so crazy
[13:54:54] <Gekz> but one of you is dutch crazy
[13:54:58] <Gekz> and one of you is possibly french crazy
[13:55:01] <Gekz> possibly british crazy
[13:55:13] <tomprince_loki> The first one I posted did have issue seeing through walls, but the tip doesn't seem to.
[13:55:46] <tomprince_loki> There is a glitch at the door to Rielev's room.
[13:55:57] <tomprince_loki> There are places where you don't see anything, but should.
[14:03:42] <tomprince_loki> The best way to test it seems to be to add an Explore(0) in Map::UpdateFog().
[14:19:19] <fuzzie> hm
[14:19:35] <fuzzie> well, i changed out latest 'WIP-explore' on x86 and built it, then ran bg2
[14:19:57] <fuzzie> HEAD isf3ce44527c442252aad62038977e149a42be07b8
[14:20:47] <fuzzie> and i got seeing-through-walls all over the bg2 first area
[14:20:53] <fuzzie> is that HEAD ok?
[14:23:46] <tomprince> I don't know where you got isf...
[14:23:57] <fuzzie> missing space after 'is' :)
[14:24:08] <tomprince> 491dcd907 is the latest.
[14:24:16] <tomprince> That fixes some of the seeing through walls.
[14:24:19] <tomprince> :)
[14:24:22] <fuzzie> but i mean, this was when i was testin g it earlier
[14:24:31] <fuzzie> and if you say you don't see any bugs..
[14:25:07] <tomprince> No, I did see some seeing through walls, after I went inside.
[14:26:03] <fuzzie> ok.
[14:26:46] --> barra_desktop has joined #GemRb
[14:28:15] <fuzzie> 491dcd907 much better !
[14:28:44] <tomprince_loki> Excellent.
[14:35:17] <fuzzie> i don't see any regressions at a glance
[14:38:10] <fuzzie> but it doesn't seem to help my wall issues either, hmph
[14:41:35] <fuzzie> (which games do you have?)
[14:42:34] <tomprince_loki> I have bg1/bg2 setup right now.
[14:43:58] <fuzzie> ok. the real annoying wall problems are in pst, but they're present in the existing code.
[14:45:38] <tomprince_loki> Where abouts in PsT?
[14:46:16] <fuzzie> all over :( in the start area you can just look at anything on the north wall of the first room, in outside areas you can just look at any wall
[14:49:04] <fuzzie> i have no idea what the problem is. some of it is obviously "doors shouldn't block lines of sight", but not all.
[14:51:24] <tomprince_loki> Is it that it doesn't show enough of the wall?
[14:51:30] <fuzzie> yes
[14:51:56] <fuzzie> It may well be that the parameters are different in pst, I really have no idea about this code.
[14:52:15] <tomprince_loki> Is perhaps that the wall in PsT seem to be thicker, so we should look through more of a wall in PsT?
[14:52:30] <fuzzie> could be :)
[14:52:58] <tomprince_loki> With the sf code, try changing the initial pass, to 3 or 4, and see if that is any better.
[14:57:49] <fuzzie> If you are interested in this code in general, the IsVisible function between two points is I think responsible for various issues.
[14:59:22] <fuzzie> And Map.cpp also has the pathfinder, some of which should really probably be using A*.
[14:59:58] <fuzzie> (see FindPathNear, which I wrote as a quick hack of the existing pathfinder code)
[15:00:50] <tomprince_loki> Partly, I am interested, since you suggested that it is one of the bottlenecks, after SDL.
[15:01:22] <fuzzie> Well, I just mention those because I am always interested in attempting to palm off the high-priority things on my todo list onto others. :)
[15:01:48] <tomprince_loki> But yes, I am interested in cleaning up all the code that was put in because it was just barely good enough.
[15:02:43] <fuzzie> Increasing the Pass helps for the walls (I tried 4, maybe too high), but the doors are still only half-visible. Not sure quite how it looks in the original game, but I know they're all visible.
[15:02:51] <fuzzie> Obviously this is using the sf code, though.
[15:04:18] <-- Gekz has left IRC (Ping timeout: 265 seconds)
[15:05:19] <tomprince_loki> I am curious how the original engine does it. Since 491d doesn't look through walls, but it doesn't handle looking along walls as well as its parent.
[15:05:52] <fuzzie> I think something more like the algorithm that is on sf.
[15:06:22] <fuzzie> Purely on the basis of looking at the artifacts.
[15:07:15] <tomprince_loki> Does it handle walking up to walls, and looking along them?
[15:07:34] <fuzzie> Yes, but it looks *through* the walls too.
[15:08:55] <tomprince_loki> So, I am not going crazy, and the grid size is just to large. Okay.
[15:09:01] <fuzzie> Yes :-)
[15:09:27] <fuzzie> It's impossible to find a perfect balance, I'm sure.
[15:09:55] <tomprince_loki> Well, I am not prepared to say impossible yet.
[15:10:08] <fuzzie> But the game relies on you not being able to see too far, and your earlier code was doing so.
[15:11:48] <fuzzie> (Are you checking in bg1, by the way?)
[15:12:22] <tomprince_loki> Well, I have BWP installed, and am using that to check the first area of bg1.
[15:14:03] <fuzzie> The bg1/pst code is different in some important way I forget.
[15:14:37] <fuzzie> I assume BWP is one of these bg1-in-bg2-engine hacks.
[15:15:18] <tomprince_loki> Yes.
[15:15:46] <fuzzie> So I would suggest you try against a real bg1/pst install, if you can.
[15:16:06] <tomprince_loki> As far as I can tell, PATH_MAP_SIDEWALL is for walls that you should be able to look along, but not through. The trick is to tell when that is the case.
[15:16:29] <fuzzie> Although it would certainly be nice someday if we could use gemrb to get rid of the advantages of pure-bg1 mode.
[15:18:44] <tomprince_loki> Anyway, have you had a chance to profile the new code?
[15:21:29] <tomprince_loki> Not much point fiddling with the new algorithm if it isn't at least comparable. :)
[15:22:42] <fuzzie> Heh, that stupid BMPImp::GetPixelIndex is up there.
[15:25:32] <fuzzie> It doesn't seem much of a change either way with a glance at oprofile -- either way, ExploreTile seems the culprit -- but oprofile is definitely not the most reliable of methods.
[15:27:56] <tomprince_loki> I wonder if it would be better to change that to an array of bools, rather than bit-fiddling there.
[15:28:06] <fuzzie> About 0.5% of total time spent in ProcessObstruction, if it can be trusted.
[15:28:46] <fuzzie> The reason it's bit-twiddling is just because that's how the data is stored, afaik.
[15:32:03] <fuzzie> I thought I mentioned the other day that it might be worth #ifdeffing. How much memory would it use as a bool, any idea?
[15:32:54] <tomprince_loki> It should be exactly 8 times as much.
[15:33:24] <tomprince_loki> According to IESDP, 1 byte per 16x16 pixel cell.
[15:35:34] <fuzzie> Well, the relative size doesn't matter so much, just wondering if it would have an impact on our overall usage.
[15:37:10] <fuzzie> If my hasty calculations putting it far below 1mb are correct, that doesn't seem to be a worry.
[15:38:00] <fuzzie> In the end this is all of 3% or so of CPU time, though, although we should *really* be doing something similar in functions such as IsVisible too, which might add a little more.
[15:38:08] <fuzzie> The blitter is much more of a problem.
[15:38:47] <tomprince_loki> I agree.
[15:39:18] <fuzzie> But improved visibility code would be very welcome either way.
[15:39:45] <fuzzie> And now I need to disappear, bbiab.
[16:00:48] <tomprince_loki> Random thought, would it make sense to use the conservative algorithm for exploring, and the permisive one for visibility? Or perhaps vice-versa.
[16:26:50] <tomprince_loki> I suspect my algorithm could be improved by using the actual position in the cell, rather than using the middle, for the start point.
[17:19:48] <-- ratpor has left IRC (Ping timeout: 258 seconds)
[17:21:24] <fuzzie> it is pretty easy to compare the algorithms, which is helpful :)
[17:27:16] <fuzzie> Your SetVarAssoc patch seems to remove half the logic.
[17:28:13] <fuzzie> I mean, I see that is promptly fixed by the next commit, but in that case they should perhaps be the other way around..
[17:29:52] <fuzzie> Or, no, it isn't fixed by the next commit, I guess.
[17:30:00] <fuzzie> Confused.
[17:35:29] <tomprince_loki> Are you sure it isn't fixed by the next commit? Sum should be intialized to 0 there, but otherwise I think it does.
[17:35:43] <tomprince_loki> Although, it has been a long time since I looked at most of those patches.
[17:36:08] <tomprince_loki> I wrote most of them back around the new year.
[17:36:18] <fuzzie> It isn't fixed by the next commit because the next commit breaks the build, afaics.
[17:37:26] <fuzzie> (You change the prototype of RedrawControls, but don't fix the new caller in Control?)
[17:39:02] <tomprince_loki> Yes. They were originally one commit, and I obviously didn't test thouroughly enough when I split them.
[17:40:28] <fuzzie> Well, not sure how rushed you are in getting the contents of 'fixes' applied, but would prefer to be able to just apply unmodified commits if possible.
[17:40:37] <tomprince_loki> Not rushed at all.
[17:41:18] <tomprince_loki> Personally, I am more interested in the other stuff. But I know that is all bigger changes.
[17:42:08] <tomprince_loki> I suspect that the other stuff has probably got at least a *little* bit more testing than the fixes branch.
[17:42:12] <fuzzie> Well, more useful changes, too.
[17:42:58] <tomprince_loki> Yes. I think I mentioned before, that the fixes branch was just various random things that I had in my tree, that I forward ported, split and pushed.
[17:44:10] <tomprince_loki> The fixes branch was simple and obvious fixes ... well, they would have been, if they didn't all seem to be broken. :)
[17:47:48] <fuzzie> Well, the plugins branch doesn't build either.
[17:48:27] <fuzzie> (spelling mistake in the most recent commit - void Plugin::relase())
[17:48:43] <tomprince_loki> gahh....
[17:51:44] <tomprince_loki> What I should really do is just stop writting new code, until most everything is applied.
[17:52:25] <tomprince_loki> Because I can't seem to test everything, when I have so much stuff waiting. :(
[17:52:30] <tomprince_loki> :( about the testing that is.
[17:53:14] <lynxlynxlynx> excellent idea
[17:53:20] <fuzzie> Well, this is why I keep looking at the commits on the fixes branch; they really should be relatively easy candidates.
[17:53:43] <fuzzie> But commits depending on existing commits quickly lead to disaster, yes :|
[17:53:47] <lynxlynxlynx> then you can also start pushing things directly or to branches on sf, so it's all in one repo
[17:56:25] <fuzzie> would you prefer the one repo?
[17:57:45] <tomprince_loki> l honestly don't care where I put my branches. One thing about having a seperate repo is that I don't need to worry about rebasing, or push many branches, and having random people be confused.
[17:58:17] <tomprince_loki> But like I said. I don't care at all.
[17:58:51] <fuzzie> Well, I am just pulling everything into one local repo, so it doesn't make much difference to me.
[18:04:28] <fuzzie> The plugins branch seems to work after that typo change and another deletion of *.so.
[18:09:45] <lynxlynxlynx> to me it is easier, i don't need to go search the log for your url
[18:10:11] <fuzzie> oh, for the web interface?
[18:10:26] <lynxlynxlynx> or for pulling
[18:10:37] <lynxlynxlynx> i haven't added the remote
[18:10:56] <fuzzie> The trouble I have with the plugins thing is that they are still huge changes.
[18:11:05] <lynxlynxlynx> bbl
[18:11:37] <fuzzie> I can understand being reluctant to split up the patches further, though.
[18:11:42] <tomprince_loki> I can understand that.
[18:12:46] <tomprince_loki> I'm not sure that I *can* split them up. Not reasonably.
[18:13:37] <tomprince_loki> If you would like them smaller, and you have some idea on how to split them up, then I am willing to do that.
[18:14:23] <tomprince_loki> Part of the reason some of the patches are so big is that they are refactoring, so some of it is just moving large chuncks of code around.
[18:14:36] <fuzzie> Well, I am looking at the first patch.
[18:17:45] <tomprince_loki> lynxlynxlynx: My repo is now on the frontpage of the wiki, no more hunting through the logs.
[18:18:06] <fuzzie> Maybe we should have some nice copy-and-paste remote configurations?
[18:19:21] <fuzzie> Anyway, the added "Resource *res = types[j].Create(ret);" code doesn't seem to need to be in the same commit, and it is leaking 'ret', I think.
[18:21:35] <tomprince_loki> It doesn't leak ret, look in plugindef.h
[18:22:36] <fuzzie> plugindef.h seems to delete only the new resource, and most plugins do not have autoFree set by default.
[18:23:16] <fuzzie> I don't claim there is a bug there, just that it's additional code I don't quite understand!
[18:28:18] <fuzzie> And you know your intended design much better than I do, so I am reluctant to go try fixing bugs which I might be completely misunderstanding.
[18:28:41] <tomprince_loki> Well, it took me sometime to verify that it isn't a bug.
[18:29:05] <fuzzie> Where is it freed?
[18:29:44] <tomprince_loki> It is freed in Resource::~Resource(), and autoFree is always true for resources.
[18:30:16] <tomprince_loki> Check: git grep 'autoFree = false'.
[18:31:10] <tomprince_loki> That is actually something I want to clean up at somepoint. We never actually reuse a Resource object, so we should have code there to handle it, and we never don't autoFree.
[18:33:36] <fuzzie> Aha.
[18:34:05] <fuzzie> ok. could you forge me a commit with that single change?
[18:34:48] <tomprince_loki> What change? The Resource *res?
[18:34:55] <fuzzie> yes
[18:35:25] <fuzzie> i mean, i could do it, but then i end up with my authorship.
[18:35:45] <fuzzie> Am intending to just apply the rest on top, so no need for rebase/etc.
[18:36:18] <fuzzie> (Although I would also like to seperate out the name change from that, if possible.)
[18:37:27] <tomprince_loki> The name change?
[18:37:28] <fuzzie> If I were writing these commits, I would have refactored the ResourceMgr.h changes out too, I guess.
[18:37:43] <fuzzie> You change KeyImp -> KEYImporter in the commit.
[18:38:06] <tomprince_loki> Ah, yes.
[18:39:02] <fuzzie> The diffs are a lot more readable if I chop it up into minimal commits, but I spent enough time staring at this now, I think.
[18:39:50] <tomprince_loki> I don't know if it makes sense to seperate the ResourceMgr.h changes, since description is replacing PathEntry::description.
[18:40:21] <fuzzie> Well, the trouble is that you give one to KEYImporter too.
[18:41:23] <fuzzie> By adding the data to an abstract interface :) But I mean, this is not requesting that they be split up, I'm just explaining how I would doit.
[18:42:01] <tomprince_loki> Trivial patch to or.cz/for-fuzzie
[18:43:52] <fuzzie> I guess the real problem is that AddDirectory should really know that it's getting a DirectoryImporter* back there. But, nitpicking.
[18:45:09] <tomprince_loki> GameData::AddPath? It doesn't always get a DirectoryImporter.
[18:45:32] <fuzzie> No, AddDirectory.
[18:45:33] <CIA-43> GemRB: 03tom.prince * r2b69c2809a8e 10gemrb/gemrb/plugins/KEYImporter/KEYImporter.cpp: KEYImporter: Check for all possible resource types in a bif.
[18:46:49] <tomprince_loki> Yes, that AddDirectory. :) I did want a description for all ResourceMgr. What happens if you have multiple chitin.key's, or a bunch of zipfiles?
[18:47:23] <fuzzie> Well, I mean, it's a two-way thing: either you add new functionality there, or you simply replace PathEntry::description.
[18:47:58] <fuzzie> If you're doing the former, then a seperate commit makes sense. If you're doing the latter, it needn't be in ResourceMgr at all.
[18:50:09] <tomprince_loki> That makes sense.
[18:51:45] <tomprince_loki> I guess my mental model is a bit different. The model I have is that KeyImp got split into three pieces, DirectoryImporter, KEYImporter, and the glue code, which is in GameData.
[18:52:42] <tomprince_loki> I had originally intended for there to be three types of ResourceMgr, one to handle a list of ResourceMgrs, but there was no clean way to initialize one, if it lived in a plugin.
[18:54:35] <tomprince_loki> Do you want a seperate commit for the rename?
[18:55:25] <-- Nomad010 has left IRC (Ping timeout: 268 seconds)
[18:55:27] <fuzzie> No, I am just trying to explain what I meant by splitting them up, sorry.
[18:55:43] <tomprince_loki> No problem.
[18:57:17] <tomprince_loki> All my patches seem to go through you, so just trying to learn how to make your life easier.
[18:58:28] <fuzzie> It's just an awful lot easier for me to glance through a series of small patches and commit them as I go, and I imagine easier for you.
[18:59:34] <tomprince_loki> And I think discussions like this are useful anyway ... more brains thinking about a problem, and you get a better solution.
[18:59:56] <tomprince_loki> I certainly don't take anything as more than well intentioned contructive criticism.
[19:00:54] <fuzzie> In the end, you can get any of the others to commit things you really think are a good idea, if I'm not getting around to it.
[19:01:32] <tomprince_loki> I wasn't suggesting that you weren't getting around to things, more that you were the only one who was.
[19:01:58] <fuzzie> No, but I mean, you can always bug other people about individual patches. :)
[19:03:47] <fuzzie> And obviously it's not as if the git repository has to be particularly authoritative in a git world anyway.
[19:03:56] <fuzzie> Erm, the sf repository.
[19:04:27] <tomprince_loki> :)
[19:05:54] <fuzzie> Hence why I was wondering if putting some hints for adding remotes on the wiki might be welcome.
[19:06:52] <tomprince_loki> Might be good to put a git add remote line for each of the repositories.
[19:07:12] --> Nomad010 has joined #GemRb
[19:08:30] --> edheldil has joined #GemRb
[19:19:51] <tomprince_loki> done.
[19:20:58] <fuzzie> thankyou
[19:27:27] <fuzzie> This is a regression in the output of extensions, again?
[19:30:03] <fuzzie> If I apply the first two patches of the plugins branch, could you add a commit to output the filename+extension somewhere, perhaps just before the printBracket calls?
[19:31:22] <tomprince_loki> Yes.
[19:31:40] <tomprince_loki> I do print the extensions on failure, but not on success.
[19:32:03] <tomprince_loki> And I can fix it.
[19:32:12] <fuzzie> Yes, I just want to be able to see what kind of file was loaded, because it's not uncommon for that to be the most useful indication of what went wrong somewhere.
[19:32:28] <fuzzie> It doesn't have to be like the current output.
[19:33:38] <tomprince_loki> Should we perhaps have a description in TypeID, and print that in GameData when we begin searching?
[19:34:53] <fuzzie> It seems like just "Searching for FILE... FILE.EXT[FOUND]" would be easiest solution.
[19:35:16] <fuzzie> And you can't do that with TypeID.
[19:36:19] <fuzzie> Can understand that it would be tidier the other way, but would like not to lose information.
[19:37:34] <tomprince_loki> Also, I'm just stupid and didn't think of printing the filename again.
[19:38:05] <fuzzie> I'm waiting on valgrind..
[19:43:01] <tomprince_loki> I've got it for stuff from override. It isn't so easy for stuff from bifs, since the found is printed in BIFImp::GetStream. I'll put it after the found for now, with a note to fix it.
[19:43:23] <fuzzie> [GameData]: Searching for am2000d7.wav...[GameData]: Searching for bag03e.sto...[Cache]
[19:43:26] <fuzzie> [FOUND]
[19:43:27] <fuzzie> ^- This kind of output is odd.
[19:44:08] <-- edheldil has left IRC (Ping timeout: 265 seconds)
[19:44:55] <tomprince_loki> That does look odd.
[19:45:03] <tomprince_loki> I wonder what could cause that?
[19:46:40] <tomprince_loki> I could understand if they were reversed, potentially.
[19:49:06] <tomprince_loki> I have no idea what would cause that.
[19:49:10] <fuzzie> Me neither.
[19:49:59] <fuzzie> Oh, wait.
[19:50:06] <fuzzie> This is without your sound changes applied, ofc.
[19:50:37] <fuzzie> I wonder if it's just something lurking in OpenAL land.
[19:50:55] <tomprince_loki> That might be it.
[19:52:42] <fuzzie> There is a core->GetMusicMgr()->PlayNext() call in that thread.
[19:53:22] <tomprince_loki> That would do it.
[19:53:32] <fuzzie> That goes on the "things to look at carefully" list, I suppose.
[19:55:13] <fuzzie> [GameData]: Searching for ar2200.wed...Cannot find data/AREA2200.bif... Resource unavailable.
[19:55:16] <fuzzie> [ERROR]
[19:55:33] <fuzzie> ^- would be nice to get rid of the newline.
[19:56:00] <CIA-43> GemRB: 03tom.prince * r86d078b216b7 10gemrb/ (14 files in 6 dirs):
[19:56:00] <CIA-43> GemRB: KEYImporter: Split into KEYImporter and DirectoryImporter.
[19:56:00] <CIA-43> GemRB: Also, move search path handling to GameData.
[19:56:00] <CIA-43> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:56:00] <CIA-43> GemRB: Signed-off-by: Alyssa Milburn <fuzzie@fuzzie.org>
[19:56:07] <CIA-43> GemRB: 03tom.prince * r487becad2abb 10gemrb/gemrb/plugins/KEYImporter/ (KEYImporter.cpp KEYImporter.h):
[19:56:07] <CIA-43> GemRB: KEYImporter: De-duplicate code in GetResource.
[19:56:07] <CIA-43> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:56:50] <fuzzie> I don't believe I made any changes other than to the print statements.
[19:57:24] <fuzzie> Oh, and some extra braces.
[19:58:20] <tomprince_loki> Looks good.
[20:02:41] --> edheldil has joined #GemRb
[20:02:42] <tomprince_loki> or.cz/for-fuzzie.
[20:03:07] <tomprince_loki> The KEYImporter output should be fixed up, but that is more invasive.
[20:17:08] <fuzzie> Hm, fopen()s append semantics are spectacularly unhelpful.
[20:17:48] <tomprince_loki> The major things left on that branch are the two sound patches, and the imagemgr stuff.
[20:18:12] <tomprince_loki> Which includes SaveGame using directory importer.
[20:20:09] <CIA-43> GemRB: 03fuzzie * r760bf9ef5552 10gemrb/gemrb/plugins/Core/FileStream.cpp: fix FileStream::Modify to use r+ instead of a
[20:20:47] <tomprince_loki> The JPEGImporter is more or less independent of the other imagemgr changes, but depends on them.
[20:21:03] <fuzzie> I noticed, otherwise I'd have taken it already.
[20:23:29] <fuzzie> Your MUSImporter patch doesn't change OpenPlaylist?
[20:27:32] <tomprince_loki> No.
[20:30:16] <tomprince_loki> Part of the reason is, I can seem to see where the extension is added, if it ever is.
[20:30:25] <fuzzie> I don't think it is.
[20:32:23] <tomprince_loki> That would be why. Something to be put on the todo list.
[20:33:09] <fuzzie> Handling direct opening of files?
[20:33:55] <tomprince_loki> Something like that.
[20:34:25] <tomprince_loki> I can understand Avenger's dislike of too much being in plugins, since it constrains our interface to them.
[20:36:13] <fuzzie> Mhm.
[20:36:33] <fuzzie> But it also helps a lot, of course; it keeps all knowledge of Python out of the core, for example.
[20:38:07] <tomprince_loki> Yes. The discipline it enforces are good, but there isn't away to avoid that when it *does* make sense.
[20:38:55] <tomprince_loki> I think for now it makes sense to keep it, until Core is cleaned up. And then at some mythical point in the future, relaxing it somewhat.
[20:39:22] <tomprince_loki> Or, maybe by that point, there won't be a need.
[20:41:54] <fuzzie> Well, it would be nice if it actually helped fix things. :)
[20:42:19] <fuzzie> One reason I am slow to review these patches is that they only lead to regressions in the short-term, of course.
[20:43:56] <fuzzie> Hence my also taking the time to try and fix some other things in between, meaning I can hopefully spot anything which regressed.
[20:44:08] <tomprince_loki> Well, my intention isn't to have any of the patches induce regressions.
[20:44:47] <fuzzie> Could you confirm that the filename/extension commit was pushed?
[20:45:11] * fuzzie prods CIA-43
[20:45:48] <fuzzie> Oh, wait, I have a web browser, nm.
[20:45:57] <fuzzie> Ok, just CIA being quiet.
[20:46:41] <tomprince_loki> Part of the reason is that I don't have a good testbed. I started hacking on GemRB before playing with it all that much, so I don't have a large collection of saved games or anything to test against.
[20:48:20] <fuzzie> There are some savegames at http://www.eowyn.cz/gemrb/
[20:48:32] <fuzzie> Not that many for bg1.
[20:48:34] <fuzzie> Erm, for bg2.
[20:49:56] <CIA-43> GemRB: 03tom.prince * r437a1a9449a7 10gemrb/gemrb/plugins/ (2 files in 2 dirs):
[20:49:56] <CIA-43> GemRB: ResourceMgr: Print filename and extension on success.
[20:49:56] <CIA-43> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[20:50:20] <fuzzie> The engine versions differ rather a lot from each other, which doesn't help.
[20:51:08] <fuzzie> But mostly I find myself struggling with the same problems as every other RE project I've worked on; it is impossible to avoid regressions if no-one knows what the correct behaviour *is*.
[20:54:30] --- barra_desktop is now known as barraAway
[20:58:50] <tomprince_loki> If any of my stuff does cause regression, feel free to punt it to me.
[20:59:23] <tomprince_loki> Or is it exposing other regressions?
[20:59:33] <fuzzie> I think this last batch of commits was fine.
[21:00:46] --> Gekz has joined #GemRb
[21:04:08] <tomprince_loki> Gekz: Would you be willing to be a guinea pig for fixing autotools on win32/osx. Or at least telling me how badly broken they are now, or after the autoconf patch on or.cz/plugins?
[21:09:41] <fuzzie> tomprince_loki: should probably remove the "Search it in the GemRB override Directory" comment.
[21:10:31] <fuzzie> Looking at the source of that, is that a regression?
[21:14:11] <fuzzie> Doesn't look like it.
[21:15:00] <-- Gekz has left IRC (Read error: Connection reset by peer)
[21:15:55] <tomprince_loki> No. Just a stray comment that should have been deleted during the split. (untested :)) fix at or.cz/for-fuzzie.
[21:17:40] --> cfchris6_ has joined #GemRb
[21:18:01] <CIA-43> GemRB: 03tom.prince * r9a96d0333785 10gemrb/gemrb/plugins/DirectoryImporter/DirectoryImporter.cpp: DirectoryImporter: Get rid of obsolete comment.
[21:18:16] <fuzzie> thanks again :)
[21:18:22] <tomprince_loki> np.
[21:21:07] <-- cfchris6 has left IRC (Ping timeout: 276 seconds)
[21:33:53] <tomprince_loki> How about the core branch? (I am just rebasing it now.)
[21:34:43] <fuzzie> I think it would be sensible to fix up the VC++ project files first.
[21:37:02] <fuzzie> While mingw+gcc4 is not a bad compiler any more, there seem to be enough people building it that way, and Avenger does write most of the code.
[21:38:19] <tomprince_loki> It seems like it would be a very easy thing to fix, if you have access to it.
[21:39:11] <tomprince_loki> Or should I prod him about it, next time he shows up.
[21:39:49] * tomprince_loki goes to have supper.
[21:46:07] <fuzzie> i am seeing a huge performance regression with those latest patches.
[21:46:14] <fuzzie> I can't think why.
[21:48:07] <fuzzie> The profile has strncpy at 5%, that is crazy.
[21:49:04] <fuzzie> (via SearchIn, it seems)
[21:52:21] <-- Gekz_ has left IRC (*.net *.split)
[21:52:21] <-- cfchris6_ has left IRC (*.net *.split)
[21:52:21] <-- Lightkey has left IRC (*.net *.split)
[21:52:21] <-- fuzzie has left IRC (*.net *.split)
[21:52:21] <-- lynxlynxlynx has left IRC (*.net *.split)
[21:52:21] <-- anji has left IRC (*.net *.split)
[21:52:21] <-- edheldil has left IRC (*.net *.split)
[21:52:21] <-- |Cable| has left IRC (*.net *.split)
[21:52:21] <-- tomprince_loki has left IRC (*.net *.split)
[21:52:21] <-- tomprince has left IRC (*.net *.split)
[21:52:22] <-- CIA-43 has left IRC (*.net *.split)
[21:52:22] <-- barraAway has left IRC (*.net *.split)
[21:52:22] <-- wjp has left IRC (*.net *.split)
[21:52:22] <-- Nomad010 has left IRC (*.net *.split)
[21:52:22] <-- xrogaan has left IRC (*.net *.split)
[21:53:10] --> cfchris6_ has joined #GemRb
[21:53:10] --> edheldil has joined #GemRb
[21:53:10] --> Nomad010 has joined #GemRb
[21:53:10] --> barraAway has joined #GemRb
[21:53:10] --> lynxlynxlynx has joined #GemRb
[21:53:10] --> tomprince_loki has joined #GemRb
[21:53:10] --> Gekz_ has joined #GemRb
[21:53:10] --> tomprince has joined #GemRb
[21:53:10] --> |Cable| has joined #GemRb
[21:53:10] --> anji has joined #GemRb
[21:53:10] --> fuzzie has joined #GemRb
[21:53:10] --> Lightkey has joined #GemRb
[21:53:10] --> wjp has joined #GemRb
[21:53:10] --> CIA-43 has joined #GemRb
[21:53:10] --> xrogaan has joined #GemRb
[21:53:46] <-- edheldil has left IRC (Ping timeout: 264 seconds)
[21:55:35] --> Maighstir_laptop has joined #GemRb
[21:58:50] --> edheldil has joined #GemRb
[22:02:30] <tomprince_loki> Does changing the _MAX_PATH to 8 fix it?
[22:02:48] <tomprince_loki> I can see why that would make a difference.
[22:05:11] <fuzzie> aha.
[22:05:11] <tomprince_loki> Does it?
[22:05:11] <fuzzie> am trying.
[22:06:06] <tomprince_loki> I hope not, because I need that change for the MUSImporter patch. Or something like, since I am passing in a path, rather than a filename to GetResource there.
[22:06:47] <fuzzie> It gets rid of the strncpy in the profile.
[22:07:08] <fuzzie> It is a particularly awful savegame situation which is repeatedly loading the same files.
[22:08:16] <fuzzie> So is probably best resolved by caching where the files are (and resetting that as needed), rather than continually running this naturally slow code.
[22:08:25] <fuzzie> I am wondering why it has regressed so terribly, though.
[22:08:46] <tomprince_loki> How about min(strlen(ResRef),_MAX_PATH)
[22:08:50] <fuzzie> fopen() seems to be the main culprit, libc is doing completely mad things.
[22:18:50] <-- exultbot has left IRC (signing off...)
[22:23:43] --> exultbot has joined #GemRb
[22:23:43] --- Topic for #GemRb is: GemRB 0.6.0 | http://gemrb.sf.net | Be wary of your words for there are Modron sensors in this channel: http://log.usecode.org/gemrblog.php | Hey <CHARNAME>, we need some awesome screenshots!
[22:23:43] --- Topic for #GemRb set by lynxlynxlynx at Tue Nov 3 16:51:03 2009
[22:24:55] <-- Gekz_ has left IRC (*.net *.split)
[22:24:55] <-- cfchris6_ has left IRC (*.net *.split)
[22:24:55] <-- Lightkey has left IRC (*.net *.split)
[22:24:55] <-- fuzzie has left IRC (*.net *.split)
[22:24:55] <-- lynxlynxlynx has left IRC (*.net *.split)
[22:24:55] <-- anji has left IRC (*.net *.split)
[22:24:55] <-- |Cable| has left IRC (*.net *.split)
[22:24:55] <-- Maighstir_laptop has left IRC (*.net *.split)
[22:24:56] <-- tomprince_loki has left IRC (*.net *.split)
[22:24:56] <-- tomprince has left IRC (*.net *.split)
[22:24:56] <-- edheldil has left IRC (*.net *.split)
[22:24:56] <-- CIA-43 has left IRC (*.net *.split)
[22:24:56] <-- barraAway has left IRC (*.net *.split)
[22:24:56] <-- wjp has left IRC (*.net *.split)
[22:24:56] <-- Nomad010 has left IRC (*.net *.split)
[22:24:56] <-- xrogaan has left IRC (*.net *.split)
[22:30:25] --> edheldil has joined #GemRb
[22:30:25] --> Maighstir_laptop has joined #GemRb
[22:30:25] --> cfchris6_ has joined #GemRb
[22:30:25] --> Nomad010 has joined #GemRb
[22:30:25] --> barraAway has joined #GemRb
[22:30:25] --> tomprince_loki has joined #GemRb
[22:30:25] --> Gekz_ has joined #GemRb
[22:30:25] --> tomprince has joined #GemRb
[22:30:25] --> |Cable| has joined #GemRb
[22:30:25] --> anji has joined #GemRb
[22:30:25] --> fuzzie has joined #GemRb
[22:30:25] --> Lightkey has joined #GemRb
[22:30:25] --> wjp has joined #GemRb
[22:30:25] --> CIA-43 has joined #GemRb
[22:30:25] --> xrogaan has joined #GemRb
[22:40:29] <-- exultbot has left IRC (signing off...)
[22:42:16] --> exultbot has joined #GemRb
[22:42:16] --- Topic for #GemRb is: GemRB 0.6.0 | http://gemrb.sf.net | Be wary of your words for there are Modron sensors in this channel: http://log.usecode.org/gemrblog.php | Hey <CHARNAME>, we need some awesome screenshots!
[22:42:16] --- Topic for #GemRb set by lynxlynxlynx at Tue Nov 3 16:51:03 2009
[22:43:28] <fuzzie> i'm not seeing thefull regression from any of your patches.
[22:43:49] <fuzzie> they make it slower, of course, but presumably the root cause is in the game logic.
[22:47:09] <fuzzie> Resolving directory paths only once would be a huge improvement, I think.
[22:48:38] <fuzzie> (how on earth would changing strncpy from _MAX_PATH to 8 help, anyway!?)
[22:48:51] <fuzzie> Maybe time to stop looking and come back in the morning.
[22:49:33] <fuzzie> Oh ugh, strncpy *pads the string*?
[22:50:00] <tomprince_loki> That would do it.
[22:50:48] <tomprince_loki> I agree, ugh.
[22:53:12] <tomprince_loki> A std::string would be faster.
[23:03:49] --> raevol has joined #GemRb
[23:04:36] <fuzzie> Well, some sensible copying would be even faster :)
[23:05:44] <fuzzie> The strncpy and ResolveFilePath attempting to resolve the whole path each time would seem to account for most.
[23:07:28] <fuzzie> No wonder running gemrb from ntfs-3g has been slow.
[23:07:46] <tomprince_loki> or.cz/for-fuzzie has a patch with std::string that fixes the strncpy.
[23:08:02] <tomprince_loki> And the extra fopen.
[23:08:31] <fuzzie> I think using std::string would add a heap allocation every time, which is maybe not so good..
[23:17:13] <fuzzie> SearchIn is called 12k times by the time this game loads, FindIn is called 32k times.
[23:18:26] <fuzzie> (not trying to make a point, just thought i'd measure it.)
[23:19:14] <tomprince_loki> Scary.
[23:28:05] <edheldil> good night
[23:32:51] <-- edheldil has left IRC (Ping timeout: 276 seconds)
[23:52:42] <tomprince_loki> Actually, the right fix is probably to have a PathJoin that takes an extension.
[23:59:37] <-- cfchris6_ has left IRC (Ping timeout: 248 seconds)