[Back to Index]

[00:09] <-- m_kiewitz left irc: Quit: technology isn't intrinsically good or evil. It's how it's used. Like the Death Ray.
[00:13] --> dreammaster joined #scummvm.
[00:13] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[00:31] --> omer_mor_ joined #scummvm.
[00:34] <-- omer_mor left irc: Ping timeout: 264 seconds
[00:39] <-- sluicebox left irc: Remote host closed the connection
[00:50] <-- frankyboy_ left irc: Remote host closed the connection
[00:52] <-- edheldil left irc: Ping timeout: 272 seconds
[01:15] <-- SylvainTV left irc: Read error: Connection reset by peer
[01:24] <-- Dominus left irc: Ping timeout: 264 seconds
[01:25] --> Dominus joined #scummvm.
[01:25] <-- Dominus left irc: Changing host
[01:25] --> Dominus joined #scummvm.
[02:24] --> GitHub151 joined #scummvm.
[02:24] <GitHub151> [scummvm] dreammaster pushed 2 new commits to master: https://git.io/vPq46
[02:24] <GitHub151> scummvm/master 08453de Paul Gilbert: TITANIC: Fix checking for transparency surfaces in blitRect methods
[02:24] <GitHub151> scummvm/master 454f20b Paul Gilbert: TITANIC: Fix setting pointers in RawSurface::moveX
[02:24] GitHub151 (GitHub151@192.30.252.45) left #scummvm.
[02:28] <-- snover left irc: Quit: Leaving.
[02:28] <dreammaster> Sigh. Yet another trouble with AVI handling. I'm not getting the right data for the secondary video tracks for transparency. I suspect that the offsets for the secondary track frames are relative to the first track's frames, since on it's own, it tries to read the first transparency frame chunk from 1008h of ycursors.avi, rather than 2E080h
[02:31] <Lightkey> its*
[02:31] <dreammaster> I'll have to experiment with it tomorrow.. drop my original video track filter callbacks, and if I can figure out the offseting, simply automatically expose secondary video tracks via a separate decode method
[02:38] <dreammaster> On the plus side, it looks like the guts of the CRawSurface class is simply implementing the MS RLE decoder, which we allready have in ScummVM. So as long as I can fix the decoder to read from the correct offset, my CRawSurface can be stripped down considerably
[02:48] <-- dreammaster left irc:
[03:17] --> Tkachov joined #scummvm.
[03:42] <-- timofonic2 left irc: Ping timeout: 272 seconds
[04:04] <-- Poly-C left irc: Ping timeout: 244 seconds
[04:04] --> Polynomial-C joined #scummvm.
[04:48] <-- LittleToonCat left irc: Remote host closed the connection
[06:03] <-- Tkachov left irc: Quit: https://fnordserver.eu
[06:55] --> waltervn joined #scummvm.
[06:55] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services.
[07:08] --> frankyboy_ joined #scummvm.
[07:27] --> salty-horse joined #scummvm.
[07:27] <-- salty-horse left irc: Changing host
[07:27] --> salty-horse joined #scummvm.
[07:27] #scummvm: mode change '+o salty-horse' by ChanServ!ChanServ@services.
[07:39] --> t0by joined #scummvm.
[07:39] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services.
[07:40] <-- t0by left irc: Read error: Connection reset by peer
[07:40] --> t0by joined #scummvm.
[07:40] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services.
[08:16] --> Henke37 joined #scummvm.
[08:18] --> WooShell joined #scummvm.
[08:22] <WooShell> meow =^.^=
[08:33] --> m_kiewitz joined #scummvm.
[08:33] #scummvm: mode change '+o m_kiewitz' by ChanServ!ChanServ@services.
[08:52] --> edheldil joined #scummvm.
[08:58] --> WinterGrascph joined #scummvm.
[08:58] #scummvm: mode change '+o WinterGrascph' by ChanServ!ChanServ@services.
[08:58] <-- WinterGrascph left irc: Client Quit
[08:58] <-- edheldil left irc: Ping timeout: 272 seconds
[09:08] <rootfather> hi folks
[09:08] <rootfather> I think I found another small rendering issue with SDL2, report following soon
[09:09] <rootfather> and I really hope that we get a checkbox item to select/disable bilineear filtering for all SDL2 modes as wjp suggested
[10:06] --> WinterGrascph joined #scummvm.
[10:06] #scummvm: mode change '+o WinterGrascph' by ChanServ!ChanServ@services.
[10:07] <-- WinterGrascph left irc: Remote host closed the connection
[10:46] <-- frankyboy_ left irc: Read error: Connection reset by peer
[10:46] <-- salty-horse left irc: Read error: Connection reset by peer
[10:47] --> frankyboy_ joined #scummvm.
[10:57] --> ny00123 joined #scummvm.
[10:58] <-- frankyboy_ left irc: Read error: Connection reset by peer
[10:59] --> frankyboy_ joined #scummvm.
[11:01] --> GitHub192 joined #scummvm.
[11:02] <GitHub192> [scummvm] sev- pushed 2 new commits to master: https://git.io/vPqiI
[11:02] <GitHub192> scummvm/master e2325f0 Eugene Sandulenko: FULLPIPE: Fix tube logic on scene37
[11:02] <GitHub192> scummvm/master 90ec4f6 Eugene Sandulenko: FULLPIPE: Fix crash on reenter to scene37
[11:02] GitHub192 (GitHub192@192.30.252.45) left #scummvm.
[11:03] --> SylvainTV joined #scummvm.
[11:03] #scummvm: mode change '+o SylvainTV' by ChanServ!ChanServ@services.
[11:13] <-- frankyboy_ left irc: Read error: Connection reset by peer
[11:14] --> frankyboy_ joined #scummvm.
[11:29] <-- Polynomial-C left irc: Quit: GNU/Linux, because I'd rather own a free OS than steal one that's not worth paying for.
[11:58] --> Polynomial-C joined #scummvm.
[12:03] <-- t0by left irc: Quit: Bye!
[12:09] --> WinterGrascph joined #scummvm.
[12:09] #scummvm: mode change '+o WinterGrascph' by ChanServ!ChanServ@services.
[12:33] --> criezy joined #scummvm.
[12:33] #scummvm: mode change '+o criezy' by ChanServ!ChanServ@services.
[12:42] <-- WinterGrascph left irc: Ping timeout: 244 seconds
[12:49] --> WinterGrascph joined #scummvm.
[12:49] #scummvm: mode change '+o WinterGrascph' by ChanServ!ChanServ@services.
[12:58] --> omer_mor joined #scummvm.
[13:01] <-- omer_mor_ left irc: Ping timeout: 264 seconds
[13:05] <-- WinterGrascph left irc: Quit: Leaving
[13:14] --> GitHub58 joined #scummvm.
[13:14] <GitHub58> [scummvm] sev- pushed 5 new commits to master: https://git.io/vPqDc
[13:14] <GitHub58> scummvm/master 4acb6c8 Eugene Sandulenko: FULLPIPE: Center mouse cursor on startup
[13:14] <GitHub58> scummvm/master 4ddf68a Eugene Sandulenko: FULLPIPE: Fix ball collision detection in scene14
[13:14] <GitHub58> scummvm/master 405c4e0 Eugene Sandulenko: FULLPIPE: Improve collision detection in scene06
[13:14] GitHub58 (GitHub58@192.30.252.42) left #scummvm.
[13:20] --> uruk-hai joined #scummvm.
[13:20] #scummvm: mode change '+o uruk-hai' by ChanServ!ChanServ@services.
[13:25] --> ajax16384 joined #scummvm.
[13:25] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[13:29] --> Littleboy joined #scummvm.
[13:29] #scummvm: mode change '+o Littleboy' by ChanServ!ChanServ@services.
[13:47] --> GitHub92 joined #scummvm.
[13:47] <GitHub92> [scummvm] sev- pushed 1 new commit to master: https://git.io/vPqyz
[13:47] <GitHub92> scummvm/master ed62aca Eugene Sandulenko: FULLPIPE: Implement MotionController::enableLinks()
[13:47] GitHub92 (GitHub92@192.30.252.46) left #scummvm.
[14:26] --> NuSuey joined #scummvm.
[14:34] <-- Dominus left irc: Ping timeout: 265 seconds
[14:35] --> Dominus joined #scummvm.
[14:35] <-- Dominus left irc: Changing host
[14:35] --> Dominus joined #scummvm.
[14:41] --> K4T joined #scummvm.
[14:42] <-- K4T left irc: Client Quit
[14:43] --> LittleToonCat joined #scummvm.
[14:44] <-- frankyboy_ left irc: Read error: Connection reset by peer
[14:45] --> frankyboy_ joined #scummvm.
[14:56] <-- frankyboy_ left irc: Read error: Connection reset by peer
[14:58] --> frankyboy_ joined #scummvm.
[15:11] <-- frankyboy_ left irc: Read error: Connection reset by peer
[15:12] --> frankyboy_ joined #scummvm.
[15:13] --> snover joined #scummvm.
[15:13] #scummvm: mode change '+o snover' by ChanServ!ChanServ@services.
[15:14] <m_kiewitz> ah snover
[15:15] <m_kiewitz> any reason why we can't just change the int16 type to the other type, that uses reg_ts?
[15:15] <m_kiewitz> internally?
[15:16] --> omer_mor_ joined #scummvm.
[15:18] <-- omer_mor left irc: Ping timeout: 272 seconds
[15:26] <-- frankyboy_ left irc: Read error: Connection reset by peer
[15:27] --> frankyboy_ joined #scummvm.
[15:31] <-- frankyboy_ left irc: Remote host closed the connection
[15:32] <snover> it would hide incorrect insertion of objects or other references into numeric arrays
[15:32] <m_kiewitz> how is it incorrect?
[15:33] <m_kiewitz> ssci had uint16 offsets to objects and so on
[15:33] <snover> how is reading an object id as a number incorrect?
[15:34] <m_kiewitz> ssci didn't differentiate between those
[15:34] <wjp> rather than going this "incorrect" route: you've found no instances of mixed int16 / reference arrays?
[15:34] <m_kiewitz> and the scripts won't be able to do anything with those unless they use them on kernel calls, and then we get signature mismatches anyway
[15:34] <m_kiewitz> sci16 does exactly the same
[15:35] <wjp> the difference is that sci32 (tries to) differentiate between int16 and refs
[15:35] <wjp> so we can already enforce the type check earlier
[15:35] <snover> wjp: you mean, a game that intentionally sometimes puts int16s in an array sometimes, and then other times puts references into the same array?
[15:36] <wjp> snover: not necessarily intentionally, but, yes
[15:36] --> frankyboy_ joined #scummvm.
[15:36] <m_kiewitz> but for what in the end?
[15:37] <wjp> it triggers the relevant warnings closer to where the script problem is
[15:37] <m_kiewitz> did sci32 actually do anything different between int16 + ref handling?
[15:37] <snover> wjp: i havent noticed anything like that, but then, i didnt think to put in an assertion for it
[15:37] <snover> so it is possible numbers are going into IDArrays
[15:38] <m_kiewitz> also do we have documentation on that or are we just guessing around?
[15:38] <wjp> although that now that I think about it, int16s going into IDArrays is not necessarily a problem I suppose
[15:38] <m_kiewitz> i mean in case ssci32 actually aborted or did some extra checks, but that's quite obviously not the case otherwise the gk1 script patches wouldn't be needed
[15:39] <snover> m_kiewitz: there is no way that ssci could have differentiated between int16s and object references, which is why these errors are happening in scummvm and worked in ssci
[15:39] <snover> there has been a situation where phantasmagoria tries to put ego object into a string array
[15:39] <m_kiewitz> and that corrupted a string?
[15:40] <m_kiewitz> i mean does it actually have an actual effect on anything?
[15:40] <snover> also, there would never be a signature mismatch on any of this, since the kernel call (kArraySetElements) is generic for all arrays
[15:40] <m_kiewitz> no i was talking obviously about scripts actually reading data from inside the array and then passing that to a kernel call
[15:41] <m_kiewitz> also - as i already asked - was this other type just added for fun? or does the original code does anything differently based on that type?
[15:42] <m_kiewitz> maybe it actually does some tiny thing differently and that was why they did what they did
[15:42] <m_kiewitz> or maybe it's not, but was supposed to and they never actually implemented it, except for the 2 possible types
[15:43] <m_kiewitz> and in that case our assumptions would be semi-correct, but it wouldn't make sense to do it in any case simply because there was no reason for anyone to actually use it that way and it also never worked that way
[15:44] <wjp> I'm completely lost on what you're talking about now
[15:44] <m_kiewitz> about the ID-type and the int16 type
[15:44] <wjp> what are "it" and "that way"?
[15:44] <m_kiewitz> 2 types, so is there any difference at all in original SCI32?
[15:44] <m_kiewitz> maybe they added some "free reference" code when the array was deleted or something like that
[15:45] <m_kiewitz> they couldn't check if you inserted actual references or raw int16s, so it's either a feature that was never actually implemented
[15:45] <m_kiewitz> or it's some tiny difference somewhere and we just assume that they meant ID-array type of references and the other one for raw int16
[15:46] <m_kiewitz> "that way" == blocking reference writes to int16 arrays
[15:46] <m_kiewitz> has anyone actually checked the original code on that first?
[15:46] <wjp> I'm pretty sure snover quite extensively RE'ed these new functions :-)
[15:47] <snover> of course, i dont add features just by guesswork&
[15:47] <m_kiewitz> so what's the difference for handling int16 array types and ID array types in ssci?
[15:47] <m_kiewitz> and where does this "int16 is only meant for raw int16s" come from? SSCI obviously couldn't differentiate or check
[15:48] <snover> it comes from the system script array.sc
[15:48] <m_kiewitz> in what way?
[15:48] <-- frankyboy_ left irc: Remote host closed the connection
[15:48] <m_kiewitz> are there script differences? are there kernel differences?
[15:49] <snover> in the ssci kernel there is no difference in the way IntArray and IDArray are handled, but it is clear that IntArray was intended for numbers and IDArray was intended for objects/references
[15:49] <m_kiewitz> how is this clear, when SSCI couldn't differentiate and obviously also didn't check?
[15:49] <m_kiewitz> are there script differences then?
[15:49] <snover> again this kind of goes back to what i was saying before, about how ssci didnt do lots of things that scummvm does, like validating kernel call signatures
[15:49] <m_kiewitz> if so, then it what way?
[15:50] <snover> it doesnt mean that they intended for people to call the kernel with invalid arguments, it just happened sometimes because there are no checks in ssci
[15:50] <m_kiewitz> kernel call signatures is not the same as this here
[15:51] <m_kiewitz> again - how is it clear, when SSCI couldn't differentiate and also didn't check? Is there at least some script differences?
[15:51] <m_kiewitz> or are there just 2 types and we assume that they meant it to be that way?
[15:51] <m_kiewitz> as i said - maybe they wanted to add such checks, but didn't have the time to do it, so it was never implemented, and that's why there are 2 types and that's it?
[15:52] --> frankyboy_ joined #scummvm.
[15:52] <wjp> I think what m_kiewitz is trying to ask is if there were any in-interpreter differences between int16 arrays and ID arrays
[15:53] <snover> I dont know if there are or arent
[15:54] <m_kiewitz> wjp: yes
[15:54] <snover> The game programmers accidentally used IntArray to hold references too so obviously they arent incredibly different
[15:54] <m_kiewitz> to me it really looks like some unfinished feature, they probably wanted to add checks, didn't have time to implement them and then left it as it is
[15:54] <m_kiewitz> which is why script developers weren't forced to do it that way
[15:55] <wjp> in either case the distinction is quite convenient for us, as we can (and do) in fact do those checks
[15:55] --> TMM joined #scummvm.
[15:55] <m_kiewitz> but there is no real distiction
[15:55] <wjp> so?
[15:55] <m_kiewitz> it's just 2 types, with no difference between them
[15:55] <wjp> so?
[15:55] <m_kiewitz> which is why sci script developers sometimes used int16 and sometimes used the other one
[15:55] <wjp> so?
[15:55] <m_kiewitz> because it made no difference
[15:55] <m_kiewitz> you want to script patch every single occurence?
[15:56] <m_kiewitz> do you allow raw int16s in ID arrays?
[15:56] <m_kiewitz> what will you do in case they write int16 + ids into arrays? you want to script patch the whole game?
[15:56] <wjp> yes, int16s go into ID arrays
[15:56] <m_kiewitz> so why not simply combine those 2? just like in the ID array case or in kMemory case, etc.?
[15:57] <wjp> "simply"?
[15:57] <m_kiewitz> there is no difference for the kernel between those 2
[15:57] <wjp> let's cross that bridge when it turns out to be necessary?
[15:57] <m_kiewitz> so we could just act like the sierra kernel and treat them the same
[15:57] <wjp> yes, but you lose the error checking
[15:57] <m_kiewitz> well you already allow raw int16s in ID arrays?
[15:57] <wjp> the other one
[15:58] <m_kiewitz> shouldn't that be removed then as well?
[15:58] <wjp> maybe
[15:58] <m_kiewitz> you already removed part of the so called error checking, why remove half of it and keep the other one?
[15:58] <wjp> I'm a bit confused on the point of this discussion
[15:58] <snover> there is no strong argument in either direction, and i dont really understand the accusatory nature of this conversation
[15:58] <wjp> because we _can_ keep the other half
[15:59] <m_kiewitz> yes we can, but we will have to patch tons of cases
[15:59] <wjp> we will?
[15:59] <m_kiewitz> or we dont?
[15:59] <wjp> shall we just decide what to do when we find this ton of cases?
[15:59] <m_kiewitz> don't we error out, when scripts want to write IDs to int16 arays?
[15:59] <wjp> we do
[15:59] <m_kiewitz> so we just keep it as it is? or we patch them out?
[16:00] <m_kiewitz> or we remove it?
[16:00] <m_kiewitz> that's the only options left
[16:00] <wjp> look at them on a case-by-case basis to see if it's a script bug
[16:00] <snover> patching scripts to use IDArray is annoying; messing with the SciArray interface to allow interchangeability is annoying
[16:00] <m_kiewitz> well in that case it's not really a script bug per se
[16:01] <wjp> I _really_ don't see the point of having this discussion now
[16:01] <m_kiewitz> and we also seem to have no problems with raw int16s inside ID arrays, which I don't understand
[16:01] <m_kiewitz> why don't we error() out on both of those?
[16:01] <snover> In SQ6 there was only one instance of an IntArray needing to be changed to IDArray during my walkthrough
[16:01] <m_kiewitz> well, the other way wasn't tested, right?
[16:02] <wjp> the difference is of course that we _can_ store int16s in reg_t's, but not the other way around. But we could certainly add a check for that to see how common it is
[16:02] <m_kiewitz> we can, yes. but we could also just use reg_ts for both of those. and we don't
[16:02] <m_kiewitz> so int16 arrays error()ing out on iD writes is explained because of error checking
[16:02] <m_kiewitz> why don't we check the other way too?
[16:03] <m_kiewitz> too many errors?
[16:03] <wjp> I asked that earlier
[16:03] <wjp> 17:37 <@snover> wjp: i havent noticed anything like that, but then, i didnt think to put in an assertion for it
[16:04] <snover> putting a reg_t into an int16 results in a loss of data, the other way around doesnt, so thats why I didnt put one there from the start
[16:04] <m_kiewitz> then it would make at least some sense for error checking
[16:04] <wjp> I really don't see what you're trying to achieve right now
[16:04] <m_kiewitz> i'm simply asking why the other way isn't checked
[16:05] <m_kiewitz> and i guess instead of patching every single occurrence, one could also instead do some sort of workaround lookup for array creation
[16:05] <m_kiewitz> and then change the array type based on let's say code signatures
[16:06] <m_kiewitz> such a lookup isn't the fastest thing to do though, no idea how many arrays are created and free'd by scripts
[16:07] <m_kiewitz> but it would make the whole thing a bit easier. there are also all sorts of translated game versions out there, we would have to check them all
[16:07] <wjp> we could certainly add a warning or error on storing raw int16s in IDArrays
[16:07] <m_kiewitz> it would make sense to do that
[16:07] <m_kiewitz> but i wouldn't be surprised in case scripts mixed those up
[16:08] <m_kiewitz> that could have also been the reason why it was never checked for in SSCI
[16:08] <m_kiewitz> either that or not enough time.
[16:10] <m_kiewitz> and qfg4 testing will probably be a nightmare in any case
[16:11] --> t0by joined #scummvm.
[16:11] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services.
[16:11] <m_kiewitz> although i guess we could even add another type for mixed ID + int16 usage
[16:12] <m_kiewitz> in case such mixed cases happen (and I would bet that they are)
[16:18] --> omer_mor joined #scummvm.
[16:19] <-- omer_mor_ left irc: Ping timeout: 244 seconds
[16:23] <m_kiewitz> snover: wait, I also thought about it a bit more in depth
[16:23] <m_kiewitz> can't we just create reg_t arrays in both cases - int16 + ID and just do the checks on top?
[16:23] <m_kiewitz> then we could trigger an error handler when the wrong type is written
[16:23] <m_kiewitz> and then we could change the array type when it's needed without any issues
[16:24] <m_kiewitz> because the current approach means that all sorts of saved games are effectively broken as soon as another one of those issues show up
[16:24] <m_kiewitz> if we created reg_t arrays in any case, we could simply change the array type whenever we want and without breaking all sorts of saved games
[16:25] <m_kiewitz> and we would also have a definitive trigger and we could then use a regular workaround table instead of script patching
[16:26] <m_kiewitz> then it would literally work just like kernel signatures and uninitialized reads and such things
[16:29] <m_kiewitz> and we could even for example set this object-write-into-byte-array in phantasmagoria to "ignore" and just not do the write at all
[16:30] <snover> it already is ignored since it does the call through kString and we get enough signature checking that way to detect the problem
[16:30] --> omer_mor_ joined #scummvm.
[16:31] <m_kiewitz> ok, still right now when a new one of those issues happens, we won't be able to fix saved games unless those saved games were made before array creation. Which in the worst case could be right at the start of the game
[16:32] <m_kiewitz> so in case we used reg_ts, it would make it possible for us to just add a workaround entry, tell it to change array type to ID and then let it do the write
[16:32] <-- omer_mor left irc: Ping timeout: 244 seconds
[16:32] <m_kiewitz> imo that would be a way better approach
[16:55] <-- NuSuey left irc: Quit: Connection closed for inactivity
[16:57] <-- uruk-hai left irc: Read error: Connection reset by peer
[17:23] <rootfather> hi
[17:24] <rootfather> can someone recommend a good soundfont for using in fluidsynth?
[17:26] --> dreammaster joined #scummvm.
[17:26] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[17:39] --> omer_mor joined #scummvm.
[17:40] <-- omer_mor_ left irc: Ping timeout: 244 seconds
[17:42] <-- frankyboy_ left irc: Read error: Connection reset by peer
[17:43] --> frankyboy_ joined #scummvm.
[17:49] --> NuSuey joined #scummvm.
[17:56] <snover> rootfather: Fluid R3
[17:56] <rootfather> thanks, I'll give that a try
[17:57] <-- frankyboy_ left irc: Read error: Connection reset by peer
[17:58] --> frankyboy_ joined #scummvm.
[18:06] <rootfather> snover, thanks, works like a charm and sounds really great
[18:07] <rootfather> btw, I have probably yet another issue with SDL2... when the mouse cursor moves over objects/animations in game, the cursor hangs for the fraction of a second
[18:08] <wjp> which game?
[18:08] <rootfather> most noticable in the animations in Myst or less visible in monkey island 1 when the game hovers over objects and the verb line changes
[18:11] <wanwan> oh, we just crossed 77,777 commits recently
[18:12] <dreammaster> Nice. Just a dozen or so more engines until we hit the big 100K :)
[18:12] <-- frankyboy_ left irc: Read error: Connection reset by peer
[18:12] <rootfather> wjp okay, I cannot reproduce it in monkey1 anymore, so probably something ate my CPU in the background
[18:13] <rootfather> but in Myst the cursor hangs while an animation is played and starts moving again as soon as the animation is over
[18:13] --> frankyboy_ joined #scummvm.
[18:13] Nick change: OGadmin -> borosky
[18:16] <rootfather> wjp but this could also be a myst related bug
[18:19] <wjp> that's what I would expect, yes
[18:22] <wjp> hm
[18:22] <wjp> I seem to actually not own myst
[18:32] <rootfather> maybe I should open (yet another) bug report
[18:37] <rootfather> btw I love how smooth the new bugtracker runs
[18:38] <rootfather> no bloat like on sf
[18:38] <wjp> much better reports too
[18:39] <rootfather> is it just me or do we have more bugreports incoming since we moved away from sf?
[18:40] <wjp> not sure
[18:45] <dreammaster> Well, snover's TODO list has contributed quite a few
[18:47] --> girafe joined #scummvm.
[18:49] <wjp> apart from those, the volume seems like it might be a bit lower currently
[18:49] <m_kiewitz> rootfather: for SCI+AGI, I think there was a single one for SCI (except for snovers SCI32 bug reports) and that's it
[18:49] <m_kiewitz> and that single one was about a game bug, not a ScummVM bug
[18:50] <m_kiewitz> wjp: what do you think about my idea for those ID/int16 arrays? Making them reg_t arrays all the time and then changing the type dynamically in case it's needed?
[18:50] <m_kiewitz> i could work on that
[18:51] <rootfather> m_kiewitz: okay, then I might be wrong
[18:51] <rootfather> I'm not observing the SCI+AGI engines though, because I am not really interested in those
[18:51] <m_kiewitz> rootfather: i was talking about AGI+SCI only, maybe it's different for other engines, idk.
[18:51] <rootfather> sorry to say :P
[18:51] <m_kiewitz> :(
[18:51] <m_kiewitz> :P
[18:52] <wjp> I have very little opinion as we don't yet know how often scripts do things wrong, and which things they do wrong
[18:52] <wjp> so I don't see the point in changing things now
[18:55] <m_kiewitz> if we keep it as it is, then all sorts of saved games may be broken including our owns
[18:56] <m_kiewitz> i surely won't play through gk1 again just to get some array issue in the end and having to throw away quite a few saved games.
[18:56] <wjp> huh?
[18:56] <wjp> converting an int16 array into a reg_t array later is trivial
[18:56] <m_kiewitz> "broken" as in wrong array type active, and our script patches won't change that
[18:56] <wjp> when loading, I mean
[18:57] <wjp> as long as we change the savegame version
[18:57] <m_kiewitz> but how are we supposed to know which array is supposed to be changed?
[18:57] <wjp> eh?
[18:57] <m_kiewitz> during load? When we patch the creation of the array?
[18:58] <wjp> what are you talking about?
[18:58] <m_kiewitz> ???
[18:58] <m_kiewitz> let's say an array is created at the start of the game as int16, ok?
[18:58] <m_kiewitz> now later a reference is written into it. That causes an error
[18:58] <m_kiewitz> current approach is to patch the creation of the array (unless Im wrong about that)
[18:59] <m_kiewitz> which means any saved game done after array creation will contain a int16 array and not an ID array, thus making it error() out even though the problem is patched
[18:59] <m_kiewitz> i wrote exactly that 1 or 2 hours ago
[18:59] <m_kiewitz> and if we would create reg_t arrays right now for both int16 + reg_t, then we could simply change the array type internally via workaround table
[19:00] <m_kiewitz> which would mean that we wouldn't have to patch scripts at all, but instead the array type would get changed internally even for such saved games
[19:01] <m_kiewitz> thus all saved games would work (similar to how uninitialized read detection works)
[19:01] <wjp> you can convert all int16 arrays to use reg_t storage simply by increasing the savegame version and read the int16s from the savegame into reg_t's
[19:01] <wjp> but whatever
[19:01] <m_kiewitz> that would only work in case we actually changed everything to reg_t at some point
[19:02] <wjp> obviously
[19:02] <m_kiewitz> but the current approach of just patching scripts will result in all sorts of saved games error()ing out all the time
[19:02] <wjp> whatever
[19:02] <m_kiewitz> whatever?
[19:02] <wjp> if you care so much, just do it
[19:04] <m_kiewitz> i only care in case i do another walkthrough, create tons of saved games and then those saved games don't work anymore
[19:04] <m_kiewitz> and in case we would do public testing, I'm not sure if testers would like it either.
[19:04] <m_kiewitz> especially in games like qfg4
[19:08] <m_kiewitz> i asked for your opinion, so in case your opinion is "whatever", then i will simply save my time, because I have to assume that it's seen as worthless instead of improving things.
[19:14] --> timofonic2 joined #scummvm.
[19:15] <wjp> my opinion is, as I said, that I don't see the point in changing this without knowing what scripts to wrong how often
[19:15] <wjp> s/to wrong/do wrong/
[19:15] <wjp> if you do see a point, fair enough, but I'm not following
[19:22] <rootfather> hm, I tried to enable translations for the myst pause dialog, but I get a compilation error:
[19:23] <rootfather> engines/mohawk/mohawk.cpp: In member function 'virtual Common::Error Mohawk::MohawkEngine::run()':
[19:23] <rootfather> engines/mohawk/mohawk.cpp:60:89: error: '_' was not declared in this scope
[19:23] <rootfather> _pauseDialog = new PauseDialog(this, _("The game is paused. Press any key to continue."));
[19:23] <rootfather> any guess what's wrong here?
[19:24] <snover> #include "common/translation.h"
[19:25] <-- t0by left irc: Remote host closed the connection
[19:25] <rootfather> snover thanks again :)
[19:26] --> GitHub81 joined #scummvm.
[19:26] <GitHub81> [scummvm] sev- pushed 2 new commits to master: https://git.io/vPmfT
[19:26] <GitHub81> scummvm/master 2d4ce85 Retro-Junk: FULLPIPE: Scene11: Preserve Dude's state during swing update
[19:26] <GitHub81> scummvm/master ab82cac Eugene Sandulenko: FULLPIPE: Restore original swing logic in scene11
[19:26] GitHub81 (GitHub81@192.30.252.45) left #scummvm.
[19:40] --> GitHub64 joined #scummvm.
[19:40] <GitHub64> [scummvm] rootfather pushed 5 new commits to master: https://git.io/vPmfM
[19:40] <GitHub64> scummvm/master ebd2d69 Lothar Serra Mari: MOHAWK: Enable translations for 'game is paused' string
[19:40] <GitHub64> scummvm/master c46f704 Lothar Serra Mari: I18N: Update translations template
[19:40] <GitHub64> scummvm/master edad9da Lothar Serra Mari: I18N: Update German translation
[19:40] GitHub64 (GitHub64@192.30.252.41) left #scummvm.
[19:59] <m_kiewitz> snover: i replied to your AV sync bug report (GK2). I can't reproduce it at all. Everything looks and sounds fine to me.
[20:03] --> GitHub137 joined #scummvm.
[20:03] <GitHub137> [scummvm] rootfather pushed 5 new commits to branch-1-9: https://git.io/vPmJi
[20:03] <GitHub137> scummvm/branch-1-9 ed5419c Lothar Serra Mari: MOHAWK: Enable translations for 'game is paused' string
[20:03] <GitHub137> scummvm/branch-1-9 7b124c0 Lothar Serra Mari: I18N: Update translations template
[20:03] <GitHub137> scummvm/branch-1-9 f3e8f23 Lothar Serra Mari: I18N: Update German translation
[20:03] GitHub137 (GitHub137@192.30.252.45) left #scummvm.
[20:04] --> GitHub180 joined #scummvm.
[20:04] <GitHub180> [scummvm] sev- pushed 1 new commit to master: https://git.io/vPmJP
[20:04] <GitHub180> scummvm/master 55d9b5e Eugene Sandulenko: FULLPIPE: More corrections to scene logic in scene11
[20:04] GitHub180 (GitHub180@192.30.252.41) left #scummvm.
[20:18] <-- rootfather left irc: Quit: Page closed
[20:26] <-- Littleboy left irc: Read error: Connection reset by peer
[20:26] --> Littleboy joined #scummvm.
[20:26] #scummvm: mode change '+o Littleboy' by ChanServ!ChanServ@services.
[20:31] --> _dreammaster joined #scummvm.
[20:31] #scummvm: mode change '+o _dreammaster' by ChanServ!ChanServ@services.
[20:32] <-- dreammaster left irc: Ping timeout: 252 seconds
[20:35] --> sluicebox joined #scummvm.
[20:36] <sluicebox> i've been having a lot of misc scummvm stability issues with the nightlies since the sdl2 switchover
[20:36] <sluicebox> i thought it was just the box i was using but it's gotten worse so i tried on others and it's pretty consistent
[20:37] <sluicebox> biggest one now is that when running an sci16 game, laura bow 2 CD version being the worst, just switching in and out of full screen kills the process with no errors or anything in the logs
[20:37] <sluicebox> this happens on win xp, 7, and 10
[20:39] <sluicebox> to repo: run scummvm nightly, start lb2cd, wait for the sierra logo to appear, alt+enter. It starts to go to full screen then quits
[20:39] <snover> https://bugzilla.libsdl.org/show_bug.cgi?id=3147
[20:48] <criezy> There might be another issue because I am getting some random crashes sometimes when switching between windowed and fullscreen, and I am on OS X.
[20:48] <criezy> And this doesn't happen when I select one of the two OpenGL graphic modes.
[20:49] <-- ajax16384 left irc: Read error: Connection reset by peer
[20:50] <criezy> The crash is in SurfaceSdlGraphicsManager::internalUpdateScreen()), but I didn't have the time to look into it yet.
[20:51] <sluicebox> I just realized that the scummvm windows nightlies are bundled with SDL1.2, not 2
[20:53] <sluicebox> whereas the one i compile from master is using 2 and, at least now, not dying when switching between fullscreen
[20:55] <sluicebox> i guess the bottom line is that it's difficult to test with the nightly builds on windows because switching to-from full screen crashes
[20:55] <snover> do you have a backtrace?
[20:56] <m_kiewitz> sluicebox: works for me on Windows XP
[20:56] <m_kiewitz> and SDL1
[20:56] <m_kiewitz> although i haven't tried the nightly builds, it's my own build using MSVC
[21:01] <-- ny00123 left irc: Quit: Leaving
[21:04] --> GitHub97 joined #scummvm.
[21:04] <GitHub97> [scummvm] sev- pushed 1 new commit to master: https://git.io/vPmko
[21:04] <GitHub97> scummvm/master c20bc7f Retro-Junk: FULLPIPE: Scene11: Rewrite scene handler in a sane way
[21:04] GitHub97 (GitHub97@192.30.252.46) left #scummvm.
[21:24] <-- WooShell left irc: Quit: Zu gotdy od mpy nrmy stpimf. Zu drvpmf zrsmd aogy jrt iq pt viy jrt yp yjr htpimf.
[21:28] --> Vampire0 joined #scummvm.
[21:31] <m_kiewitz> omg, Red Letter Media - Star Wars Awakens review https://www.youtube.com/watch?v=miVRaoR_8xQ
[21:39] --> GitHub129 joined #scummvm.
[21:39] <GitHub129> [scummvm] sev- pushed 1 new commit to master: https://git.io/vPmI9
[21:39] <GitHub129> scummvm/master 3f6ca96 Retro-Junk: FULLPIPE: Scene11: Fix non-swinging swing
[21:39] GitHub129 (GitHub129@192.30.252.40) left #scummvm.
[21:44] <-- sluicebox left irc: Remote host closed the connection
[21:46] <-- frankyboy_ left irc: Remote host closed the connection
[21:51] --> sluicebox joined #scummvm.
[21:57] --> GitHub96 joined #scummvm.
[21:57] <GitHub96> [scummvm] bluegr opened pull request #838: CHEWY: Escape from F5 (master...chewy) https://git.io/vPmLi
[21:57] GitHub96 (GitHub96@192.30.252.45) left #scummvm.
[21:59] <waltervn> *Esc :P
[22:03] <waltervn> I have the game, very LucasArts-y
[22:03] <sluicebox> I switched my msvc14 build to sdl1, am getting the same crash there, looks like what criezy described. a write access violation in Normal2x() called by SurfaceSdlGraphicsManager::updateScreen()
[22:04] <sluicebox> sorry. that's internUpdateScreen
[22:04] <-- waltervn left irc: Quit: Leaving
[22:04] <sluicebox> this is on win7x64
[22:29] --> macdude22 joined #scummvm.
[22:34] <snover> m_kiewitz: thanks for checking on the av sync. i cant remember when i originally wrote that note so it is possible that some of the work i did to try to improve video output latency helped. or your computer has less latency. or i am crazy.
[22:34] <m_kiewitz> snover: can you just check it again?
[22:34] <m_kiewitz> i doubt my computer is faster than yours
[22:35] <m_kiewitz> and where exactly did those happen?
[22:35] <snover> well, its not really about cpu/gpu speed and more about how much stuff sits in between the program and the actual hardware
[22:37] <m_kiewitz> you tried it on linux, i guess?
[22:37] <m_kiewitz> i doubt windows xp is better in that aspect
[22:38] <snover> mac os
[22:39] <m_kiewitz> ah, can you just try it out once more?
[22:39] <snover> i am running it now. these videos are so long.
[22:39] <m_kiewitz> maybe it's also platform specific
[22:39] <m_kiewitz> yes :P
[22:39] <snover> and their foley people did a terrible job
[22:39] <m_kiewitz> what's weird is that audio should be stuttering, but it shouldn't go out of sync
[22:41] <snover> its definitely off by the time the guy is whispering in the womans ear from the stagecoach
[22:41] <snover> and not like, a little bit off
[22:42] <snover> the accumulation of delay is substantial
[22:43] <m_kiewitz> can you check with the youtube video?
[22:43] <m_kiewitz> is that working out correctly?
[22:44] <snover> checking&
[22:44] <m_kiewitz> and in any case please gimma the time stamp
[22:44] <m_kiewitz> so that i can check that specifically
[22:45] <snover> sync is bad in the let's play but it is not as bad as in scummvm
[22:45] <m_kiewitz> time stamp?
[22:46] <snover> there are a few
[22:46] <snover> 4:29 is the earliest
[22:46] <m_kiewitz> when is it the worst?
[22:47] <snover> 5:27 when grace screams gabriel!, though who knows if they overdubbed that
[22:47] <snover> its so bad in scummvm that the video for her screaming gabriel! has cut back to gabriels close-up before you hear the word
[22:47] <m_kiewitz> will look into this
[22:48] <m_kiewitz> maybe the frames per second value is not 100% accurate
[22:48] <m_kiewitz> and maybe that intro movie is one big file, which means that it would add up
[22:51] <snover> yeah. this may also explain the trouble with the phant1 chase sequence.
[22:51] <snover> ffprobe seems to think that the framerate for the chapter 6 intro is actually 10.03
[22:51] [md5] --> (~md5@unaffiliated/md5/x-729473) joined #scummvm.
[22:51] #scummvm: mode change '+o [md5]' by ChanServ!ChanServ@services.
[22:51] <[md5]> good evening
[22:51] <snover> (7180)
[22:51] <_dreammaster> G'day
[22:52] Nick change: _dreammaster -> dreammaster
[22:52] <snover> and then 7510, which plays right after that, 10.41
[22:52] <[md5]> G'day, dreammaster :)
[22:54] --> edheldil joined #scummvm.
[22:54] <snover> m_kiewitz: tbr/tbn/tbc are the framerate https://gist.github.com/csnover/86ae31769f34b110f5212d5fd653544c
[22:55] <dreammaster> Nice seeing the Chewy pull request
[22:55] <dreammaster> Just a shame there's so much remaining. At least it'll keep you busy ;)
[22:56] <[md5]> there's a lot, unfortunately... the original is a bit messy, to say the least :/ but yes, it'll keep me busy :)
[23:01] --> WinterGrascph joined #scummvm.
[23:01] #scummvm: mode change '+o WinterGrascph' by ChanServ!ChanServ@services.
[23:02] <-- WinterGrascph left irc: Client Quit
[23:13] <-- girafe left irc: Read error: Connection reset by peer
[23:48] <-- SylvainTV left irc: Read error: Connection reset by peer
[23:55] <-- m_kiewitz left irc: Quit: technology isn't intrinsically good or evil. It's how it's used. Like the Death Ray.
[00:00] --- Mon Oct 3 2016