[00:00:12] <tomprince> Removed in 178ef86730e016c3efdcabb9b7868f71def2f12f (looked at 'git log -SVolumeMusic' to find it)
[00:00:46] <brad_a> i see
[00:00:54] <brad_a> so i didnt break it :-P
[00:09:56] <-- kalimann has left IRC (Quit: Page closed)
[00:12:22] --> joneirik has joined #gemrb
[00:24:17] <-- lupinIII_ has left IRC (Ping timeout: 252 seconds)
[00:25:35] <-- edheldil_ has left IRC (Ping timeout: 265 seconds)
[00:27:32] <-- tomprince has left IRC (Ping timeout: 252 seconds)
[00:28:03] --> tomprince has joined #gemrb
[00:35:49] <brad_a> tomprince: ignoring that this should be multiple commits with actual messages
[00:35:57] <brad_a> http://dl.dropbox.com/u/13866402/quickpatch.patch
[00:36:08] <brad_a> be back later
[00:36:28] --> brad_a_ has joined #gemrb
[00:36:58] <-- basse has left IRC (Ping timeout: 276 seconds)
[00:40:03] <tomprince> I don't like changing the name of options. And I don't like grabbing all keys willy-nilly. Particularly since we try to force them to integers.
[00:40:08] <tomprince> s/we/you/
[00:40:17] <-- brad_a has left IRC (Ping timeout: 248 seconds)
[00:40:38] <-- brad_a_ has left IRC (Ping timeout: 240 seconds)
[00:44:13] --> basse has joined #gemrb
[00:57:34] --> kamui has joined #gemrb
[01:08:13] --> brad_a has joined #gemrb
[01:08:15] <brad_a> yes i was clearly in a hurry and not thinking
[01:08:45] <brad_a> now that ive had a moment to think it should be possible to just do vars->setAt after reading in Fullscreen
[01:09:16] <brad_a> as for setting the additional vars we can worry about that later
[01:14:04] <tomprince> I'd really like decrease, rather than increase the usage of vars. :(
[01:14:50] <brad_a> yes i know
[01:14:57] <tomprince> :)
[01:15:04] <brad_a> http://dl.dropbox.com/u/13866402/quickpatch.patch
[01:15:09] <brad_a> that should be better
[01:16:44] <brad_a> still uses vars but right now its about the only way to make gemrb.cfg override baldur.ini
[01:16:50] <brad_a> and its simple
[01:17:08] <brad_a> and realistically fullscreen get put into vars anyway
[01:18:01] <tomprince> I don't see why it should.
[01:23:05] <brad_a> because you think too long term :)
[01:23:33] <tomprince> :)
[01:23:40] <brad_a> but at the moment setting things in teh UI map to vars
[01:23:48] <brad_a> so thats why for now :)
[01:23:57] <brad_a> i think i botched that commit anyway
[01:24:06] <brad_a> but you should still get the picture
[01:24:47] <tomprince> Haven't had a chance to look yet.
[01:50:23] <tomprince> I just marked ~140 exams in ~40 min ... well one page of.
[01:57:02] <-- harijan has left IRC (*.net *.split)
[01:59:09] --> harijan has joined #gemrb
[02:00:29] <brad_a> you teach?
[02:00:39] <brad_a> i mean more than me :-P
[02:01:04] <tomprince> I'm a TA (working on my phd)
[02:02:06] <tomprince> So, eventually I'll probably be teaching a fair bit, yes.
[02:02:39] <brad_a> very nice
[02:04:31] <-- edheldil has left IRC (Remote host closed the connection)
[02:09:44] <tomprince> That patch working depends on the exact formulation of CONFIG_INT, which seems fragile. I had to go and look at the definition to see that it was in fact correct.
[02:12:06] <tomprince> And, your patch doesn't in fact make vars['Full Screen'] do anything.
[02:12:13] <-- fuzzie has left IRC (*.net *.split)
[02:12:40] --> fuzzie has joined #gemrb
[02:13:01] <brad_a> like i said im pretty sure i mucked it up :) but you do see what i intend
[02:13:19] <brad_a> i just want to make sure its an acceptable solution
[02:14:23] <tomprince> It isn't clear to me what you intend.
[02:15:47] <brad_a> well i intent to set full screen in vars so that when the baldur.ini loads it sees they key already has a vlaue and doesnt overwrite it
[02:16:16] <-- gembot has left IRC (*.net *.split)
[02:16:56] --> gembot has joined #gemrb
[02:17:33] <-- tomprince has left IRC (*.net *.split)
[02:17:34] <-- |Cable| has left IRC (*.net *.split)
[02:18:27] --> tomprince has joined #gemrb
[02:18:27] --> |Cable| has joined #gemrb
[02:19:39] <-- brad_a has left IRC (Quit: brad_a)
[03:43:23] <-- joneirik has left IRC (Remote host closed the connection)
[04:10:30] <tomprince> I think we probably want to create some kind of config class, that handles all these details. And then we could add a field to that whitelist data structure, saying whether and where a given options was read from.
[04:11:05] <tomprince> That will also make it easy to write changes back to where they came from, or not write them, if they are unchanged from the default.
[04:11:10] <tomprince> Well, "easy".
[04:12:36] <tomprince> Then we can even give it an interface to access config variables both directly from C++, and by name.
[04:49:00] <tomprince> Apprently the github network is comepletly messed up right now, but it is being fixed.
[05:08:47] --> kamui_ has joined #gemrb
[05:10:40] <-- kamui has left IRC (Read error: Connection reset by peer)
[05:32:34] --> harijan_ has joined #gemrb
[05:32:56] <-- harijan has left IRC (Ping timeout: 252 seconds)
[08:34:36] --> lynxlynxlynx has joined #gemrb
[08:34:36] --- ChanServ gives channel operator status to lynxlynxlynx
[08:38:11] --> edheldil has joined #gemrb
[08:38:11] --- ChanServ gives channel operator status to edheldil
[09:02:17] <lynxlynxlynx> what a coincidence
[09:02:30] <lynxlynxlynx> tomprince is a TA and gsoc is about to start
[09:18:36] <edheldil> hehe. Tom, would you mentor gsoc? :)
[09:19:31] <tomprince> I'll probably be quite busy with my thesis then. Plus, I have 1-2months when I am mostly offline. :(
[09:29:56] <wjp> besides mentoring, any good ideas for tasks?
[09:30:22] <tomprince> opengl plugin?
[09:30:45] <tomprince> logging cleanup maybe.
[09:32:24] <lynxlynxlynx> we already have a wiki page from the last brainstorming
[09:32:58] <lynxlynxlynx> http://www.gemrb.org/wiki/doku.php?id=developers:gsoc_ideas
[09:33:00] <lynxlynxlynx> minimal
[09:34:16] <tomprince> cleaning out GUIScript.cpp
[09:35:45] <lynxlynxlynx> that one sounds too easy
[09:35:54] <wjp> also too boring :-)
[09:35:56] <wjp> remote gemrb debugger (for debugging both gemrb and the games themselves) ?
[09:36:00] <lynxlynxlynx> fixing up the animation subsystem - too hard?
[09:37:38] <fuzzie> i think anything that we can't decide on an approach for ourselves is perhaps not a good idea
[09:37:48] --> demitar has joined #gemrb
[09:40:42] <lynxlynxlynx> that's the case for animations?
[09:40:43] <fuzzie> my argument elsewhere is basically 'anything which might end up as a refactoring nightmare is not a good idea'
[09:40:55] <fuzzie> and come to think of it, the opengl plugin might end up like that :/
[09:41:22] <lynxlynxlynx> btw, pst animations already work fine (since they're ini based) or do we lack something important there?
[09:41:31] <fuzzie> we don't actually obey the pst ini file
[09:41:43] <fuzzie> so that would be an obvious improvement
[09:42:10] <fuzzie> but the non-pst case is perhaps tricky because working out the details probably requires RE
[09:43:10] <wjp> opengl could work out, though. Even if the end result is not necessarily perfect, it'll be very useful and cool to have a proof of concept to work from
[09:43:35] <fuzzie> yes, I think a realistic end-point would be "a version of gemrb which uses opengl", rather than an opengl plugin for the existing code
[09:43:57] <wjp> yup
[09:44:14] <fuzzie> but I think "do we have anyone who can mentor?" is a good question
[09:44:23] <wjp> it is
[09:45:58] <fuzzie> i'm sure i could find time to help out in july, but i have exams scattered around june and maybe august, and vacation somewhere in there
[09:46:29] <tomprince> About the same for me.
[09:47:06] <tomprince> Wait, July and august for me.
[09:48:20] <fuzzie> am sure that collaboratively we could provide enough technical/design support, but someone else would have to do the actual mentoring bit.
[09:50:22] <lynxlynxlynx> i can take care of all the administration
[09:50:43] --> kettuz has joined #gemrb
[09:51:11] <lynxlynxlynx> i've updated the page a bit
[09:51:27] <-- kettuz has left IRC (Client Quit)
[09:55:12] <lynxlynxlynx> so far i've only submitted an org once - we had the same problems, getting people willing to mentor
[09:55:42] <lynxlynxlynx> they have some annoying guidelines too
[09:56:54] <lynxlynxlynx> hmm, i'll add "demo"
[10:10:12] <tomprince> I'd certainly be willing to help mentor.
[10:10:48] <tomprince> I was somewhat involved in bbot's last year, altough mostly indirectly.
[10:11:11] <tomprince> And probably will be somewhat involved again this year.
[10:12:15] <lynxlynxlynx> i'm reading the docs, but one of these problems was that there can be no officially shared mentorship
[10:16:44] <edheldil> lynxlynxlynx: I was just going to add it, though it's dubious whether it's really a coding project
[10:17:03] <edheldil> (demo)
[10:17:05] <lynxlynxlynx> i need to elaborate on it
[10:17:23] <lynxlynxlynx> the gui side is coding, the ingame scripting is coding
[10:17:47] <lynxlynxlynx> gui being also all the potential chargen
[10:18:20] <lynxlynxlynx> something much muc simpler than what the games have, but it has to get you into an area :)
[10:19:03] <lynxlynxlynx> hmm, so far it only mentions backups (eg secondary admin, mentor fallbacks)
[10:20:12] <edheldil> what about "developing a test suite"? ;-))))
[10:21:33] <tomprince> That would be great, but potentially quite difficult. At leat for unit testing.
[10:21:39] <tomprince> We have so much global state.
[10:23:41] <lynxlynxlynx> yeah, overwhelming and edheldil knows it :)
[10:23:55] <lynxlynxlynx> but great news from the next manual
[10:24:20] <lynxlynxlynx> mentorship can be shared, also there doesn't seem to be a ban on administration/mentorship overlap
[10:24:46] <lynxlynxlynx> "Some org admins also mentor students during GSoC, and that's perfectly fine; it is just highly recommended that folks know they have enough time to execute both roles simultaneously." and "Some organizations choose to assign more than one mentor to each of their students"
[10:26:07] <tomprince> We wouldn't want any more than one student, probably, in any case.
[10:28:48] <edheldil> what about tiled drawing for MOS?
[10:29:55] <tomprince> That semms like it would be a reasonable project.
[10:30:15] <lynxlynxlynx> that's the big resource hog, right?
[10:30:27] <edheldil> and a configuration frontend ala scummvm, realized within GemRB
[10:30:33] <lynxlynxlynx> can you write something more detailed on the page? I don't know the hairy bits
[10:31:31] <tomprince> I think the hairy bits are tracing the code, and figuring how to do caching.
[10:31:40] <tomprince> i.e. what to load and what to drop.
[10:32:28] <tomprince> That project could also invovle finishin my tiz importer. :)
[10:34:57] <tomprince> I wonder how long it takes to read a tile from a mos. I guess in any situation where we are concerned about memory pressure, we don't need to worry about spinning disks?
[10:35:23] <lynxlynxlynx> "spinning" :)
[10:36:00] <lynxlynxlynx> i think it's inevitable
[10:36:44] <tomprince> ?
[10:39:41] <tomprince> Are there any possbile projects that involve knowing IE?
[10:40:13] <tomprince> Perhaps there is somebody in the modding community, for example, that'd be interested.
[10:54:18] <lynxlynxlynx> most would be like that, but that's very a closed circle, so i think it is best left to them to make suggestions
[10:54:42] <lynxlynxlynx> i'll add the rest of the i18n work
[10:54:49] <lynxlynxlynx> maybe brad has some suggestions too
[11:01:59] <lynxlynxlynx> added Scalable party support
[11:02:08] <lynxlynxlynx> maybe thebigg would be willing to mentor that
[11:17:11] <-- edheldil has left IRC (Remote host closed the connection)
[11:36:59] --> edheldil has joined #gemrb
[11:36:59] --- ChanServ gives channel operator status to edheldil
[11:45:58] <edheldil> should I add the tiling support and sconfig frontend?
[11:49:17] <lynxlynxlynx> sure
[11:52:07] <tomprince> Maybe somebody should post solicitaions on g3 an shs, or wherever.
[11:57:53] <lynxlynxlynx> what do you mean?
[12:18:51] --> barra_home has joined #gemrb
[12:21:49] --> kamui has joined #gemrb
[12:25:29] <-- kamui_ has left IRC (Ping timeout: 244 seconds)
[12:43:37] --> Baldurer has joined #gemrb
[13:06:34] <fuzzie> tomprince: the mos issue is basically just that we're not using tiles at all anyway, right?
[13:06:53] <fuzzie> i don't think it's worth worrying about caching individual tiles there
[13:07:51] <fuzzie> but if you meant tis, then yes, presumably always nice free-seeking but maybe slowish I/O
[13:23:19] <-- lynxlynxlynx has left IRC (Ping timeout: 276 seconds)
[13:24:00] --> lynxlynxlynx has joined #gemrb
[13:24:01] <-- lynxlynxlynx has left IRC (Changing host)
[13:24:01] --> lynxlynxlynx has joined #gemrb
[13:24:01] --- ChanServ gives channel operator status to lynxlynxlynx
[13:39:24] --> barra_away has joined #gemrb
[13:41:41] <-- barra_home has left IRC (Ping timeout: 248 seconds)
[15:06:53] <-- Baldurer has left IRC (Ping timeout: 247 seconds)
[15:12:17] --> joneirik has joined #gemrb
[15:42:55] --> kettuz has joined #gemrb
[16:28:34] <-- kettuz has left IRC (Quit: Leaving)
[16:43:34] --> barra_home has joined #gemrb
[16:45:15] <-- barra_away has left IRC (Ping timeout: 260 seconds)
[17:01:58] <lynxlynxlynx> ok, to get back on the gsoc topic
[17:02:29] <lynxlynxlynx> if we want to participate, we need to decide on who would be willing to mentor already now, since it will set the tone for everything
[17:03:23] <lynxlynxlynx> from the current list, I can only completely mentor the demo
[17:03:51] <lynxlynxlynx> could also play a good role on the party one, if valerio would bear the gist of it
[17:04:22] <lynxlynxlynx> other than that, i can be just the usual moderator
[17:04:34] <fuzzie> well, I can *help* mentor anything technical but since I am likely rushed in June, can't do it all
[17:05:02] <lynxlynxlynx> i was thinking if you would pair with tomprince or someone else
[17:05:06] <-- joneirik has left IRC (Ping timeout: 245 seconds)
[17:05:26] <lynxlynxlynx> it's supposedly a 10h/week time input, but that can vary
[17:06:02] <lynxlynxlynx> edheldil: would you be willing to mentor the configuration one?
[17:06:18] <lynxlynxlynx> i see you haven't actually added it yet :P
[17:06:49] <tomprince> If I recall correctly, the designated mentor doesn't *need* to be an expert on the specifc project.
[17:07:33] <lynxlynxlynx> well sure, but i for example can't really do technical reviews of opengl or any ugly details for that matter
[17:07:39] <tomprince> I certainly won't have ~10h from mid-july on.
[17:07:48] <fuzzie> i thought it was 5h/week input
[17:07:55] <lynxlynxlynx> we just need to ensure that the potential student would get enough support
[17:07:55] <fuzzie> for one mentored student
[17:08:04] <fuzzie> with a maximum of two students per mentor
[17:08:44] <lynxlynxlynx> it helps that there's a few weeks between org acceptance and student allocation, so we can already pick out some favourites
[17:08:58] <lynxlynxlynx> of the self-initiative kind
[17:09:10] <lynxlynxlynx> less needed oversight :)
[17:09:21] <fuzzie> but I would think that collectively on IRC, we can deal with any technical issues that come along
[17:09:52] <lynxlynxlynx> sure, but we'll need to put down the names
[17:10:15] <fuzzie> well, I was going to say, it's not a guarantee that students will actually cooperate with that
[17:10:23] <lynxlynxlynx> i was thinking of applying for 2 slots if we get in; we can always just pick 1 if the turnout is bad
[17:10:51] <fuzzie> sounds reasonable
[17:11:19] <tomprince> I'd suggest just 1, since it isn't clear that we have mentoring resources for more than that.
[17:11:35] <fuzzie> well, I think it depends which kind of projects..
[17:11:53] <lynxlynxlynx> yes
[17:12:14] <fuzzie> for a technical project we probably don't want to do more than one, yes
[17:12:47] <lynxlynxlynx> i'll email the bigg about it, maybe we can outsource some of it :)
[17:14:06] <fuzzie> not sure of the viability of another
[17:15:22] <fuzzie> but I should be able to scrape up at least a few hours a week in July/August. will ponder on it after I've had dinner.
[17:15:34] <lynxlynxlynx> ok
[17:17:04] <edheldil> lynxlynxlynx: I am not sure I have expertise, and worse, time
[17:19:42] <lynxlynxlynx> ok, forget it then
[17:23:03] <CIA-41> GemRB: 03bradallred * r310521a3f983 10gemrb/gemrb/core/Interface.cpp:
[17:23:03] <CIA-41> GemRB: Interface: ensure GemRB.cfg values have priority over baldur.ini.
[17:23:03] <CIA-41> GemRB: when reading GemRB.cfg put Fullscreen and Bpp into the Vars dictionary and when reading baldur.ini only set a value if the key hasn't been set before.
[17:24:01] --> barra_away has joined #gemrb
[17:25:39] --> joneirik has joined #gemrb
[17:26:14] <-- barra_home has left IRC (Ping timeout: 252 seconds)
[17:26:27] --> brad_a has joined #gemrb
[17:27:36] <lynxlynxlynx> oh, another idea
[17:28:08] <lynxlynxlynx> we can ask for example the qt community for a mentor, since the dltcep rewrite doesn't concern us so much
[17:28:22] <lynxlynxlynx> hey brad_a
[17:28:28] <brad_a> hello
[17:30:24] <brad_a> re gsoc: i like the supporting of different resolutions out of the box
[17:31:39] <brad_a> alos would like to improve our internationalization without requiring user mods
[17:35:49] <lynxlynxlynx> http://www.gemrb.org/wiki/doku.php?id=developers:gsoc_ideas
[17:36:06] <lynxlynxlynx> please expand on that i18n topic, since you know the most by now
[17:36:22] <lynxlynxlynx> also, would you be willing to mentor? :)
[17:36:36] <brad_a> i'm not sure what mentoring is :-/
[17:36:53] <brad_a> but if i am qualified then probably
[17:39:09] <lynxlynxlynx> hehe
[17:39:36] <lynxlynxlynx> mentoring is helping fullfil the students destiny, i mean project
[17:39:58] <lynxlynxlynx> like what we grumpy existing developers do when new developers join us
[17:39:59] <tomprince> http://en.flossmanuals.net/GSoCMentoring/
[17:40:30] <brad_a> well im really more of a student myself, but i can help to the best of my abilities :)
[17:41:13] <lynxlynxlynx> http://en.flossmanuals.net/GSoCMentoring/what-makes-a-good-mentor/ <-- specifically this
[17:41:34] <lynxlynxlynx> i'm sure you're capable enough, but i'll need to know if you have enough time
[17:41:39] <brad_a> who would be the student?
[17:41:45] <brad_a> yes i should have enough time
[17:41:50] <lynxlynxlynx> awesome
[17:42:05] <lynxlynxlynx> we get to pick the student, since they have to write a proposal
[17:42:13] <brad_a> tho i am currently looking for a new job so i dont know what will happen if i get a new one
[17:42:16] <lynxlynxlynx> but first we have to get in :)
[17:43:02] <lynxlynxlynx> we were talking about max two projects, so the rest of us could fill in in times of need
[17:43:48] <brad_a> ok seems like that should work :)
[17:44:04] <tomprince> There is a max of 2 projects anyway, since they don't give out more to new orgs.
[17:45:50] <lynxlynxlynx> they say 5
[17:46:05] --> Yoshimo has joined #gemrb
[17:46:07] <-- brad_a has left IRC (Quit: brad_a)
[17:46:12] <lynxlynxlynx> anyway, applications are not possible yet and the deadline is 9.3., so we have plenty of time to prepare
[18:07:58] --> brad_a has joined #gemrb
[18:11:22] <brad_a> we could post a thread (with poll) on G3 asking the user what things they would like to see most.
[18:11:50] <brad_a> i think the arbitrary resolution thing would be in high demand :)
[18:11:57] <brad_a> also i think it would be interesting to implement
[18:13:02] <tomprince> What is this 'user' you are talking about? .... ;)
[18:14:21] <lynxlynxlynx> yep, it would be awesome
[18:14:34] <brad_a> well im judging from the fact we have mobile users with diffrent resolution screens etc
[18:15:17] <lynxlynxlynx> i think it would require extending the chu format though, so not really something you could get out of the box
[18:15:51] <brad_a> we couldnt do runtime calculations and adjustments with an existing chu?
[18:16:08] <brad_a> i obviously have no idea what a CHU really is
[18:16:41] <tomprince> Well, for gemrrb, the widescreen mod just modfies some chus/mos, right. Or is even just the single chu for the main interface?
[18:17:18] <tomprince> Instead of picking an existing chu by a "well known name", we could just generate it on the fly, couldn't we?
[18:17:34] <brad_a> that what i was thinking
[18:17:39] --> Avenger has joined #gemrb
[18:17:39] --- ChanServ gives channel operator status to Avenger
[18:17:56] <Avenger> brad, maybe i misunderstood you, but here is it: http://iesdp.gibberlings3.net/file_formats/ie_formats/chu_v1.htm
[18:18:50] <brad_a> yes i have just never really looked at to what CHU contains or anything. BAM is about the only IE format i have any understanding of :)
[18:20:32] <Avenger> some projects for gemrb: multiplayer support (big), tile cache (small), 3d avatars (dunno)
[18:21:35] <brad_a> 3d avatars?
[18:21:43] <tomprince> I don't think multiplayer support would be a good project, since we don't have a clear idea on how that would be implemented, and it would probably invovle invasive changes all through the code base.
[18:21:51] <brad_a> multiplayer would be awesome especially for mobile platforms
[18:21:51] --> joneirikb has joined #gemrb
[18:21:56] <tomprince> I think the other two are quite good ideas.
[18:22:04] <brad_a> but i must agree with tomprince about its viability at this time
[18:22:18] <brad_a> there will be other years for multiplayer :)
[18:23:08] <tomprince> I think it might be rasonable, if big, if we had a good handle on how to implement it.
[18:23:16] <Avenger> brad_a: 3d avatars is like directly taking in nwn/blender creature animations and rendering them on the fly
[18:23:32] <brad_a> that would be cool
[18:24:07] <Avenger> it is probably easy once drmccoy implements that part :D
[18:24:31] <fuzzie> opengl plugin would be obvious nice first step there
[18:24:35] <tomprince> That'd require someone with a demonstrated knowledge of 3d graphics, but otherwise would be excellent, I think.
[18:24:36] <lynxlynxlynx> yes, too big for gsoc
[18:24:54] <Avenger> lynx: i hope you meant the multiplayer part
[18:25:03] <-- joneirik has left IRC (Ping timeout: 246 seconds)
[18:25:12] <lynxlynxlynx> as for the resolution thing, i'm leaning more in the extended chu approach or complete vector graphics approach
[18:25:13] <fuzzie> don't overestimate the ability of most gsoc students
[18:25:35] <lynxlynxlynx> yes and they take time to acustom themselves and read code too
[18:25:41] <lynxlynxlynx> so it's less than the 3 months
[18:25:44] <Avenger> well, the tile cache should be the easiest, including the arbitrary resolutions
[18:26:11] <tomprince> lynxlynxlynx: So what is your thought about extend chus?
[18:26:16] <fuzzie> yeah, you could have a mix of performance/usability enhancements, like tile cache and resolutions and fixing options screens or whatever
[18:26:22] <lynxlynxlynx> i was thinking of adding min/max fields for width/height
[18:26:29] <Avenger> it is probably less than 50 lines of code and a weekend of work
[18:26:34] <fuzzie> and you could have opengl plugin, and I think just making that work is a whole gsoc
[18:26:37] <lynxlynxlynx> the problem would still be the bg mos
[18:26:56] <fuzzie> well, we really need to fix mos to be tiled anyway
[18:27:15] <Avenger> hmm, why?
[18:27:20] <fuzzie> Avenger: because they are tiled
[18:27:27] <fuzzie> and right now we waste huuuge amounts of RAM making them non-tiled
[18:27:34] <lynxlynxlynx> but the gui ones are not seamless
[18:27:54] <lynxlynxlynx> all fixed size
[18:27:56] <fuzzie> and once you made them tiled, it probably wouldn't be too hard to extend them in the middle by repeating whatever the widescreen mod does?
[18:28:12] <Avenger> they are tiled because of the compression needs, i doubt they are tiled once they are rendered
[18:28:29] <fuzzie> Avenger: if you decompress them, you have to make it 24bpp, it is a huge huge waste of RAM
[18:28:43] <fuzzie> the storage required for the decompressed world map is more than the entire original engine uses to display it
[18:29:56] <fuzzie> seriously, the MOS importer is at the top of my memory usage profile for gemrb :P
[18:30:04] <Avenger> adding directly rendered mos will complicate a lot of things, sprite2d won't be as simple as today
[18:30:30] <fuzzie> yes, well, that is why I didn't do it yet
[18:30:51] <tomprince> Well, I've wanted to refactor that for ages ...
[18:30:53] <fuzzie> because I was just going to add a TiledSprite which would draw itself, and everyone came up with objections
[18:31:45] <Avenger> can you make it a single common object without much overhead on normal sprites?
[18:32:03] <fuzzie> well, we only need it in certain places, the GUI code and the world map
[18:32:28] <tomprince> Well, I'd suggest having an abstract base sprite, and then having multiple variants with different rendering code paths.
[18:32:32] <fuzzie> and you could just have two implementations, one which uses a Sprite2D (to keep compat with BMP or whatever) and one which uses a MOSImporter
[18:32:38] <tomprince> We essentially have that, but done by hand right now.
[18:32:48] <fuzzie> and it doesn't have to touch the graphics layer at all.
[18:33:45] <Avenger> buttons and window backgrounds may take a .mos
[18:34:59] <Avenger> ok, having two implementations may be a good solution
[18:35:00] <fuzzie> where do buttons take .mos?
[18:35:26] <fuzzie> i know sliders take them
[18:35:29] <Avenger> loadscreen skull
[18:35:33] <fuzzie> and some edits and stuff
[18:35:49] <fuzzie> but I thought I'd just replace all the GUI code uses
[18:36:03] <Avenger> yes, actually many gui controls
[18:36:32] <fuzzie> tomprince: while I assume you are wanting to refactor Sprite2D *itself*, and I think I am back to agreeing with your previous "this is impossible to do without an OpenGL backend" point
[18:39:35] <fuzzie> although if you handle stuff like MOS with wrappers then Sprite2D can remain boiled down to "raw sprite" vs "bam sprite" + some magic reference maintenance, and maybe that's really not so dificult to do
[18:41:13] <tomprince> Well, my thought has always been to factor it into raw sprite + bam sprite + now tiled sprite.
[18:41:22] <fuzzie> but the backend doesn't need to know about tiled sprites, right?
[18:41:32] <tomprince> No.
[18:41:40] <fuzzie> am just thinking, the backend shouldn't know about *anything* which isn't performance-critical
[18:41:59] <fuzzie> and now I am wondering why we don't mmap() TIS files and let the filesystem cache deal with them
[18:42:35] <tomprince> Well, so raw and bam would be implemented in the backend, and tiled elsewhere.
[18:42:55] <tomprince> Is there mmap on win32?
[18:43:04] <fuzzie> well, there's an equivalent (MapViewOfFile or something)
[18:44:04] <tomprince> How about android/ios?
[18:44:12] <fuzzie> they're just *nix at that level
[18:44:43] --> barra__away has joined #gemrb
[18:45:10] <fuzzie> probably it isn't viable because the palette is a huge percentage of the data and we'd have to touch all the pages to work out the transparent colour, in our current design
[18:46:33] <tomprince> Well, if we rewrote TIS to just read from a file as needed (which would probably need its own sprite class) we could perhaps just drop in a MMappedStream and use that.
[18:47:05] <fuzzie> yes, that would be really nice, I think
[18:47:45] <-- barra_away has left IRC (Ping timeout: 260 seconds)
[18:50:26] <tomprince> So, looking at the widescreen mod, They just duplicate a 100px wide swath, so doing the same thing with 64px swath tilewise wouldn't be hard.
[18:54:00] <fuzzie> well, I imagine we could also just make a tile sprite wrapper class be cleverer
[18:54:19] <fuzzie> so in any case I hope that would work out
[18:57:07] <brad_a> yes i think we can do better
[18:58:08] --> Baldurer has joined #gemrb
[19:13:05] <-- Avenger has left IRC (Quit: bye!)
[19:15:39] <Yoshimo> what are you discussing with sprites and widescreen mod?
[19:16:03] <-- demitar has left IRC (Read error: Operation timed out)
[19:17:18] --> SiENcE has joined #gemrb
[19:18:23] <brad_a> participating in the google summer of code
[19:19:09] <brad_a> figuring out what we want to do for it and one of the options is supporting arbitrary resolutions ideally out of the box
[19:19:37] <Yoshimo> basically creating your own ui replacement that would be?
[19:19:55] <brad_a> no really
[19:20:22] <brad_a> i think doing runtime calculations and modification with data from the original CHU files
[19:21:04] <brad_a> maybe some of our own graphis tho… im nor entirely sure
[19:40:37] --- barra__away is now known as barra_home
[19:42:28] <lynxlynxlynx> it depends on how costly the autogeneration would be
[19:43:19] <lynxlynxlynx> i forgot that we don't actually have to change the real data, it could be done by control flags in the guiscripts
[20:06:49] --> barra_away has joined #gemrb
[20:08:38] <-- barra_home has left IRC (Ping timeout: 240 seconds)
[20:19:33] --> wrotek has joined #gemrb
[20:22:10] <-- wrotek has left IRC (Read error: Connection reset by peer)
[20:30:15] --> wrotek has joined #gemrb
[20:42:51] <-- wrotek has left IRC (Ping timeout: 248 seconds)
[21:04:59] --> kettuz has joined #gemrb
[21:12:09] <brad_a> instead of reordering the core loading im just going to move the auto cd path loop out of LoadConfig.
[21:12:31] <brad_a> at least i think that should acomplish what im trying to do
[21:12:45] <fuzzie> as long as you don't reorder it (it should be last)?
[21:13:31] <fuzzie> assuming autodetection doesn't need any of the CDs
[21:13:54] <brad_a> thats waht i intend to figure out
[21:16:20] <lynxlynxlynx> iirc we don't check any movies, so there's a good chance everything is on cd 1s
[21:17:37] <fuzzie> not sure what the plan is here; not very helpful if brad is about to sabotage all the CD paths
[21:17:59] <brad_a> heh :)
[21:18:55] <brad_a> ill let you review this before i commit it
[21:20:33] <fuzzie> well if you break it then I expect it'll be very obvious
[22:18:23] <brad_a> ok well nothing obvious broke :)
[22:40:21] <brad_a> fuzzie, tomprince: http://dl.dropbox.com/u/13866402/cdpaths.patch
[22:41:14] <brad_a> the best part is 22 insertions(+), 30 deletions(-)
[22:42:31] <brad_a> it may perhapps be better if that were split into 2 commits tho
[22:53:42] --> kingron has joined #gemrb
[23:00:22] <-- Yoshimo has left IRC (Quit: Yoshimo)
[23:07:27] <-- SiENcE has left IRC (Quit: cya)
[23:25:34] <-- Baldurer has left IRC (Ping timeout: 245 seconds)
[23:31:10] <-- barra_away has left IRC (Quit: Verlassend)
[23:43:18] <-- kettuz has left IRC (Quit: Leaving)
[23:58:07] <-- kingron has left IRC (Quit: Leaving)