#gemrb@irc.freenode.net logs for 28 Apr 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:20:05] <CIA-52> GemRB: 03tom.prince * rea4d2b8076d9 10gemrb/gemrb/ (6 files in 2 dirs):
[00:20:05] <CIA-52> GemRB: Add basic caching of stores.
[00:20:05] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[00:20:05] <CIA-52> GemRB: 03tom.prince * rd594d1b4ee65 10gemrb/gemrb/ (10 files in 4 dirs): Merge branch 'store-cache'.
[00:20:08] <CIA-52> GemRB: 03tom.prince * rda151e81a5e1 10gemrb/gemrb/ (4 files in 2 dirs):
[00:20:08] <CIA-52> GemRB: Cleanup STOImporter.
[00:20:08] <CIA-52> GemRB: - All the private Put* functions always returned 0, so make them void.
[00:20:08] <CIA-52> GemRB: - Nobody needs the return value of GetStoredFileSize, so just make it private,
[00:20:08] <CIA-52> GemRB: and call it from PutStore.
[00:20:08] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[00:20:09] <CIA-52> GemRB: 03tom.prince * r50b5bc3df52d 10gemrb/gemrb/core/GameScript/GSUtils.cpp:
[00:20:09] <CIA-52> GemRB: Don't use CurrentStore when searching through inventory.
[00:20:10] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[00:22:34] <tomprince> Weird order for the commit to show up in.
[00:24:41] <tomprince> I only changed one use of CurrentStore. The other use wouldn't play well with having CurrentStore point at the store it is changing.
[00:24:50] <tomprince> Perhaps it does need to be held.
[00:35:49] <gembot> build #43 of mingw32 is complete: Failure [failed zip install] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/43 blamelist: tom.prince@ualberta.net
[00:35:49] <gembot> build #43 of mingw32 is complete: Failure [failed zip install] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/43 blamelist: tom.prince@ualberta.net
[00:59:02] <gembot> build #45 of mingw32 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/45
[00:59:02] <gembot> build #45 of mingw32 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/45
[01:03:22] <-- gembot has left IRC (Quit: buildmaster reconfigured: bot disconnecting)
[01:03:49] --> gembot has joined #gemrb
[01:18:34] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[05:25:53] --> ubermad has joined #gemrb
[06:52:10] <-- mihairu has left IRC (Ping timeout: 260 seconds)
[07:05:34] --- ChanServ gives channel operator status to wjp
[07:09:32] --> adominguez has joined #gemrb
[07:11:49] --> Bo_Thomsen has joined #gemrb
[07:24:17] --> lynxlynxlynx has joined #gemrb
[07:24:29] <-- lynxlynxlynx has left IRC (Changing host)
[07:24:29] --> lynxlynxlynx has joined #gemrb
[07:24:29] --- ChanServ gives channel operator status to lynxlynxlynx
[07:43:51] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[07:46:01] <fuzzie> tomprince: The only important change was the one you did, anyway. The rest rather fades into irrelevant one-time stuff. Thanks!
[07:46:29] <tomprince> np.
[07:46:51] <tomprince> The other would be good, just cause it is saner.
[07:47:59] <fuzzie> I *think* we should probably simply error() if a store is open there.
[07:48:35] --> lubos has joined #gemrb
[07:49:31] <tomprince> That would work. No reason we couldn't handle it properly.
[07:50:03] <fuzzie> I mean, I have no objection to having stuff Held, if it's useful elsewhere.
[07:50:33] <tomprince> I won't worry about it for now.
[07:56:40] <fuzzie> I'm just thinking of the one specific case I can think of. :)
[07:57:22] <tomprince> Which case?
[07:57:56] <fuzzie> The action which modifies store properties.
[07:58:17] <tomprince> That is the only other use of stores, period.
[07:59:29] <fuzzie> Well, I mean, as you asked yesterday, there seems rather likely to be some more store manipulations which gemrb doesn't implement yet, at least removing items.
[08:01:23] <edheldil> and if there is not, it might be a nice extension :-P
[08:01:30] <edheldil> morning, guys
[08:01:31] <fuzzie> That too!
[08:02:59] <fuzzie> But anything which could possibly modify the data of CurrentStore is presumably either going to need an error(), or some logic for making sure the GUI know that the store changed from under it.
[08:03:33] <fuzzie> But am not awake, possible I'm missing the obvious.
[08:03:56] <fuzzie> I doubt we've implemented pst's store stuff, to..
[08:09:31] <fuzzie> hm, it seems unused
[08:12:35] <fuzzie> no way to trigger actions from anywhere interesting either
[08:12:51] <fuzzie> there are two SetGlobal()s in the strings but they're clearly leftover notes
[08:15:25] <fuzzie> > NOTE: This is a narrative text test. Will it work? Will it be displayed in a different color than the dialog text? It would sure make me happy.
[08:16:39] <fuzzie> some of these are a little grumpy :-P
[08:17:16] <dhewg> heh, where's that from?
[08:17:33] <fuzzie> Planescape: Torment's strings list
[08:17:48] <dhewg> ah
[08:17:49] <fuzzie> (all translatable strings for GUI/dialogs/etc are in the .TLK file)
[08:18:28] <dhewg> yeah, i slowly get the picture about all the data formats and how it fits together
[08:19:17] <dhewg> its a nice start to poke at resourcemanager
[08:19:33] <fuzzie> just be very grateful tomprince got there first
[08:19:44] <dhewg> refactoring wise?
[08:19:48] <fuzzie> mmhm
[08:19:52] <dhewg> ;)
[08:20:12] <dhewg> i have an intial version of my cache dir state tracking ready
[08:20:36] <dhewg> i need to test it a little more, was getting late yesterday
[08:20:53] <dhewg> but im seeing a ~10% cpu improvement on my box
[08:21:11] <fuzzie> at startup?
[08:21:26] <dhewg> during game
[08:21:32] <dhewg> just letting the party stand there
[08:22:03] <fuzzie> that is disturbing :P
[08:22:07] <dhewg> but i guess its less than that now with the store cashing
[08:22:23] <dhewg> well, the cache dir is prio #1
[08:22:31] <dhewg> its getting poked at all the time
[08:22:50] <fuzzie> we should probably split it into cache/temp
[08:22:58] <fuzzie> but that's a different point
[08:23:31] <dhewg> well the idea with that was to keep track of all entries that go through the cache dir
[08:23:36] <fuzzie> the big performance hit for the store caching seems to have been the writing-to-disk, it's weird
[08:23:53] <dhewg> while now its only doing caching, its a no brainer to use it for savegames now
[08:23:59] <dhewg> just a flag for an entry
[08:24:08] <dhewg> same can be done with tmp stuff
[08:24:22] <tomprince> Well, we wrote to disk everytime we closed a store, so everytime we looked into one.
[08:24:25] <dhewg> and then size-limiting the cache on top of that or whatever
[08:24:57] <dhewg> but well, dunno if you want to have such a change :P
[08:25:04] <fuzzie> i haven't looked at it
[08:25:11] <fuzzie> so no opinion yet :P
[08:25:22] <dhewg> yeah, its not really done yet, some cleanup and testing is missing
[08:25:34] <dhewg> should i push it so you guys can look at it?
[08:25:39] <fuzzie> i have no immediate objection to something which will make I/O faster
[08:25:44] <tomprince> won't hurt.
[08:25:44] <fuzzie> i keep complaining about it
[08:25:56] <fuzzie> but yes, would be good :)
[08:26:02] <dhewg> i mean, it was just a test, it looks good so far to me, but if you dont like it it doesnt make much sense for me to keep working on it
[08:26:47] <fuzzie> gemrb seems to be permanently spawning huge numbers of golems/rajahs, next to Elhan in Suldanessellar
[08:27:01] <fuzzie> i assume that is not intended
[08:27:06] <dhewg> k pushed
[08:27:22] <dhewg> that will most likely conflict with the error/store commits though :P
[08:27:51] <dhewg> also, i fixed the style and incoorporated tomprince's notes from github
[08:28:01] <fuzzie> i will look after coffee
[08:28:38] <dhewg> k cool, thanks
[08:28:57] <dhewg> oh, another thing
[08:29:06] <dhewg> i tried liek 10 hash functions
[08:29:12] <dhewg> the current one is no good
[08:29:24] <dhewg> with the resrefs you get conflicts left and right
[08:29:41] <dhewg> i tried qt's, git's etc, but more or less same story there
[08:30:02] <fuzzie> well conflicts of some kind are fairly inevitable :p
[08:30:09] <dhewg> well...
[08:30:14] <fuzzie> i probably want to sit down and write something there
[08:30:27] <dhewg> scummvm borrowed from cpython, which is not as fast as others due to it using multiplication instead of bit ops
[08:30:44] <dhewg> so i use that, and have seen no conflicts so far
[08:30:54] <dhewg> (i abort() on conflict)
[08:31:16] <fuzzie> but dealing with hash stuff gets pretty boring after spending so long explaining it to students, my head explodeth
[08:32:06] <dhewg> hehe
[08:32:11] <tomprince> It is probably cleaner to do files[locator&...] = ... than files.insert(...)
[08:32:18] <dhewg> well i think the one im using now is good
[08:32:43] <dhewg> tomprince: the former will call a constructor and return a reference
[08:32:57] <dhewg> which is exactly why the hashmap uses insert :)
[08:33:07] <tomprince> The latter is perhaps more correct, but I think the syntax is the first is nicer. (If we had C++11 ... ;))
[08:33:38] <fuzzie> yes, not thinking so much of the hash function so much as the implementation of the map, which i haven't looekd at since first time
[08:34:12] <fuzzie> tomprince's patch has so far not corrupted any stores from underneath me
[08:36:00] <fuzzie> walking NPCs look much more ridiculous in master :/
[08:36:15] <tomprince> I would create a separate class to handle the caching, rather than stuffing it into ResourceManager.
[08:37:38] <dhewg> i was thinking about doing that with deriving from ResourceSource
[08:37:44] <dhewg> but it looked kinda silly
[08:37:50] <fuzzie> tomprince: bag caching seems to help a lot.
[08:38:00] <tomprince> Perhaps FileCache? That was why I started moving stuff there, but the code hadn't yet grown any state.
[08:38:57] <dhewg> dunno, i dont care that much
[08:39:12] <fuzzie> now you're sounding more like me :p
[08:39:16] <dhewg> resourcemanager is kinda small as it is now, and filecache was just 2 loose functions
[08:39:47] <dhewg> well its the same stuff, it boils down to a matter of taste i guess
[08:40:02] <tomprince> My original thought was to create two classes, one that was a ResourceSource, and one that managed creating files in the cache. (Just cause multiple inheritance is evil, and I had vaguely in the back of my mind, implementing a second version that kept everything in memory.
[08:40:41] <tomprince> And if we split the cache for things like compressed files, from the savegame cache, we might want two instances of it.
[08:41:13] <dhewg> savegame cache?
[08:41:54] <tomprince> All the savegame state that is kept in the cache directory: unload stores and areas, etc.
[08:42:18] <dhewg> but its probably easier to just keep that one cache, and add flags to its entries
[08:42:37] <dhewg> like mark the savegame relevant ones as such
[08:43:39] <dhewg> so when saving a games you iterate over the entries, skipping those without the flag
[08:45:08] <dhewg> its also likely that i miss something and seperating has an obvious advantage
[08:45:17] <dhewg> i dont claim to see the full picture yet :)
[08:45:39] <fuzzie> well there was the suggestion from someone the other day that we not decompress SAVs at load time, and keep them around instead
[08:46:07] <edheldil> since the resrefs are guaranteed to be at most 8 chars, some specialized hash fn would do them good
[08:46:08] <fuzzie> which means you have to be pretty smart about what's where etc
[08:46:53] <fuzzie> but can't think it would require seperate caches. haven't looked.
[08:48:43] <dhewg> ah, i remember why i dont derive from ResourceSource
[08:49:02] <dhewg> it was because of GetResource() by TypeID
[08:49:36] <dhewg> so i can iterate over all types on the cache first, and only after no hit iterate over the registered sources
[08:50:09] <tomprince> Minor nit Core or core instead of CORE in commit messages.
[08:51:03] <edheldil> or at least c0re ;-)
[08:51:05] <dhewg> sure, dunno if it makes sense in the first place
[08:51:11] <dhewg> more like a habit
[08:51:34] <tomprince> I have the same habit. :)
[08:51:35] <dhewg> also, how about renaming core?
[08:51:37] * dhewg runs
[08:51:48] <fuzzie> i bravely resist the habit, for gemrb
[08:51:59] <dhewg> if i run gemrb in ./gemrb and it crashes it cant create a core file because of the core dir :P
[08:52:08] <tomprince> now dhewg is sounding like me :)
[08:52:12] <fuzzie> haha.
[08:52:15] <fuzzie> well, better ideas?
[08:52:25] <lynxlynxlynx> gemrb-core
[08:52:29] <fuzzie> we do have a rename planned at some point
[08:52:33] <lynxlynxlynx> hehe
[08:52:42] <fuzzie> just no-one can decide on what to rename what to
[08:53:21] <edheldil> run gemrb from another dir :-P
[08:53:39] <fuzzie> and i would rather prefer we do it *once*, lest git's lack of path tracking drive me crazy
[08:56:27] <lynxlynxlynx> maybe they'll fix it
[08:56:53] <fuzzie> there's a thread somewhere with Linux decrying the entire concept of --follow as a terrible hack
[08:57:10] <tomprince> I'm sure it is somewhere in the log, but I can't remember the reason for searching through all the sources for each type, rather than the other way arround.
[08:57:59] <fuzzie> you mean, current code?
[08:58:06] <fuzzie> s/Linux/Linus/ ofc.
[09:01:41] <tomprince> Yes. I can't remember if there is a good reason the for loops aren't switched around.
[09:01:44] <fuzzie> well
[09:02:00] <fuzzie> i thought the idea was that it was meant to prefer certain types
[09:02:19] <fuzzie> but i doubt the PluginMgr is cooperating there
[09:02:55] <lynxlynxlynx> most common to least
[09:03:10] <fuzzie> i think there's actually some bugs if you don't try the right types first
[09:03:28] <tomprince> I thought that might be the case, but that would mean you couldn't override something in the bifs with some other type in the override.
[09:03:29] <fuzzie> and we seem to have happily broken that
[09:03:56] <fuzzie> but i'm tempted to just remove the generic ImageMgr stuff from the relevant places instead
[09:04:10] <fuzzie> if it's even a problem
[09:04:14] <fuzzie> i'd have to also dig in irc logs :P
[09:05:45] <fuzzie> certainly the ImageMgr for the map MOS needs to die
[09:06:02] <fuzzie> i should find time to do that
[09:06:08] <tomprince> size issue?
[09:06:20] <fuzzie> yes
[09:06:37] <lynxlynxlynx> we probably did check if there are any root-type clashes
[09:06:48] <fuzzie> i think we worked out that there are root-type clashes
[09:06:59] <-- |Cable| has left IRC (Remote host closed the connection)
[09:07:00] <fuzzie> but maybe only BAM vs others
[09:07:09] <lynxlynxlynx> mhm
[09:08:28] --> Beh0lder has joined #gemrb
[09:08:41] <Beh0lder> hello all
[09:08:45] <fuzzie> hi
[09:10:39] <edheldil> hi
[09:11:49] <fuzzie> so mishandled MOS on standard bg2 wastes about 5mb for the worldmap and 3mb for the GUI
[09:12:46] <fuzzie> not as much as i remember, possibly i was playing with a modded worldmap
[09:13:50] <tomprince> some of the modded worldmaps are insanely huge.
[09:14:29] <fuzzie> the 8bpp->32bpp conversion is 4x, so easy to work out the cost for a given size
[09:14:43] <fuzzie> right now we load the worldmap at startup, too, which is a bit silly
[09:15:23] <Beh0lder> One user can not run IWD:HoW, please look at the log http://pastebin.com/fpUPeGvY , I can't understand what is wrong. Config file is correct at first glance.
[09:16:06] <fuzzie> I/printf: ( 6263): Cannot write ./Cache/\ear9100.bif.
[09:16:09] <fuzzie> ^- that is wrong
[09:16:43] <fuzzie> that is 0.6.4?
[09:17:11] <Beh0lder> yes, 0.6.4. May be he missing some resources?
[09:17:35] <fuzzie> that '\' doesn't look good
[09:17:55] <Beh0lder> hm, you are right
[09:18:11] <fuzzie> that is not in config file?
[09:18:28] <dhewg> oh look, the same openal error i get too
[09:18:33] <Beh0lder> CachePath=./Cache/
[09:19:49] <fuzzie> dhewg: provisionally i have been filing that under 'users with broken audio systems'
[09:20:08] <dhewg> :p
[09:20:17] <dhewg> btw, i fixed that bifimporter recursion there
[09:21:06] <fuzzie> howso fixed?
[09:21:47] <fuzzie> Beh0lder: so what is user trying to do there?
[09:21:48] <edheldil> could it be some mod with broken paths
[09:22:17] <fuzzie> just start new game?
[09:22:45] <fuzzie> edheldil: HoW/TotL have those slashes in the key file..
[09:23:06] <dhewg> fuzzie: after it decompressed it uses the resourcemanager to open the decompressed file again
[09:23:17] <dhewg> which runs the same code again
[09:23:24] <edheldil> sure, but maybe if there's st. like \file instead of data\file we do not strip it?
[09:25:10] <fuzzie> i do in the key file, but not if it's baked into a bif :-/
[09:27:16] <edheldil> ah
[09:27:23] <edheldil> sounds like a bug :)))
[09:27:37] <fuzzie> yes, i just wonder why
[09:28:17] <edheldil> why what?
[09:28:22] <fuzzie> why it happens here
[09:28:45] <tomprince> Well, unix doesn't have a problem with \ in the filename.
[09:28:47] <edheldil> decompression of the bif
[09:28:50] <fuzzie> probably it is a user running with Cache on FAT
[09:30:05] <lynxlynxlynx> maybe it's one of the special chars from the start of ascii
[09:30:09] <fuzzie> yup
[09:30:16] <fuzzie> it is a bug with Cache on FAT
[09:30:17] <Beh0lder> Android sdcard formatted only in FAT
[09:30:29] <fuzzie> shouldn't put the Cache on the sdcard :P
[09:30:41] <fuzzie> but, ok, that is bug in gemrb
[09:31:18] <Beh0lder> but I have no problems with it ;)
[09:31:19] <fuzzie> i think Xoom slowness problem is because sdcard on Xoom is not real, by the way - very slow
[09:31:34] <fuzzie> and you can reproduce problem by making a new *expansion* game in HoW
[09:31:54] <fuzzie> we will fix it on master
[09:32:03] <fuzzie> master should be good to use again, it should be faster too
[09:32:54] <fuzzie> tomprince: don't suppose I can get you to volunteer to fix that? or suggest how
[09:33:44] <fuzzie> (i guess i would just make PathAppend ignore slashes if they're at the start of a name)
[09:34:14] <lynxlynxlynx> that would still leave the e
[09:34:27] <fuzzie> the e is legitimate i think
[09:34:39] <Beh0lder> Ok I will wait for stable version
[09:34:59] <tomprince> That would make sense, : too, according to KEYImporter.cpp:185
[09:35:29] <tomprince> My other suggestion would be to copy that loop. But fixing path append sounds better.
[09:35:59] <fuzzie> well
[09:36:11] <fuzzie> the nice thing there is that i could get rid of the bit a few lines down from 185
[09:36:39] <fuzzie> since FindBIF calls PathExists calls PathJoin calls PathAppend
[09:36:52] <tomprince> Yes.
[09:38:06] <fuzzie> although i don't understand how it works as-is since PathDelimiter is surely '/' on unix
[09:38:41] <tomprince> We first convert eveything to PathDelimiter, and then get rid of the leading one.
[09:38:46] <fuzzie> Ah! :)
[09:39:05] <fuzzie> right. so check for all possible seperators, I guess.
[09:47:16] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[09:49:26] --> lynxlynxlynx has joined #gemrb
[09:49:26] --- ChanServ gives channel operator status to lynxlynxlynx
[09:53:55] <fuzzie> tomprince: still awake?
[09:55:00] <tomprince> sortof.
[09:55:13] <tomprince> :P
[09:55:14] <fuzzie> user on forum reports error in PluginMgr destructor
[09:55:34] <fuzzie> > error: cannot convert 'std::ma
[09:55:34] <fuzzie> p<long unsigned int, PluginMgr::PluginDesc>::mapped_type' to 'HINSTANCE__*' for
[09:55:57] <fuzzie> > argument '1' to 'BOOL FreeLibrary(HINSTANCE__*)'
[09:56:56] <tomprince> simple fix: comment out that line.
[09:57:36] <fuzzie> just curious if you knew what on earth :)
[10:00:05] <fuzzie> i suppose it should probably be HMODULE
[10:01:24] <tomprince> That freeing code is so untested ... we never save hMod to desc.handle anyway ...
[10:01:38] <fuzzie> we do
[10:01:50] <fuzzie> > PluginDesc desc = { hMod, ID(), Description(), Register };
[10:01:56] <tomprince> Yes. Missed that.
[10:02:05] <tomprince> But yes, I think your guess is right.
[10:02:06] <fuzzie> i had to read through it 3 times to see it
[10:04:50] <tomprince> I am guessing one is void* and one is void**, so the assignment works one way.
[10:33:15] <tomprince> could also suggest trying the build from the bot. I linked to it on the getting started page.
[10:36:03] <-- ubermad has left IRC (Ping timeout: 260 seconds)
[10:38:02] <-- Beh0lder has left #gemrb
[11:16:45] <lynxlynxlynx> yep, traps work again
[11:17:00] <fuzzie> great
[11:18:59] <CIA-52> GemRB: 03lynxlupodian * r3e52ed0ff8d3 10gemrb/gemrb/core/GameScript/GameScript.cpp: GameScript::EvaluateAllBlocks: always mention a missing cutscene ID
[11:19:00] <CIA-52> GemRB: 03lynxlupodian * r0c64bbfc3c86 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp: don't stack the same kind of poison
[11:20:26] <dhewg> nice
[11:20:41] <dhewg> i assume that fixes the golem gas cloud?
[11:21:26] <lynxlynxlynx> yep
[11:21:59] --> mihairu has joined #gemrb
[11:22:12] <lynxlynxlynx> now onto the windspear mess
[11:22:46] <lynxlynxlynx> did you have any problems there with Garren?
[11:22:55] <dhewg> did you run into that poision issue in the planar sphere?
[11:23:40] <dhewg> is that the fella in the windspear hut?
[11:24:03] <lynxlynxlynx> yes @ 2
[11:24:12] <lynxlynxlynx> haven't been to the sphere yet
[11:24:43] <dhewg> apart from leftover quests the only thing i noticed that he was positioned at a weird spot
[11:25:10] <lynxlynxlynx> outside?
[11:25:37] <dhewg> kinda, somewhere at the door so you only notice him when pausing
[11:25:57] <dhewg> i mean, it was the map of inside the hut
[11:26:00] <-- mihairu has left IRC (Remote host closed the connection)
[11:26:07] <lynxlynxlynx> ah, haven't seen that problem yet
[11:26:23] <lynxlynxlynx> here he goes to athakla to sort things out and then nothing happens
[11:26:33] <lynxlynxlynx> i think the kid is supposed to say something
[11:26:43] <lynxlynxlynx> then the abduction triggers
[11:26:47] --> mihairu has joined #gemrb
[11:26:47] <lynxlynxlynx> sounds about right?
[11:27:03] <dhewg> i think you should run into him when entering the dugeon?
[11:27:19] <dhewg> asking for help about the kidnapping
[11:28:44] <lynxlynxlynx> maybe that's a shortcut, but that's not the usual way
[11:28:54] <lynxlynxlynx> i forgot there are whole LP videos online
[11:29:09] <dhewg> did you run into the bandits?
[11:31:45] <lynxlynxlynx> after some work
[11:31:58] <lynxlynxlynx> i didn't enter where i should
[11:36:53] <fuzzie> lynxlynxlynx: always mention a missing cutscene id is not so nice
[11:37:08] <fuzzie> well, wait, let me look at the commit
[11:37:17] <lynxlynxlynx> there is no else else
[11:37:34] <fuzzie> yes, not so nice
[11:37:49] <lynxlynxlynx> how come? sounds like a big issue
[11:38:18] <fuzzie> because cutscene targets are missing all the time
[11:38:53] <fuzzie> - } else {
[11:38:53] <fuzzie> + } else if ((InDebug&ID_CUTSCENE) || !action->objects[1]) {
[11:39:01] <fuzzie> ^- proposal
[11:39:18] <lynxlynxlynx> ok
[11:39:26] <lynxlynxlynx> no need to wait for me
[11:39:39] <fuzzie> otherwise e.g. a soloing player gets spam for player2/3/4/5/6, any optional participants, etc in many cutscenes
[11:39:54] <fuzzie> maybe that's not such a huge problem?
[11:40:09] <fuzzie> i am just on a vague quest to reduce console spam
[11:41:41] <fuzzie> so just looking for opinions before i run roughshod over that
[11:46:10] <lynxlynxlynx> sounds fine
[11:47:10] <lynxlynxlynx> just went through the lp; my memory is ok
[11:51:41] <fuzzie> so what is the held state?
[11:52:17] <fuzzie> none?
[11:53:13] <fuzzie> that seems weird
[11:53:29] <lynxlynxlynx> i don't understand
[11:53:49] <fuzzie> as in, STATE_
[11:54:09] <gembot> build #55 of autotools clang++ is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/autotools%20clang%2B%2B/builds/55 blamelist: lynxlupodian@users.sourceforge.net
[11:54:09] <gembot> build #55 of autotools clang++ is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/autotools%20clang%2B%2B/builds/55 blamelist: lynxlupodian@users.sourceforge.net
[11:54:59] <fuzzie> > clang: error: unable to execute command: Segmentation fault
[11:55:56] <lynxlynxlynx> heh
[11:56:52] <fuzzie> fairly sure that's not your fault :)
[11:57:26] <lynxlynxlynx> i don't know how hold differs from stun
[11:57:47] <lynxlynxlynx> maybe it just immobilises
[11:58:21] <lynxlynxlynx> stunned opponents get autohit, i think
[12:03:21] <fuzzie> Avenger has some notes i think, will look shortly
[12:06:25] <lynxlynxlynx> i think our effects are already mostly ok for this
[12:06:38] <lynxlynxlynx> there are some 6 opcodes
[12:14:40] <lynxlynxlynx> found the problem
[12:15:17] <lynxlynxlynx> SeeCore isn't checking for IF_VISIBLE, so a deactivated actor is seen by another, inhibiting the start of the dialog
[12:18:59] <fuzzie> this is See()?
[12:21:37] <lynxlynxlynx> yes, but i was wrong
[12:21:45] <lynxlynxlynx> or i'm doing something wrong
[12:23:29] <lynxlynxlynx> hmm, on loading the game IF_VISIBLE is reset too
[12:23:56] <lynxlynxlynx> ok
[12:24:42] <lynxlynxlynx> http://sprunge.us/dOGW?diff <-- this was enough for a fresh attempt
[12:25:21] <fuzzie> i'm not sure if that's right
[12:26:46] <lynxlynxlynx> considering the second issue, maybe (de)activate actions should be doing more
[12:26:55] <fuzzie> setting STATE_DISEASED, maybe
[12:27:06] <fuzzie> thankyou bioware
[12:29:41] <lynxlynxlynx> seriously?
[12:30:18] <fuzzie> yeah
[12:30:21] <fuzzie> Avenger, devSin, etc all agree
[12:30:37] <fuzzie> and there's a note in our disase effect about it
[12:30:48] <fuzzie> apparently it's also saved as a flag somewhere though..
[12:31:38] <fuzzie> > field 0x2c08 (actor is hidden) determines the 0x80000 bit of basestats[IE_STATE] (the permanent state flags).
[12:31:41] <fuzzie> > This hack is called before every 'writeactor', 'exportactor' etc
[12:32:38] <fuzzie> and plenty of complaints about STATE_DISEASED not being that
[12:33:20] <fuzzie> there are usages in iwd2 too, hm
[12:35:56] <-- devurandom has left IRC (Read error: Operation timed out)
[12:36:45] --> devurandom has joined #gemrb
[12:40:09] --> BaldimerBrandybo has joined #gemrb
[12:43:21] <-- PixelScum has left IRC (Ping timeout: 260 seconds)
[12:49:48] <fuzzie> i have no idea, i guess.
[12:51:43] <fuzzie> oh, yes i do, field 2c08!
[12:54:51] <fuzzie> hmm that's weird :)
[12:56:10] <-- DrMcCoy has left IRC (Disconnected by services)
[12:56:15] --> budlust has joined #gemrb
[12:56:23] --> DrMcCoy has joined #gemrb
[12:56:56] --> gembot_ has joined #gemrb
[12:57:23] --> nyytit_ has joined #gemrb
[12:58:28] <fuzzie> lynxlynxlynx: do you have more details of what exactly the check is?
[12:58:54] <lynxlynxlynx> See("garren")
[12:59:14] <lynxlynxlynx> where garren deactivated a few ticks back
[12:59:19] <-- gembot has left IRC (*.net *.split)
[12:59:21] <-- nyytit has left IRC (*.net *.split)
[12:59:26] <fuzzie> huh :-/
[12:59:50] <lynxlynxlynx> but the see is ran from another actor
[13:00:05] <lynxlynxlynx> in my case garkid01
[13:01:19] <fuzzie> I am guessing the check is somewhere deeper.
[13:01:41] <fuzzie> Probably when resolving the object by script name?
[13:01:52] --> test32894789234u has joined #gemrb
[13:02:59] <fuzzie> But I'd have to actually look, maybe this evening.
[13:03:27] <fuzzie> can always commit whatever for now.
[13:04:15] <lynxlynxlynx> another activation issue
[13:04:46] <lynxlynxlynx> the triggers matched and garren started his talk too early
[13:04:58] <lynxlynxlynx> he should have waited to be reactivated
[13:05:03] <fuzzie> mm
[13:05:12] <lynxlynxlynx> maybe something for begindialog
[13:05:30] <fuzzie> i think probably scripts don't run on deactivated actors
[13:05:37] <fuzzie> but again i can't look at that from here
[13:05:49] <fuzzie> unless someone is talking *to* Garren?
[13:06:53] <lynxlynxlynx> no, he talks to you
[13:06:58] <lynxlynxlynx> ar1204.baf <--
[13:07:12] <fuzzie> yes, i found it
[13:07:20] <fuzzie> so it makes sense if scripts don't run on deactivated actors?
[13:07:25] <lynxlynxlynx> will fixing activation be enough? will his dialog start before that cutscene?
[13:07:38] <lynxlynxlynx> makes plenty sense to me
[13:07:46] <fuzzie> his dialog will start before that cutscene, yes
[13:07:58] <lynxlynxlynx> that's also not matching then
[13:08:54] <fuzzie> i mean, if the triggers do match
[13:08:59] <fuzzie> oh hm
[13:09:07] <fuzzie> no, wait
[13:09:17] <fuzzie> the CutSceneMode will also kill script execution here, so it's ok
[13:09:45] <lynxlynxlynx> http://www.youtube.com/watch?v=x9OtSyvplGg#t=8m55s
[13:09:51] <lynxlynxlynx> ok :)
[13:11:40] <lynxlynxlynx> so that leaves us with the See/Activate remaining
[13:11:59] <lynxlynxlynx> and the attached disease
[13:12:26] <fuzzie> the saving issue is almost certainly disease
[13:12:34] <fuzzie> the rest i'd have to look, but commit hacks if you wish
[13:14:17] <lynxlynxlynx> i'll just leave them in-tree
[13:14:33] <lynxlynxlynx> added skipping to map::updatescripts
[13:18:11] <lynxlynxlynx> perfection :)
[13:18:58] <fuzzie> horrible :P
[13:19:22] <fuzzie> the map::updatescripts stuff is the last remaining super broken part of the scripting, i guess
[13:20:12] <lynxlynxlynx> sure, wrong place and all, but that's where we do it currently
[13:20:28] <fuzzie> yes, definitely
[13:20:34] <fuzzie> i mean, it's not even that it's the wrong place :-)
[13:21:02] <fuzzie> just that the updating is more subtle than an on/off, and i break a lot of scripts with the instants handling due to that
[13:21:16] <fuzzie> i should fix that rather than finishing up anything else i guess
[13:32:39] <-- mihairu has left IRC (Remote host closed the connection)
[13:32:57] <edheldil> grr, spent almost whole day chasing lack of vnc output in kvm
[13:33:13] <-- test32894789234u has left #gemrb
[13:35:32] --> mihairu has joined #gemrb
[13:43:37] --> boriskr has joined #gemrb
[13:53:19] <lynxlynxlynx> heh, vampiric stuff again
[13:54:02] <lynxlynxlynx> on the first run vampires were crashing the game due to the different forms and animations and now vampiric mists are evidently bad as well
[13:55:21] <fuzzie> ah, i quite possibly broke those
[13:55:52] <dhewg> oh?
[13:55:59] <fuzzie> stupid monster anims
[13:56:02] <dhewg> it kinda-worked at my playtesting
[13:56:14] <dhewg> there was only an animation problem when they turn into bats
[13:56:28] <fuzzie> but not going to look at them right now, ti is a huge time-sink
[13:57:14] <dhewg> we all know you love avatars.2da
[13:57:55] --- BaldimerBrandybo is now known as Drakkar
[13:57:59] <-- Drakkar has left IRC (Quit: The beer is meal.)
[13:58:15] --> Drakkar has joined #gemrb
[13:58:51] --> Maighstir has joined #gemrb
[14:01:55] <lynxlynxlynx> just an unaccounted stance
[14:02:08] <lynxlynxlynx> it is not clear what animation to use though
[14:04:25] <dhewg> isnt that part of the stance info?
[14:04:43] <CIA-52> GemRB: 03tom.prince * r8e50a442331d 10gemrb/gemrb/core/PluginMgr.h:
[14:04:43] <CIA-52> GemRB: win32: Use HMODLUE instead of HINSTANCE for plugins.
[14:04:43] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[14:05:12] <lynxlynxlynx> it's hardcoded
[14:05:26] <dhewg> ugh
[14:05:34] <lynxlynxlynx> and someone broke turn-undead
[14:05:42] <dhewg> i was just about to say
[14:05:43] <lynxlynxlynx> even my alive party members scatter :)
[14:05:49] <fuzzie> what's wrong with it?
[14:05:56] <dhewg> that even crashes because of an unknown stance
[14:05:59] <lynxlynxlynx> maybe the general check fails now
[14:06:44] <fuzzie> i modified Turn() to replace the LastTurner with trigger_turnedby
[14:07:59] <lynxlynxlynx> huh, it happens without Actor::Turn getting run at all
[14:09:47] <lynxlynxlynx> or the effects
[14:09:55] <fuzzie> which effect is it meant to run?
[14:10:02] <lynxlynxlynx> i'll just blame the fixpack
[14:10:13] <lynxlynxlynx> still don't have iwd handy to test there
[14:10:39] <fuzzie> last time i looked, bg2 had no way to turn stuff
[14:13:03] <fuzzie> yes, indeed
[14:13:17] <fuzzie> there's an iwd-only override/shared/turn.spl
[14:14:38] <fuzzie> oh i see, it's using 0x6e as an alternative reference to IWDOpcodes
[14:20:19] <fuzzie> huh, iwd2 comes with effect docs?
[14:20:44] <fuzzie> that's nice
[14:25:24] <fuzzie> now fighting with weidu
[14:29:11] <fuzzie> which apparently also hasn't quite grasped the idea of slashes quite yet
[14:31:44] <fuzzie> alas, looks like iwd2 was forked pre-ToB
[14:33:52] <gembot_> build #56 of autotools clang++ is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/autotools%20clang%2B%2B/builds/56
[14:44:35] --> test32894789234u has joined #gemrb
[15:13:13] <-- budlust has left IRC (Ping timeout: 258 seconds)
[15:28:43] --> barra_home has joined #gemrb
[15:29:47] <-- lubos has left IRC (Quit: Leaving.)
[15:40:30] --> Bo_Thomsen has joined #gemrb
[16:26:36] <-- mihairu has left IRC (Remote host closed the connection)
[16:28:34] --> mihairu has joined #gemrb
[16:34:35] <-- barra_home has left IRC (Read error: Connection reset by peer)
[16:35:57] <lynxlynxlynx> boom crash
[16:36:57] <lynxlynxlynx> strnlwrcpy
[16:37:12] <lynxlynxlynx> due to a bad map
[16:37:30] <fuzzie> in cache?
[16:37:52] --> barra_home has joined #gemrb
[16:39:23] <lynxlynxlynx> doubt it, it's a mod area
[16:39:33] <lynxlynxlynx> there is no tilemap for it
[16:40:36] <lynxlynxlynx> so map2->AddActor in MoveBetweenAreasCore is where things go downhill - map2 is null
[16:41:12] <lynxlynxlynx> i see
[16:41:42] <lynxlynxlynx> the mod bundles tiz files and they didn't get decompressed
[16:41:44] <fuzzie> still not sure why we don't abort in such cases
[16:42:00] <fuzzie> tomprince has a crazy tizimporter somewhere :P
[16:42:23] <lynxlynxlynx> abort sounds fine to me - we crash anyway
[16:42:44] <fuzzie> or, rather, error()
[16:45:49] <lynxlynxlynx> of course
[16:46:20] <-- mihairu has left IRC (Remote host closed the connection)
[16:48:59] --> mihairu has joined #gemrb
[16:50:21] <-- barra_home has left IRC (Read error: Connection reset by peer)
[16:58:16] <-- mihairu has left IRC (Remote host closed the connection)
[17:01:27] --> barra_home has joined #gemrb
[17:02:26] --- barra_home is now known as barraAway
[17:07:04] --> lynxlynxlynx_ has joined #gemrb
[17:07:04] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[17:08:23] <lynxlynxlynx_> hehe
[17:08:42] <lynxlynxlynx_> managed to deadlock my system using build tools and recursion
[17:09:03] <lynxlynxlynx_> cgroups didn't help at all
[17:11:47] <fuzzie> tomprince: thanks for getting there before me on hmodule/forum reply, too
[17:14:02] --> budlust has joined #gemrb
[17:17:00] --> mihairu has joined #gemrb
[17:30:22] <-- adominguez has left IRC (Remote host closed the connection)
[17:39:56] <-- mihairu has left IRC (Remote host closed the connection)
[17:43:47] --- barraAway is now known as barra_home
[17:43:51] --> |Cable| has joined #gemrb
[18:07:10] --- barra_home is now known as barraAway
[18:13:49] <-- budlust has left IRC (Ping timeout: 252 seconds)
[18:17:36] <dhewg> its really ridiculous how fast gemrb is now
[18:17:47] <dhewg> at compared to master a couple of days ago
[18:26:03] <lynxlynxlynx_> hmm, something is off with global timers
[18:29:42] <lynxlynxlynx_> disregard that, it goes bad sooner
[18:31:41] <fuzzie> heh
[18:31:58] <lynxlynxlynx_> maybe it's or-related
[18:32:08] <fuzzie> got a snippet?
[18:32:09] <lynxlynxlynx_> but the first block is already true
[18:32:18] <fuzzie> i am distressingly aware of how everything works now
[18:32:51] <lynxlynxlynx_> http://pastebin.com/Y7qLeuzt
[18:33:14] <lynxlynxlynx_> the vars are 0 and 2, i can ctrl-y her to get the hp lower
[18:33:20] <fuzzie> and they're all dead?
[18:33:22] <lynxlynxlynx_> revived stays at 0
[18:33:32] <lynxlynxlynx_> dead or in other areas
[18:33:44] <fuzzie> InActiveArea isn't broken?
[18:33:53] <lynxlynxlynx_> no
[18:33:59] <lynxlynxlynx_> i found the problem
[18:34:04] <fuzzie> yay :)
[18:34:13] <lynxlynxlynx_> one of her action scripts is too aggressive
[18:34:26] <lynxlynxlynx_> she always drank a potion before this kicked in
[18:34:42] <fuzzie> ah.
[18:34:44] <lynxlynxlynx_> so after some five repeats she was finally free of potions
[18:34:58] <fuzzie> do you think that's a gemrb thing?
[18:38:21] <fuzzie> i guess i'm going to go take another look at the ai update stuff shortly, to check deactivated/hold/etc
[18:38:24] <fuzzie> so would be good time to know
[18:40:53] <lynxlynxlynx_> not sure, but it was a problem before
[18:41:05] <lynxlynxlynx_> and not to worry, i'm already stuck in another cutscene
[18:45:52] <fuzzie> :-/
[18:46:00] <fuzzie> you're maintaining the list?
[18:48:28] <lynxlynxlynx_> sure
[18:48:47] <dhewg> uhm
[18:48:53] <lynxlynxlynx_> appears that one of the guards retreated from the other area and the others don't reckognise him
[18:49:03] <lynxlynxlynx_> so as soon as i enter, they start combat
[18:49:12] --> mihairu has joined #gemrb
[18:49:18] <dhewg> about the stack amount
[18:49:21] <lynxlynxlynx_> then a few moments later a trivial cutscene starts, but never finishes
[18:49:49] <dhewg> the number of the icon is the stack count, and the number in brackets in the amount of stacks?
[18:50:13] <fuzzie> yes
[18:50:52] <fuzzie> for your own bags, stack count should always be 1, with an exploitable exception in the default ToB bags
[18:51:35] <dhewg> yhea, thats why im asking
[18:51:45] <dhewg> why's that?
[18:52:31] <fuzzie> in the original, because you can gain infinite items by adding small numbers to a larger stack, since it only increases the amount of stacks
[18:52:53] <fuzzie> in gemrb, because i copied the original's behaviour (by observation, mind, i might've missed something, but it is exploitable in original)
[18:53:25] <dhewg> ah heh
[18:53:33] <dhewg> still a little weird
[18:53:44] <dhewg> but ok, then it works
[18:53:44] <lynxlynxlynx_> some other script has manual timers to prevent too much potion drinking
[18:54:02] <fuzzie> scripts run about once every second during combat etc
[18:54:47] <fuzzie> dhewg: well, was only a gemrb bug that let you put non-1 stacks in the bag, i guess :)
[18:56:15] <fuzzie> i'm sure gemrb could do something cleverer
[18:56:58] <dhewg> i dont know about other games than bg, but are there containers for stuff other then gems/jewelry and scrolls?
[18:57:08] <dhewg> for those items its not annoying
[18:57:28] --> Beh0lder has joined #gemrb
[18:57:37] <fuzzie> yes
[18:57:59] <fuzzie> first bag of holding is at start of spellhold
[18:58:14] <fuzzie> ToB has potion bags also
[18:58:15] <dhewg> ah okay
[18:58:30] <dhewg> my last save is still start of act4
[18:59:23] <Beh0lder> hi again)
[19:00:10] <-- test32894789234u has left #gemrb
[19:03:27] <fuzzie> hi
[19:03:31] <fuzzie> dhewg: poor neglected imoen?
[19:03:54] <dhewg> hehe
[19:09:15] <dhewg> how did i manage that: http://pastie.org/1844505 ?
[19:10:27] <dhewg> i can only reproduce that with my branch though :)
[19:10:43] <dhewg> on the other side, i didnt touch that 1biff caching in the keyimporter
[19:12:05] <fuzzie> the 1biff caching in the importer can explode if you load a game
[19:12:17] <dhewg> thats exactly the spot
[19:12:25] <dhewg> this one savegame, 50% chance
[19:13:06] <dhewg> and why does it only happen on my branch? :P
[19:13:19] <dhewg> is that proof that its faster?
[19:13:20] <dhewg> heh
[19:13:38] --> budlust has joined #gemrb
[19:13:49] <fuzzie> i dunno, what're you caching?
[19:14:13] <dhewg> just that stuff i pushed this morning
[19:14:23] <fuzzie> i was depending on the fact that on master, another bif gets loaded
[19:14:27] <dhewg> just based that, but happens on this savegame before the rebasing too
[19:15:13] <dhewg> uhm
[19:15:18] <dhewg> as opposed to what?
[19:17:07] <fuzzie> as opposed to it not happening
[19:17:13] <fuzzie> don't think it's changed by your branch
[19:17:28] <dhewg> no, its the same
[19:17:43] <dhewg> grepme: Couldn't load animation: mmstg1, cycle 16
[19:19:48] <dhewg> lol: http://static.hackmii.com/dhewg/deaddead.png
[19:19:53] <fuzzie> but i think i mumbled about this being broken
[19:20:12] <fuzzie> heh
[19:20:35] <fuzzie> that is in gemrb i assume
[19:20:44] <dhewg> yah
[19:21:01] <fuzzie> you can get much weirder things happening in original engine, message ordering is not guaranteed
[19:21:08] <fuzzie> awful for debugging
[19:24:10] <tomprince> That TIZImporter was why I started hacking on GemRB.
[19:24:12] * tomprince grins
[19:25:20] <fuzzie> been a long time now
[19:29:02] <fuzzie> i forget why i disliked the idea
[19:30:09] <fuzzie> well, i seem to remember i liked the idea but you didn't like the 8bpp form, but perhaps i misremember :)
[19:31:23] <-- budlust has left #gemrb
[19:31:45] <fuzzie> speaking of things from a long time ago, still don't have a low-memory TIS option
[19:32:41] --> barra_away has joined #gemrb
[19:32:59] <fuzzie> i cringe every time i see reports of a 256mb device having memory issues w/gemrb, given what the original ran in :)
[19:35:00] <Beh0lder> 256Mb RAM devices (Android) has less of 100Mb free
[19:35:11] <fuzzie> original engine needed some 8mb :)
[19:35:42] <Beh0lder> GemRB use 128Mb or more)
[19:35:45] <-- barraAway has left IRC (Ping timeout: 250 seconds)
[19:35:57] <fuzzie> yes :P
[19:36:13] <dhewg> 8?
[19:36:32] <Beh0lder> I think, 32
[19:36:38] <Beh0lder> not 8
[19:36:48] <fuzzie> bg1 would run in 8mb, even if it officially required 16mb
[19:37:12] <fuzzie> plus 166mhz cpu, enough vram for the framebuffer and 300mb of disk space for bifs
[19:37:39] <fuzzie> bg2 made that 32mb and 800mb of disk space, whee
[19:37:44] <Beh0lder> great optimization)
[19:39:00] <fuzzie> my massif run earlier needed 13mb for the TIS tiles, 8mb for MOS, some 5mb for BAMs, 1mb for KEYImporter cache, and a lot of random junk
[19:39:22] <fuzzie> so we shouldn't be too far off the target if only we didn't do so many stupid things
[19:40:39] <tomprince> Yes, the TIZ often stores 32bpp tiles.
[19:41:12] <fuzzie> yes, but the original tool makes 8bpp output, so can't be that bad :P
[19:42:07] <fuzzie> should be possible to support 32bpp tiles, just seems a really bad default
[19:49:24] <Beh0lder> Avenger says that implementation of tile caching may greatly reduce memory usage
[19:50:59] <fuzzie> yep
[19:51:23] <fuzzie> while, on the other hand, 32bpp tiles may increase memory usage by 4x :p which is what made me remember this whole thing
[19:51:32] <fuzzie> it's just a bit painful to do properly
[19:54:22] <fuzzie> and MOS thing is much easier target
[19:54:40] <Beh0lder> properly solution is a compromise :)
[19:56:34] <Beh0lder> Well, actually, if it was possible to reduce memory consumption in half, it would be great.
[19:58:13] <tomprince> Part of why it never got implemented is it stoped being an itch :)
[19:58:20] <fuzzie> ah, heh
[19:58:36] <fuzzie> maybe i can dig it out someday and have a look, but i never really encountered them
[19:59:35] <fuzzie> Beh0lder: what do you test with, for memory usage?
[20:05:34] <-- mihairu has left IRC (Quit: mihairu)
[20:16:01] <dhewg> i usually peek at: cat /proc/`pidof gemrb`/status|grep Vm
[20:18:33] <fuzzie> well it generally crashes first
[20:20:02] <dhewg> huh? :P
[20:20:28] <fuzzie> on android
[20:20:37] <dhewg> oh
[20:20:39] <fuzzie> nom nom delicious RAMz
[20:20:40] <dhewg> that bad?
[20:20:46] <dhewg> i didnt try it
[20:21:06] <fuzzie> Beh0lder just gave me stats in a query, blossoms v.quickly to beyond what a device without swap can provide
[20:21:20] <fuzzie> which is not surprising given what i see in massif
[20:22:17] <fuzzie> also makes me feel less crazy for complaining about memory usage, win all around
[20:23:24] <Beh0lder> )
[20:24:44] <tomprince> Maybe make sprites that know where they came from, and keep an LRU of sprite bodies?
[20:25:20] <Beh0lder> I go to sleep. bb all
[20:25:20] <tomprince> That would (yay) mean sprites would have to be properly factored out from SDLVideo.
[20:25:51] <fuzzie> i don't think there is a significant amount of Sprite2D usage which shouldn't die
[20:26:11] <-- Beh0lder has left #gemrb
[20:27:28] <dhewg> arent all these plugins already an overhead?
[20:27:42] <fuzzie> you can STATIC_LINK
[20:28:03] <dhewg> oh nice
[20:28:07] <fuzzie> another tomprince innovation
[20:28:08] <dhewg> droid does that?
[20:28:27] <fuzzie> i doubt it :P
[20:28:35] <dhewg> heh
[20:28:38] <dhewg> well.. :P
[20:28:47] <fuzzie> but the overhead there is laod time overhead
[20:28:50] <dhewg> i shall try that
[20:28:53] <fuzzie> linux's linker suck of doom
[20:28:55] <dhewg> with leet lto
[20:30:23] <fuzzie> yeah, Sprite2D overhead isn't significant
[20:30:51] <fuzzie> other than stuff like MOS which is dwarved by the cost of storing it as a sprite at all etc bla bla
[20:34:21] <tomprince> Does that include the stuff that is hiding in SDL?
[20:36:17] <tomprince> But my thought was more along the lines that most of the code in core shouldn't need to know that we don't keep all the images in memory.
[20:36:57] <fuzzie> yes, it includes that :p
[20:37:06] <fuzzie> i mean, i'm not objecting to the idea
[20:37:10] <fuzzie> i'm just saying it's mostly irrelevant
[20:38:02] <fuzzie> at least from what i've tried.
[20:38:41] <tomprince> Well, maybe it shouldn't be in Sprite2D, but isn't all the memory want to save coming from images? MOS/TIS/BAM
[20:38:48] <fuzzie> yes
[20:39:09] <fuzzie> but MOS needs some thought anyway, because it shouldn't be handled as a Sprite2D, as discussed many times :P
[20:39:40] <fuzzie> and TIS is passed as byte arrays to the blitter, since it has to do custom blit, and Sprite2D for BAM is just a ptr to BAM data, and you really need most of that around
[20:41:20] <tomprince> Well, my suggestion is to make Sprite smart, perhaps with multiple impls.
[20:41:28] <fuzzie> right
[20:41:41] <fuzzie> but it's really troublesome working out what 'smart' means
[20:41:56] <tomprince> So the sprite from a TIS knows which TIS it came from, so the data can be discared, and the reloaded.
[20:42:13] <tomprince> And the mos appears as a sprite, but is stored as tiles ...
[20:42:18] <fuzzie> yes
[20:42:37] <fuzzie> this is one reason i keep wanting to find time to write an opengl backend
[20:43:01] <fuzzie> so we have a real way to make sure that the balance between 'smart for backend' and 'smart for core' works out
[20:43:30] <fuzzie> i'm pretty sure that in any case, the MOS should show up as tiles, though
[20:43:59] <tomprince> To core?
[20:44:17] <fuzzie> to the backend
[20:44:46] <fuzzie> for core, some smart Sprite would be .. well, smart
[20:44:47] <tomprince> Yes, that makes sense, from a memory usage point of view, anyway. I have 0 clue re speed.
[20:45:46] <fuzzie> well, speed isn't so hard: the backend needs to be able to retrieve stuff in the most helpful format, and the backend needs to be able to minimise uploading sprites somehow..
[20:46:38] <fuzzie> dhewg probably knows the embedded situation better than me, but i'm guessing 16bpp textures on android are your only real option and that paletted stuff is a mess
[20:46:56] <dhewg> well depends
[20:47:06] <dhewg> paletted stuff works
[20:47:19] <dhewg> i mean scummvm is dumb in that regard
[20:47:32] <dhewg> there's one huge pixel buffer and engines mess with it
[20:47:50] <fuzzie> yes, obviously we wouldn't do that :P
[20:47:53] <dhewg> if you go with a tile or sprite class, the backend can handle those as textures
[20:48:02] <fuzzie> but we also have huge amounts of sprites, in theory
[20:48:07] <dhewg> the crappy thing on android is changing textures
[20:48:13] <fuzzie> no way it's going to fit into the amounts of texture ram these devices have available
[20:48:37] <dhewg> so static paletted textures handled by a gl backend would likely work out
[20:49:12] <dhewg> but i suspect that those sucky drivers dont do real paletted stuff and convert to something exploding in the driver
[20:49:17] <fuzzie> yes
[20:49:26] <fuzzie> i am assuming that, tentatively
[20:49:30] <dhewg> hehe
[20:49:42] <dhewg> but that shouldnt gemrb from using paletted textures
[20:50:27] <dhewg> and a texture cache should be done by the backend obvioulsy
[20:50:55] <fuzzie> well, i think tomprince's thought is that the core has a better idea when some sprites are much less likely to be needed in the future
[20:51:01] <fuzzie> e.g. tiles which have been scrolled away from
[20:51:20] <fuzzie> but then we could just tell the backend to delete those sprites entirely
[20:51:40] <dhewg> yeah, somehow they need to talk to each other
[20:52:06] <fuzzie> but i keep sitting around theorising about this stuff, and have yet to actually try it
[20:52:19] <dhewg> hehe
[20:53:30] <tomprince> Either that, or at least have the sprite know how to regenerate the texture, if the backend handles it.
[20:54:17] <fuzzie> yes, it would be nice to also have that
[20:54:48] <fuzzie> the problem is that the cost of uploading to texture RAM is a *lot* less than the cost of hitting the disk to grab data
[20:55:27] <fuzzie> you really don't want to be going off and doing I/O because something decided to dump out BAM anim textures in the middle of a battle
[20:55:34] <fuzzie> so i think it's really non-trivial to get right
[20:56:30] <dhewg> let the core tell the backend about now-required textures and let the backend decide what to hold in gpu/ram and how to recreate via resourcemanager?
[20:57:01] <fuzzie> that kind of thing
[20:57:27] <fuzzie> but going via resourcemanager means a lot of special-casing
[20:57:50] <dhewg> why?
[20:58:05] <fuzzie> because now the backend has to know about the different sprite files
[20:58:32] <dhewg> i didnt even start looking at gfx related files :)
[20:58:36] <fuzzie> mm
[20:58:42] <fuzzie> it's difficult
[20:58:46] <dhewg> but whats the issue?
[20:58:56] <dhewg> frame based stuff for animations?
[20:58:58] <fuzzie> you have animation files (BAMs) full of RLEd 8bpp frames
[20:59:04] <dhewg> bingo!
[20:59:06] <fuzzie> and tiled files (TIS, MOS) for area backgrounds and GUI
[20:59:18] <fuzzie> and then normal sprites (BMP, PNG, etc)
[20:59:18] <tomprince> Well, it needs to now enough about the different formats it can get. Which in parctice is about the same as the file type.
[20:59:30] <fuzzie> oh and the PLT craziness i guess
[20:59:30] <tomprince> s/now/know/
[20:59:43] <fuzzie> well, the backend doesn't necessarily have to know about the tiled stuff
[20:59:52] <fuzzie> you could just hand each tile to the backend as a seperate sprite
[21:00:02] <dhewg> ugh
[21:00:41] <dhewg> is it safe to assume that if you need an animation, that all frames are required?
[21:00:53] <fuzzie> well
[21:01:05] <fuzzie> good question :)
[21:02:07] <dhewg> because if you have a known number of static frames for a single animation, dont split per frame
[21:02:21] <fuzzie> but you really don't want I/O to start pulling frames from disk in the middle of an anim
[21:02:33] <dhewg> gl wise its nicer to put every frame in one big texture and address those with texture coords
[21:02:56] <dhewg> tiles :)
[21:04:37] <dhewg> maybe multiple IE formats can be abstracted to a single sprite like entry with contains a list of texture coords
[21:04:48] <dhewg> *which
[21:04:49] <fuzzie> yeah, but *that* only works for gl
[21:05:24] <dhewg> the sdl plugin does software blending, right?
[21:05:26] <fuzzie> because the software blitter is a performance sinkhole which depends on RLE etc
[21:06:28] <dhewg> gemrb holds the rle stuff in mem and the gfx backend decodes while blitting?
[21:06:37] <fuzzie> yep
[21:06:42] <dhewg> ugh
[21:06:56] <fuzzie> i say 'blit', but it's a complex blend/tint thing with a lot of special effects
[21:07:59] <dhewg> bit it decodes and then applies effects?
[21:08:00] --- barra_away is now known as barra_home
[21:08:02] <fuzzie> there's alternative data/flags for opengl where doing it in opengl was too difficult though
[21:08:06] <fuzzie> it doesn't decode
[21:08:20] <fuzzie> it just does the whole thing directly from the RLEd data
[21:12:00] <fuzzie> i mean, for clarity, it only encodes runs of transparency
[21:12:14] <fuzzie> this is pretty typical for games of the era but i keep forgetting it's not too obvious to mention :P
[21:13:15] <fuzzie> ok that XNEG macro is insane
[21:15:00] <fuzzie> surely must be a better way to do that
[21:15:22] <fuzzie> other than finding some weeks to convert to tempaltes
[21:17:10] <-- boriskr has left IRC (Remote host closed the connection)
[21:23:49] <dhewg> the whole file is a beauty!
[21:24:53] <dhewg> looks like a little optimized asm wouldnt hurt there
[21:25:44] <wjp> the first step would be profiling it at a higher resolution to determine which blitting types need it the most
[21:26:14] <wjp> this define-magic produces quite a few different blitters from the same code
[21:27:02] <fuzzie> dhewg: how's your MIPS? :p
[21:27:23] <wjp> I wonder how much benefit SIMD on x86 could give
[21:27:38] <dhewg> my asm voodoo lacks on all archs :P
[21:28:02] <fuzzie> i must confess to not being too worried about the performance on x86
[21:28:06] <dhewg> but maintaining asm for multiple archs is a pita
[21:28:17] <wjp> no, it does seem to produce enough fps on desktop machines
[21:28:19] <fuzzie> since people seem to have managed 60fps
[21:28:38] <fuzzie> I mean, *I* never get 60fps, but I have long-sinced concluded that x86 machines hate me.
[21:28:47] <wjp> I got over a 100 while I was working on this in some moderately effect-heavy scenes
[21:29:04] <wjp> but it really depends a lot on the area, actors and effects and such
[21:29:11] <wjp> a few alpha effects kill performance
[21:30:17] <fuzzie> i wonder if we can do those in another way
[21:30:49] <fuzzie> but honestly the blitter code looks like it's going to be horribly ruined performance-wise by the shifting
[21:31:11] <wjp> is shifting expensive on mips?
[21:31:33] <wjp> or what do you mean?
[21:31:40] <fuzzie> it's shifting using non-constants
[21:31:58] <wjp> ah
[21:32:13] <wjp> I suppose they're often quite constant in practice
[21:32:17] <fuzzie> that should really be macroed
[21:32:35] <fuzzie> just insist on 32bpp or 565
[21:32:41] <fuzzie> will try that later
[21:32:59] <wjp> should be easy enough
[21:33:25] <fuzzie> well, also feel free to do it..
[21:33:28] <wjp> just make [rgb]{loss,shift} macros set by BPP16/32
[21:33:34] <fuzzie> mhm
[21:33:56] <fuzzie> oh i found that diseased/deactivated code by accident
[21:34:07] <wjp> or even just hardcoded consts for a first profile run
[21:34:30] <fuzzie> well, mr profiler says you're xoring in the core loop
[21:34:35] <fuzzie> mr profiler is very sad and not speaking to you
[21:34:55] <fuzzie> so might have to feed some cookies
[21:35:06] <wjp> hm?
[21:35:15] <wjp> oh, the negs
[21:35:39] <fuzzie> which is why i had this open at all
[21:36:06] <wjp> where is xor slow?
[21:36:07] <fuzzie> it looks like that can be hardcoded too, easily enough
[21:36:21] <fuzzie> well, i'm on powerpc
[21:37:01] <wjp> hardcoded? That'll double the number of cases again
[21:37:02] <fuzzie> the "while (XNEG((int)(endpix - pix)) > 0)" loop is what seems to be issue
[21:37:08] <fuzzie> yes :-/
[21:37:12] <wjp> or maybe only make xneg hardcoded
[21:37:18] <wjp> I suppose yneg is less important
[21:37:24] <fuzzie> definitely
[21:37:51] <wjp> so if we make the yneg always conditional, and hardcode the xneg it isn't so bad
[21:38:00] <wjp> but re-ordering the #defines is always a pain
[21:38:14] <wjp> I've considered a python script to generate the callers :-)
[21:38:35] <fuzzie> how exactly do you face yourself in the mornings again?
[21:38:58] <wjp> just be sleepy enough not to realize what you did the previous night
[21:39:11] <tomprince> Could perhaps do some template metaprograming to do it, instead. ;)
[21:39:11] <fuzzie> :)
[21:39:29] <wjp> yes
[21:39:30] <fuzzie> tomprince: see the "other than finding some weeks to convert to tempaltes" above ;p
[21:39:43] <wjp> I already did the tile renderer that way to make you happy :-)
[21:40:24] <fuzzie> and we are grateful :)
[21:40:49] <tomprince> Yes. But I was also thinking that template metaprogramming could be used to generate all the calls to all the combinations, rather than doing that in python. Although that sounds a bit insane.
[21:41:28] <fuzzie> the code being healthily sanity-free right now? :)
[21:43:57] <wjp> oh dear, template metaprogramming
[21:44:15] <tomprince> I was thinking that what I suggested was more of a boost::mpl level insanity.
[21:44:17] <wjp> but yes, that's a possibility :-)
[21:44:35] <fuzzie> boost::mpl is so great for scaring people
[21:44:45] <wjp> I'm going to avoid looking at that
[21:45:19] <tomprince> Please do (avoid that).
[21:45:40] <wjp> I suppose in this case with 4 parameters you'd just need 4 template functions with 0, 1, 2, 3, 4 template arguments and a simple if inside, with a final call to the blitter in the deepest one
[21:45:43] <fuzzie> wjp: mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na
[21:45:56] <wjp> oh, look at the time
[21:45:59] * wjp runs
[21:46:01] <fuzzie> majority of template parameters removed for sake of your sanity
[21:46:33] <tomprince> Although I wonder how much of the insanity of mpl could be reduced with C++11. Probably at least some.
[21:47:57] <fuzzie> variadic templates?
[21:48:05] <tomprince> Yes.
[21:49:31] <wjp> hm, 48 times #include "SDLVideoDriver.inl" currently
[21:50:12] <fuzzie> the xneg thing would only change the FLIP variants
[21:50:23] <fuzzie> so, 64? :p
[21:50:35] <lynxlynxlynx_> crap, corrupted a savegame
[21:50:41] <wjp> most are FLIP
[21:51:31] <fuzzie> :(
[21:52:03] <fuzzie> oh i see, even the non-flipped stuff goes through FLIP
[21:52:10] <fuzzie> no wonder it's showing up in profile
[21:52:10] <wjp> hm, kick me this weekend and I'll think about rearranging some stuff
[21:52:41] <fuzzie> will try :)
[21:52:42] <wjp> now I'll go and read a book to try and purge this from my mind so I can sleep :-)
[21:52:56] <wjp> good night
[21:54:52] <fuzzie> ninight
[22:32:00] <fuzzie> ok sometimes our effect.ids is not so helpful
[22:32:05] <fuzzie> $ grep 138 ~/gemrb/gemrb/override/bg2/effects.ids
[22:32:05] <fuzzie> 0x138 *Crash*
[22:32:10] <fuzzie> no, no that is not it :P
[22:34:02] <fuzzie> Avenger has annotated one relevant field in the original as 'super_atomic_speed_fighting_action', i suspect i've missed something fun
[22:39:50] <tomprince> super_atomic_speed_fighting_action? :)
[22:40:55] <fuzzie> apparently 'Super Atomic Speed Fighting Action=1' in [Game Options].
[22:41:06] <fuzzie> i suspect i can safely ignore this code :p
[22:43:56] <tomprince> Hey ... I want my super atomic speed fighting ... :(
[22:54:01] <Maighstir> That sounds... interesting. Any idea what it does?
[23:01:08] <fuzzie> applies some effect ever so often to attacking enemies
[23:02:00] <fuzzie> complete with way too much supporting code
[23:16:34] <fuzzie> anyway, ok, ai function: decoded.
[23:27:54] <-- lynxlynxlynx_ has left IRC (Remote host closed the connection)
[23:43:22] <-- Bo_Thomsen has left IRC (Quit: Leaving.)