[00:04] LittleToonCat (~littlecat@sydnns0115w-142162196041.dhcp-dynamic.FibreOp.ns.bellaliant.net) left irc: Ping timeout: 268 seconds [00:04] |Cable| (~cable@33.138.117.91.dynamic.reverse-mundo-r.com) left irc: Ping timeout: 260 seconds [00:16] |Cable| (~cable@33.138.117.91.dynamic.reverse-mundo-r.com) joined #scummvm. [00:35] is libtitanic.a supposed to be this huge is it because it is just a WIP? [00:38] what do you mean by huge? [00:39] tsoliman: ^ [00:39] (this is obviously not related at all to the release .. this is me trying to build master with --enable-all-engines on maemo and the linker taking forever and so I am investigating) [00:39] if I sum all the size of all the .a files in the project they are 880112 [00:39] libtitanic.a alone is 412628 [00:39] so almost half of that [00:40] excluding the titanic engine allows the linker to finish in a minute or so - but if I include it, the linker takes over 5 mins (and I kill it) [00:41] so I was like "huh I wonder what changed between 1.9.0 and master that's causing this linker problem" and found that it is TITANIC [00:42] it's not a big deal .. just an idle question :) [00:42] it certainly has a lot of TUs [00:43] if you enable only the titanic engine and build, does it still take many minutes? [00:45] trying it now, it's not a very parallelizable make apparently [00:45] (using -j5 is as fast as using -j2 with 4 cores) [00:46] at least it isnt 111434240 bytes, which is the size of libtitanic.a when i build without --enable-release :P [00:46] also I should consider running ccache on this VM [00:46] this toolchain always enables the specific release optimization -Os [00:47] with or without --enable-release :) .. this is because its target is a very crappy ARM CPU [00:48] someone smarter than me decided that -Os is faster than -O3 on this platform - it's literally the smallest binary that it can be [00:50] the toolchain requires Debian 5 - I am running it in VM on an i7, giving it 4 "CPUs" of my 8 "CPUs" [00:51] i feel like i have noticed the lack of build parallelisation with make [00:52] I've disabled libcurl (for now) FWIW [00:53] because I am just trying to get a build *at all* of master and not wait until before a 1.10.0 release [00:53] snover: I think the linker is stuck [00:54] it is chewing 100% of a single core [00:55] ok it finished [00:55] so theoretically it will take 10+ mins to finish if I enable everything [00:56] (just the linker - I test this by deleting the scummvm binary and rerunning make) [00:57] granted this is a really old toolchain [00:58] it is several virtualization levels deep too .. macOS -> VMware running Debian 5 -> Scratchbox 2 cross compiling ARM [01:00] turtles all the way down [01:03] on the bright side, the host mac is on an SSD .. so I thought "why even ccache" [01:04] it used to (with make -j5) be sooo fast (<1 min per build) so you don't need SSD [01:05] s/SSD/ccache [01:05] Henke37 (~Henrik@81-227-16-59-no133.bredband.skanova.com) left irc: Quit: ERR_SHUTDOWN [01:07] there's 16GB on this host, I could theoretically just make a 3GB ramdrive and put the ccache files there .. [01:34] GitHub0 (~GitHub0@192.30.252.40) joined #scummvm. [01:34] [scummvm] csnover pushed 2 new commits to master: https://git.io/vPEOI [01:34] scummvm/master 4b6b328 Colin Snover: SCI32: Check for existence of visiblePlane before dereferencing... [01:34] scummvm/master c118e2f Colin Snover: SCI32: Reset active hot rect index when changing hot rects [01:34] GitHub0 (GitHub0@192.30.252.40) left #scummvm. [01:56] Vampire0 (~Vampire@jEdit/Vampire) joined #scummvm. [01:59] Vampire0_ (~Vampire@jEdit/Vampire) left irc: Ping timeout: 260 seconds [02:00] Dominus (~dominus@unaffiliated/dominus) left irc: Ping timeout: 260 seconds [02:00] DominusExult (~dominus@178-191-227-235.adsl.highway.telekom.at) joined #scummvm. [02:00] DominusExult (~dominus@178-191-227-235.adsl.highway.telekom.at) left irc: Changing host [02:00] DominusExult (~dominus@unaffiliated/dominus) joined #scummvm. [02:00] Nick change: DominusExult -> Dominus [02:26] snover (~Adium@unaffiliated/snover) left irc: Quit: Leaving. [04:02] Polynomial-C (~Poly-C@gentoo/developer/Polynomial-C) joined #scummvm. [04:04] Poly-C (~Poly-C@gentoo/developer/Polynomial-C) left irc: Ping timeout: 268 seconds [04:23] LePhilousophe (valemboi20@amsn/developer/lephilousophe) got netsplit. [04:23] LePhilousophe (valemboi20@amsn/developer/lephilousophe) returned to #scummvm. [05:13] Littleboy (~littleboy@c-174-62-174-85.hsd1.ma.comcast.net) left irc: Quit: Être dans le vent, une ambition de feuille morte. [06:31] m_kiewitz (~m_kiewitz@x4d03cd0d.dyn.telefonica.de) joined #scummvm. [06:31] m_kiewitz (~m_kiewitz@x4d03cd0d.dyn.telefonica.de) left irc: Changing host [06:31] m_kiewitz (~m_kiewitz@scummvm/undead/m-kiewitz) joined #scummvm. [06:31] #scummvm: mode change '+o m_kiewitz' by ChanServ!ChanServ@services. [06:48] bgKa (~bgk@2001:41d0:2:599c::2a60:8434) left irc: Ping timeout: 260 seconds [06:54] bgKa (~bgk@2001:41d0:2:599c::2a60:8434) joined #scummvm. [06:54] #scummvm: mode change '+o bgKa' by ChanServ!ChanServ@services. [06:54] _sev: which devs are on Mac OS X again? [06:54] snover, right? [06:54] <_sev> m_kiewitz: I am [06:54] oh nice [06:55] there seems to be an issue in the OpenGL backend on OS X? [06:55] https://bugs.scummvm.org/ticket/9607#comment:1 [06:55] <_sev> why is that a bug? [06:56] the game shouldn't work that insanely fast [06:56] <_sev> the original removed any delays during the fastest mode [06:56] I'm delaying for 10 milliseconds each [06:56] <_sev> and its performance was dependent on the CPU speed [06:56] yes, although I'm not really doing that, I'm still slightly delaying it, so that it doesn't run crazily fast [06:56] <_sev> We were turning on Turbo mode for making it faster [06:56] the user also has the issue with "fast", which should be locked in any case [06:57] <_sev> ok, let me quickly check [06:57] and it seems as if the backend somewhat doesn't do delays of 10 milliseconds at all [06:57] i can't think of any other reason for that behavior [06:57] works fine for me [06:59] <_sev> I have same version. I do not see the 'fastest' mode there [06:59] <_sev> only 'fast', 'normal' and 'slow' [06:59] yes, me neither [06:59] but try black cauldron [07:00] waltervn (~waltervn@82-171-142-149.ip.telfort.nl) joined #scummvm. [07:00] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services. [07:00] <_sev> ask the user to clarify [07:00] i guess "fast" should still be way too fast?! [07:00] <_sev> not really [07:00] <_sev> ah, wait [07:00] <_sev> I'm on SDL [07:00] morning [07:00] well the user says that "fast" also runs insanely fast [07:01] morning walter [07:01] how are delays handled? I guess SDL does it, when we use it. But how are those handled otherwise? [07:02] <_sev> not insanely, but I cannot navigate to the bridge [07:02] <_sev> e.g. I'm getting drowned [07:02] for me everything works properly, quite fast but not insanely fast [07:03] can you check how delays are handled for MacOS X / OpenGL? [07:03] <_sev> but faster than for 2x mode [07:03] <_sev> it is same thing [07:03] <_sev> delay are governed by the engine [07:04] <_sev> but blitting is bottleneck [07:04] yes, but I'm calling delay millis [07:04] <_sev> which of course happens much faster [07:04] <_sev> right, but 10 is 1000fps [07:04] <_sev> err 100fps [07:04] <_sev> which could be fast, indeed [07:04] <_sev> as you're doing not just screen updates but script execution also [07:05] no, I'm not delaying just 10 milliseconds, I'm delaying for that amount multiple times [07:07] at least i think so [07:07] <_sev> if you need to have a constant fps [07:07] <_sev> then do as I do in the Full Pipe: [07:08] it's not as simple, with the old code for example there were all sorts of weird issues with Gold Rush [07:09] <_sev> https://github.com/scummvm/scummvm/blob/master/engines/fullpipe/fullpipe.cpp#L319 [07:09] <_sev> I'd say that this is not an issue [07:09] <_sev> well, you still could add delay similar to above right after the screen update, if it happened to be too fast for you [07:10] <_sev> there is no difference in delay implementation between opengl/sdl backends, only graphics [07:10] <_sev> but graphics is tons faster under OpenGL [07:10] <_sev> primarily because it does the color conversion in hardware [07:26] morning [07:26] hurray, a tag :-) [07:29] _sev: AGI should already process next cycle only, when a certain amount of time has passed [07:29] if (_passedPlayTimeCycles >= timeDelay) { [07:30] _passedlayTimeCycles is actually calculated based on real time [07:30] and that's done inside void AgiEngine::inGameTimerUpdate() [07:31] 1 cycle should be around 50 milliseconds [07:31] / This is also called in the main loop, because the game needs to be sync'd to 20 cycles per second [07:31] so the current OpenGL behavior makes no sense unless timer related functions do not work properly on Mac OS X [07:33] back then i wrote that code to avoid such hardware related speed issues [07:33] <_sev> hmm [07:34] <_sev> I see that AgiEngine::wait() is implemented properly [07:34] you could add a warning to [07:34] if (playTimeCycleDelta > 0) { [07:34] _passedPlayTimeCycles += playTimeCycleDelta; [07:34] } [07:34] and then check how that works on Mac OS X / OpenGL [07:35] maybe there is some bug inside my code but I don't see it [07:35] and as I said - it works properly for me on Windows in any case [07:35] the game should not be able to run at some insane effective frame rate [07:35] <_sev> ok, running now [07:36] I mean it actually can run at a higher frame rate, but frames would be duplicated and would not change [07:37] you could check the time delay variable of the game [07:38] it shouldn't be 0, if it is then that would explain something, still at least the "fast" setting shouldn't set 0 [07:38] <_sev> is is always 1 [07:38] <_sev> WARNING: _passedPlayTimeCycles: 1! [07:38] <_sev> unless I run menu [07:39] yes, that should be fine [07:39] <_sev> also FPS drops if I move mouse fast [07:39] o_O [07:39] <_sev> which is expected, as there are now actual changes [07:39] <_sev> well, it runs at perhaps 100fps and then drops to 70fps or somethin [07:40] <_sev> still noticeable [07:40] passedPlayTimeCycles means that at least 50 milliseconds have happened inbetween [07:41] and only then game scripts are called (actual game cycle) [07:41] that's not the case for you? [07:41] the graphics can be updated at a faster rate, but without game scripts changing anything [07:42] how often do you see that warning? more than 20 times a second? [07:43] <_sev> tough to say, let me run it with a timer [07:44] <_sev> about 20 [07:45] <_sev> let me try to run fast mode under 2x [07:45] TMM (~hp@fsf/member/pdpc.professional.tmm) left irc: Ping timeout: 248 seconds [07:45] TMM (~hp@fsf/member/pdpc.professional.tmm) joined #scummvm. [07:46] <_sev> and same under 2x [07:46] <_sev> but the animation is definitely faster O_o [07:46] but the game runs faster?! [07:46] o_O [07:46] can you put a warning right at the start of void AgiEngine::interpretCycle()? [07:46] and then check again? [07:47] <_sev> doing [07:51] <_sev> it is about the same, 75 fps [07:52] wait interpretCycle() is called 75 times a second? [07:52] <_sev> which tells me that SDL does not keep up with this rate, but OpenGL does, unless cursor is drawn [07:52] <_sev> yes [07:52] that definitely should not be the case [07:52] <_sev> so you have a bug somewhere [07:52] it seems so [07:54] kurtwr (~kurtwr@c-73-12-209-100.hsd1.ca.comcast.net) left irc: Read error: Connection reset by peer [07:55] kurtwr (~kurtwr@c-73-12-209-100.hsd1.ca.comcast.net) joined #scummvm. [08:03] TMM (~hp@fsf/member/pdpc.professional.tmm) left irc: Quit: Ex-Chat [08:32] OmerMor (~Omer@46-117-132-33.bb.netvision.net.il) joined #scummvm. [08:39] Poly-C (~Poly-C@gentoo/developer/Polynomial-C) joined #scummvm. [08:40] L0ngcat_ (~L0ngcat@weekend.thorsen.pm) joined #scummvm. [08:41] m_kiewitz (~m_kiewitz@scummvm/undead/m-kiewitz) got netsplit. [08:41] Polynomial-C (~Poly-C@gentoo/developer/Polynomial-C) got netsplit. [08:41] omer_mor_ (~Omer@46-117-132-33.bb.netvision.net.il) got netsplit. [08:41] ScottT (~ScottT@2401:a400:6100:f400:10fb:23cd:9d70:da80) got netsplit. [08:41] gus (~quassel@2401:1801:7800:101:be76:4eff:fe18:1911) got netsplit. [08:41] L0ngcat (~L0ngcat@weekend.thorsen.pm) got netsplit. [08:41] skymandr (~skymandr@h-5-150-255-103.na.cust.bahnhof.se) got netsplit. [08:41] m_kiewitz (~m_kiewitz@x4d03cd0d.dyn.telefonica.de) joined #scummvm. [08:41] m_kiewitz (~m_kiewitz@x4d03cd0d.dyn.telefonica.de) left irc: Changing host [08:41] m_kiewitz (~m_kiewitz@scummvm/undead/m-kiewitz) joined #scummvm. [08:41] #scummvm: mode change '+o m_kiewitz' by ChanServ!ChanServ@services. [08:41] Nick change: L0ngcat_ -> L0ngcat [08:41] Possible future nick collision: L0ngcat [08:49] ScottT (~ScottT@2401:a400:6100:f400:10fb:23cd:9d70:da80) returned to #scummvm. [08:49] gus (~quassel@2401:1801:7800:101:be76:4eff:fe18:1911) returned to #scummvm. [08:49] skymandr (~skymandr@h-5-150-255-103.na.cust.bahnhof.se) returned to #scummvm. [08:49] #scummvm: mode change '+o ScottT ' by tepper.freenode.net [08:52] omer_mor_ (~Omer@46-117-132-33.bb.netvision.net.il) got lost in the net-split. [08:52] Polynomial-C (~Poly-C@gentoo/developer/Polynomial-C) got lost in the net-split. [09:04] TMM (~hp@fsf/member/pdpc.professional.tmm) joined #scummvm. [09:19] _sev|work (~sev@proxy-gw-l.booking.com) joined #scummvm. [09:19] _sev|work (~sev@proxy-gw-l.booking.com) left irc: Changing host [09:19] _sev|work (~sev@scummvm/undead/sev) joined #scummvm. [09:19] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services. [09:41] erdic (~erdic@unaffiliated/motley) left irc: Ping timeout: 248 seconds [09:42] erdic (~erdic@unaffiliated/motley) joined #scummvm. [10:00] Henke37 (~Henrik@81-227-16-59-no133.bredband.skanova.com) joined #scummvm. [10:14] wohoo, 1.9.0 tagged \o/ [10:45] Henke37 (~Henrik@81-227-16-59-no133.bredband.skanova.com) left irc: Ping timeout: 260 seconds [10:57] salty-horse (~salty-hor@bzq-79-180-120-168.red.bezeqint.net) joined #scummvm. [10:57] salty-horse (~salty-hor@bzq-79-180-120-168.red.bezeqint.net) left irc: Changing host [10:57] salty-horse (~salty-hor@unaffiliated/salty-horse) joined #scummvm. [10:57] #scummvm: mode change '+o salty-horse' by ChanServ!ChanServ@services. [11:00] Henke37 (~Henrik@81-227-16-59-no133.bredband.skanova.com) joined #scummvm. [11:03] ny00123 (~ny00123@46-116-115-228.bb.netvision.net.il) joined #scummvm. [12:08] ajax16384 (~User@ip138.net138.n37.ru) joined #scummvm. [12:08] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services. [13:39] Rasi (~carnager@archlinux/support/rasi) left irc: Ping timeout: 250 seconds [13:41] Rasi (~carnager@archlinux/support/rasi) joined #scummvm. [14:32] #scummvm: mode change '+o fuzzie' by ChanServ!ChanServ@services. [14:41] snover (~Adium@unaffiliated/snover) joined #scummvm. [14:41] #scummvm: mode change '+o snover' by ChanServ!ChanServ@services. [15:00] LittleToonCat (~littlecat@sydnns0115w-156057019210.dhcp-dynamic.FibreOp.ns.bellaliant.net) joined #scummvm. [15:00] WinterGrascph (~WinterGra@winter.sch.bme.hu) joined #scummvm. [15:00] #scummvm: mode change '+o WinterGrascph' by ChanServ!ChanServ@services. [15:01] WinterGrascph (~WinterGra@winter.sch.bme.hu) left irc: Client Quit [15:22] girafe (~girafe@LFbn-1-8015-136.w90-112.abo.wanadoo.fr) joined #scummvm. [15:22] _sev|work (~sev@scummvm/undead/sev) left irc: Quit: This computer has gone to sleep [15:29] Littleboy (~littleboy@c-174-62-174-85.hsd1.ma.comcast.net) joined #scummvm. [15:29] #scummvm: mode change '+o Littleboy' by ChanServ!ChanServ@services. [15:39] phyber (~phyber@unaffiliated/phyber) left irc: Ping timeout: 260 seconds [15:39] phyber (phyber@unaffiliated/phyber) joined #scummvm. [15:46] ajax16384 (~User@ip138.net138.n37.ru) left irc: Quit: Leaving [15:59] TMM (~hp@fsf/member/pdpc.professional.tmm) left irc: Quit: Ex-Chat [16:08] ajax16384 (~User@ip33.net130.n37.ru) joined #scummvm. [16:08] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services. [16:37] snover (~Adium@unaffiliated/snover) left irc: Quit: Leaving. [16:41] WooShell (~Markus@ipbcc071f7.dynamic.kabel-deutschland.de) joined #scummvm. [16:44] Are the ZVision games not launching in master known issues? [16:49] (on Windows, console error for both is 'Invalid TrueMotion1 compression type 31') [16:50] _sev: when you got those 75 cycles per second, did you select "fastest"? [16:50] because I'm still only getting 20 cycles per second on "fast" in black cauldron [16:51] exmensa: haven't heard that before [16:51] for "fastest" I guess the game speed is set to 0, which means cycles will get started every 10 milliseconds at best/worst [16:53] exmensa: maybe you have a game version we don't know about, or maybe your data files are corrupted? [16:54] wjp: I'm not 100% about Nemesis, but I just copied Grand Inquisitor from DVD - it launches fine in stable 1.9.0, just the master builds won't run. Same for both games, for what it's worth. [16:54] where did you get the 1.9.0 and master builds? [16:55] The daily build page. [16:55] which platform? [16:55] Windows? [16:55] Windows 10, tried master for both 32/64 bit and stable 64 bit [16:56] which ones did you download exactly? [16:58] Both were 'latest' on buildbot page, c118e2fe if that's what you're looking for [16:58] from this page? http://buildbot.scummvm.org/builds.html [16:58] Right. [16:58] bottom row? [16:58] Right. [16:58] ok [16:58] odd [16:58] and you say "development" doesn't work, but "stable" does work? [16:59] let's see what I can figure out about the difference between those two [16:59] Correct. Development throws the error right on launching the game. [17:01] meow =^.^= [17:04] right, so we really broke this recently [17:04] hm, only thing that appears related at first glance is an avi demuxer change [17:06] yeah, that's the culprit [17:07] could you file a bug report on https://bugs.scummvm.org/ about this? [17:07] Sure, I think I have a github login, I'll see if I can track it down [17:11] great, thanks [17:16] Happy Yom Kippur guys [17:19] wjp: Filed #9608, are there any other details you'd like there? [17:21] thanks! [17:21] Thank you :) [17:22] left a follow-up comment about the culprit; hopefully we'll be able to fix it soon [17:22] Good to hear. [17:28] t0by (~t0by@host104-254-dynamic.54-82-r.retail.telecomitalia.it) joined #scummvm. [17:28] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services. [17:33] bgKa (~bgk@2001:41d0:2:599c::2a60:8434) left irc: Ping timeout: 250 seconds [17:37] bgKa (~bgk@2001:41d0:2:599c::2a60:8434) joined #scummvm. [17:37] #scummvm: mode change '+o bgKa' by ChanServ!ChanServ@services. [17:44] Anonymous (50729275@gateway/web/freenode/ip.80.114.146.117) joined #scummvm. [17:44] Hi! Any devs online? [17:44] Nick change: Anonymous -> Guest47897 [17:45] Oh, I guess Anonymous was taken. I'm now Guest + a bunch of numbers. [17:45] what can we help you with? [17:46] ScummVM gave me an error, but I think the error itself is wrong. Just a moment, I'll grab the log... [17:47] Okay, here's the log message (more follows in a moment): [17:47] Unknown res tag '....' encountered (expected 'SCRP') while trying to load res (Script,249) in room 79 at 58453119+66645 in file dig.la1! [17:47] Now, I've looked at the specified offset in the specified file... [17:47] By starting Word, pressing Alt+F11 and then using the console. [17:48] open"c:\program files\the dig\dig\dig.la1"for binary access read as#1:s$="____":get#1,58453119+66645+1,s:close:?s [17:48] The answer I got was: [17:48] SCRP [17:49] Which is the same as what ScummVM was expecting to find, but strangely didn't find. I'm perplexed. [17:49] TMM (~hp@fsf/member/pdpc.professional.tmm) joined #scummvm. [17:50] bgKa (~bgk@2001:41d0:2:599c::2a60:8434) left irc: Ping timeout: 260 seconds [17:50] most often this error message just indicates a corrupt data file [17:50] That was what I thought at first. [17:51] But when I inspected the file, the required tag was present at the offset in question. [17:51] Also, it worked before on a different computer which is unfortunately broken. I cannot remember if I used ScummVM then though. [17:53] So I'm pretty sure the data file isn't corrupt, and I'm absolutely sure that the error message is wrong (even if something is wrong with the data file). [17:56] just to be sure, have you double checked that ScummVM is indeed using C:\Program Files\the dig\ ? [17:57] I'll start it and check it with ProcessExplorer. Just a minute. [17:58] Okay, I'm getting the same error message. I'll look at its handles using Process Hacker. [18:00] It says: C:\Users\ROCO\AppData\Local\VirtualStore\Program Files\The Dig\DIG\DIG.LA1 [18:00] Which is odd. [18:00] SylvainTV (~SylvainTV@LFbn-1-8392-241.w81-254.abo.wanadoo.fr) joined #scummvm. [18:00] #scummvm: mode change '+o SylvainTV' by ChanServ!ChanServ@services. [18:00] Thanks for your help so far, I'll have a look at the game's config. I'll be back in a minute. [18:01] I've had a look at the code behind the error message in the mean time, and that seems sane at first glance [18:01] (it does a seek and a 4 byte read right before it) [18:01] It does, doesn't it? I think it's somehow using the wrong file or something. [18:05] The game's config points to: C:\Users\ROCO\AppData\Local\VirtualStore\Program Files\The Dig\DIG [18:05] But it seems to be reading this file: C:\Users\ROCO\AppData\Local\VirtualStore\Program Files\The Dig\DIG\DIG.LA1 [18:06] At first glance that file seems to be a truncated version of the original dig.la1. [18:07] Any idea why it might be reading from a different file? Any idea how the other dig.la1 got created or why it might be truncated? I didn't put it there myself, that much is certain. [18:07] you say your game config points to C:\Users\ROCO\AppData\Local\VirtualStore\... ? [18:09] No. [18:09] copy-paste error earlier then I guess [18:10] I wonder if Windows does some kind of internal transparent redirecting of this [18:10] (don't use Windows myself, so I can't say much about it) [18:10] I said (or meant to say) that although my game config points to Program Files, ScummVM actually reads from VirtualStore. I don't know what this VirtualStore is, or why ScummVM reads fro it. [18:14] Oh, look at the time... I gotta split, but I'll return to this channel when I'm back, which might be late though. [18:16] ok, see you later [18:17] Sylvain (~SylvainTV@LFbn-1-8392-241.w81-254.abo.wanadoo.fr) joined #scummvm. [18:19] bgKa (~bgk@2001:41d0:2:599c::2a60:8434) joined #scummvm. [18:19] #scummvm: mode change '+o bgKa' by ChanServ!ChanServ@services. [18:19] Sylvain (~SylvainTV@LFbn-1-8392-241.w81-254.abo.wanadoo.fr) left irc: Client Quit [18:28] wjp: I looked into your uninitialized read bug in QfG3. I added the info to the ticket. [18:29] Looks like a script bug. [18:32] I saw; thanks [18:33] (it's not really "mine", by the way; I just did some multiple-bugs-in-one-report cleanup) [18:33] oh, ok :) [18:35] can you see in other notify functions what it should return on unhandled messages? [18:35] criezy (~criezy@host109-147-203-115.range109-147.btcentralplus.com) joined #scummvm. [18:35] #scummvm: mode change '+o criezy' by ChanServ!ChanServ@services. [18:35] The base Rgn::notify function is an empty function. returns nothing. [18:36] Rm740::notify also returns nothing. It just redraws the rope bridge. [18:37] odd [18:37] I think it was a mistake to inherit from notify in Rm470. It seems like it serves a different role, and returns values to its explicit callers. [18:37] _sev|work (~sev@92.110.93.218) joined #scummvm. [18:37] _sev|work (~sev@92.110.93.218) left irc: Changing host [18:37] _sev|work (~sev@scummvm/undead/sev) joined #scummvm. [18:37] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services. [18:37] GitHub138 (~GitHub138@192.30.252.34) joined #scummvm. [18:37] [scummvm] sev- pushed 1 new commit to master: https://git.io/vPzvQ [18:37] scummvm/master 719bc03 Eugene Sandulenko: GRAPHICS: Added stub for BDF font scaler [18:37] GitHub138 (GitHub138@192.30.252.34) left #scummvm. [18:38] It is called explicitly (and not polymorphically) from both script 470 and script 471. [18:38] _sev|work (~sev@scummvm/undead/sev) left irc: Client Quit [18:39] I guess when they added that function, they forgot there's a base notify() function as well, that is called from the char sheet script. [18:39] _sev|work (~sev@scummvm/undead/sev) joined #scummvm. [18:39] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services. [18:39] _sev|work (~sev@scummvm/undead/sev) left irc: Client Quit [18:40] What happens when SCI is calling a function with a return value, but don't use the result? I guess it's benign, right? [18:47] frankyboy_ (~franky@ppp79-139-212-81.pppoe.spdop.ru) joined #scummvm. [18:51] wjp: Looks like there's already a workaround for this: https://github.com/scummvm/scummvm/blob/master/engines/sci/engine/workarounds.cpp#L349 [18:51] Any idea why it's not triggered? [18:51] gog "fan" patches [18:51] hm, return values just go into the accumulator, right? [18:51] wjp: correct [18:52] huh, I completely missed that workaround. Oops [18:52] ah that workaround doesn't use a signature, that's weird then [18:52] it's an uninitialized read [18:52] yes, but the workaround is for uninitialized reads [18:53] we don't seem to be able to read the object's name [18:53] (0008) [014] name = 0000:dec0 (57024) [18:53] is it index 0? [18:53] oh [18:53] so maybe really fan patches :( [18:53] wonder if they forgot the relocation entry [18:53] it should be the room itself [18:53] or is it another object? [18:53] (0006) [1006] -super- = 0004:12bc (Rm) [18:54] it only triggers for the GOG version correct? [18:54] yes [18:54] is that script patched in that version? [18:54] yes [18:55] do we see the name as ? [18:55] #scummvm: mode change '+o [vEX]' by ChanServ!ChanServ@services. [18:55] d: script 470 - ::notify(0000:fff1) [18:56] (in the debugger bt) [18:56] ah yes [18:56] that could explain it [18:56] dang, those silly fan patches [18:56] yes, it explains it [18:56] the workaround names the method [18:56] the workaround is checked that way [18:56] and the fan patches script is simply broken [18:56] good news is that works in the workaround :-) [18:56] how does the object name is retrieved in the debugger? [18:57] yes, of course [18:57] so we can presumably duplicate it with rm470 + "" [18:57] yes but on the other hand i don't really want to duplicate every single script patch for the broken GOG version [18:57] i mean we could, but we don't even know if those fan patche introduced maybe even more issues [18:57] patches [18:57] what causes the script to have an invalid name object? [18:58] broken script data [18:58] hypothesis: broken relocation table in the patched script [18:58] yes [18:58] SCI Companion recognize the object name correctly in the GOG version [18:58] yeah, but they don't actually need to do the relocations to parse the data [18:59] what is this relocation table? [18:59] because SCI Companion can safely assume all pointers point into the script itself [18:59] it is a list of all pointers in the script data [18:59] when loading the script, all those pointers have to updated to the address at which the script is loaded [19:00] so there's an entry for the notify function in the table in script 470? [19:01] yes [19:01] 40a is in there [19:01] and this value is being assigned at runtime or is it a static value from the script file? [19:01] hm [19:02] maybe I'm confused [19:02] but the notify function isn't relevant here [19:02] the 'name' property is [19:02] ok [19:02] the name property is a pointer [19:03] the name property of the Rm470 instance? [19:03] and it points to 'rm470' in the script (well, heap) data [19:05] Can I see this table using SV ? [19:05] Or any other tool? [19:05] no idea [19:06] Where did you see the value 40a? [19:06] that was a random coincidence :-) [19:07] What's I'm trying to understand if there's a way to overcome the broken relocation tables [19:08] Since companion is being able to find the information statically, I guess there could be a way to exploit that information and fix that tables at runtime [19:15] For those who can read French: [19:15] http://www.lemonde.fr/pixels/article/2016/10/10/vingt-ans-apres-les-chevaliers-de-baphomet-la-resurrection-du-jeu-video-d-aventure_5011309_4408996.html [19:15] "Vingt ans après son âge dor, la résurrection du jeu vidéo daventure" [19:15] (Twenty years after their golden age, adventure games are back) [19:16] Where? :P [19:17] oddly the relocation table might be ok [19:18] no idea where the dec0 is coming from [19:18] what dec0? [19:18] sluicebox (~userid@104-6-192-21.lightspeed.irvnca.sbcglobal.net) joined #scummvm. [19:19] 20:53 < wjp> (0008) [014] name = 0000:dec0 (57024) [19:22] _sev (~sev@scummvm/undead/sev) left irc: Quit: Leaving [19:32] _sev (~sev@92.110.93.218) joined #scummvm. [19:32] _sev (~sev@92.110.93.218) left irc: Changing host [19:32] _sev (~sev@scummvm/undead/sev) joined #scummvm. [19:32] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services. [19:39] Strangerke (~Strangerk@cable-85.28.84.13.coditel.net) joined #scummvm. [19:42] hi [19:45] #scummvm: mode change '+o Strangerke' by ChanServ!ChanServ@services. [19:45] hi guys [19:45] hi Strangerke [19:46] hi [19:47] ahhhh [19:47] Strangerke [19:48] yeah, I was in PAris the last two days and the wifi wasn't working at all at the hotel >:( [19:57] GitHub150 (~GitHub150@192.30.252.46) joined #scummvm. [19:57] [scummvm] Strangerke pushed 2 new commits to master: https://git.io/vPz3l [19:57] scummvm/master 7c13823 Strangerke: DM: Handle demo dungeon file [19:57] scummvm/master 86e525c Strangerke: DM: Fix isSquareACorridorTeleporterPitOrDoor for the demo, set version of demo to 2.0 [19:57] GitHub150 (GitHub150@192.30.252.46) left #scummvm. [19:59] m_kiewitz, OmerMor: the relocation table is fine. Looks like a script is using this name field as storage, maybe? [20:00] _sev: The version in the 1.9.0 tools tarball still indicates 1.8.0, and this is seen in the tool itself (e.g. window title bar or About dialog). [20:00] wjp: but why would that happen with the fan patches only? [20:00] maybe there is some other glitch somewhere else inside the fan script that writes to it? [20:00] but still why should any script code write to the name [20:00] it would be a nice hack if a script needed an extra variable to write data :-) [20:01] (e.g., for timing or something) [20:03] <_sev> criezy: oops [20:06] GitHub126 (~GitHub126@192.30.252.46) joined #scummvm. [20:06] [scummvm-tools] sev- created branch-1-9-0 (+1 new commit): https://git.io/vPzsa [20:06] scummvm-tools/branch-1-9-0 cf42183 Eugene Sandulenko: TOOLS: This is 1.9.0 [20:06] GitHub126 (GitHub126@192.30.252.46) left #scummvm. [20:07] GitHub16 (~GitHub16@192.30.252.42) joined #scummvm. [20:07] [scummvm-tools] sev- force-pushed v1.9.0 from 937ebb3 to 6267e0c: https://git.io/vP05d [20:07] GitHub16 (GitHub16@192.30.252.42) left #scummvm. [20:07] <_sev> that is the tools tag [20:07] <_sev> no harm [20:10] GitHub48 (~GitHub48@192.30.252.46) joined #scummvm. [20:10] [scummvm-tools] sev- pushed 1 new commit to branch-1-9-0: https://git.io/vPzGL [20:10] scummvm-tools/branch-1-9-0 8fd6723 Eugene Sandulenko: TOOLS: This is 1.10.0pre [20:10] GitHub48 (GitHub48@192.30.252.46) left #scummvm. [20:10] waltervn (~waltervn@82-171-142-149.ip.telfort.nl) left irc: Quit: Leaving [20:18] m_kiewitz: FYI, the fan patch is using rm470::name to store the last time rm470::doit was executed to avoid it being called too often, apparently [20:19] aaarrrggghhh [20:19] who the hell... [20:19] why not simply create more locals [20:20] t0by (~t0by@host104-254-dynamic.54-82-r.retail.telecomitalia.it) left irc: Quit: Bye! [20:21] snover (~Adium@unaffiliated/snover) joined #scummvm. [20:21] #scummvm: mode change '+o snover' by ChanServ!ChanServ@services. [20:26] phew! after days of little conversation, today was a busy day in #scummvm [20:27] wjp: would you have interest in talking about the -propDict- problem? [20:28] I was hoping to have a look yesterday or today already, but ended up helping friends move furniture yesterday, and switch phones today... [20:29] salty-horse (~salty-hor@unaffiliated/salty-horse) left irc: Quit: Leaving [20:29] but no time like the present :-) [20:29] free exercise! [20:29] indeed [20:31] so [20:31] propdict [20:32] yeah. [20:33] as you probably know already, in ssci -propDict- is a memid [20:33] I strongly suspected it [20:34] did you find the code that sets it? [20:34] I had a look around phant68k and sq6 without too much luck [20:35] but I expect we'll have to do relocations on -propDict- and -methDict- [20:35] its in the Object constructor, one second. [20:35] ah [20:36] do I see 7 relocations in there? [20:40] looking in phant68k, but do you have it in sq6? [20:41] 496F8 I guess [20:43] snover: i'm getting gk1 crashes again when interrogating/interviewing using master [20:44] first room for example, click Ask on grace, the question screen appears, click Exit, click Ask on grace again [20:44] wjp: ugh, sorry, temporary meltdown :) [20:45] and it bombs with Send to invalid selector... [20:45] i tried interviewing a few other characters, similar results [20:45] sluicebox: the storage of intarrays changed, you need to start a new game, your save games are broken [20:45] i did [20:45] oh [20:46] this isn't the same behavior as before, it loads correctly once, the second time bombs. [20:46] sorry, i am broken [20:46] i finished actually doing what you said you were doing [20:47] i will try to figure out what happened as soon as i try to do this thing about propdict [20:47] i tried disabling that interrogation script patch you'd done, since i didn't know if that was still necessary since your last array change, with same results [20:47] cool, thanks! [20:51] wjp: yes, 496f8 [20:52] 497b8 is also an object constructor, used for cloning [20:54] hm, not seeing it do relocations though [20:57] i think that happens in LoadScript [20:58] I think I agree [20:58] just not 100% sure where yet :-) [21:09] ok [21:09] you found it? [21:10] should be LoadScript+6E2 for -propDict- [21:10] LoadScript+7AD for -methDict- [21:12] (stepped through it to see where the properties were changed) [21:13] seems consistent with the +4 and the +6 (resp.) before that [21:16] not in the debugger now, but I also see a write to +A at +7EC [21:17] and +59F is writing to -super- at +C [21:20] im a little behind but mostly tracking where you are at [21:26] i am caught up now [21:28] ny00123 (~ny00123@46-116-115-228.bb.netvision.net.il) left irc: Quit: Leaving [21:34] unfortunately i have to go now :( but i shall return. [21:59] AFAICT it's always allocating a separate MemID for -methDict-, and for -propDict- only if -script- != 0xFFFF, otherwise it copies -propDict- from -super- [22:01] (the check if -script= != 0xFFFF seems to be before it is overwritten by ... something) [22:02] but I'm still a bit confused about the whole structure here [22:05] WooShell (~Markus@ipbcc071f7.dynamic.kabel-deutschland.de) left irc: Quit: It's easy to laugh and it's easy to hate... it takes guts to be gentle and kind. [22:08] sluicebox (~userid@104-6-192-21.lightspeed.irvnca.sbcglobal.net) left irc: Ping timeout: 260 seconds [22:09] bgKa (~bgk@2001:41d0:2:599c::2a60:8434) left irc: Ping timeout: 260 seconds [22:09] m_kiewitz (~m_kiewitz@scummvm/undead/m-kiewitz) left irc: Quit: technology isn't intrinsically good or evil. It's how it's used. Like the Death Ray. [22:13] bgKa (~bgk@2001:41d0:2:599c::2a60:8434) joined #scummvm. [22:13] #scummvm: mode change '+o bgKa' by ChanServ!ChanServ@services. [22:15] ajax16384 (~User@ip33.net130.n37.ru) left irc: Read error: Connection reset by peer [22:16] snover: that loop is doing this for each object, AFAICT: [22:16] if (super == -1) super = 0; else super = memid of superclass; [22:16] if (script == -1) propDict = super->propDict; else propDict = allocate memory and fill; [22:16] methDict = allocate memory and fill [22:16] script = memid of script [22:17] few misc other things in there that I'm 90% sure are memory management (maybe locking or incrementing refcounts of memids pointed to) [22:23] omer_mor (~Omer@46-117-132-33.bb.netvision.net.il) joined #scummvm. [22:25] so I guess a possible conclusion is we might as well use my hack for -propDict-, since that makes it unique per class, which should be the only property that scripts could derive from this snippet of code [22:25] OmerMor (~Omer@46-117-132-33.bb.netvision.net.il) left irc: Ping timeout: 260 seconds [22:25] -methDict- apparently should be unique per object [22:30] frankyboy_ (~franky@ppp79-139-212-81.pppoe.spdop.ru) left irc: Read error: Connection reset by peer [22:31] frankyboy_ (~franky@ppp79-139-212-81.pppoe.spdop.ru) joined #scummvm. [22:33] (but I don't see any SCI2 scripts using methDict) [22:33] omer_mor_ (~Omer@46-117-132-33.bb.netvision.net.il) joined #scummvm. [22:35] omer_mor (~Omer@46-117-132-33.bb.netvision.net.il) left irc: Ping timeout: 240 seconds [22:38] reading& [22:40] frankyboy_ (~franky@ppp79-139-212-81.pppoe.spdop.ru) left irc: Quit: #E>6C O >B 20A [22:44] wjp: is there a chance of a conflict in the offset of the reg_t? [22:45] also, can the hack be simplified slightly to use the segmentId that is passed into initializeObjectsSci11? [22:45] i.e. `obj->setPropDictSelector(make_reg(segmentId, obj->getPropDictSelector().getOffset()));` [22:47] a conflict in the offset? [22:48] (oh, and yes, using segmentId is much better) [22:49] i think i answered my own question. i was for some reason thinking that reg_t were dynamically allocated in a way where the offset could be 8 for -propDict- and 8 for some other object in the same segment, but&well, i imagine it is called offset for a reason :) [22:50] :-) [22:50] so this seems very good to me. [22:51] another option would be just setting it to reg [22:51] and methdict too [22:51] oh, youre absolutely right. [22:52] (although that might end up confusing us in the future, but it _should_ satisfy the uniqueness properties these allocs give) [22:56] what actually uses -methDict- ? [22:56] nothing AFAICT [22:57] ok, good. [22:57] so we can probably just keep ignoring that I suppose [22:58] about bedtime for me [22:58] would you like to do the honours or shall i? [22:59] if you don't mind it not being extensively tested, I can :-) [22:59] there is still the question of the SCI version range [23:00] I'm tempted to do it for all [23:00] hm. i am being called away again so i guess it can wait until tomorrow to give time to think about that [23:06] quickly made it a PR [23:07] bgKa (~bgk@2001:41d0:2:599c::2a60:8434) left irc: Ping timeout: 260 seconds [23:07] GitHub84 (~GitHub84@192.30.252.42) joined #scummvm. [23:07] [scummvm] wjp opened pull request #846: SCI: Make -propDict- unique for each class (master...sci_propdict) https://git.io/vPzPk [23:07] GitHub84 (GitHub84@192.30.252.42) left #scummvm. [23:07] good night [23:10] bgKa (~bgk@2001:41d0:2:599c::2a60:8434) joined #scummvm. [23:10] #scummvm: mode change '+o bgKa' by ChanServ!ChanServ@services. [23:18] bgKa (~bgk@2001:41d0:2:599c::2a60:8434) left irc: Ping timeout: 250 seconds [23:25] bgKa (~bgk@2001:41d0:2:599c::2a60:8434) joined #scummvm. [23:25] #scummvm: mode change '+o bgKa' by ChanServ!ChanServ@services. [23:53] SylvainTV (~SylvainTV@LFbn-1-8392-241.w81-254.abo.wanadoo.fr) left irc: Read error: Connection reset by peer [23:57] ScottT (~ScottT@2401:a400:6100:f400:10fb:23cd:9d70:da80) left irc: Read error: Connection reset by peer [00:00] --- Wed Oct 12 2016