[Back to Index]

[00:04] <-- LittleToonCat left irc: Ping timeout: 268 seconds
[00:04] <-- |Cable| left irc: Ping timeout: 260 seconds
[00:16] --> |Cable| joined #scummvm.
[00:35] <tsoliman> is libtitanic.a supposed to be this huge is it because it is just a WIP?
[00:38] <snover> what do you mean by huge?
[00:39] <snover> tsoliman: ^
[00:39] <tsoliman> (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] <tsoliman> if I sum all the size of all the .a files in the project they are 880112
[00:39] <tsoliman> libtitanic.a alone is 412628
[00:39] <tsoliman> so almost half of that
[00:40] <tsoliman> 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] <tsoliman> 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] <tsoliman> it's not a big deal .. just an idle question :)
[00:42] <snover> it certainly has a lot of TUs
[00:43] <snover> if you enable only the titanic engine and build, does it still take many minutes?
[00:45] <tsoliman> trying it now, it's not a very parallelizable make apparently
[00:45] <tsoliman> (using -j5 is as fast as using -j2 with 4 cores)
[00:46] <snover> at least it isnt 111434240 bytes, which is the size of libtitanic.a when i build without --enable-release :P
[00:46] <tsoliman> also I should consider running ccache on this VM
[00:46] <tsoliman> this toolchain always enables the specific release optimization -Os
[00:47] <tsoliman> with or without --enable-release :) .. this is because its target is a very crappy ARM CPU
[00:48] <tsoliman> 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] <tsoliman> the toolchain requires Debian 5 - I am running it in VM on an i7, giving it 4 "CPUs" of my 8 "CPUs"
[00:51] <snover> i feel like i have noticed the lack of build parallelisation with make
[00:52] <tsoliman> I've disabled libcurl (for now) FWIW
[00:53] <tsoliman> 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] <tsoliman> snover: I think the linker is stuck
[00:54] <tsoliman> it is chewing 100% of a single core
[00:55] <tsoliman> ok it finished
[00:55] <tsoliman> so theoretically it will take 10+ mins to finish if I enable everything
[00:56] <tsoliman> (just the linker - I test this by deleting the scummvm binary and rerunning make)
[00:57] <tsoliman> granted this is a really old toolchain
[00:58] <tsoliman> it is several virtualization levels deep too .. macOS -> VMware running Debian 5 -> Scratchbox 2 cross compiling ARM
[01:00] <snover> turtles all the way down
[01:03] <tsoliman> on the bright side, the host mac is on an SSD .. so I thought "why even ccache"
[01:04] <tsoliman> it used to (with make -j5) be sooo fast (<1 min per build) so you don't need SSD
[01:05] <tsoliman> s/SSD/ccache
[01:05] <-- Henke37 left irc: Quit: ERR_SHUTDOWN
[01:07] <tsoliman> there's 16GB on this host, I could theoretically just make a 3GB ramdrive and put the ccache files there ..
[01:34] --> GitHub0 joined #scummvm.
[01:34] <GitHub0> [scummvm] csnover pushed 2 new commits to master: https://git.io/vPEOI
[01:34] <GitHub0> scummvm/master 4b6b328 Colin Snover: SCI32: Check for existence of visiblePlane before dereferencing...
[01:34] <GitHub0> 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 joined #scummvm.
[01:59] <-- Vampire0_ left irc: Ping timeout: 260 seconds
[02:00] <-- Dominus left irc: Ping timeout: 260 seconds
[02:00] --> DominusExult joined #scummvm.
[02:00] <-- DominusExult left irc: Changing host
[02:00] --> DominusExult joined #scummvm.
[02:00] Nick change: DominusExult -> Dominus
[02:26] <-- snover left irc: Quit: Leaving.
[04:02] --> Polynomial-C joined #scummvm.
[04:04] <-- Poly-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.

