[00:05] Dominus (Dominus@84.119.86.3) left #scummvm. [00:13] chkr (~chkr@p579326EC.dip.t-dialin.net) left irc: Remote host closed the connection [00:17] thirteenth (~thirteent@174-26-196-151.phnx.qwest.net) joined #scummvm. [00:33] Bokunenjin (~Bokunenji@5350EF2B.cm-6-1d.dynamic.ziggo.nl) joined #scummvm. [00:34] Nebrac (~Bokunenji@5350EF2B.cm-6-1d.dynamic.ziggo.nl) left irc: Ping timeout: 248 seconds [00:34] Nick change: Bokunenjin -> Nebrac [00:37] Will the ScummVM Android Market version be updated upon point release updates, or only major versions..? [00:37] D0SFreak (~D0SFreak@71-23-3-153.gar.clearwire-wmx.net) joined #scummvm. [00:53] thirteenth (~thirteent@174-26-196-151.phnx.qwest.net) left irc: Quit: Bebacklater!IMGONNABEemoOK??????? [01:02] sirlemonhead (bduncan22@86-45-5-182-dynamic.b-ras2.prp.dublin.eircom.net) left #scummvm. [01:22] SylvainTV (~Sylvain@ALille-553-1-44-168.w90-34.abo.wanadoo.fr) left irc: Ping timeout: 240 seconds [01:23] pok0j (~pok0j@abth18.neoplus.adsl.tpnet.pl) left irc: Remote host closed the connection [01:33] Johannes Schickel master * r6402d30 / graphics/fonts/ttf.cpp : GRAPHICS: Use monochrome font hinter for TTF's monochrome loading. - http://git.io/M5sjIg [01:33] Johannes Schickel master * r66c3279 / graphics/fonts/ttf.cpp : [01:33] GRAPHICS: Obtain pointer to dst surface after bounds checks in TTF renderer. [01:33] This should really make sure we are not drawing outside the surface bounds. - http://git.io/5cvccA [01:43] wjp, fuzzie: it seems it's pretty easy to allow non-anti-aliased TTF fonts (the GUI does a complete reinitialization when you switch the renderer mode, thus it will also try to load the fonts again), sadly it seems freetype2 has some problems with FreeSansBold when doing monochrome rendering, it places the "r" one pixel line too high... I'm getting this same problem with SDL_ttf and monochrome rendering there too... so that would make it look a ... [01:43] ... bit odd [02:01] Nebrac (~Bokunenji@5350EF2B.cm-6-1d.dynamic.ziggo.nl) left irc: Read error: Connection reset by peer [02:01] Nebrac (~Bokunenji@5350EF2B.cm-6-1d.dynamic.ziggo.nl) joined #scummvm. [02:06] D0SFreak (~D0SFreak@71-23-3-153.gar.clearwire-wmx.net) left irc: Ping timeout: 248 seconds [02:16] Javacat (~Javacat@unaffiliated/javacat) left irc: Quit: Please, try the fish [02:26] Tron_ (~Tron@srbk-5d8070ac.pool.mediaWays.net) joined #scummvm. [02:26] Tron (~Tron@srbk-5d804b34.pool.mediaWays.net) left irc: Ping timeout: 245 seconds [02:29] Vampire0_ (vampire@jEdit/Vampire) joined #scummvm. [02:32] risca (~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net) joined #scummvm. [02:32] Vampire0 (vampire@jEdit/Vampire) left irc: Ping timeout: 255 seconds [03:00] LordHoto (~loom@unaffiliated/lordhoto) left irc: Quit: night [03:02] Nebrac (~Bokunenji@5350EF2B.cm-6-1d.dynamic.ziggo.nl) left irc: Quit: HydraIRC -> http://www.hydrairc.com <- Nine out of ten l33t h4x0rz prefer it [03:07] Kenjin (~josesanto@2.80.236.227) joined #scummvm. [03:07] hello [03:17] clone2728 (~AndChat@157.sub-75-228-86.myvzw.com) joined #scummvm. [03:20] droid2727 (~AndChat@245.sub-75-193-189.myvzw.com) left irc: Ping timeout: 245 seconds [03:34] Dominus (~Dominus@84.119.86.3) joined #scummvm. [03:39] droid2727 (~AndChat@239.sub-75-250-102.myvzw.com) joined #scummvm. [03:44] clone2728 (~AndChat@157.sub-75-228-86.myvzw.com) left irc: Ping timeout: 255 seconds [03:58] Is there someone familiar with the Sky engine around? [04:02] droid2727 (~AndChat@239.sub-75-250-102.myvzw.com) left irc: Ping timeout: 255 seconds [04:07] droid2727 (~AndChat@201.sub-75-226-184.myvzw.com) joined #scummvm. [04:19] Kaidane (~Kaidane@adsl-065-005-218-152.sip.cae.bellsouth.net) left irc: Read error: Connection reset by peer [04:29] droid2727 (~AndChat@201.sub-75-226-184.myvzw.com) left irc: Ping timeout: 255 seconds [04:32] droid2727 (~AndChat@19.sub-75-228-67.myvzw.com) joined #scummvm. [04:32] droid2727 (~AndChat@19.sub-75-228-67.myvzw.com) left irc: Client Quit [04:52] risca (~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net) left irc: Quit: Lämnar [05:05] risca (~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net) joined #scummvm. [05:39] Nick change: Unseen2 -> unseen2 [05:42] Kenjin (~josesanto@2.80.236.227) left irc: Quit: Computer has gone to sleep [06:02] Nick change: Tron_ -> Tron [06:14] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) joined #scummvm. [06:16] ajax16384 (~ajax16384@ip138.net138.n37.ru) joined #scummvm. [06:16] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services. [06:20] dtcrshr (~datacrush@unaffiliated/datacrusher) left irc: Ping timeout: 260 seconds [06:22] dtcrshr (~datacrush@unaffiliated/datacrusher) joined #scummvm. [06:46] Herrman (wolter@p50911321.dip.t-dialin.net) left irc: Quit: “Ich bin Chuck Norris. Das war wohl Gotteslästerung :-O” [06:48] cyco (~cyco@82.113.98.227) joined #scummvm. [06:56] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) left irc: Ping timeout: 276 seconds [06:58] ajax16384 (~ajax16384@ip138.net138.n37.ru) left irc: Quit: ajax16384 [07:00] _sev (~sev@scummvm/undead/sev) left irc: Quit: This computer has gone to sleep [07:12] ajax16384 (~ajax16384@ip138.net138.n37.ru) joined #scummvm. [07:12] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services. [07:24] risca (~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net) left irc: Quit: Lämnar [07:32] Ouch, the Android port passes --gui-theme=scummmodern in a fake command line to scummvm_main. [07:50] ny00123 (~ny00123@bzq-79-176-216-88.red.bezeqint.net) joined #scummvm. [07:53] Nick change: appel_ -> appel1 [08:07] Strangerke (~Strangerk@cable-85.28.107.228.coditel.net) left irc: Disconnected by services [08:07] Strangerke (51f60aa1@gateway/web/freenode/ip.81.246.10.161) joined #scummvm. [08:07] #scummvm: mode change '+o Strangerke' by ChanServ!ChanServ@services. [08:08] Strangerke_ (~Strangerk@cable-85.28.107.228.coditel.net) joined #scummvm. [08:20] hi guys [08:21] morning [08:27] Action: Strangerke looks at scene 1330 in R2R and starts crying [08:27] Daaaaaamn [08:28] This thing will take me a month to reverse :'( [08:41] _sev (~sev@188.230.122.62) joined #scummvm. [08:41] _sev (~sev@188.230.122.62) left irc: Changing host [08:41] _sev (~sev@scummvm/undead/sev) joined #scummvm. [08:41] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services. [08:47] cyco (~cyco@82.113.98.227) left irc: Quit: cyco [08:51] cyco (~cyco@82.113.98.3) joined #scummvm. [08:53] Boom-shanka [08:57] madmoose: Boom shakala to you too! [09:10] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) joined #scummvm. [09:16] dtcrshr (~datacrush@unaffiliated/datacrusher) left irc: Ping timeout: 240 seconds [09:18] dtcrshr (~datacrush@unaffiliated/datacrusher) joined #scummvm. [09:19] dreammaster (~paulfgilb@C-59-101-229-34.bur.connect.net.au) joined #scummvm. [09:19] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services. [09:23] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) left irc: Ping timeout: 276 seconds [09:25] Nick change: unseen2 -> Unseen2 [09:25] dtcrshr (~datacrush@unaffiliated/datacrusher) left irc: Max SendQ exceeded [09:27] dtcrshr (~datacrush@unaffiliated/datacrusher) joined #scummvm. [09:29] dreammaster (~paulfgilb@C-59-101-229-34.bur.connect.net.au) left irc: Ping timeout: 240 seconds [09:30] dreammaster (~paulfgilb@C-61-68-180-191.bur.connect.net.au) joined #scummvm. [09:30] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services. [09:35] <_sev> wjp: as I see you've handled those MaximRussia's queue changes, right? [09:39] Kenryu (UPP@c-71-193-60-169.hsd1.ca.comcast.net) joined #scummvm. [09:39] Vaikungfu (UPP@c-71-193-60-169.hsd1.ca.comcast.net) left irc: Disconnected by services [09:39] Nick change: Kenryu -> Vaikungfu [09:40] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) joined #scummvm. [09:40] James|GlideM (~James|Gli@cpc2-mapp11-2-0-cust447.12-4.cable.virginmedia.com) joined #scummvm. [09:40] #scummvm: mode change '+v James|GlideM' by ChanServ!ChanServ@services. [09:45] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) left irc: Ping timeout: 272 seconds [09:45] _sev: I'm not sufficiently familiar with the code to be really confident about handling it yet [09:46] but I have put his code together with fuzzie's suggested change on a github branch in my repo there [09:46] wjp: re the last commit there: why is the update of the last time not the first thing in the block? [09:58] because I wasn't thinking straight :-) [09:58] well, I mean, you didn't change that, just thinking that if there's a FIXME maybe it would be a good first thing :) [09:59] I literally spent no time at all thinking about the fixme yet [09:59] but, yes [10:04] dtcrshr (~datacrush@unaffiliated/datacrusher) left irc: Ping timeout: 240 seconds [10:06] dtcrshr (~datacrush@unaffiliated/datacrusher) joined #scummvm. [10:29] D0SFreak (~D0SFreak@71-23-3-153.gar.clearwire-wmx.net) joined #scummvm. [10:30] kettuz (~kettuz@host-94-101-5-98.igua.fi) joined #scummvm. [10:43] D0SFreak (~D0SFreak@71-23-3-153.gar.clearwire-wmx.net) left irc: Ping timeout: 248 seconds [10:47] Action: ST is hearing rumors of T7G/11H PC (re-)releases... [11:02] <_sev> st: interesting [11:02] Indeed [11:02] Wonder if they will enhance the original MIDI music [11:03] Yes... I have a one track mind lol [11:03] James|GlideM: You could always enhance it yourself :P [11:03] Give me the MIDI and I can always take a look [11:04] We would have to get permission for release though! [11:05] Hmm. Could make things interesting... [11:05] Aye [11:06] Now where is my 7th Guest CD... [11:06] Action: James|GlideM looks [11:09] Looks like another trip to the coldest room of the house, the garage! [11:09] Hehe :) [11:09] brb [11:12] D0SFreak (~D0SFreak@72.1.88.158) joined #scummvm. [11:13] Hmmm I have the 11th Hour somewhere as well... [11:13] Oh well find them both later [11:16] 76 MIDI files [11:18] Heh. Didn't realise there was quite so many [11:19] Me niether [11:19] A lot of them are really short though [11:19] Well, if someone can do a clean rip of the MIDI files for me I can take a look ASAP [11:19] As I cant find my CD at the moment among all the dead spiders [11:23] Do we have any contacts regarding 7th guest _sev ? [11:23] Might be worth just seeing what happens with this pending release first [11:25] <_sev> James|GlideM: none I'm aware of [11:25] ok [11:26] _sev (~sev@scummvm/undead/sev) left irc: Quit: Leaving [11:26] spooky made contact with both Graeme and Rob originally. I've interacted once or twice via Twitter with the new Trilobyte (Rob is parrt of them) [11:26] What's their twitter accounts? [11:28] @trilobytegames is the most obvious one [11:30] OK leave it with me [11:31] dtcrshr (~datacrush@unaffiliated/datacrusher) left irc: Ping timeout: 240 seconds [11:32] Action: ST wonders if all the files are actually used o_O [11:32] Amazing how many bizarre listings there are [11:32] duplicates etdc [11:32] *etc [11:33] dtcrshr (~datacrush@unaffiliated/datacrusher) joined #scummvm. [11:33] The ones that share the names (but an 'a' prefix on one) is where the scripts choose depending on the music driver [11:34] Alyssa Milburn master * r7e9b011 / engines/hugo/parser.cpp : HUGO: Fix keyHandler (noticed by Strangerke). - http://git.io/u5LDVg [11:35] The rest, some have similarities but are slightly different [11:36] dreammaster (~paulfgilb@C-61-68-180-191.bur.connect.net.au) left irc: Quit: Leaving for the day [11:37] dtcrshr (~datacrush@unaffiliated/datacrusher) left irc: Max SendQ exceeded [11:37] Well the MIDI files I have are in pretty good shape, getting some nice choirs going etc in the main theme [11:38] Still need the full clean rip list though, dont trust these downloaded ones [11:39] dtcrshr (~datacrush@unaffiliated/datacrusher) joined #scummvm. [11:39] Smartnow (~Smartnow@unaffiliated/smartnow) left irc: Remote host closed the connection [11:40] James|GlideM: Original .xmi files I assume? [11:40] no MIDI [11:40] General MIDI [11:40] There an easy way to convert? :P [11:41] Not sure [11:41] dtcrshr (~datacrush@unaffiliated/datacrusher) left irc: Max SendQ exceeded [11:43] dtcrshr (~datacrush@unaffiliated/datacrusher) joined #scummvm. [11:45] _sev (~sev@188.230.122.62) joined #scummvm. [11:45] _sev (~sev@188.230.122.62) left irc: Changing host [11:45] _sev (~sev@scummvm/undead/sev) joined #scummvm. [11:45] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services. [11:51] Smartnow (~Smartnow@unaffiliated/smartnow) joined #scummvm. [12:00] Recording a single track now for example purposes [12:02] Kenjin (~josesanto@bl19-236-227.dsl.telepac.pt) joined #scummvm. [12:05] dtcrshr (~datacrush@unaffiliated/datacrusher) left irc: Ping timeout: 240 seconds [12:05] Hello [12:05] Hi [12:08] http://www.jameswoodcock.co.uk/7thGuest_JamesWoodcock_Test.mp3 [12:09] I have been reading the source of the Sky engine. I'm having a little trouble figuring out how the _skyDisk->loadFile(fileNr) works. I've been unsuccessful in calling this. Anyone around that is familiar with the Sky engine? [12:10] James|GlideM: Considering how "quick" that was for you, pity they didn't do similar for their iOS release. [12:10] James|GlideM: are you the james from the BASS enhanced soundtrack? :) [12:10] Yep [12:11] James|GlideM: cool. Thank you for that :) [12:11] Pleasure :) [12:12] ST, Well, if I can get permission for ScummVM maybe they will add support with the soundtrack to their iOS stuff [12:14] So i've been playing a bit with the Sky engine. And the getFileInfo(fileNr) that does a check in the sky.dnr file before reading stuff from sky.dsk always returns null for me. [12:15] James|GlideM: Their iOS port already loads external m4a's for all their music so should be easy to swap them over if they wanted [12:16] OK - just the hard part then of getting permission AND doing the actual enhancing :) [12:17] Right lunch time, speak to you later ST [12:17] cya :) [12:20] ( James|GlideM: just for comparison, a few instruments seemed a bit quiet but they are in the iOS music files too. guess I'm just used to the 7-11 soundtrack variant) [12:20] Kirben (kirben@c220-239-194-17.brasd3.vic.optusnet.com.au) left irc: Ping timeout: 240 seconds [12:21] dtcrshr (~datacrush@2801:88:f7a:100:240:a7ff:fe13:bf7) joined #scummvm. [12:21] dtcrshr (~datacrush@2801:88:f7a:100:240:a7ff:fe13:bf7) left irc: Changing host [12:21] dtcrshr (~datacrush@unaffiliated/datacrusher) joined #scummvm. [12:29] ST: you know when is the best time to ask engine related questions [12:29] ? [12:29] I agree, it was only a 15 minute enhancement :) [12:29] Kenjin: Depends on the engine [12:30] ST: Sky engine [12:31] Kenjin: you mean the sky engine doesn't work for you? [12:32] fuzzie: works fine :) I've been reading the source and playing with it a bit [12:32] Kenjin: Generally 'whenever Europe is awake' is a reasonable assumption - though that doesn't mean everyone's around ;) [12:32] it is not the best of engines to read, honestly.. [12:33] I just ask because if getFileInfo is always returning null then you would think the engine is not going to work at all. [12:34] fuzzie: I'm trying to read the file outside the engine [12:34] fuzzie: the engine is working fine [12:35] so you're creating a Disk object from your own code but you get no entries..? [12:35] cyco_ (~cyco@trir-4d0d9b78.pool.mediaWays.net) joined #scummvm. [12:36] cyco (~cyco@82.113.98.3) left irc: Ping timeout: 248 seconds [12:36] Nick change: cyco_ -> cyco [12:38] fuzzie: Something like that. I'm am able to read the sky.dnr file, read data into _dinnerTableArea and for instance get the game version [12:38] well, if you're not building this in the context of scummvm then it could be all manner of things [12:38] but when calling getFileInfo I don't ever get a hit. I'm missig something [12:39] fuzzie: yes indeed :/ [12:41] fuzzie: something in the getFileInfo function is eluding me. For what I understand it simply iterates over _dinnerTableArea, _dinnerTableEntries times until if finds the fiven fileNr [12:41] s/fiven/given [12:41] yes, but e.g. what did you do to replace READ_LE_UINT16? [12:42] fuzzie: I tried putting the related code in my file also. [12:43] I think it's pretty impossible to help without seeing the actual code as you modified it, maybe you could e.g. pastebin the relevant bits you modified/copied. [12:43] fuzzie: will do. thanks for the patience ;) [12:48] fuzzie: http://pastebin.com/gUUyuy0M [12:50] right, so your READ_LE_UINT16 is incorrect [12:50] just call your READ_UINT16 directly from getFileInfo, I guess [12:50] fuzzie: I'll try [12:51] for context, LE stands for little endian [12:51] assuming you're on a little-endian platform but the fact you haven't mentioned anything is probably indicating that :) [12:51] fuzzie: yeah OS X intel [12:52] the sky code is so very very horrible here [12:52] I've tried different fileNr, from the ones found on the source and I still can't get a hit [12:52] fuzzie: I've tried reading the original. This one looks much better in compariso [12:52] well, you can just put a print in the loop which prints the values of READ_UINT16(dnrTbl16Ptr) [12:53] so you know what's in the array [12:53] fuzzie: I've tried that with the previous call of READ_LE_UINT16. I'll try again [12:53] and, yes, but the sane way to do this would be to parse all this information into a struct at startup time [12:53] the whole engine is full of this weird pointer manipulation [12:54] and I keep getting really bad bug reports on sky and I can't reproduce and it's impossible to see if there are Very Bad Bugs lurking somewhere in this stuff, so it is not my friend :) [12:55] fuzzie: hehe ;) [12:56] oh and of course you're returning the wrong value from getFileInfo (should be a pointer) [12:57] but it would be terribly bad luck if that truncation happened to end up as zero [12:57] so the print seems correct, since the first value is "5097" which give the game version. Still any value I see in the source used in _skyDisk->loadFile does not show [13:01] the first value shoudln't be 5097 [13:01] ah, you are off-by-one [13:01] it shouldn't? [13:01] you aren't reading the entry count from the file. [13:01] which is the first uint32 (4 bytes). [13:03] fuzzie: so after the first 4 bytes, is where I need to check for 2 bytes for the getFileInfo match? [13:03] well, yes, in that the _dinnerTableEntries start only after the first 4 bytes [13:04] fuzzie: but if I read the entire file as uint16 shouldn't that work? [13:05] sure, you can just skip the first two uint16s [13:05] fuzzie: thats what I'm doing in the getFileInfo, but am just printing everything [13:06] the first two uint16s give 5097 and 0 [13:06] and none of the following uint16 match the fileNr [13:07] there's something evil behind the scenes at work here [13:07] you can't do that if you have the '+= 4' in there still [13:08] but you can just add a '+2' after the _dinnerTableArea in your getFileInfo [13:10] fuzzie: awsome! [13:10] works? [13:10] yeah [13:10] i got a hit! [13:10] :) [13:10] fuzzie: hm, had almost forgotten about that sky save/load issue. Did you get more reports? [13:10] yes [13:11] any actual broken savegames to try? [13:11] but it is difficult to distinguish them from the issue where the autosave is corrupt due to not existing by default [13:11] no, that kind of thing would be far too useful [13:11] remind me why we didn't fix that in 1.4.1? :-) [13:11] (I had completely forgotten...) [13:11] well, I don't get the whole thing [13:12] for some reason we [13:12] 're not using target ids there [13:12] but instead we're just sort of playing guess-the-version [13:12] and it makes my head explode [13:13] fuzzie: this change also works dnrTbl16Ptr += 2 [13:13] Kenjin: if you do that, you might get incorrect pointers for some files [13:13] oh [13:13] fuzzie: but why do I need to add the +2 in _dinnerTableArea [13:14] Kenjin: because you need to skip the 4 bytes (2 uint16s) that are not part of the dinnerTableArea but you are loading anyway [13:14] but you only need to do that *once* [13:15] wjp: so I guess listSaves doesn't know the version number, only the target name, and so we have no way of working out what the savegame filename might be.. [13:15] oh, would you look at that.... http://www.dotemu.com/en [13:15] but then of course it doesn't know that for any of the other savegames either, so we could just shove them all in there [13:15] fuzzie: why does that not happen in the engine? Am I missing something in my code? [13:16] Kenjin: it does happen in the engine [13:16] as I said, you're not reading the entry count from the file. the engine is. [13:17] fuzzie: sorry. I meant that my issue didn't happen in the engine. I understand [13:18] fuzzie: _dinnerTableEntries = dnrHandle->readUint32LE() :) [13:18] yes :) [13:18] was about to paste that, to be clear, in fact [13:19] fuzzie: I tried to reproduce that bit on my code, but was always getting 0 [13:19] fuzzie: what would be the correct way? since I'm not using Common::File *dnrHandle [13:20] you can just fread() 4 bytes into &_dinnerTableEntries, since it's LE [13:24] fuzzie: I could've sworn I trying that :P [13:24] s/trying/tried [13:26] fuzzie: everything making much sense now ;) [13:26] droid2727 (~AndChat@137.sub-75-193-18.myvzw.com) joined #scummvm. [13:26] #scummvm: mode change '+o droid2727' by ChanServ!ChanServ@services. [13:28] kettuz (~kettuz@host-94-101-5-98.igua.fi) left irc: Remote host closed the connection [13:29] cyco (~cyco@trir-4d0d9b78.pool.mediaWays.net) left irc: Quit: cyco [13:33] pok0j (~pok0j@abtf183.neoplus.adsl.tpnet.pl) joined #scummvm. [13:41] Smartnow (~Smartnow@unaffiliated/smartnow) left irc: Remote host closed the connection [13:46] cyco (~cyco@trir-4d0d9b78.pool.mediaWays.net) joined #scummvm. [14:04] Smartnow (~Smartnow@unaffiliated/smartnow) joined #scummvm. [14:14] Schnaks (~Schnaks@pD958B411.dip.t-dialin.net) left irc: Quit: Schnaks [14:20] giucam (~giulio@adsl-ull-175-252.49-151.net24.it) joined #scummvm. [14:46] So, who's gonna be at FOSDEM this weekend? Maybe we shoudl agree on a meeting place or signal or something? [14:49] Juggie (~Juggie@unaffiliated/juggie) left irc: Ping timeout: 245 seconds [14:50] Juggie (~Juggie@unaffiliated/juggie) joined #scummvm. [14:53] Smartnow (~Smartnow@unaffiliated/smartnow) left irc: Read error: Operation timed out [14:54] Smartnow (~Smartnow@unaffiliated/smartnow) joined #scummvm. [14:57] Nick change: Unseen2 -> unseen2 [15:00] ajax16384 (~ajax16384@ip138.net138.n37.ru) left irc: Quit: ajax16384 [15:08] LordHoto (~loom@unaffiliated/lordhoto) joined #scummvm. [15:08] #scummvm: mode change '+o LordHoto' by ChanServ!ChanServ@services. [15:14] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) joined #scummvm. [15:27] TAS-2012v (~TAS_2012x@h76n2fls31o286.telia.com) joined #scummvm. [15:27] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) left irc: Ping timeout: 276 seconds [15:32] towerk (~K@pool-96-244-226-235.bltmmd.fios.verizon.net) left irc: Remote host closed the connection [15:39] P2E (~tgz@74.60.157.211) left irc: Quit: power outage [15:43] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) joined #scummvm. [15:45] TAS-2012v (~TAS_2012x@h76n2fls31o286.telia.com) left irc: Ping timeout: 276 seconds [15:49] risca (~risca@wi-secure-2685.cc.umanitoba.ca) joined #scummvm. [16:04] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) left irc: Ping timeout: 276 seconds [16:23] WNivek (~WNivek@16.sub-174-252-5.myvzw.com) joined #scummvm. [16:26] Nick change: unseen2 -> Unseen2 [16:32] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) joined #scummvm. [16:44] hey ther WNivek [16:45] Heya [16:52] TAS-2012v (~TAS_2012x@h76n2fls31o286.telia.com) joined #scummvm. [16:53] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) left irc: Ping timeout: 276 seconds [16:53] WNivek (~WNivek@16.sub-174-252-5.myvzw.com) left irc: Quit: Bye [16:55] WNivek (~WNivek@16.sub-174-252-5.myvzw.com) joined #scummvm. [16:56] wrong button. >.> [16:56] heh [16:56] dtcrshr (~datacrush@unaffiliated/datacrusher) left irc: Ping timeout: 245 seconds [16:57] TAS-2012v (~TAS_2012x@h76n2fls31o286.telia.com) left irc: Read error: Connection reset by peer [16:58] Javacat (~Javacat@unaffiliated/javacat) joined #scummvm. [16:59] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) joined #scummvm. [17:00] _sev (~sev@scummvm/undead/sev) left irc: Quit: This computer has gone to sleep [17:02] Juggie (~Juggie@unaffiliated/juggie) left irc: Ping timeout: 252 seconds [17:02] dtcrshr (~datacrush@unaffiliated/datacrusher) joined #scummvm. [17:03] Juggie (~Juggie@unaffiliated/juggie) joined #scummvm. [17:08] dtcrshr (~datacrush@unaffiliated/datacrusher) left irc: Max SendQ exceeded [17:08] MetalSnake (~MetalSnak@77-22-219-166-dynip.superkabel.de) joined #scummvm. [17:09] dtcrshr (~datacrush@unaffiliated/datacrusher) joined #scummvm. [17:10] Strangerke (51f60aa1@gateway/web/freenode/ip.81.246.10.161) left irc: Quit: Don't forget GSoC 2012! [17:10] Nick change: Strangerke_ -> Strangerke [17:18] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) left irc: Ping timeout: 256 seconds [17:18] ajax16384 (~User@ip216.net175.n37.ru) joined #scummvm. [17:18] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services. [17:18] Dominus (~Dominus@84.119.86.3) left irc: Quit: Leaving. [17:19] Dominus (~Dominus@84.119.86.3) joined #scummvm. [17:19] risca (~risca@wi-secure-2685.cc.umanitoba.ca) left irc: Ping timeout: 240 seconds [17:32] droid2727 (~AndChat@137.sub-75-193-18.myvzw.com) left irc: Remote host closed the connection [17:41] SylvainTV (~Sylvain@ALille-553-1-44-168.w90-34.abo.wanadoo.fr) joined #scummvm. [17:41] #scummvm: mode change '+o SylvainTV' by ChanServ!ChanServ@services. [17:43] WooShell (woo@178-27-165-32-dynip.superkabel.de) joined #scummvm. [17:44] nöbend [17:45] woo! [17:45] hoo! [18:07] Hkz (~Hkz@2001:470:c89a:2:21c:c0ff:fedc:e508) joined #scummvm. [18:07] #scummvm: mode change '+o Hkz' by ChanServ!ChanServ@services. [18:10] sirlemonhead (~bduncan22@86-45-5-182-dynamic.b-ras2.prp.dublin.eircom.net) joined #scummvm. [18:15] kriskelvin (~peter@p54B331DF.dip.t-dialin.net) joined #scummvm. [18:18] Strangerke (~Strangerk@cable-85.28.107.228.coditel.net) left irc: Ping timeout: 272 seconds [18:57] kriskelvin (peter@p54B331DF.dip.t-dialin.net) left #scummvm ("WeeChat 0.3.6"). [18:58] James|GlideM (~James|Gli@cpc2-mapp11-2-0-cust447.12-4.cable.virginmedia.com) left irc: Read error: Connection reset by peer [19:02] kriskelvin (~peter@p54B331DF.dip.t-dialin.net) joined #scummvm. [19:15] Smartnow (~Smartnow@unaffiliated/smartnow) left irc: Remote host closed the connection [19:21] syke (~matt@nat-sv.bluecoat.com) joined #scummvm. [19:21] #scummvm: mode change '+o syke' by ChanServ!ChanServ@services. [19:21] y0 [19:36] digitall (~digitall@cpc2-hitc2-0-0-cust28.9-2.cable.virginmedia.com) joined #scummvm. [19:36] #scummvm: mode change '+o digitall' by ChanServ!ChanServ@services. [19:46] kriskelvin (~peter@p54B331DF.dip.t-dialin.net) left irc: Quit: off to see the wizard [19:46] kriskelvin (~peter@p54B331DF.dip.t-dialin.net) joined #scummvm. [19:47] Hkz (~Hkz@2001:470:c89a:2:21c:c0ff:fedc:e508) left irc: Read error: Connection reset by peer [20:14] Dominus (Dominus@84.119.86.3) left #scummvm. [20:14] Dominus (~Dominus@84.119.86.3) joined #scummvm. [20:16] Smartnow (~Smartnow@unaffiliated/smartnow) joined #scummvm. [20:21] P2E (~tgz@74.60.157.211) joined #scummvm. [20:32] Hkz (~Hkz@2001:470:c89a:2:21c:c0ff:fedc:e508) joined #scummvm. [20:32] #scummvm: mode change '+o Hkz' by ChanServ!ChanServ@services. [20:41] {V} (~{V}@174-76-ftth.onsneteindhoven.nl) left irc: Ping timeout: 240 seconds [20:41] {V} (~{V}@174-76-ftth.onsneteindhoven.nl) joined #scummvm. [20:44] droid2727 (~AndChat@69.sub-75-198-223.myvzw.com) joined #scummvm. [20:44] #scummvm: mode change '+o droid2727' by ChanServ!ChanServ@services. [20:49] fuzzie: annoyingly I don't seem to get your ugly corner problem here with opengl/4444, so I probably can't properly test if that blendPixelPtr alpha change has any bad side effects [20:50] wjp: the OpenGL backend might disable alpha blending when rendering the overlay [20:50] I am still not sure about all that ;-) [20:50] hennymcc (~hennymcc@p57A8B807.dip.t-dialin.net) joined #scummvm. [20:50] at least the GMM gives some odd blackness around the borders over here, but maybe that's because it's 1555 or something like that, dunno [20:51] hennymcc (~hennymcc@p57A8B807.dip.t-dialin.net) left irc: Client Quit [20:52] D0SFreak (~D0SFreak@72.1.88.158) left irc: Ping timeout: 248 seconds [20:52] hm, I get a black rectangle behind the GMM here [20:52] but that's unaffected by blendPixelPtr's alpha change [20:52] hm it must be using some kind of alpha blending [20:52] James|GlideM (~James|Gli@cpc2-mapp11-2-0-cust447.12-4.cable.virginmedia.com) joined #scummvm. [20:52] #scummvm: mode change '+v James|GlideM' by ChanServ!ChanServ@services. [20:53] it seems clearOverlay just sets all data to 0 and there is definitly game screen around the GMM, so it can't do any faking I guess [20:53] ajax16384 (~User@ip216.net175.n37.ru) left irc: Read error: Connection reset by peer [20:59] wjp: did you make the OpenGL backend say it supports kFeatureOverlaySupportsAlpha? in case that makes any difference [21:00] I can't see any code actually using that though... so I am not sure why we have it or what gone wrong there [21:04] _sev (~sev@109.87.142.103) joined #scummvm. [21:04] _sev (~sev@109.87.142.103) left irc: Changing host [21:04] _sev (~sev@scummvm/undead/sev) joined #scummvm. [21:05] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services. [21:11] hm, I actually seem to be having trouble getting 4444 [21:12] this code is confusing me [21:12] it's not only confusing you, trust me ;-) [21:13] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) joined #scummvm. [21:13] wjp: I take setting _overlayFormat to RGBA4444 by using the same value as in getGLPixelFormat does not work? [21:14] right before you said that I noticed the existence of _overlayFormat :-) [21:14] D0SFreak (~D0SFreak@71-23-3-153.gar.clearwire-wmx.net) joined #scummvm. [21:15] I guess I was fiddling with the game mode [21:17] now I get ugly corners, yay [21:17] but the black rectangle behind the GMM is gone [21:17] great :-) [21:17] well... [21:17] yeah that black rectangle is there because the standard overlay format does not have an alpha channel and the OpenGL backend doesn't copy the screen contents into the overlay on clearOverlay [21:18] (or rather just have an alpha channel with 1 bit and the copyRectToOverlay code always sets the bit to 1 when copying data) [21:20] hm, "for correct overlay drawing"... [21:20] given that it's _not_ drawing it correctly, that seems a bit suspect [21:20] I don't know what that comment talks about either [21:20] wonder if the incorrect drawing is that blendPixelPtr thing [21:21] hm [21:21] running PC-Lint on the scumm [21:21] code [21:21] can someone verify if this is real? [21:21] that blendPixelPtr bug was already there when that "correct drawing" "fix" was applied [21:21] TAS_2012v (~TAS_2012x@h76n2fls31o286.telia.com) left irc: Ping timeout: 244 seconds [21:22] what blendPixelPtr bug? [21:22] the ugly-corner one [21:22] (blending both colour and alpha channels, instead of keeping dst alpha unchanged) [21:22] this one: https://github.com/wjp/scummvm/commit/a59c00b34dac3975d3d6e7abe1b65a649fac6e6d [21:23] is keeping the dst alpha channel unchanged really sensible? [21:23] yes? [21:23] During Specific Walk: [21:23] File engines/scumm/insane/insane.cpp line 776: Scumm::Insane::loadSceneData(?, [21:23] 0, 2) #2 [21:23] File engines/scumm/insane/insane_scenes.cpp line 532: Scumm::Insane::smlayer_loadSound(61, [21:23] 0, 2) #401 [21:23] File engines/scumm/insane/insane.cpp line 1137: Scumm::Insane::readArray(61) [21:23] #318 [21:23] File engines/scumm/insane/insane.cpp line 1395: Scumm::ScummEngine_v6::readArray(?, [21:23] 0, 61) #324 [21:23] engines/scumm/script_v6.cpp 422 Warning 416: Likely creation of out-of-bounds [21:23] pointer (61 beyond end of data) by operator '[' [Reference: file [21:23] engines/scumm/script_v6.cpp: lines 413, 422; file engines/scumm/insane/insane.cpp: [21:23] lines 1137, 1395; file engines/scumm/insane/insane_scenes.cpp: line 532] [21:23] engines/scumm/script_v6.cpp 413 Info 831: Reference cited in prior message [21:23] engines/scumm/script_v6.cpp 422 Info 831: Reference cited in prior message [21:23] engines/scumm/insane/insane.cpp 1137 Info 831: Reference cited in prior [21:23] message [21:23] engines/scumm/insane/insane.cpp 1395 Info 831: Reference cited in prior [21:23] ugh [21:23] message [21:23] it might make more sense to put that into a text file/bug report [21:23] pastebin please [21:23] engines/scumm/insane/insane_scenes.cpp 532 Info 831: Reference cited in prior [21:23] message [21:24] this way it's pretty much just only spamming this channel [21:24] Action: wjp enlarges the window to see what he was talking about :-) [21:24] LordHoto: I'm making a video on how to quickly use PC-Lint, and using scummvm as the example project [21:24] the report looks real to me, I just want to verify [21:25] wjp: that is sensible? I see, I mean after all for shadows around the GMM for example we need to make sure we produce a correct alpha value to have some proper blending effect [21:25] shadows are different [21:25] but maybe that blendPixelPtr is something different [21:26] hrm [21:27] the edges of the GMM and the shadow of the GMM need dst alpha changes, but drawing inside dialogs doesn't [21:27] syke: does it look real? [21:27] fuzzie: it does to me, but I would like a second opinion. [21:28] i mean, there's an out-of-bounds check right above it.. [21:28] wjp: probably yes, I don't know too much about that code, just wondering right now how you do the transparency effect of dialogs in the classic theme [21:28] "you"? :-) [21:29] you! [21:30] it might do just a filling with predefined alpha values [21:30] (and do custom blending in the case of there's no usable alpha channel) [21:30] hm no I guess it must always do custom blending, oh well [21:31] wjp: could you try to open the GMM with classic theme with that RGBA4444 overlay and tell me whether you can see through the dialog background? [21:32] yes, and you can [21:32] well, I :-) [21:32] works on android [21:32] well [21:32] Kaidane (~Kaidane@adsl-065-005-218-152.sip.cae.bellsouth.net) joined #scummvm. [21:32] Sorry being nosey, but what are you guys up to currently? :) [21:32] assuming I have this one patched right [21:33] but that blendPixelPtr change breaks it and makes it fully transparent :-( [21:33] wjp: the one you gave me? [21:33] I suspected so, since the overlay is fully transparent after clearing [21:33] (which is unsurprising given what we know I guess) [21:33] fuzzie: yes [21:33] intrsting [21:33] probably this must be patched wrong then [21:33] James|GlideM: I am busy being freezing cold. [21:34] fuzzie, Yes the temperature has dipped quite wildly in the UK although I have no idea where you are from? [21:34] The other two here have successfully being suckered into looking at my alpha issues, I imagine. [21:35] wjp: well I'm sure you will have some good idea on how to fix this ;-) [21:35] Right now I am back in Leiden, where it's a blistering -7C or so outside. [21:35] eeeek [21:35] Leiden is a pretty good word for that ;-) [21:37] wjp: I suspect that the current alpha blending in blendPixelPtr is somehow connected to the classic GUI thingy [21:37] maybe [21:37] would have to see how old it is [21:38] in any case you'd need separate modes for drawing the dialog background and the widgets [21:38] since only the former should let whatever is behind the dialog shine through [21:39] the widgets should be transparent too I think [21:39] Kenryu (UPP@c-71-193-60-169.hsd1.ca.comcast.net) joined #scummvm. [21:39] Vaikungfu (UPP@c-71-193-60-169.hsd1.ca.comcast.net) left irc: Disconnected by services [21:39] Nick change: Kenryu -> Vaikungfu [21:39] but maybe your point was a different one? [21:39] drawing the widgets might be just simply drawing the outline/border of them [21:39] for classic, yes [21:40] coo [21:40] but an AAed line shouldn't make it more transparent [21:40] ah you talk about drawing the modern GUI widgets and the classic GUI dialog backgrounds [21:40] fuzzie: this one is real: http://pastebin.com/JMdBqXkH [21:41] hm, or maybe an AAed line _should_ make it more transparent? Ugh, need to think about this more later [21:41] :-) [21:42] syke: really? shouldn't iseVoiceChannel be false if channel >= 4 and thus there should be no out of bounds read for SID_REG_OFFSET [21:43] syke: (since it actually should never go into the branch starting with line 488) [21:44] syke: oh it's even if channel >= 3 [21:44] ugh, that disconnect between isVoiceChannel and channel is weird [21:44] syke: see line 394 (updateFreq) [21:45] I don't see why this code needs that isVoiceChannel though, I mean it could do the check local to readSongChunk [21:45] but I don't think I should really take a closer look at that code ;-) [21:46] isVoiceChannel should probably just be killed [21:46] probably [21:46] unless channel is sometimes randomly changed? [21:46] don't think so [21:46] anyway, bed time. Good night [21:47] night [21:47] LordHoto: shit, you're right [21:47] I'll bet a dollar that lint is tracking locals and parameters, but not fields [21:47] pff just a dollar ;-) [21:47] figure of speech ;) [21:48] hm [21:48] I thought it did... [21:48] anyway that code really isn't in a good shape, seeing how it uses isVoiceChannel [21:50] that at least seems a very error prone way of handling this [21:50] well, yes. it looks like that POD should be wrapped with a class, at the least [21:51] (to my fresh eyes) [21:51] one could just replace the isVoiceChannel checks with "channel < 3" checks for a very simple solution [21:51] duplication [21:51] sure [21:51] you want to say something like channel.isVoice() [21:52] if (channel.isVoice()) { ... } [21:52] you could also move isVoiceChannel to that method locally and do the channel < 3 check at the start [21:52] I don't think that code uses any object oriented design [21:52] no time like the present ;) [21:52] there are some POD wrapped in classes [21:52] but overall, it does look procedural [21:52] just remember, if you break the code, you get burnt at the stake [21:53] like most of our engine code I think [21:54] fuzzie: don't worry, we'll all blame it to you [21:55] the nice thing is that you can do stuff like this incrementally [21:56] anyways, looks like a bug I need to report to Gimpel [22:00] Kirben (kirben@c220-239-194-17.brasd3.vic.optusnet.com.au) joined #scummvm. [22:00] #scummvm: mode change '+o Kirben' by ChanServ!ChanServ@services. [22:02] reporting bugs in static analysis tools is not a very productive way to spend time :-p [22:02] sure it is [22:03] well, when the vendor fixes the problems and then adds them to their testsuite [22:03] :-) [22:03] Gimpel is pretty awesome about that [22:03] and pretty much no one else, other than a *few* open source projects [22:04] that reminds me, I got a bug report about the nice gcc bug which might introduce invalid memory access when passing parameters via registers, for a moment I hoped they had some clue on how to fix it, then it turned out they just got another duplicate from another hardware platform :-P [22:04] I got a mail about* [22:04] yeah, there's quite a lot of interest in the 'doing static analysis on executables because oh gosh you really can't trust compilers' thing recently [22:05] if by recent, you mean in 2003 [22:05] that was when I started BugScan, whose sole purpose was binary analysis [22:05] :-) [22:05] well, interest in the sense of useful tools [22:06] there was a really interesting one where a certificate-checking algorithm got miscompiled (due to ambiguous C), causing a signed/unsigned bug that would then allow some invalid certs to be accepted [22:07] but mostly, that kind of stuff didn't happen post VC++ 6 and gcc 2.x [22:08] well, there's always interesting new "argh, you are miscompiling my perfectly valid code!!" bugs against LLVM [22:08] well, yes -- it's a new and immature compiler [22:08] well, also they don't care about compiling code correctly [22:08] I do like the idea of LLVM, but anyone who's using it frankly gets what they deserve [22:08] if 'correctly' means constraining their optimisations to cope with bad code [22:09] binary analysis is probably going to be useful again now that GCC does nifty loop optimizations [22:10] well, it's always useful for finding bugs in things you don't have source for ;) [22:10] mm [22:10] i must admit that i tend to discard security-orientated research in the 'useless' bin of my brain [22:11] a lot of it is retarded [22:11] we scoured whitepapers, and every so often there was a crumb of a good idea [22:11] that we then expanded on and used [22:11] well, there's also an awful lot of it, and it's a bit frustratingly narrow-orientated in a lot of cases [22:11] but also, sometimes reading a lot of "wrong" ideas gives inspiration for the "right" way [22:11] yes [22:11] yes, that is true :) [22:12] that's why we just did whatever was necessary to detect things on real binaries [22:12] we didn't has a philosophy, or approach [22:12] we just reasoned out what we would need to track/emulate [22:12] once we found the bug, we'd hone things to eliminate false positives [22:13] we started with finding bugs in open source binaries, since we could then recompile the sources with different optimization settings [22:13] once we found the apache chunking overflow, with no false positives, in -O2 [22:13] that is clever [22:13] we'd do -O1, -O3, -Os, and then -o) [22:13] O0 [22:13] -O0 was the hardest, always [22:13] it doe some really dumb shit [22:14] it would be really nice if there were a huge dataset of this kind of thing to experiment on [22:14] then we'd do a different version of GCC [22:14] usually, 2.95 and 3.3 [22:14] then we'd do it again with VC++ 6, all optimization/linking options [22:14] there's always dribs and drabs (e.g. the NECLA static analysis benchmark stuff) but obviously no-one wants to give away magic to competitors.. :) [22:14] by the end of just that one bug detection, we had a pretty sweet system [22:15] omfg [22:15] the benchmarks are just retarded [22:15] James|GlideM (~James|Gli@cpc2-mapp11-2-0-cust447.12-4.cable.virginmedia.com) left irc: Read error: Connection reset by peer [22:15] but also, some vendors were hard-coding checks for filenames and constructs [22:15] haha :) [22:15] I guess that kind of thing is predictable [22:15] the best test is to run the analyzer on sources that contain a zero-day [22:16] it detects it, or not [22:16] if it doesn't, can the vendor reasonably explain why and provide a timeframe for detecting the bug generically [22:16] benchmarks just cry for special "optimizations" to score high ;-) [22:16] the best benchmark test we ever got, besides plain real-world bugs, was from a customer [22:16] yes, I honestly hadn't thought about that reason for lack of any interesting benchmark cases [22:16] they had manually found several dozen exploitable bugs in their closed-source products [22:16] but it's a very good one [22:17] which are very popular, and sold at retail stores [22:17] they had found dozens of bugs internally, and made a test program that exemplified all of them [22:18] that was really awesome for us -- we had a few false negatives and false positives (on STL iteration code) [22:18] but they were a great customer and worked with us while we enhanced the product [22:18] so [22:19] then they were finding all kinds of stuff on their shipping products, because we had no further issues with the libraries/style they coded with [22:19] ny00123 (~ny00123@bzq-79-176-216-88.red.bezeqint.net) left irc: Quit: Leaving [22:19] and that, boys and girls, is why it's not a waste of time to report static analysis bugs :) [22:19] hehe [22:20] very fair argument :) [22:20] fuzzie: our second target was to find the bug the Blaster worm exploited in MSRPC*.dll. we did it on NT 3.5, NT 4.0 SP0-SP6a, win2k SP0-SP3, winXP SP0-SP1, etc [22:20] once we naild that, we found dozens and dozens of similar, exploitable bugs in all kinds of software [22:21] i'm really surprised it's worthwhile doing that [22:21] most ppl were [22:21] which is why the product did so well :) [22:21] there's so much negativity still about the whole thing [22:22] everyone told me how impossible it all was, and how I wasn't smart enough to do it [22:22] and, well, yes, it sounds magic :) [22:22] giucam (~giulio@adsl-ull-175-252.49-151.net24.it) left irc: Remote host closed the connection [22:22] I don't think we could have done it without TDD and pair programming, frankly [22:24] pair programming just because two people are far better for working out how best to do things, or really because it was useful at the code stage too? [22:24] both [22:24] my company was self-funded, and so I had almost no money to hire people [22:24] so I hired junior folks who I knew [22:24] and later, a couple of "senior" people [22:25] a lot of this stuff gets really hairy and complicated, so having to verbalize it to someone is quite useful [22:25] as opposed to keeping it all in your head (or trying to, anyway), making a poor assumption 5 hours back and building on it [22:25] I can understand that, for far simpler things I always try and find someone to babble at [22:25] yes [22:26] but also, as I doubled the size of my team, it was easier to scale [22:26] since everyone had worked on everything, with everyone [22:26] adding a new person into the pairing rotation was very low-cost [22:26] so every new hire was contributing, and in a high-quality fashion, immediately [22:35] ugh, what is this obsession with engines ignoring mouse-down events? [22:35] they are also most definitely not my friends. [22:35] the abstractions are too granular, making it easy for them to do the 'wrong' thing? [22:36] yes. :( [22:37] bgKa (~bbouclet@vai69-5-88-183-207-181.fbx.proxad.net) left irc: Ping timeout: 255 seconds [22:38] James|GlideM (~James|Gli@cpc2-mapp11-2-0-cust447.12-4.cable.virginmedia.com) joined #scummvm. [22:38] #scummvm: mode change '+v James|GlideM' by ChanServ!ChanServ@services. [22:40] MetalSnake (~MetalSnak@77-22-219-166-dynip.superkabel.de) left irc: Quit: MetalSnake [22:45] kriskelvin (~peter@p54B331DF.dip.t-dialin.net) left irc: Quit: off to see the wizard [22:50] digitall (digitall@cpc2-hitc2-0-0-cust28.9-2.cable.virginmedia.com) left #scummvm. [22:52] kriskelvin (~peter@p54B331DF.dip.t-dialin.net) joined #scummvm. [22:54] pok0j (~pok0j@abtf183.neoplus.adsl.tpnet.pl) left irc: Ping timeout: 240 seconds [22:55] pok0j (~pok0j@abtf183.neoplus.adsl.tpnet.pl) joined #scummvm. [22:56] James|GlideM (~James|Gli@cpc2-mapp11-2-0-cust447.12-4.cable.virginmedia.com) left irc: Ping timeout: 240 seconds [22:57] WooShell (woo@178-27-165-32-dynip.superkabel.de) left irc: Quit: svc.startd: The system is coming down. syncing file systems... done. [23:05] Hkz (~Hkz@2001:470:c89a:2:21c:c0ff:fedc:e508) left irc: Read error: Connection timed out [23:06] Hkz (~Hkz@2001:470:c89a:2:21c:c0ff:fedc:e508) joined #scummvm. [23:06] #scummvm: mode change '+o Hkz' by ChanServ!ChanServ@services. [23:08] kriskelvin (~peter@p54B331DF.dip.t-dialin.net) left irc: Quit: off to see the wizard [23:22] DJWillis (djwillis@cpc1-bath5-2-0-cust122.aztw.cable.virginmedia.com) left irc: Read error: Connection reset by peer [23:22] SylvainTV (~Sylvain@ALille-553-1-44-168.w90-34.abo.wanadoo.fr) left irc: Read error: Connection reset by peer [23:22] SylvainTV (~Sylvain@ALille-553-1-44-168.w90-34.abo.wanadoo.fr) joined #scummvm. [23:22] #scummvm: mode change '+o SylvainTV' by ChanServ!ChanServ@services. [23:22] DJWillis (djwillis@cpc1-bath5-2-0-cust122.aztw.cable.virginmedia.com) joined #scummvm. [23:22] #scummvm: mode change '+o DJWillis' by ChanServ!ChanServ@services. [23:37] Hkz (~Hkz@2001:470:c89a:2:21c:c0ff:fedc:e508) left irc: Ping timeout: 252 seconds [00:00] --- Fri Feb 3 2012