#gemrb@irc.freenode.net logs for 11 May 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[01:18:56] <-- |Cable| has left IRC (Remote host closed the connection)
[01:20:19] --> |Cable| has joined #gemrb
[04:35:27] --> Bo_Thomsen has joined #gemrb
[04:53:55] <-- tomprince has left IRC (Ping timeout: 250 seconds)
[04:54:02] <-- gembot has left IRC (Ping timeout: 248 seconds)
[04:57:46] --> tomprince has joined #gemrb
[05:29:46] <-- tomprince has left IRC (Ping timeout: 248 seconds)
[05:34:11] --> tomprince has joined #gemrb
[06:01:36] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[07:03:56] --> lubos has joined #gemrb
[07:12:15] --> test32894789234u has joined #gemrb
[07:18:31] --> adominguez has joined #gemrb
[07:41:14] --> SiENcE has joined #gemrb
[07:55:05] --> mihairu has joined #gemrb
[08:00:22] --> lynxlynxlynx has joined #gemrb
[08:00:22] --- ChanServ gives channel operator status to lynxlynxlynx
[08:29:24] <edheldil> Hi all
[08:30:14] <edheldil> perhaps good place for that dumpStats() call would be in a debugModule of GUIScript, so that you could easily invoke it from a console
[08:30:31] <fuzzie> but for which one of some hundreds? :P
[08:32:27] <fuzzie> in any case, it needs to be compiled out by default
[08:46:48] <-- mihairu has left IRC (Remote host closed the connection)
[08:49:46] --> evilestmark has joined #gemrb
[08:49:51] <-- evilestmark has left IRC (Changing host)
[08:49:51] --> evilestmark has joined #gemrb
[08:50:06] <-- evilestmark has left #gemrb
[08:50:12] <-- |Cable| has left IRC (Remote host closed the connection)
[08:51:41] --> evilestmark_ has joined #gemrb
[08:51:51] <-- evilestmark_ has left IRC (Changing host)
[08:51:51] --> evilestmark_ has joined #gemrb
[08:52:14] <evilestmark_> Hello
[08:52:37] <fuzzie> hi
[08:52:46] <evilestmark_> Dunno if you can help me or not
[08:53:08] <evilestmark_> I was trying to compile the latest source for GemRB on Linux Mint Debian edition and ran into a dependency issue I didn't understand
[08:54:06] <evilestmark_> It seemed like the library needed I think libjpeg or something similar, was available is like libjpeg64 and libjpeg8, but neither satisfied the dependency
[08:55:03] <fuzzie> hm, i'm pretty sure we don't depend on libjpeg, even indirectly
[08:55:23] <edheldil> possibly sdl does
[08:55:30] <fuzzie> only sdl-image would, which we don't use
[08:57:15] <edheldil> right
[08:57:21] <evilestmark_> weird...
[08:57:23] <evilestmark_> oh
[08:57:27] <evilestmark_> it was part of the SDL dependency
[08:57:37] <evilestmark_> let me bring it up and try again
[08:58:32] <evilestmark_> sorry, compiling on a laptop... gotta boot it up
[09:00:41] <evilestmark_> right, so the cmake error is SDL not found
[09:00:45] <evilestmark_> so i went to get SDL
[09:01:48] <evilestmark_> is it libsdl1.2-dev?
[09:01:56] <fuzzie> yes
[09:02:27] <evilestmark_> right... so this depends on libdirectfb-dev which for some reason Synaptic doesnt want to resolve...
[09:02:37] <evilestmark_> so i went to manually install that...
[09:03:03] <fuzzie> Ah, right, and *that* depends on jpeg.
[09:03:05] <evilestmark_> right
[09:03:13] <evilestmark_> libjpeg-dev
[09:03:28] <evilestmark_> which... brings me back to the original problem
[09:03:37] <evilestmark_> the package doesnt seem to exist as specified..
[09:03:55] <fuzzie> 'libjpeg62-dev' is the one you want
[09:04:15] <evilestmark_> installing that will uninstall libjpeg8 and related
[09:04:24] <evilestmark_> whats the likelihood that will break my system?
[09:04:32] <fuzzie> it depends what 'related' is..
[09:04:56] <evilestmark_> oh sorry im worng, it just wants toremove libjpeg8^dev
[09:05:00] <evilestmark_> which sounds... reasonable
[09:05:08] <evilestmark_> mostly just for compilation anyway
[09:05:40] <fuzzie> i'm not familiar with synaptic, but as long as it's not removing a bunch of packages you need, you can always go back and reinstall :)
[09:05:48] <evilestmark_> right
[09:05:56] <evilestmark_> this alone shouldnt break anything
[09:05:58] <fuzzie> and we don't use libjpeg at all.
[09:06:01] <evilestmark_> i dont do a lot of compilation
[09:06:08] <evilestmark_> yeah... just funky dependency trees
[09:06:10] <fuzzie> so it really doesn't matter what's installed, from gemrb's point of view.
[09:06:31] <evilestmark_> well lets see if that fixes that..
[09:06:47] <fuzzie> hm, i should have given you the general introduction
[09:06:57] <fuzzie> which is a big "no, planescape: torment is not completeable" warning, usually
[09:07:19] <evilestmark_> haha, thats okay, i have several infinity engine games
[09:07:28] <evilestmark_> speaking of which... fallout isnt infinity is it?
[09:07:34] <fuzzie> no :(
[09:08:03] <evilestmark_> im hoping ill be able to run BG at least as well as I can on my buggy unupdatable windows machine...
[09:08:11] <evilestmark_> which crashed it every half hour
[09:08:22] <fuzzie> usually, it is much better under wine, on x86/x64
[09:08:33] <fuzzie> most gemrb users are on mobile phones, tablets, etc
[09:09:03] <evilestmark_> ah, well, its worth giving it a spin anyway
[09:09:08] <evilestmark_> im excited about the project
[09:09:30] <evilestmark_> planescape torment is possibly my favorite game of all time, and I support any and all efforts to get that working on Linux
[09:09:36] <evilestmark_> flawlessly
[09:10:33] <evilestmark_> also, so far this is one of the easiest builds ive ever done...
[09:10:35] <evilestmark_> props for that
[09:11:20] <fuzzie> we try to keep it easy so that people can build it for their various handheld devices easily, and it seems to work :)
[09:11:49] <evilestmark_> have you had anyone try it on the open pandora?
[09:13:07] <fuzzie> there was a port, mentioned on the pandora website
[09:13:20] <fuzzie> our usual expert at keeping track is pupnik, who has not been around recently unless I am blind
[09:14:52] <evilestmark_> ah, that is another project im fairly excited abou
[09:15:08] <evilestmark_> build completed successfully, now I just need to configure and install some gamers
[09:15:35] <fuzzie> i see a thread on gp32x pandora forums hoping for PST support, heh
[09:15:39] <edheldil> pupnik is often in #maemo, but not atm
[09:17:37] <evilestmark_> yeah, what can you say? It was a brilliant game
[09:17:58] <evilestmark_> I'm impressed at the lifespan of GemRB
[09:18:03] <evilestmark_> projects like this often die out
[09:18:12] <evilestmark_> looks like youve been going for 5ish years
[09:18:47] <fuzzie> i think it's been about 7.5 years now
[09:20:14] <evilestmark_> a good sign
[09:20:17] <fuzzie> with Avenger and edheldil having been around for most of that time, and wjp for 5.5 or so
[09:20:30] <evilestmark_> I wish I had more hacker skills
[09:20:49] <evilestmark_> I'd love to help, but I am not much better than a script kiddie when it comes to any serious programming
[09:21:07] <evilestmark_> thus... hopefully I can help test
[09:21:51] --> Beh0lder has joined #gemrb
[09:24:23] <Beh0lder> Hi all. Yesterday I didn't wait for an answer, gone to sleep. Anything fixed from my buglist?
[09:24:37] <fuzzie> i think not for bg1
[09:24:53] <fuzzie> for bg2, it works fine for me
[09:25:18] <edheldil> evilestmark_: there are other things you could do. Write docs, design some simple free dataset for testing purposes, redesign our webpages ...
[09:27:39] <Beh0lder> Nalya quest fixed too?
[09:27:50] --> mihairu has joined #gemrb
[09:28:18] <fuzzie> i couldn't make the Nalia quest not work
[09:28:27] <fuzzie> so maybe i'm reproducing it wrong
[09:29:03] <Beh0lder> OK, thanks
[09:29:47] <Beh0lder> I plan to make a new build for the android.
[09:30:27] <fuzzie> i am busy recently, so no time to check a lot
[09:30:35] <fuzzie> but dhewg made loading games a lot faster in git
[09:34:09] <Beh0lder> I know. Works great. I have already built a new version, but not released it in Market.
[09:35:11] <edheldil> the maemo port is not really usable
[09:35:21] <edheldil> at least for me
[09:35:34] <Beh0lder> why?
[09:35:41] <Beh0lder> small screen?
[09:35:50] <fuzzie> it doesn't have the scroll stuff?
[09:36:25] <edheldil> well, that was expected ... but I can't scroll with mouse, because it does not allow me to get to the edge
[09:36:49] <edheldil> something like Android's fat edges would be handy
[09:36:58] <fuzzie> i had great trouble talking to any of the maemo people
[09:37:40] <edheldil> and kb scrolling does not work either, because on CZ keyboard the up/down keys use Sym modifier whioch is ignored
[09:37:41] <Beh0lder> adding -DTOUCHSCREEN flag for make set scrolling same as in Android
[09:38:20] <Beh0lder> I think it should work on maemo
[09:38:43] <edheldil> what should? The flag?
[09:40:15] <Beh0lder> If this flag is set GemRB use my code for scrolling and draws gray lines for scroll areas
[09:40:32] <Beh0lder> it is not android-specific
[09:41:09] <Beh0lder> this feature should work on all touchscreen devices
[09:48:53] <evilestmark_> edheldil: If I can get everything running once, I'll probably be encouraged to help out somehow
[09:49:26] <evilestmark_> right now I'm installing BG1 in wine because the automagical installer doesnt know about my DVD version
[09:57:28] <-- mihairu has left IRC (Remote host closed the connection)
[10:00:30] <edheldil> evilestmark_: it's also well doable to install it by hand
[10:13:42] <evilestmark_> aye, it ran BG1
[10:13:45] <evilestmark_> sort of :-P
[10:14:03] <evilestmark_> lots of problems right off the bat, might just have to do with configuration though
[10:14:34] <evilestmark_> In fact... almost certainly not finding the data files correctly
[10:14:49] <evilestmark_> since it didnt load audio, and couldnt find backgrounds, but loaded my save perfectly
[10:15:05] <evilestmark_> ill have to look at it more carefully later
[10:26:41] <lynxlynxlynx> don't forget to edit the config
[10:26:56] <lynxlynxlynx> GameType and GamePath being the most prominent
[10:27:13] <evilestmark_> interestingly... it worked perfectly on the second save, except no audio
[10:27:20] <evilestmark_> i guess my first save was corrupt
[10:27:48] <evilestmark_> increased resolution supported?
[10:27:58] <fuzzie> if you widescreen mod the data files
[10:28:12] <evilestmark_> right
[10:28:47] <-- SiENcE has left IRC (Quit: @all: cya)
[10:28:48] <evilestmark_> if i can get the audio working this will be at least as functional if not more so than the wine instal
[10:29:19] <fuzzie> the audio is using openal
[10:33:05] <evilestmark_> yeah... which i have installed
[10:33:15] <evilestmark_> im not 100% whats not happening there
[10:34:56] <evilestmark_> i dont need openal-dev for the build process though right?
[10:35:12] <evilestmark_> just for runtime
[10:35:38] <fuzzie> i think you probably need it during the build
[10:36:06] <fuzzie> you can set the AudioDriver in the config file to 'SDLAudio', but it is inferior (no ambient sounds)
[10:37:00] <evilestmark_> oh... i can rebuild it i guess
[10:37:05] <evilestmark_> can i just make clean?
[10:38:55] <fuzzie> which build system did you use?
[10:41:51] <evilestmark_> cmake then make
[10:42:06] <fuzzie> then re-run cmake :)
[10:42:11] <evilestmark_> oh
[10:42:12] <evilestmark_> ok
[10:42:16] <evilestmark_> ive never used cmake before...
[10:42:22] <fuzzie> it will rebuild whatever's required itself
[10:42:25] <evilestmark_> the last time i did any compiling was when I was developing muds
[10:42:29] <fuzzie> i mean, if you run 'make' afterwards
[10:44:22] <evilestmark_> thanks for the running assistance, really appreciated
[10:44:45] <evilestmark_> if only you could get support like this for every open source project, let alone every piece of software
[10:51:45] <evilestmark_> Weird... it says it found the music file for background music of the map but still no audio...
[10:52:16] <evilestmark_> which i take to mean it's not a problem with file path configuration... but something going wrong with my actual audio configuration
[10:52:42] <evilestmark_> I've tried openal as well as sdlaudio both with no luck... I have all the volumes uncommented and at 100%
[10:53:07] <fuzzie> but no complaining errors on console?
[10:53:19] <evilestmark_> nothing I can pinpoint as being audio related...
[10:53:25] <fuzzie> and no sounds when clicking buttons, i guess
[10:53:37] <evilestmark_> i get a bunch of random errors here and there, yeah no audio from this program whatsoever
[10:54:05] <fuzzie> yeah, the sound errors will be obvious as sound errors, i think
[10:54:20] <evilestmark_> lemme scan through it agai
[10:54:38] <fuzzie> or as complaints about NOT FOUND whenever you click anything and it can't find the sound
[10:54:58] --> mihairu has joined #gemrb
[10:55:00] <evilestmark_> what are the file types associated with audio?
[10:56:00] <tomprince> Is the openal plugin being properly loaded?
[10:56:01] <evilestmark_> Default TOT didnt load, thats the most glaring thing...
[10:56:25] <evilestmark_> does that happen immediately after the program is started?
[10:56:33] <fuzzie> yes, first thing
[11:00:14] <evilestmark_> doesnt give me any errors about it
[11:00:20] <evilestmark_> WMAPLAY doesnt load
[11:00:25] <evilestmark_> is that relevent?
[11:00:33] <tomprince> Does it say it is loaded?
[11:01:01] <fuzzie> [PluginMgr]: Loading: ./gemrb/plugins/OpenALAudio.so... OpenAL Audio Driver...[OK]
[11:01:04] <fuzzie> ^- you're looking for this
[11:03:13] <evilestmark_> so its during the plugin loading
[11:03:18] <evilestmark_> i dont think its there... lemme recheck
[11:04:17] <evilestmark_> tis not loading
[11:04:34] <evilestmark_> but i also dont have a failure to load message
[11:04:46] <fuzzie> maybe you didn't install? :)
[11:04:47] <evilestmark_> just nothing about OpenALAudio.so at all
[11:04:56] <tomprince> Then it isn't being built. (or installed)
[11:05:00] <fuzzie> i mean, if you did the first time and not the second
[11:05:07] <evilestmark_> oh
[11:05:12] <evilestmark_> this could be a big face palm
[11:07:05] <evilestmark_> hey guys what guys!
[11:07:09] <evilestmark_> guess*
[11:07:21] <evilestmark_> you're angels! and you beat Wine in terms of making this work!
[11:07:25] <evilestmark_> hehe
[11:07:46] <evilestmark_> yeah, i failed to run make install... the 2nd time
[11:07:53] <evilestmark_> i'm a compiler newbie
[11:07:59] <evilestmark_> thanks for bearing with me
[11:09:14] <tomprince> np
[11:23:51] <evilestmark_> is gemrb supposed to reset your original display resolution after exiting full screen?
[11:24:18] <fuzzie> well, SDL is meant to do it
[11:24:33] <evilestmark_> haha, meant to, ey...
[11:24:44] <evilestmark_> so im just encountering an issue with SDL
[11:26:15] <edheldil> but if gemrb crashed, the resolution might be screwed. Or perhaps due to combination of wine and notebook suspend
[11:26:37] <edheldil> xrand -s ..... to your rescue
[11:26:41] <edheldil> xrandr
[11:28:36] <edheldil> we are a newbie friendly channel :)
[11:30:26] <evilestmark_> aye, its amusing though that I consider myself a newbie... most people I talk to on a daily basis don't know what the word compiler means.
[11:30:40] <evilestmark_> everything in life is relative...
[11:31:33] <edheldil> don't worry, after few gemrb bugreports you will be a pro :)
[11:31:33] <evilestmark_> I'm going to go get some beer, imbibe it, and chill out... too much time spent on a computer today. Thanks again everyone for all the help.
[11:31:46] <evilestmark_> I'll probably be back
[11:31:46] <evilestmark_> hehe
[11:31:48] <edheldil> you are welcome
[11:32:04] <-- evilestmark_ has left #gemrb
[11:34:03] --> SiENcE has joined #gemrb
[12:15:20] <edheldil> list of gsoc projects is an interesting read
[12:16:17] <-- Beh0lder has left #gemrb
[12:28:10] <edheldil> somebody took porting GIMP to GEGL as a GSOC :-D
[12:30:02] --> gembot has joined #gemrb
[12:31:02] --> Beh0lder has joined #gemrb
[12:41:01] <tomprince> cia is down.
[12:46:05] <gembot> build #145 of msvc++6 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/145
[12:46:06] <gembot> build #145 of msvc++6 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/145
[13:13:00] <-- Beh0lder has left #gemrb
[14:29:36] <fuzzie> sheesh, original engine is really bad with bags
[14:31:48] <wjp> in which sense?
[14:33:44] <fuzzie> it's slow
[14:33:48] <fuzzie> anyone want to guess why? :P
[14:53:00] <lynxlynxlynx> edheldil: it already supports it for some ops
[14:56:10] <edheldil> lynxlynxlynx: maybe, but migration to gegl has ben planned for YEARS
[14:57:19] <edheldil> at least I hope he meant GEGL composition nodes or whatever it's called
[15:11:45] --> Maighstir has joined #gemrb
[15:15:18] <wjp> fuzzie: I think I can safely say "no" to that after 40 minutes :-)
[15:17:02] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[15:18:12] <fuzzie> wjp: it's doing the same as gemrb was, opening the STO files on every single check
[15:18:17] --> Maighstir has joined #gemrb
[15:18:47] <fuzzie> i had Process Explorer capture my click on Caspenar, while I had 2 bags of holding, 5 gem bags, 3 potion bags, 5 scroll bags, etc
[15:24:41] <-- lubos has left IRC (Quit: Leaving.)
[15:32:14] --> Bo_Thomsen has joined #gemrb
[15:56:50] <dhewg> heh :)
[16:05:17] <-- lynxlynxlynx has left IRC (Ping timeout: 252 seconds)
[16:16:48] --> lynxlynxlynx has joined #gemrb
[16:16:48] <-- lynxlynxlynx has left IRC (Changing host)
[16:16:48] --> lynxlynxlynx has joined #gemrb
[16:16:48] --- ChanServ gives channel operator status to lynxlynxlynx
[16:24:30] <-- SiENcE has left IRC (Quit: @all: cya)
[17:13:49] <-- adominguez has left IRC (Quit: Saliendo)
[17:25:49] --> |Cable| has joined #gemrb
[17:34:41] --> budlust has joined #gemrb
[17:39:44] --> budlust_ has joined #gemrb
[17:42:23] <-- budlust has left IRC (Ping timeout: 240 seconds)
[17:48:39] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[17:49:09] <CIA-52> GemRB: 03tom.prince * rdb2ca27a3b78 10gemrb/gemrb/includes/ (HashMap.h StringMap.h):
[17:49:09] <CIA-52> GemRB: Clean up HashMap.
[17:49:09] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[17:49:35] <CIA-52> GemRB: 03dhewg * r002bc22efd4e 10gemrb/gemrb/includes/ (HashMap.h StringMap.h):
[17:49:35] <CIA-52> GemRB: CORE: Add a HashMap template
[17:49:35] <CIA-52> GemRB: Based on the Cache.cpp/Dictionary.cpp/Variables.cpp implementation.
[17:49:35] <CIA-52> GemRB: Comes with a hash implementations for std::string and fixed char
[17:49:35] <CIA-52> GemRB: arrays.
[17:50:35] <tomprince> That took a long time to show up...
[17:50:45] <Gekz> it was waiting for the right time
[18:14:51] <dhewg> ah, nice :)
[18:14:55] <tomprince> dhewg: do you have numbers for anything other than your chosen table size?
[18:16:17] <dhewg> not really, i was playing with the hash function itself combined with the table size
[18:16:27] <dhewg> that just looked okay
[18:17:20] <dhewg> the 4k dir thing was just chosen as a limit, as users could add whatever they wanted
[18:18:27] <dhewg> i think the original key table was not limited, i used 32k just because there're so many empty buckets and the bucket lenghts are still ok
[18:21:59] <dhewg> the distribution was fine with most random numbers i tried, iirc the "interesting" ones are the bg2 override folder with the fixpack (+4k entries) and of course the keyimporter map
[18:23:54] <tomprince> It wouldn't be a bad idea to include numbers for a large and smaller table size in the comments.
[18:24:34] <tomprince> Also, does the primality of the hash function have any effect? If you don't know, that is fine. Just curious.
[18:25:52] <dhewg> no, i didnt check that
[18:26:36] <dhewg> what i tried is to make the bucket size a power of 2, so the expensive "%" can go, but that really sucks for the distribution
[18:29:43] <tomprince> That makes sense.
[18:33:14] <-- budlust_ has left IRC (Ping timeout: 260 seconds)
[18:34:11] --> budlust has joined #gemrb
[18:38:24] <-- budlust has left IRC (Client Quit)
[18:41:17] <tomprince> fuzzie: Is there any reason at all that BIF and SAV file handling is in the same plugin? The file formats seem completely different, and they share no implementation.
[18:50:48] <-- Dark-Star has left IRC ()
[18:51:40] --> Avenger has joined #gemrb
[18:51:46] <Avenger> hi
[18:51:52] <tomprince> hello.
[18:52:03] <Avenger> bucket size: prime number, preferably something close to 2^x
[18:52:26] <fuzzie> yes, hence dhewg's comment :p
[18:52:27] <fuzzie> hi Avenger
[18:53:09] <Avenger> anyone made some performance tests?
[18:53:57] <fuzzie> well, we're not actually using it yet
[18:54:18] <fuzzie> but dhewg has a bunch of debug stats in there for testing
[18:54:46] <Avenger> ok :)
[18:54:55] <fuzzie> i'm a bit too busy to pay attention
[18:54:59] <dhewg> yeah, its fun to play and watch :)
[18:55:02] <Avenger> i'm still busy at work, looks like it will be so until the end of summer
[18:55:06] <fuzzie> so honestly i said, make it work, and we can always fix it or remove it
[18:55:56] <fuzzie> tomprince: moving the SAV stuff wholesale to another plugin seems sensible
[18:56:36] <tomprince> That is what I am doing. And moving the BIF stuff into KEYImporter.
[18:56:53] <fuzzie> well
[18:57:04] <fuzzie> the BIF stuff comes with the standard disclaimer from the last few weeks, obviously :P
[18:57:20] <fuzzie> but as long as the SAV stuff stays in the one .cpp file, i don't think it makes any sense to have it with the BIF code
[18:57:29] <Avenger> i hope someone is adding new stuff too
[18:57:55] <fuzzie> phft, why add new stuff when you can just repeatedly break the code :-p
[18:58:04] <tomprince> :P
[18:58:05] <Avenger> exactly that...
[18:58:13] * wjp is just rewriting old stuff too...
[18:58:13] <fuzzie> i have some time tomorrow, hopefully will get some real stuff committed ;p
[18:58:24] <Avenger> besides wjp's dream/timestop fading i saw no visible new stuff
[18:58:26] <fuzzie> wjp: you added black+white and sepia tinting!
[18:58:35] <Avenger> yes, that's fun :D
[18:58:45] <fuzzie> Avenger: well, new since when? :)
[18:58:52] <Avenger> last version
[18:58:55] <fuzzie> we made ToB completeable..
[18:59:13] <Avenger> what exacltly that involved? script fixing?
[18:59:20] <fuzzie> scripts and 0xe8
[18:59:28] <Avenger> i don't want to diminish that :D 0xe8 was nice with the triggers
[18:59:34] <Avenger> but you... broke traps
[18:59:37] <fuzzie> hehe
[18:59:40] <fuzzie> yes, that was dumb
[19:00:03] <fuzzie> i did test them, because they needed svtriobj
[19:00:22] <fuzzie> oh, and we don't corrupt stores any more :P
[19:00:33] <Avenger> oh and the bag lookup
[19:00:41] <Avenger> yes, the bag lookup fix was definitely nice
[19:00:46] <-- test32894789234u has left #gemrb
[19:00:59] <fuzzie> the stores got a lot of work from me, stacking and GUI and etc
[19:01:34] <Avenger> can you now buy/sell multiple items now?
[19:01:41] <Avenger> like a bunch of gems
[19:01:41] <fuzzie> and squirrels no longer die, and item text isn't cut off in descriptions, and we don't destroy all variables on global actors
[19:01:57] <fuzzie> not unless they're in a stack - we should really fix that
[19:02:00] <Avenger> hmm, how did you fix the small hp critters?
[19:02:18] <fuzzie> they no longer get a negative bonus from CON :P
[19:02:32] <Avenger> shouldn't they get it?
[19:02:35] <fuzzie> nope
[19:02:45] <Avenger> hmm
[19:03:02] <fuzzie> i checked in original a bit, only the PC-type classes get the CON bonus
[19:03:09] <Avenger> ooh
[19:03:16] <fuzzie> i haven't checked the disasm though, feel free to do so
[19:03:25] <Avenger> well...
[19:03:40] <Avenger> this is something surely hidden by some flag
[19:03:44] <Avenger> or whatever
[19:04:01] <Avenger> it makes sense, i just couldn't figure out the rule when to apply the con bonus
[19:04:34] <Avenger> and it was always wrong whatever i did (apply/not apply it)
[19:05:06] <fuzzie> well, maybe it's still wrong, but i don't see anywhere that's visible :)
[19:05:21] <Avenger> well, the con bonus is really class specific
[19:05:30] <Avenger> so, it makes sense it is ignored for non player classes
[19:06:02] <Avenger> when i'm back in windows, i might check this
[19:06:24] <fuzzie> mostly i am just ignoring all of the stats stuff
[19:06:44] <fuzzie> i have 'fix encumbrance' on my todo list, right now gemrb sets IE_ENCUMBRANCE to weight, instead of 0/1/2
[19:07:21] <Avenger> it is 0/1/2 in original?
[19:07:26] <fuzzie> yes
[19:07:44] <fuzzie> 0 is not encumbered, 1 is slowed, 2 is can't move
[19:08:08] <Avenger> well, we have few stats, maybe some need to be converted into internal variables. Those that are accessible by other scripting triggers/actions
[19:08:19] <fuzzie> it is a stat in original, so must stay that way
[19:08:24] <Avenger> yes, i know it is
[19:08:34] <Avenger> but encumbrance is a nice thing to have
[19:08:39] <Avenger> i mean, the weight
[19:08:42] <fuzzie> sure
[19:08:47] <tomprince> https://github.com/tomprince/gemrb/commit/sav
[19:09:27] <fuzzie> tomprince: maybe don't include the irrelevant changes?
[19:09:43] <fuzzie> difficult for me to follow, i mean
[19:10:15] <tomprince> There isn't?
[19:10:43] <fuzzie> i mean, you remove a bunch of BIFImporter stuff and change it to Held and add random structs in SAVImporter
[19:11:21] <gembot> build #126 of autotools g++-4.4.5 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.4.5/builds/126 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:11:21] <gembot> build #126 of autotools g++-4.4.5 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.4.5/builds/126 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:11:30] <tomprince> the only irrelvent bit is the structs.
[19:11:32] <tomprince> gembot:mute
[19:11:33] <gembot> Shutting up for now.
[19:11:34] <fuzzie> well
[19:11:36] <fuzzie> no
[19:11:51] <fuzzie> i mean, i am going by "Split BIFImporter and SAVImporter"
[19:12:13] <gembot> build #125 of autotools g++-4.2.4 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.2.4/builds/125 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:12:32] <tomprince> Splitting them implies splitting the base class.
[19:12:36] <fuzzie> yes
[19:12:39] <fuzzie> but you haven't done that
[19:13:02] <fuzzie> which i can understand, if you don't want to bother with a base class for BIFImporter at all..
[19:13:04] <gembot> build #129 of cmake g++-4.4.5 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4.5/builds/129 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:13:11] <-- gembot has left IRC (Quit: buildmaster reconfigured: bot disconnecting)
[19:13:36] --> gembot has joined #gemrb
[19:14:00] <fuzzie> but that's a bit of a bigger change than just splitting them
[19:14:28] <tomprince> Part of it is I didn't know a good name for the BIF base class. :)
[19:14:42] <fuzzie> shouldn't the BIF base class be ArchiveImporter?
[19:14:54] <tomprince> I think SAV is closer to an archive.
[19:15:03] <fuzzie> seems like the SAV stuff is really a SaveGameImporter, at the moment
[19:15:20] <gembot> build #127 of cmake g++-4.5.2 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.5.2/builds/127 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:15:20] <gembot> build #127 of cmake g++-4.5.2 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.5.2/builds/127 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:15:35] <-- CIA-52 has left IRC (Ping timeout: 252 seconds)
[19:15:37] <tomprince> gembot:mute
[19:15:38] <gembot> Shutting up for now.
[19:15:56] <-- CIA-66 has left IRC (Ping timeout: 276 seconds)
[19:16:19] <gembot> build #113 of mingw32 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/113 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:17:05] <tomprince> Well, I am just looking at the structure of the file. And it looks like we could replace SAV by any archive format. Which isn't true of bif.
[19:17:11] <gembot> build #124 of autotools g++-4.6.0 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.6.0/builds/124 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:17:17] <fuzzie> sure
[19:17:29] <fuzzie> i haven't really thought about whether it needs a base class
[19:18:20] <fuzzie> just that doing it like this is a split plus a refactor in one commit, and i don't have time to ponder it right now
[19:18:40] <gembot> build #147 of msvc++6 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/147 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:19:00] <gembot> build #124 of autotools g++-4.5.2 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.5.2/builds/124 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:19:10] <tomprince> gembot: mute
[19:19:55] <tomprince> Do you have any idead of a name for the base class of BIFImporter (given that SAVImporter get ArchiveImporter?)
[19:20:12] <fuzzie> i don't agree with SAVImporter getting ArchiveImporter, anyway :P
[19:20:31] <fuzzie> at least, not in the state it's in
[19:21:19] <tomprince> Well, I thought of cleaning up its state ... but you would have been even more unhappy if I did that at the same time ;)
[19:21:50] <fuzzie> well, yes, small steps good :P
[19:22:02] <fuzzie> but as usual i think the small steps might be better off from the other direction here
[19:22:29] <Avenger> bye!
[19:22:31] <-- Avenger has left IRC (Quit: bye!)
[19:25:54] <fuzzie> would also be nice to get the HashMap finished
[19:26:06] <fuzzie> and maybe i really should remove the BIF cache to stop us from building more stuff on top of it
[19:26:56] <tomprince> Well, I was thinking of changing the BIFs so that we keep the hash table, but not the file open.
[19:27:25] <fuzzie> we probably should keep the files open though :-/
[19:27:58] <fuzzie> also, what's the memory cost there? let me check
[19:28:31] <fuzzie> oh, i probably can't tell, since the BIFImporter isn't kept open
[19:29:23] <dhewg> did i mention how the ex dumpStats() in the destructor painted a picture that keeping multiple bifs around might make sense?
[19:29:29] <fuzzie> the KEYImporter is currently using about 2mb, which is absurd now i look at it
[19:29:39] <fuzzie> what on earth
[19:30:03] <dhewg> its probably the array
[19:30:10] <fuzzie> it is indeed the array
[19:30:22] <dhewg> its ~1.2mb with a 32k hashmap
[19:30:27] <fuzzie> not the hashmap
[19:30:41] <dhewg> i know, but the struct there has unused fields
[19:30:46] <dhewg> so its more that the hashmap
[19:31:04] <tomprince> path[_MAX_PATH]
[19:31:29] <fuzzie> that is 4096 here, though
[19:31:43] <fuzzie> which should surely not be making the vector take more than 1mb
[19:32:43] <fuzzie> huh, I guess 182 BIF files * that size = 750k already
[19:32:45] <fuzzie> sheesh
[19:34:17] <dhewg> but it wouldnt have 182 entries in there, would it?
[19:34:28] <fuzzie> it would
[19:34:32] <dhewg> i think it adds the ones that get opened
[19:34:46] <fuzzie> they all get added at startup
[19:35:47] <fuzzie> well, i guess fixing that is an obvious gain, then
[19:36:03] <fuzzie> your hashmap in KEYImporter is ~1.2mb total?
[19:36:22] <dhewg> something like that
[19:36:24] <fuzzie> it is 850k with Dictionary, as a reference
[19:36:30] <dhewg> for the ~48k bg2 chitin.key
[19:37:01] <dhewg> huh
[19:37:09] <dhewg> that 1.2mb is from my dumpstats
[19:37:12] <fuzzie> might be worth looking at? but clearly we can gain the difference back by doing a dynamic alloc for the path
[19:37:25] <fuzzie> well, ok, i am looking at actual malloc :P
[19:37:28] <dhewg> it uses sizeof() and comes from a 64bit host
[19:37:33] <fuzzie> ah!
[19:37:36] <dhewg> so maybe we cant compare that
[19:37:40] <fuzzie> yes
[19:37:45] <fuzzie> i am looking at it on 32bit, of course
[19:38:05] <dhewg> and maybe my dumpstats isnt 100% accurate :)
[19:38:20] <dhewg> i just add the obvious stuff
[19:38:36] <fuzzie> *nod*
[19:38:41] <fuzzie> well i am still avoiding it
[19:45:44] <dhewg> hehe
[19:46:04] <dhewg> well once you try it let me know how the numbers compare then
[19:46:19] <dhewg> curious how much it differs
[19:46:49] <gembot> build #131 of cmake g++-4.6.0 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.6.0/builds/131 blamelist: Tom Prince <tom.prince@ualberta.net>
[19:47:52] <-- gembot has left IRC (Quit: buildmaster reconfigured: bot disconnecting)
[20:01:54] <tomprince> fuzzie: better? https://github.com/tomprince/gemrb/commit/sav
[20:02:48] <fuzzie> well, like i said, i think ArchiveImporter is a silly name for the SAV thing
[20:03:16] <tomprince> :)
[20:03:19] <fuzzie> but sure, much better
[20:03:36] <fuzzie> names can always be changed trivially enough
[20:10:46] <wjp> hm, interesting. I seem to have caused half the horizontal lines of the sprites to disappear
[20:10:55] <wjp> it's much faster this way, though ;-)
[20:11:41] <dhewg> just slap a "tv scanline mode" sticker on it :)
[20:20:31] <wjp> grrr, and now sprites disappear half the time. (Still much faster :-) )
[20:21:19] <wjp> all these rectangles are driving me crazy... pitched screen, screen, cover, clip, sprite, and then with 4 possible x/y flips
[20:28:47] <tomprince> https://github.com/tomprince/gemrb/compare/13048de1...bif
[20:31:17] <tomprince> Seems noticably faster.
[20:32:42] <tomprince> Although the speedup seems independent of the BIF hashing.
[20:34:06] <fuzzie> but you're trying it on a local native filesystem, presumably
[20:34:21] <fuzzie> anyway
[20:34:39] <fuzzie> NACK because it breaks stuff, obviously
[20:36:56] --> Bo_Thomsen has joined #gemrb
[20:37:53] <tomprince> Well, first you say we should keep the files open. Then when I do, you nack it. Clearly you have some more refined idea of what should happen.
[20:38:09] <fuzzie> no
[20:38:14] <fuzzie> ok, new plan
[20:38:25] <fuzzie> i mean
[20:38:40] <fuzzie> we should keep BIFs open while we might be using them
[20:39:07] <fuzzie> but the inherently broken nature of that most-recently-used thing seems to be escaping everyone
[20:43:18] <fuzzie> ok, i removed it.
[20:44:51] <fuzzie> the trouble is, what happens if a BIF is deleted from underneath the code? even with the existing cache, it doesn't cope.
[20:45:00] <fuzzie> but i discussed this some few times in the last few days and i figured you'd seen it too
[20:45:42] <tomprince> Yes, but if we keep the file open, so it isn't broken. That was I suggested keeping just hash table open.
[20:45:58] <fuzzie> yes
[20:46:08] <fuzzie> i mean, we don't keep the file open
[20:46:32] <fuzzie> because the BIF code is re-opening it again on access, right?
[20:46:56] <tomprince> Ah, yes.
[20:46:57] <fuzzie> and keeping the hash table open would work for now, but we should really come up with a non-hackish solution for this, which is why i removed my hack
[20:49:06] <fuzzie> btw, as far as i can tell, the only useful target for all the performance optimisation is devices with a limited-space cache on FAT anyway
[20:49:31] <fuzzie> and i wouldn't rely on stuff like google's crazy FUSE layer to obey unlink semantics
[20:58:06] <lynxlynxlynx> better performance -> lower power usage
[20:58:30] <fuzzie> well, i should say, these kind of performance optimisations
[20:59:45] <dhewg> what do you mean by re-opening on access? if you keep the bif instance the slicedstream clone is only thing doing that, right?
[20:59:55] <fuzzie> dhewg: yes
[21:00:01] <fuzzie> dhewg: but if the BIF is gone in the meantime, that's not going to work
[21:00:08] <dhewg> yeah, i know
[21:00:14] <fuzzie> that's all i meant though
[21:00:21] <dhewg> but wasnt the thing that gemrb doesnt delete it atm?
[21:00:30] <fuzzie> yes
[21:00:48] <fuzzie> and i really really don't want stuff building on top of that, considering how bad it is
[21:00:58] <dhewg> hehe yeah, i remember
[21:01:00] <fuzzie> so i removed my version and shall continue flailing at people trying to do it
[21:01:13] <fuzzie> imagine me waving my hands about in panic and jumping up and down
[21:01:22] <dhewg> i was just confused because tom's path as it is on top of master would work
[21:01:42] <dhewg> obviously it would be nicer to not let the cache constantly grow
[21:01:57] <tomprince> https://gist.github.com/967345
[21:02:11] <tomprince> what I was working on when you went and eleted your stuff.
[21:02:55] <fuzzie> yeah, the lastSeenCache is why i deleted it, obviously :)
[21:03:20] <fuzzie> the entry.cd thing is more interesting if it really works
[21:04:04] <dhewg> isnt it just crazy if you run gemrb with that?
[21:04:26] <tomprince> Doesn't work as well as I had hoped.
[21:04:49] <fuzzie> but i guess it doesn't really work
[21:05:10] <tomprince> On my tests it kept bouncing between CREAnim1 CREAnim and AREA????
[21:05:12] <fuzzie> because entry->cd isn't always set
[21:07:14] <fuzzie> ideally, we'd cache everything which isn't compressed, ignoring GameOnCD difficulties
[21:07:25] <lynxlynxlynx> i think it is pretty useless to care about that
[21:07:49] <fuzzie> so, if you're thinking of making BIFImporter private anyway, you could give the KEYImporter information about whether the BIF can be used in-place or not
[21:08:48] <tomprince> Or just make BIFImporter smart about keeping the stream open or not?
[21:09:47] <fuzzie> well, if you have a way to do that nicely
[21:12:37] <fuzzie> i mean, i'm not sure if this is the right approach anyway, maybe we should be doing something much smarter
[21:19:31] <fuzzie> lynxlynxlynx: care about which bit?
[21:19:42] <tomprince> Can I get rid of GameOnCD?
[21:19:50] <tomprince> That bit, I am guessing.
[21:19:54] <fuzzie> ah
[21:19:59] <fuzzie> well, it's kind of two concepts right now
[21:20:13] <fuzzie> and the "this is on really slow media" bit would be nice to keep, i don't know if we really obey it any more
[21:20:18] <lynxlynxlynx> yes
[21:20:49] <fuzzie> i don't see any point in keeping the disk-swapping, but i think you should probably ask edheldil
[21:21:32] <tomprince> But if we want if for slow media, I think maybe we want to be more agressive at caching anyway?
[21:21:33] <lynxlynxlynx> all, not just our instructions say you should do a full install and newer bundlings remove this complexity by using dvds or a single download
[21:21:54] <tomprince> Or, I guess we are, maybe.
[21:22:19] <fuzzie> yes, i thought your CacheFile stuff took over the aggressive caching
[21:24:53] <tomprince> s/GameOnCD/SlowBIFs/ ...
[21:24:57] <fuzzie> i'm not sure it's *useful*, mind
[21:26:07] <fuzzie> tomprince: i'm not sure :)
[21:27:18] <fuzzie> i mean, i think it would still be nice to keep the diskswapping as a potential feature
[21:27:29] <fuzzie> but if you can get edheldil to OK it, it can go
[21:28:14] <lynxlynxlynx> your journal has been updated
[21:28:39] * tomprince burst out laughing
[21:30:07] <fuzzie> gosh, that would be a useful thing
[21:30:18] <fuzzie> automatic quest entries for whenever something should get fixed :)
[21:32:05] <fuzzie> but simple renames of things doesn't seem like a disaster, trivial to change
[21:32:28] <tomprince> Well, I am also ripping out the GameOnCD code in KEYImporter.
[21:32:55] <fuzzie> yeah, that you should ask about i think, since edheldil has talked about it recently and i think it's his code
[21:33:37] <fuzzie> assuming it's not revertable since you're going to refactor the code around it(?)
[21:34:42] <fuzzie> also, since StringMap got merged, does it make sense to at least merge the DirectoryImporter patch to use it?
[21:35:04] <fuzzie> unfortunately i guess i screwed up a clean merge of the KEYImporter one
[21:35:27] <fuzzie> if that could be done, then i can take the msvc6 build from your buildbot and test it tomorrow, make sure it works!
[21:35:57] <fuzzie> but now i should go do stuff, will peer back for a moment a bit later
[21:36:01] <tomprince> Yes, it does.
[21:36:51] <tomprince> do you mean the mingw?
[21:36:56] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[21:37:05] <fuzzie> oh, no msvc6 binaries?
[21:37:34] <fuzzie> i am more concerned about making sure we don't add a broken HashMap everywhere which i have to revert *everything* about because it broke for Avenger
[21:37:54] <tomprince> I haven't got it set up to build them, no.
[21:38:04] <fuzzie> ok. maybe can find time to do it myself then.
[21:38:54] <tomprince> Oh, lynx disappeared. I was going to bug him about testing against real data ....
[21:39:35] <fuzzie> will probably see it in backscroll. or I will, if I finally turn out to have time..
[21:39:38] <fuzzie> but, *poof*
[21:57:05] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[21:59:07] <fuzzie> wjp: btw, good to hear you're making progress ;p
[22:13:10] <tomprince> FileCache is broken ... obviously, no one runnig master uses GameOnCD ....
[22:14:23] <fuzzie> i think expecting *any* bugs to be noticed in master is a bad idea
[22:15:03] <tomprince> This is causes error to be called.
[22:15:19] <fuzzie> i mean, you could barely do anything in master without it crashing out after your file changes
[22:15:37] <fuzzie> and no-one noticed for a week
[22:16:28] <tomprince> :)
[22:16:34] <fuzzie> but i'm pretty sure i already said that afaik, GameOnCD is broken
[22:17:24] <fuzzie> in fact, you have commented on it being broken, last year
[22:19:01] <fuzzie> what i'm remembering is from april 25th, "i doubt it has a chance of working now"
[22:19:39] <fuzzie> (re: the FileCache changes)
[22:20:23] <fuzzie> but i got distracted thinking about the Cache/temp changes since i really don't like the two being mixed, and then it got forgotten again
[22:21:15] <fuzzie> but from what i can remember, it wasn't even doing Create and i didn't understand it
[22:21:39] <fuzzie> but i figured you did since you'd rewritten from fopen :)
[22:23:27] <tomprince> No, that is broken. :)
[22:23:59] <fuzzie> but i'm pretty definitely sure the diskswapping stuff has been broken for years
[22:24:24] <fuzzie> i just know that when i mentioned it before, i think edheldil expressed interest in eventually fixing it. i think :P
[22:53:42] <tomprince> https://gist.github.com/967569