[06:31] --> m_kiewitz joined #scummvm.
[06:31] <-- m_kiewitz left irc: Changing host
[06:31] --> m_kiewitz joined #scummvm.
[06:31] #scummvm: mode change '+o m_kiewitz' by ChanServ!ChanServ@services.
[06:48] <-- bgKa left irc: Ping timeout: 260 seconds
[06:54] --> bgKa joined #scummvm.
[06:54] #scummvm: mode change '+o bgKa' by ChanServ!ChanServ@services.
[06:54] <m_kiewitz> _sev: which devs are on Mac OS X again?
[06:54] <m_kiewitz> snover, right?
[06:54] <_sev> m_kiewitz: I am
[06:54] <m_kiewitz> oh nice
[06:55] <m_kiewitz> there seems to be an issue in the OpenGL backend on OS X?
[06:55] <m_kiewitz> https://bugs.scummvm.org/ticket/9607#comment:1
[06:55] <_sev> why is that a bug?
[06:56] <m_kiewitz> the game shouldn't work that insanely fast
[06:56] <_sev> the original removed any delays during the fastest mode
[06:56] <m_kiewitz> I'm delaying for 10 milliseconds each
[06:56] <_sev> and its performance was dependent on the CPU speed
[06:56] <m_kiewitz> 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] <m_kiewitz> 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] <m_kiewitz> and it seems as if the backend somewhat doesn't do delays of 10 milliseconds at all
[06:57] <m_kiewitz> i can't think of any other reason for that behavior
[06:57] <m_kiewitz> 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] <m_kiewitz> yes, me neither
[06:59] <m_kiewitz> but try black cauldron
[07:00] --> waltervn joined #scummvm.
[07:00] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services.
[07:00] <_sev> ask the user to clarify
[07:00] <m_kiewitz> 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] <waltervn> morning
[07:00] <m_kiewitz> well the user says that "fast" also runs insanely fast
[07:01] <m_kiewitz> morning walter
[07:01] <m_kiewitz> 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] <m_kiewitz> for me everything works properly, quite fast but not insanely fast
[07:03] <m_kiewitz> 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] <m_kiewitz> 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] <m_kiewitz> no, I'm not delaying just 10 milliseconds, I'm delaying for that amount multiple times
[07:07] <m_kiewitz> 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] <m_kiewitz> 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] <wjp> morning
[07:26] <wjp> hurray, a tag :-)
[07:29] <m_kiewitz> _sev: AGI should already process next cycle only, when a certain amount of time has passed
[07:29] <m_kiewitz> if (_passedPlayTimeCycles >= timeDelay) {
[07:30] <m_kiewitz> _passedlayTimeCycles is actually calculated based on real time
[07:30] <m_kiewitz> and that's done inside void AgiEngine::inGameTimerUpdate()
[07:31] <m_kiewitz> 1 cycle should be around 50 milliseconds
[07:31] <m_kiewitz> / This is also called in the main loop, because the game needs to be sync'd to 20 cycles per second
[07:31] <m_kiewitz> so the current OpenGL behavior makes no sense unless timer related functions do not work properly on Mac OS X
[07:33] <m_kiewitz> 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] <m_kiewitz> you could add a warning to
[07:34] <m_kiewitz> if (playTimeCycleDelta > 0) {
[07:34] <m_kiewitz> _passedPlayTimeCycles += playTimeCycleDelta;
[07:34] <m_kiewitz> }
[07:34] <m_kiewitz> and then check how that works on Mac OS X / OpenGL
[07:35] <m_kiewitz> maybe there is some bug inside my code but I don't see it
[07:35] <m_kiewitz> and as I said - it works properly for me on Windows in any case
[07:35] <m_kiewitz> the game should not be able to run at some insane effective frame rate
[07:35] <_sev> ok, running now
[07:36] <m_kiewitz> I mean it actually can run at a higher frame rate, but frames would be duplicated and would not change
[07:37] <m_kiewitz> you could check the time delay variable of the game
[07:38] <m_kiewitz> 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] <m_kiewitz> yes, that should be fine
[07:39] <_sev> also FPS drops if I move mouse fast
[07:39] <m_kiewitz> 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] <m_kiewitz> passedPlayTimeCycles means that at least 50 milliseconds have happened inbetween
[07:41] <m_kiewitz> and only then game scripts are called (actual game cycle)
[07:41] <m_kiewitz> that's not the case for you?
[07:41] <m_kiewitz> the graphics can be updated at a faster rate, but without game scripts changing anything
[07:42] <m_kiewitz> 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 left irc: Ping timeout: 248 seconds
[07:45] --> TMM joined #scummvm.
[07:46] <_sev> and same under 2x
[07:46] <_sev> but the animation is definitely faster O_o
[07:46] <m_kiewitz> but the game runs faster?!
[07:46] <m_kiewitz> o_O
[07:46] <m_kiewitz> can you put a warning right at the start of void AgiEngine::interpretCycle()?
[07:46] <m_kiewitz> and then check again?
[07:47] <_sev> doing
[07:51] <_sev> it is about the same, 75 fps
[07:52] <m_kiewitz> 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] <m_kiewitz> that definitely should not be the case
[07:52] <_sev> so you have a bug somewhere
[07:52] <m_kiewitz> it seems so
[07:54] <-- kurtwr left irc: Read error: Connection reset by peer
[07:55] --> kurtwr joined #scummvm.
[08:03] <-- TMM left irc: Quit: Ex-Chat
[08:32] --> OmerMor joined #scummvm.
[08:39] --> Poly-C joined #scummvm.
[08:40] --> L0ngcat_ 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 joined #scummvm.
[08:41] <-- m_kiewitz left irc: Changing host
[08:41] --> 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 joined #scummvm.
[09:19] --> _sev|work joined #scummvm.
[09:19] <-- _sev|work left irc: Changing host
[09:19] --> _sev|work joined #scummvm.
[09:19] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[09:41] <-- erdic left irc: Ping timeout: 248 seconds
[09:42] --> erdic joined #scummvm.
[10:00] --> Henke37 joined #scummvm.
[10:14] <rootfather> wohoo, 1.9.0 tagged \o/
[10:45] <-- Henke37 left irc: Ping timeout: 260 seconds
[10:57] --> salty-horse joined #scummvm.
[10:57] <-- salty-horse left irc: Changing host
[10:57] --> salty-horse joined #scummvm.
[10:57] #scummvm: mode change '+o salty-horse' by ChanServ!ChanServ@services.
[11:00] --> Henke37 joined #scummvm.
[11:03] --> ny00123 joined #scummvm.
[12:08] --> ajax16384 joined #scummvm.
[12:08] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[13:39] <-- Rasi left irc: Ping timeout: 250 seconds
[13:41] --> Rasi joined #scummvm.
[14:32] #scummvm: mode change '+o fuzzie' by ChanServ!ChanServ@services.
[14:41] --> snover joined #scummvm.
[14:41] #scummvm: mode change '+o snover' by ChanServ!ChanServ@services.
[15:00] --> LittleToonCat joined #scummvm.
[15:00] --> WinterGrascph joined #scummvm.
[15:00] #scummvm: mode change '+o WinterGrascph' by ChanServ!ChanServ@services.
[15:01] <-- WinterGrascph left irc: Client Quit
[15:22] --> girafe joined #scummvm.
[15:22] <-- _sev|work left irc: Quit: This computer has gone to sleep
[15:29] --> Littleboy joined #scummvm.
[15:29] #scummvm: mode change '+o Littleboy' by ChanServ!ChanServ@services.
[15:39] <-- phyber left irc: Ping timeout: 260 seconds
[15:39] --> phyber joined #scummvm.
[15:46] <-- ajax16384 left irc: Quit: Leaving
[15:59] <-- TMM left irc: Quit: Ex-Chat
[16:08] --> ajax16384 joined #scummvm.
[16:08] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[16:37] <-- snover left irc: Quit: Leaving.
[16:41] --> WooShell joined #scummvm.
[16:44] <exmensa> Are the ZVision games not launching in master known issues?
[16:49] <exmensa> (on Windows, console error for both is 'Invalid TrueMotion1 compression type 31')
[16:50] <m_kiewitz> _sev: when you got those 75 cycles per second, did you select "fastest"?
[16:50] <m_kiewitz> because I'm still only getting 20 cycles per second on "fast" in black cauldron
[16:51] <wjp> exmensa: haven't heard that before
[16:51] <m_kiewitz> 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] <wjp> exmensa: maybe you have a game version we don't know about, or maybe your data files are corrupted?
[16:54] <exmensa> 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] <wjp> where did you get the 1.9.0 and master builds?
[16:55] <exmensa> The daily build page.
[16:55] <wjp> which platform?
[16:55] <wjp> Windows?
[16:55] <exmensa> Windows 10, tried master for both 32/64 bit and stable 64 bit
[16:56] <wjp> which ones did you download exactly?
[16:58] <exmensa> Both were 'latest' on buildbot page, c118e2fe if that's what you're looking for
[16:58] <wjp> from this page? http://buildbot.scummvm.org/builds.html
[16:58] <exmensa> Right.
[16:58] <wjp> bottom row?
[16:58] <exmensa> Right.
[16:58] <wjp> ok
[16:58] <wjp> odd
[16:58] <wjp> and you say "development" doesn't work, but "stable" does work?
[16:59] <wjp> let's see what I can figure out about the difference between those two
[16:59] <exmensa> Correct. Development throws the error right on launching the game.
[17:01] <WooShell> meow =^.^=
[17:04] <wjp> right, so we really broke this recently
[17:04] <wjp> hm, only thing that appears related at first glance is an avi demuxer change
[17:06] <wjp> yeah, that's the culprit
[17:07] <wjp> could you file a bug report on https://bugs.scummvm.org/ about this?
[17:07] <exmensa> Sure, I think I have a github login, I'll see if I can track it down
[17:11] <wjp> great, thanks
[17:16] <OmerMor> Happy Yom Kippur guys
[17:19] <exmensa> wjp: Filed #9608, are there any other details you'd like there?
[17:21] <wjp> thanks!
[17:21] <exmensa> Thank you :)
[17:22] <wjp> left a follow-up comment about the culprit; hopefully we'll be able to fix it soon
[17:22] <exmensa> Good to hear.
[17:28] --> t0by joined #scummvm.
[17:28] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services.
[17:33] <-- bgKa left irc: Ping timeout: 250 seconds
[17:37] --> bgKa joined #scummvm.
[17:37] #scummvm: mode change '+o bgKa' by ChanServ!ChanServ@services.
[17:44] --> Anonymous joined #scummvm.
[17:44] <Anonymous> Hi! Any devs online?
[17:44] Nick change: Anonymous -> Guest47897
[17:45] <Guest47897> Oh, I guess Anonymous was taken. I'm now Guest + a bunch of numbers.
[17:45] <wjp> what can we help you with?
[17:46] <Guest47897> ScummVM gave me an error, but I think the error itself is wrong. Just a moment, I'll grab the log...
[17:47] <Guest47897> Okay, here's the log message (more follows in a moment):
[17:47] <Guest47897> 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] <Guest47897> Now, I've looked at the specified offset in the specified file...
[17:47] <Guest47897> By starting Word, pressing Alt+F11 and then using the console.
[17:48] <Guest47897> 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] <Guest47897> The answer I got was:
[17:48] <Guest47897> SCRP
[17:49] <Guest47897> Which is the same as what ScummVM was expecting to find, but strangely didn't find. I'm perplexed.
[17:49] --> TMM joined #scummvm.
[17:50] <-- bgKa left irc: Ping timeout: 260 seconds
[17:50] <wjp> most often this error message just indicates a corrupt data file
[17:50] <Guest47897> That was what I thought at first.
[17:51] <Guest47897> But when I inspected the file, the required tag was present at the offset in question.
[17:51] <Guest47897> Also, it worked before on a different computer which is unfortunately broken. I cannot remember if I used ScummVM then though.
[17:53] <Guest47897> 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] <wjp> just to be sure, have you double checked that ScummVM is indeed using C:\Program Files\the dig\ ?
[17:57] <Guest47897> I'll start it and check it with ProcessExplorer. Just a minute.
[17:58] <Guest47897> Okay, I'm getting the same error message. I'll look at its handles using Process Hacker.
[18:00] <Guest47897> It says: C:\Users\ROCO\AppData\Local\VirtualStore\Program Files\The Dig\DIG\DIG.LA1
[18:00] <Guest47897> Which is odd.
[18:00] --> SylvainTV joined #scummvm.
[18:00] #scummvm: mode change '+o SylvainTV' by ChanServ!ChanServ@services.
[18:00] <Guest47897> 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] <wjp> 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] <wjp> (it does a seek and a 4 byte read right before it)
[18:01] <Guest47897> It does, doesn't it? I think it's somehow using the wrong file or something.
[18:05] <Guest47897> The game's config points to: C:\Users\ROCO\AppData\Local\VirtualStore\Program Files\The Dig\DIG
[18:05] <Guest47897> But it seems to be reading this file: C:\Users\ROCO\AppData\Local\VirtualStore\Program Files\The Dig\DIG\DIG.LA1
[18:06] <Guest47897> At first glance that file seems to be a truncated version of the original dig.la1.
[18:07] <Guest47897> 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] <wjp> you say your game config points to C:\Users\ROCO\AppData\Local\VirtualStore\... ?
[18:09] <Guest47897> No.
[18:09] <wjp> copy-paste error earlier then I guess
[18:10] <wjp> I wonder if Windows does some kind of internal transparent redirecting of this
[18:10] <wjp> (don't use Windows myself, so I can't say much about it)
[18:10] <Guest47897> 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] <Guest47897> 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] <wjp> ok, see you later
[18:17] --> Sylvain joined #scummvm.
[18:19] --> bgKa joined #scummvm.
[18:19] #scummvm: mode change '+o bgKa' by ChanServ!ChanServ@services.
[18:19] <-- Sylvain left irc: Client Quit
[18:28] <OmerMor> wjp: I looked into your uninitialized read bug in QfG3. I added the info to the ticket.
[18:29] <OmerMor> Looks like a script bug.
[18:32] <wjp> I saw; thanks
[18:33] <wjp> (it's not really "mine", by the way; I just did some multiple-bugs-in-one-report cleanup)
[18:33] <OmerMor> oh, ok :)
[18:35] <wjp> can you see in other notify functions what it should return on unhandled messages?
[18:35] --> criezy joined #scummvm.
[18:35] #scummvm: mode change '+o criezy' by ChanServ!ChanServ@services.
[18:35] <OmerMor> The base Rgn::notify function is an empty function. returns nothing.
[18:36] <OmerMor> Rm740::notify also returns nothing. It just redraws the rope bridge.
[18:37] <wjp> odd
[18:37] <OmerMor> 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 joined #scummvm.
[18:37] <-- _sev|work left irc: Changing host
[18:37] --> _sev|work joined #scummvm.
[18:37] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[18:37] --> GitHub138 joined #scummvm.
[18:37] <GitHub138> [scummvm] sev- pushed 1 new commit to master: https://git.io/vPzvQ
[18:37] <GitHub138> scummvm/master 719bc03 Eugene Sandulenko: GRAPHICS: Added stub for BDF font scaler
[18:37] GitHub138 (GitHub138@192.30.252.34) left #scummvm.
[18:38] <OmerMor> It is called explicitly (and not polymorphically) from both script 470 and script 471.
[18:38] <-- _sev|work left irc: Client Quit
[18:39] <OmerMor> 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 joined #scummvm.
[18:39] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[18:39] <-- _sev|work left irc: Client Quit
[18:40] <OmerMor> 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_ joined #scummvm.
[18:51] <OmerMor> 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] <OmerMor> Any idea why it's not triggered?
[18:51] <m_kiewitz> gog "fan" patches
[18:51] <wjp> hm, return values just go into the accumulator, right?
[18:51] <m_kiewitz> wjp: correct
[18:52] <wjp> huh, I completely missed that workaround. Oops
[18:52] <m_kiewitz> ah that workaround doesn't use a signature, that's weird then
[18:52] <wjp> it's an uninitialized read
[18:52] <m_kiewitz> yes, but the workaround is for uninitialized reads
[18:53] <wjp> we don't seem to be able to read the object's name
[18:53] <wjp> (0008) [014] name = 0000:dec0 (57024)
[18:53] <m_kiewitz> is it index 0?
[18:53] <m_kiewitz> oh
[18:53] <m_kiewitz> so maybe really fan patches :(
[18:53] <wjp> wonder if they forgot the relocation entry
[18:53] <m_kiewitz> it should be the room itself
[18:53] <m_kiewitz> or is it another object?
[18:53] <wjp> (0006) [1006] -super- = 0004:12bc (Rm)
[18:54] <m_kiewitz> it only triggers for the GOG version correct?
[18:54] <wjp> yes
[18:54] <m_kiewitz> is that script patched in that version?
[18:54] <OmerMor> yes
[18:55] <m_kiewitz> do we see the name as <unknown>?
[18:55] #scummvm: mode change '+o [vEX]' by ChanServ!ChanServ@services.
[18:55] <wjp> d: script 470 - <invalid name>::notify(0000:fff1)
[18:56] <wjp> (in the debugger bt)
[18:56] <m_kiewitz> ah yes
[18:56] <OmerMor> that could explain it
[18:56] <m_kiewitz> dang, those silly fan patches
[18:56] <m_kiewitz> yes, it explains it
[18:56] <OmerMor> the workaround names the method
[18:56] <m_kiewitz> the workaround is checked that way
[18:56] <m_kiewitz> and the fan patches script is simply broken
[18:56] <wjp> good news is that <invalid name> works in the workaround :-)
[18:56] <OmerMor> how does the object name is retrieved in the debugger?
[18:57] <m_kiewitz> yes, of course
[18:57] <wjp> so we can presumably duplicate it with rm470 + "<invalid name>"
[18:57] <m_kiewitz> yes but on the other hand i don't really want to duplicate every single script patch for the broken GOG version
[18:57] <m_kiewitz> i mean we could, but we don't even know if those fan patche introduced maybe even more issues
[18:57] <m_kiewitz> patches
[18:57] <OmerMor> what causes the script to have an invalid name object?
[18:58] <m_kiewitz> broken script data
[18:58] <wjp> hypothesis: broken relocation table in the patched script
[18:58] <m_kiewitz> yes
[18:58] <OmerMor> SCI Companion recognize the object name correctly in the GOG version
[18:58] <wjp> yeah, but they don't actually need to do the relocations to parse the data
[18:59] <OmerMor> what is this relocation table?
[18:59] <wjp> because SCI Companion can safely assume all pointers point into the script itself
[18:59] <wjp> it is a list of all pointers in the script data
[18:59] <wjp> when loading the script, all those pointers have to updated to the address at which the script is loaded
[19:00] <OmerMor> so there's an entry for the notify function in the table in script 470?
[19:01] <wjp> yes
[19:01] <wjp> 40a is in there
[19:01] <OmerMor> and this value is being assigned at runtime or is it a static value from the script file?
[19:01] <wjp> hm
[19:02] <wjp> maybe I'm confused
[19:02] <wjp> but the notify function isn't relevant here
[19:02] <wjp> the 'name' property is
[19:02] <OmerMor> ok
[19:02] <wjp> the name property is a pointer
[19:03] <OmerMor> the name property of the Rm470 instance?
[19:03] <wjp> and it points to 'rm470' in the script (well, heap) data
[19:05] <OmerMor> Can I see this table using SV ?
[19:05] <OmerMor> Or any other tool?
[19:05] <wjp> no idea
[19:06] <OmerMor> Where did you see the value 40a?
[19:06] <wjp> that was a random coincidence :-)
[19:07] <OmerMor> What's I'm trying to understand if there's a way to overcome the broken relocation tables
[19:08] <OmerMor> 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] <criezy> For those who can read French:
[19:15] <criezy> 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] <criezy> (Twenty years after their golden age, adventure games are back)
[19:16] <m_kiewitz> Where? :P
[19:17] <wjp> oddly the relocation table might be ok
[19:18] <wjp> no idea where the dec0 is coming from
[19:18] <OmerMor> what dec0?
[19:18] --> sluicebox joined #scummvm.
[19:19] <wjp> 20:53 < wjp> (0008) [014] name = 0000:dec0 (57024)
[19:22] <-- _sev left irc: Quit: Leaving
[19:32] --> _sev joined #scummvm.
[19:32] <-- _sev left irc: Changing host
[19:32] --> _sev joined #scummvm.
[19:32] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[19:39] --> Strangerke joined #scummvm.
[19:42] <wanwan> hi
[19:45] #scummvm: mode change '+o Strangerke' by ChanServ!ChanServ@services.
[19:45] <Strangerke> hi guys
[19:45] <madmoose> hi Strangerke
[19:46] <criezy> hi
[19:47] <m_kiewitz> ahhhh
[19:47] <m_kiewitz> Strangerke
[19:48] <Strangerke> yeah, I was in PAris the last two days and the wifi wasn't working at all at the hotel >:(
[19:57] --> GitHub150 joined #scummvm.
[19:57] <GitHub150> [scummvm] Strangerke pushed 2 new commits to master: https://git.io/vPz3l
[19:57] <GitHub150> scummvm/master 7c13823 Strangerke: DM: Handle demo dungeon file
[19:57] <GitHub150> 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] <wjp> m_kiewitz, OmerMor: the relocation table is fine. Looks like a script is using this name field as storage, maybe?
[20:00] <criezy> _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] <m_kiewitz> wjp: but why would that happen with the fan patches only?
[20:00] <m_kiewitz> maybe there is some other glitch somewhere else inside the fan script that writes to it?
[20:00] <m_kiewitz> but still why should any script code write to the name
[20:00] <wjp> it would be a nice hack if a script needed an extra variable to write data :-)
[20:01] <wjp> (e.g., for timing or something)
[20:03] <_sev> criezy: oops
[20:06] --> GitHub126 joined #scummvm.
[20:06] <GitHub126> [scummvm-tools] sev- created branch-1-9-0 (+1 new commit): https://git.io/vPzsa
[20:06] <GitHub126> 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 joined #scummvm.
[20:07] <GitHub16> [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 joined #scummvm.
[20:10] <GitHub48> [scummvm-tools] sev- pushed 1 new commit to branch-1-9-0: https://git.io/vPzGL
[20:10] <GitHub48> 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 left irc: Quit: Leaving
[20:18] <wjp> 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] <m_kiewitz> aaarrrggghhh
[20:19] <m_kiewitz> who the hell...
[20:19] <m_kiewitz> why not simply create more locals
[20:20] <-- t0by left irc: Quit: Bye!
[20:21] --> snover joined #scummvm.
[20:21] #scummvm: mode change '+o snover' by ChanServ!ChanServ@services.
[20:26] <snover> phew! after days of little conversation, today was a busy day in #scummvm
[20:27] <snover> wjp: would you have interest in talking about the -propDict- problem?
[20:28] <wjp> 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 left irc: Quit: Leaving
[20:29] <wjp> but no time like the present :-)
[20:29] <snover> free exercise!
[20:29] <wjp> indeed
[20:31] <wjp> so
[20:31] <wjp> propdict
[20:32] <snover> yeah.
[20:33] <snover> as you probably know already, in ssci -propDict- is a memid
[20:33] <wjp> I strongly suspected it
[20:34] <wjp> did you find the code that sets it?
[20:34] <wjp> I had a look around phant68k and sq6 without too much luck
[20:35] <wjp> but I expect we'll have to do relocations on -propDict- and -methDict-
[20:35] <snover> its in the Object constructor, one second.
[20:35] <wjp> ah
[20:36] <wjp> do I see 7 relocations in there?
[20:40] <wjp> looking in phant68k, but do you have it in sq6?
[20:41] <wjp> 496F8 I guess
[20:43] <sluicebox> snover: i'm getting gk1 crashes again when interrogating/interviewing using master
[20:44] <sluicebox> first room for example, click Ask on grace, the question screen appears, click Exit, click Ask on grace again
[20:44] <snover> wjp: ugh, sorry, temporary meltdown :)
[20:45] <sluicebox> and it bombs with Send to invalid selector...
[20:45] <sluicebox> i tried interviewing a few other characters, similar results
[20:45] <snover> sluicebox: the storage of intarrays changed, you need to start a new game, your save games are broken
[20:45] <sluicebox> i did
[20:45] <snover> oh
[20:46] <sluicebox> this isn't the same behavior as before, it loads correctly once, the second time bombs.
[20:46] <snover> sorry, i am broken
[20:46] <snover> i finished actually doing what you said you were doing
[20:47] <snover> i will try to figure out what happened as soon as i try to do this thing about propdict
[20:47] <sluicebox> 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] <sluicebox> cool, thanks!
[20:51] <snover> wjp: yes, 496f8
[20:52] <snover> 497b8 is also an object constructor, used for cloning
[20:54] <wjp> hm, not seeing it do relocations though
[20:57] <snover> i think that happens in LoadScript
[20:58] <wjp> I think I agree
[20:58] <wjp> just not 100% sure where yet :-)
[21:09] <wjp> ok
[21:09] <snover> you found it?
[21:10] <wjp> should be LoadScript+6E2 for -propDict-
[21:10] <wjp> LoadScript+7AD for -methDict-
[21:12] <wjp> (stepped through it to see where the properties were changed)
[21:13] <wjp> seems consistent with the +4 and the +6 (resp.) before that
[21:16] <wjp> not in the debugger now, but I also see a write to +A at +7EC
[21:17] <wjp> and +59F is writing to -super- at +C
[21:20] <snover> im a little behind but mostly tracking where you are at
[21:26] <snover> i am caught up now
[21:28] <-- ny00123 left irc: Quit: Leaving
[21:34] <snover> unfortunately i have to go now :( but i shall return.
[21:59] <wjp> 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] <wjp> (the check if -script= != 0xFFFF seems to be before it is overwritten by ... something)
[22:02] <wjp> but I'm still a bit confused about the whole structure here
[22:05] <-- WooShell 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 left irc: Ping timeout: 260 seconds
[22:09] <-- bgKa left irc: Ping timeout: 260 seconds
[22:09] <-- 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 joined #scummvm.
[22:13] #scummvm: mode change '+o bgKa' by ChanServ!ChanServ@services.
[22:15] <-- ajax16384 left irc: Read error: Connection reset by peer
[22:16] <wjp> snover: that loop is doing this for each object, AFAICT:
[22:16] <wjp> if (super == -1) super = 0; else super = memid of superclass;
[22:16] <wjp> if (script == -1) propDict = super->propDict; else propDict = allocate memory and fill;
[22:16] <wjp> methDict = allocate memory and fill
[22:16] <wjp> script = memid of script
[22:17] <wjp> 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 joined #scummvm.
[22:25] <wjp> 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 left irc: Ping timeout: 260 seconds
[22:25] <wjp> -methDict- apparently should be unique per object
[22:30] <-- frankyboy_ left irc: Read error: Connection reset by peer
[22:31] --> frankyboy_ joined #scummvm.
[22:33] <wjp> (but I don't see any SCI2 scripts using methDict)
[22:33] --> omer_mor_ joined #scummvm.
[22:35] <-- omer_mor left irc: Ping timeout: 240 seconds
[22:38] <snover> reading&
[22:40] <-- frankyboy_ left irc: Quit: #E>6C O >B 20A
[22:44] <snover> wjp: is there a chance of a conflict in the offset of the reg_t?
[22:45] <snover> also, can the hack be simplified slightly to use the segmentId that is passed into initializeObjectsSci11?
[22:45] <snover> i.e. `obj->setPropDictSelector(make_reg(segmentId, obj->getPropDictSelector().getOffset()));`
[22:47] <wjp> a conflict in the offset?
[22:48] <wjp> (oh, and yes, using segmentId is much better)
[22:49] <snover> 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] <wjp> :-)
[22:50] <snover> so this seems very good to me.
[22:51] <wjp> another option would be just setting it to reg
[22:51] <wjp> and methdict too
[22:51] <snover> oh, youre absolutely right.
[22:52] <wjp> (although that might end up confusing us in the future, but it _should_ satisfy the uniqueness properties these allocs give)
[22:56] <snover> what actually uses -methDict- ?
[22:56] <wjp> nothing AFAICT
[22:57] <snover> ok, good.
[22:57] <wjp> so we can probably just keep ignoring that I suppose
[22:58] <wjp> about bedtime for me
[22:58] <snover> would you like to do the honours or shall i?
[22:59] <wjp> if you don't mind it not being extensively tested, I can :-)
[22:59] <wjp> there is still the question of the SCI version range
[23:00] <wjp> I'm tempted to do it for all
[23:00] <snover> hm. i am being called away again so i guess it can wait until tomorrow to give time to think about that
[23:06] <wjp> quickly made it a PR
[23:07] <-- bgKa left irc: Ping timeout: 260 seconds
[23:07] --> GitHub84 joined #scummvm.
[23:07] <GitHub84> [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] <wjp> good night
[23:10] --> bgKa joined #scummvm.
[23:10] #scummvm: mode change '+o bgKa' by ChanServ!ChanServ@services.
[23:18] <-- bgKa left irc: Ping timeout: 250 seconds
[23:25] --> bgKa joined #scummvm.
[23:25] #scummvm: mode change '+o bgKa' by ChanServ!ChanServ@services.
[23:53] <-- SylvainTV left irc: Read error: Connection reset by peer
[23:57] <-- ScottT left irc: Read error: Connection reset by peer
[00:00] --- Wed Oct 12 2016