ScummVM IRC Log - 04 Feb 2017

[Back to Index]

[00:01] <-- kurtwr left irc: Ping timeout: 255 seconds
[00:05] <-- WooShell left irc: Quit: If you understand or if you don't, if you believe or if you doubt - There's a universal justice, and the eyes of truth are always watching you.
[00:14] <snover> m_kiewitz: if you have a minute, can you look and tell me if you see anything wrong with this patch? https://github.com/csnover/scummvm/blob/working/engines/sci/engine/guest_additions.cpp#L356-L360 that &rest in SRDialogPatch seems to work fine and as I expect it to work for other games, but this Torin patch is sending 2 rest arguments (0000:0001, 0000:0000) when the parameter should be just (0000:0000)
[00:14] <snover> i gotta run for a half hour but i wanted to get that out in case you had time to look tonight
[00:23] <m_kiewitz> snover: why the change for Torin?
[00:24] <m_kiewitz> what's kScummVMSaveLoad?
[00:24] <m_kiewitz> why not use the same calling parameters as SCI16?
[00:25] <snover> torin is a unique snowflake with its own special save code
[00:25] <snover> but it still is a dialogue pop-up, they just&made it different for some reason
[00:26] <snover> i guess it has something to do with the autosave stuff they put in it, and lsl7 is probably written the same way
[00:26] <m_kiewitz> i think that also maybe there should be one GuestAdditions class for SCI16 and one for SCI32, it was already moved out of the base class and there's lots of code. Or maybe there is some common code that I overlooked
[00:30] <snover> kScummVMSaveLoad is just a convenient callback into ScummVM that allows the native scummvm dialog to run in place of the games own dialogue
[00:32] <snover> if by same calling parameters as SCI16 you mean why not keep hooking into Game::restore/Game::save and add more stuff into kSaveGame/kRestoreGame, there are a few reasons: (1) keeps the scummvm code isolated from the rest, (2) eliminates copy of game script code into scummvm, which is frequently different across games, (3) not all sci32 games save through Game::restore/Game::save
[00:34] <snover> as far as separating GuestAdditions, the audio sync code that SCI16 uses also applies to some SCI32 games. the patching mechanisms for sci16 and sci32 are a little different now by necessity, earlier revisions of this code had them both patching at the same time
[00:36] <snover> at the moment im mostly just concerned by how `script 64866 - call 36 (0000:0000)` turns into `kScummVMSaveLoad (0000:0001, 0000:0000)`
[00:36] <snover> the forwarded argument should be `(0000:0000)`
[00:37] <m_kiewitz> well, i would really prefer that special kernel opcode to simply not exist
[00:37] <-- Harekiet left irc: Ping timeout: 276 seconds
[00:37] <m_kiewitz> and i mean im not sure what you are exactly doing
[00:37] <snover> makes me wonder if that 0000:0001 is somehow arg
[00:37] <snover> argc*
[00:37] <m_kiewitz> but it's minor code, which could be written as pur sci script code
[00:37] <m_kiewitz> and that should then probably solve that other issue too
[00:38] <m_kiewitz> *pure
[00:38] <snover> sci scripts cant create GUI::SaveLoadChoosers
[00:38] <m_kiewitz> wait, right now the scummvm GMM is shown for sci16. what are you showing?
[00:38] <m_kiewitz> well GMM Restore/Save
[00:39] <snover> sorry, i dont know what GMM is
[00:40] <Lightkey> OMG you're such a n00b!
[00:40] <m_kiewitz> GMM is the menu, that you can access via hotkey, where you can select options/restore game/etc.
[00:40] <m_kiewitz> and I'm talking specifically about the internal ScummVM standard dialog for restoring/saving
[00:40] <snover> Lightkey: tell me about it&
[00:40] <Lightkey> it's the Global Menu Manager :p
[00:40] <snover> GUI::SaveLoadChooser is the ScummVM standard dialog for restoring/saving
[00:41] <-- Farmboy0 left irc: Remote host closed the connection
[00:42] <snover> the kernel interface is for game calling into the interpreter, ScummVM is the interpreter, patching a call to the game script save/load dialog to instead call into the kernel for the same functionality prevents having to copy and maintain 20 different derivative save game codes from every sci32 game that exist within Game::restore and Game::save
[00:43] <snover> since those functions do other stuff besides just showing a dialog
[00:44] <m_kiewitz> 20 different derivative save game codes?
[00:44] <snover> yes, different versions of the SCI system scripts have different code
[00:44] <m_kiewitz> the hook code even exists already in kRestoreGame32/kSaveGame32
[00:44] <m_kiewitz> ???
[00:44] <snover> that is not the correct place to hook
[00:44] <m_kiewitz> ???
[00:45] <m_kiewitz> there is code for showing the menu
[00:45] <m_kiewitz> that's not the hook
[00:45] <m_kiewitz> the hook simply calls kSaveGame / kRestoreGame in SCI16 with special parameters
[00:45] <snover> yes, and im telling you that doesnt work for sci32
[00:45] <m_kiewitz> and that same code already exists for kSaveGame32 too
[00:45] <m_kiewitz> why shouldn't it work?
[00:46] <m_kiewitz> the code is still in there, so if it doesn't work, then it needs to be fixed
[00:46] <m_kiewitz> adding our own opcode is beyond hackish
[00:46] <snover> it is not in there on my branch
[00:46] <snover> it is not hackish in any way
[00:46] <m_kiewitz> its in my trunk, which is not up-to-date
[00:46] <m_kiewitz> yes, it is. you are using new ids for scummvm specific kernel calls
[00:46] <snover> it is hackish to copy game script code into scummvm
[00:46] <snover> kRestoreGame is the kernel call that actually performs the game restoration. By the time that kernel call is invoked the game has already run other code to clean up the graphics in preparation for the restore
[00:47] <snover> if you wait until kRestoreGame to show the game restore GUI, its too late
[00:47] <m_kiewitz> ???
[00:47] <snover> if you patch Game::restore, you blow up the game-specific cleanup code
[00:47] <m_kiewitz> you can simply call kRestoreGame w/ special parameters, that calls ScummVM UI already and returns the save game slot
[00:47] <m_kiewitz> you do not HAVE to save at the same time
[00:48] <m_kiewitz> you can show UI that way, without adding new ScummVM-specific kernel calls and then continue like before
[00:48] <snover> no
[00:48] <snover> im telling you that it is not possible to do that without breaking the game
[00:48] --> Harekiet joined #scummvm.
[00:48] <m_kiewitz> i think you do not understand what I'm talking about
[00:48] <m_kiewitz> im not talking about patching Game::restore for SCI32 too
[00:49] <m_kiewitz> or do you simply forward a call from kRestoreGame32 into that other method?
[00:50] <-- ajax16384 left irc: Quit: Leaving
[00:50] <snover> no, kRestoreGame is called after the game decides whether or not it is going to restore a game
[00:50] <snover> the order of operations are:
[00:50] <m_kiewitz> from where is GuestAdditions::kScummVMSaveLoad called from?
[00:50] <snover> a patched SRDialog::doit
[00:50] <m_kiewitz> is it a new ScummVM-specific opcode?
[00:51] <m_kiewitz> or is it called from kRestoreGame32?
[00:51] <m_kiewitz> if it's the former, then that's bad
[00:51] <m_kiewitz> and if it's the latter, then it's confusing but okay-ish
[00:52] <m_kiewitz> for me it looks like a new opcode, otherwise there should be one method for restore and one for saving
[00:52] <snover> When a user asks to restore a game from the game, the game scripts call Game::restore. Game::restore calls Restore::doit (this is SRDialog) which displays the load game dialog. If Restore::doit returns a value other than -1, Game::restore continues by cleaning up all the graphics stuff, *then* calls kRestoreGame
[00:53] <m_kiewitz> that's not what i asked for
[00:53] <snover> So this code patches the Restore::doit call, which normally renders the in-game dialogue, by having it call to the kernel so that the ScummVM dialog can be shown in place of the in-game dialog.
[00:54] <m_kiewitz> how is that code called by the scripts? by calling kRestoreGame32 with special parameters like it's done in sci16?
[00:54] <snover> trying to patch in kRestoreGame is too late, by that time the game already has committed to restoring the game
[00:54] <m_kiewitz> or is it a new ScummVM-specific kernel call?
[00:54] <m_kiewitz> ???
[00:54] <m_kiewitz> have you checked what sci16 is doing?
[00:54] <snover> i dont know how to make this any clearer other than to have you read the Game.sc from a SCI32 game
[00:55] <m_kiewitz> you can simply identify calls to the kernel made by the hook and to actually save directly
[00:55] <m_kiewitz> you do not have to save or restore on every kRestoreGame call
[00:55] <snover> yes you do
[00:55] <m_kiewitz> ???
[00:55] <m_kiewitz> in sci16, kRestoreGame can get called by the hook with special parameters
[00:55] <snover> the game script is committed to restoring by the time kRestoreGame is invoked. if you wait until then to show the dialog, the game has already deleted all of the graphics items in anticipation of the restore
[00:56] <m_kiewitz> so kRestoreGame sees that it's called by the hook and not by the regular game scripts
[00:56] <m_kiewitz> and when kRestoreGame knows that, it does not have to restore the game right then
[00:56] <snover> i do not know how to make any clearer that *the game script controls the graphics*
[00:56] <m_kiewitz> it can for example show the dialog, ask the user
[00:56] <snover> *the game script deletes all the graphics*
[00:56] <snover> *the game graphics are all gone by the time kRestoreGame is called*
[00:56] <m_kiewitz> and then return some ID back to the hook, which passes it over to the scripts
[00:57] <m_kiewitz> and then the actual restoring can happen
[00:57] <m_kiewitz> the game scripts control the graphics in sci16 as well, but graphics do not matter
[00:57] <m_kiewitz> have you looked at sci16 kRestoreGame?
[00:57] <m_kiewitz> there is special code that is able to detect calls from the hook
[00:57] <snover> of course i looked at it, sci32 originally was doing it the same way and was broken because of it
[00:58] <snover> anyway all i wanted to know was if the call structure was wrong or not
[00:58] <m_kiewitz> im not talking about patching Game::restore
[00:58] <snover> so this is not helpful to me, i am going afk for a while.
[00:58] <m_kiewitz> what the hell is wong? im not saying patch Game::restore
[00:58] <m_kiewitz> im saying you could simply re-use kRestoreGame - the kernel call ! to display the ScummVM UI
[00:59] <m_kiewitz> that's not about hooking
[00:59] <m_kiewitz> so maybe this will make it more obvious
[00:59] <m_kiewitz> SRdialog::doit is called okay?
[00:59] <m_kiewitz> you patch that
[00:59] <m_kiewitz> the patch calls kRestoreGame32 with special parameters
[00:59] <m_kiewitz> and thus kRestoreGame32 is called - the kernel call
[01:00] <m_kiewitz> it sees special parameters
[01:00] <m_kiewitz> it now shows the ScummVM UI, and DOES NOT DO any restore
[01:00] <m_kiewitz> it simply passes the value back to the *SRDialog::doit* hook
[01:00] <m_kiewitz> and that's it
[01:01] <m_kiewitz> that way you do not have to add a new ScummVM-specific kernel function to the SCI engine
[01:01] <m_kiewitz> it's simply reusing kRestoreGame32 and it has nothing to do with a) restoring/saving the game immediately nor b) patching the scripts like in SCI16
[01:02] <m_kiewitz> you can patch whatever you like.
[01:03] <m_kiewitz> but no special kernel functions need to be added, but existing VM kernel functions can be re-used
[01:07] <-- girafe left irc: Read error: Connection reset by peer
[01:09] <m_kiewitz> wjp: maybe you understand what I was trying to say the whole time. No idea if my English is that bad, if you understand it, please tell snover.
[01:10] <m_kiewitz> right now it seems VM kenel call 0x57 is used
[01:15] <snover> m_kiewitz: i understand now what you were saying. walking away is good sometimes.
[01:18] <m_kiewitz> ok, i can help you create the hook script code in case you want me to. we could simply differentiate between save + restore within that code and then call kSaveGame(32) or kRestoreGame(32)
[01:18] <m_kiewitz> this could then also solve the torin problem
[01:18] <m_kiewitz> you are setting local variables for Torin, but for the generic one, why is that so?
[01:18] <m_kiewitz> does Torin do things differently?
[01:19] <snover> yep.
[01:19] <m_kiewitz> how is the description set for the other games?
[01:20] <m_kiewitz> ah nvm
[01:20] <snover> the dialogue is passed a string reference to be filled
[01:20] <m_kiewitz> inside .data
[01:20] <snover> i feel that overloading kRestoreGame in the way that it is in sci16 is much more of a hack than adding a new kernel function designed for scummvm integration. the overloaded kRestoreGame function combines two unrelated concepts (showing a dialogue to pick a game, and receiving a save game number to actually restore a game).
[01:20] <snover> there are plenty free kernel slots, and the whole point of the kernel interface is to allow the interpreter to assist the game, so i dont see that taking a dummy kernel slot and using it for the scummvm interpreter is a hack.
[01:21] <m_kiewitz> you never know when some fan-hacker will hack some new opcode into the engine
[01:21] <m_kiewitz> for AGI that went to absurd situations
[01:22] <m_kiewitz> where one "free" kernel id is used by 2 or 3 different hacks and we got to figure out which of those is supposed to be there
[01:23] <m_kiewitz> well in any case, what i really don't like is two completely different approaches
[01:23] <m_kiewitz> so otherwise one could change the SCI16 approach to that one
[01:24] <snover> yeah. consistency is good.
[01:24] <m_kiewitz> we could also for example use some higher up kernel opcodes
[01:24] <m_kiewitz> like maybe reserve 0xE0 -> 0xEF for us
[01:25] <snover> that sounds very reasonable
[01:25] <m_kiewitz> because in for example AGI Sierra themselves called some of the Dummy ones
[01:25] <m_kiewitz> you never know if they used those inbetweeners for debug functions
[01:25] <snover> a dummy call does lead to a crash doesnt it?
[01:25] <snover> error: dummy function called! or whatever
[01:25] <m_kiewitz> haven't tried that in SCI
[01:26] <m_kiewitz> ah it does? i thought it was a warning
[01:26] <snover> error("Kernel function was called, which was considered to be unused - see log for details");
[01:26] <m_kiewitz> ah, weird i thought it was just a warning
[01:26] <m_kiewitz> in AGI I think it is a warning and I saw it pop up during several games
[01:26] <snover> kStub is a warning
[01:26] <m_kiewitz> ah, ok
[01:27] <snover> i reintroduced kWait for Hoyle5 to get rid of its spinloops so that would also need to get hoisted to wherever, if we do decide to carve out a specific opcode range
[01:27] <m_kiewitz> i think 0xE0 to 0xEF would be pretty nice, E for enhancement
[01:28] <snover> but, going back to my original thing& why is `&rest 0` sending (0000:0001, 0000:0000) instead of (0000:0000) when the parent calls arguments are (0000:0000)? :\
[01:28] <m_kiewitz> sci2.1 goes up to 0xA0
[01:28] <m_kiewitz> no idea if we got the kernel list for sci3 already somewhere
[01:28] <snover> (i put that 0xE0 range on my list of todos)
[01:28] <snover> I think SCI3 goes up to 0xA1
[01:29] <m_kiewitz> hmm
[01:30] <m_kiewitz> could you try &rest 1?
[01:30] <m_kiewitz> i think &rest 0 passes over the parameter count as well
[01:31] <snover> yeah, using &rest 1 for torin gets just the (0000:0000), but then the default one gets zero arguments, so i am wondering if i am doing something wrong or if i have just triggered a edge bug in the VM
[01:32] <m_kiewitz> wtf is going wrong
[01:32] <m_kiewitz> and SRDialog::doit gets really called with 1, 0 by the scripts in Torin?
[01:33] <snover> The default one (SRDialog::doit) is always called from a member function, whereas in Torin the call is a local procedure
[01:33] <m_kiewitz> that really sounds like a VM bug in ScummVM then
[01:33] <m_kiewitz> or maybe it's something where the original SCI engine also goes crazy, idk
[01:34] <m_kiewitz> so Torins local procedure gets called with "1 parameter, parameter list 0"?
[01:34] <m_kiewitz> ah wait
[01:34] <m_kiewitz> local procedures do not have a parameter list, afaik
[01:35] <snover> the backtraces: https://gist.github.com/csnover/72423168a3dc70d34611259abbe1d56c
[01:35] <m_kiewitz> hmm, need to verify that somehow
[01:36] <m_kiewitz> we should really add comments to those VM opcodes
[01:37] <snover> 64866 export 1 has no parameters, it calls to localproc 36 with one parameter (0)
[01:38] <snover> i patch localproc 36 to forward arguments using `&rest 0` to `callk kScummVMSaveLoad, 0`
[01:38] <snover> (0000:0001, 0000:0000) is sent instead
[01:39] <snover> in most of the other SCI32 games, SRDialog::doit is called with one parameter (0), i patch SRDialog::doit to forward arguments using `&rest 0` to `callk kScummVMSaveLoad, 0` and correctly receive (0000:0000)
[01:39] <m_kiewitz> it really has to be the local procedure
[01:40] <snover> thats what i was thinking, but i cant really see anything in op_call that jumps out at me as being materially different yet
[01:41] <snover> my eyes glaze over a little bit at the parameter list to ExecStack tho :)
[01:43] <m_kiewitz> can you set a breakpoint on the op_rest opcode
[01:43] <m_kiewitz> and then check what s->xs->argc says?
[01:44] <snover> one moment please
[01:45] <snover> some other code is using op_rest so i need to figure out the condition for this breakpoint
[01:46] <m_kiewitz> you could also warning() the s->xs->argc out
[01:46] <m_kiewitz> and then set a breakpoint on your kernel function
[01:47] <m_kiewitz> are local subroutines capable of dynamic parameters?
[01:47] --> dreammaster joined #scummvm.
[01:47] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[01:47] <snover> the pmachine document and the code for op_call seem to indicate so
[01:47] <snover> documentation*
[01:48] <m_kiewitz> but then that would be quite a big bug in &rest
[01:48] <m_kiewitz> maybe sierra never used it in such a case
[01:49] --> GitHub35 joined #scummvm.
[01:49] <GitHub35> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vDnrq
[01:49] <GitHub35> scummvm/master 9e09592 Paul Gilbert: TITANIC: Implementing more CMusicRoomHandler code
[01:49] GitHub35 (GitHub35@192.30.252.45) left #scummvm.
[01:49] <snover> im doing a quick check to see if i can find anywhere that seems to call a local or export with rest
[01:50] <snover> `Print.sc: (= temp0 (proc64921_3 &rest))` heres one, using calle though
[01:52] <snover> well, actually, i should double-check that it is using calle. its a call to an exported localproc i think
[01:52] <m_kiewitz> that would be calle then and different
[01:52] <m_kiewitz> maybe it works in that case too
[01:53] <snover> the local call in torin is an exported localproc
[01:53] <snover> export 2
[01:53] <snover> but it the code calls it as a local
[01:53] <m_kiewitz> hmm, ok so what happens then?
[01:54] <snover> well, it is the proc that seems to have broken &rest forwarding :)
[01:55] <snover> so Print::addTextF is `push0; &rest 1; call $0191, 0`
[01:56] <snover> interesting that it starts at &rest 1
[01:56] <snover> since it has no explicitly named parameters
[01:56] <snover> now lets see what happens with the &rest calls that are made to selectors&
[01:57] <m_kiewitz> i guess it depends on the original call opcode
[01:58] <snover> it is also &rest 1. so i guess i am dumb and &rest 0 is wrong
[01:59] <m_kiewitz> can you find &rest 0 anywhere?
[02:00] <m_kiewitz> but with &rest 1, it also doesn't work correctly, right?
[02:00] <snover> &rest 1 might not work correctly because maybe the first parameter was optional, or just did an invalid read
[02:01] <m_kiewitz> it depends
[02:01] <m_kiewitz> im not sure if &rest 0 means -> pass over all parameters including parameter count
[02:01] <m_kiewitz> or if &rest 0 is basically invalid and &rest1 means exactly that instead
[02:01] <m_kiewitz> op_rest code says
[02:01] <m_kiewitz> / +1 because temp counts the paramcount while argc doesn't
[02:03] <m_kiewitz> in case &rest 0 is invalid, maybe we should add an error() for that case
[02:03] <snover> i found only one place that seems to use &rest param2, so i am looking at that
[02:03] <snover> i have not found any explicit &rest 0
[02:03] <snover> yet
[02:03] <m_kiewitz> when we figure this out we should really add a comment to op_rest
[02:03] <snover> it is unfortunate that zero arguments looks like one argument of value 0, since 0 is the expected value&
[02:04] <snover> /s/zero arguments/&rest 0
[02:04] <m_kiewitz> what happens again when you try &rest 1 inside the patched hook?
[02:04] <m_kiewitz> when you try it on one of the other games?
[02:04] <m_kiewitz> what exactly do you get?
[02:04] <snover> one moment
[02:05] <m_kiewitz> &rest 0 should happen quite often in case it really just forwarded all parameters
[02:10] <snover> yeah, that is another very good observation
[02:11] <m_kiewitz> wait, it seems it's a parameter count
[02:11] <snover> im starting to remember that i think there was an uninitialized read complaint about Restore::doit
[02:13] <snover> WARNING: Uninitialized read for parameter 1 from method Restore::doit (room 375, script 64990, localCall ffffffff)! sigh
[02:13] <snover> well the good news is everything makes sense now.
[02:13] <snover> thank you so much for your help.
[02:13] <snover> the vm is fine, though i will also do what you suggest and make a note in op_rest
[02:14] <m_kiewitz> does it work now?
[02:14] <m_kiewitz> i guess we should at least add a warning() to op_rest, when it's called with parameter[0] = 0
[02:14] <m_kiewitz> or even an error(), i guess so much testing has to be done anyway, that an error() wouldn't be that bad
[02:15] <m_kiewitz> oh right and a comment should be added in any case about the exact behavior
[02:15] <m_kiewitz> i think i went through this years ago already figuring out the same questions
[02:16] <m_kiewitz> or welll answers
[02:23] <snover> yeah, seems to be working ok now that you managed to dislodge the stupid that was stuck to my brain :)
[02:23] <m_kiewitz> you're welcome. have to get some sleep now. bye
[02:23] <snover> ok. thanks again :
[02:23] <snover> :)
[02:23] <-- m_kiewitz left irc: Quit: technology isn't intrinsically good or evil. It's how it's used. Like the Death Ray.
[02:36] <-- WinterGrascph left irc: Ping timeout: 256 seconds
[02:39] <-- Dominus left irc: Ping timeout: 240 seconds
[02:40] --> Dominus joined #scummvm.
[02:40] <-- Dominus left irc: Changing host
[02:40] --> Dominus joined #scummvm.
[02:41] --> Vampire0_ joined #scummvm.
[02:44] <-- Vampire0 left irc: Ping timeout: 240 seconds

[03:38] <-- D0SFreak left irc: Ping timeout: 258 seconds
[03:40] --> GitHub110 joined #scummvm.
[03:40] <GitHub110> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vDnXR
[03:40] <GitHub110> scummvm/master 529680e Paul Gilbert: TITANIC: Beginnings of music object and parser classes
[03:40] GitHub110 (GitHub110@192.30.252.45) left #scummvm.
[03:43] <dreammaster> I'm honestly not sure if I should be happy or frustrated that there's a (currently unknown) music related support class that itself using a special string parser for parsing a whole bunch of goobledegook for setting up an array of values
[03:43] <dreammaster> It's kind of fascinating, in a bizarre kind of way :)
[03:51] <Lightkey> https://www.gog.com/promo/20170130_weekly_sale Sierra catalogue at discount
[03:56] <snover> dreammaster: that sounds amazing
[03:58] <dreammaster> My current guess that it's some kind of wave table or sound font for each of the four instruments. Though I'm not sure why it'd be needed if that's the case, since the source raw data for the music is coming from .wav files, not MIDI
[03:59] <dreammaster> I suppose I should count it as a plus that there's intruiging/interesting support classes mixed up in all this music handling stuff
[04:40] --> te_lanus joined #scummvm.
[04:41] <-- ST left irc: Quit: Leaving.
[04:45] --> GitHub56 joined #scummvm.
[04:45] <GitHub56> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vDnMv
[04:45] <GitHub56> scummvm/master d10ac86 Paul Gilbert: TITANIC: Implemented CMusicObject initialization
[04:45] GitHub56 (GitHub56@192.30.252.42) left #scummvm.
[05:06] <snover> o kay. torin integrated save/load seems to be working now too.
[05:08] <snover> so gk1, pq4, qfg4, lsl6 hires, sq6, torin, and gk2 all have the scummvm save integration
[05:08] <dreammaster> Cool :)
[05:08] <dreammaster> What's left?
[05:08] <snover> hoyle has no save, kq7 and phant1 do bookmarks so arent relevant
[05:09] <snover> mgdx also does bookmarks
[05:09] <snover> and nobody cares about pq:swat
[05:09] <dreammaster> LOL :)
[05:09] <snover> so thats all the sci2/2.1 games
[05:09] <snover> oh, and shivers has its own special thing, i dunno if i wanna mess with it
[05:10] <snover> hypothetically the game would maybe work with integration, but it uses this weird guestbook model
[05:10] <snover> i shutter to think of what happens if someone manages to generate a save game with a long name
[05:10] <snover> so i might just leave that one with its custom save/load for now
[05:11] --> GitHub176 joined #scummvm.
[05:11] <GitHub176> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vDnM9
[05:11] <GitHub176> scummvm/master 7abea34 Paul Gilbert: TITANIC: Minor fixes to CMusicObject & CMusicParser
[05:11] GitHub176 (GitHub176@192.30.252.42) left #scummvm.
[05:11] <snover> whats left is making the deferred save code work
[05:11] <snover> which is that thing that lets you load a game direct from the launcher
[05:11] <dreammaster> Well, certainly ScummVM save integration isn't a mandatory requirement
[05:15] <dreammaster> Anyway, getting a bit late for me, so goodnight
[05:15] <-- dreammaster left irc:
[05:34] <-- peterkohaut left irc: Ping timeout: 255 seconds
[05:35] <snover> for the delayed games i am currently thinking of some way to invoke Game::restore and bypass the dialog call by having it immediately return the stored delayed save game number; well see how that goes.
[06:38] <-- Strangerke left irc: Ping timeout: 256 seconds
[06:51] --> frankyboy_ joined #scummvm.
[06:54] --> goom joined #scummvm.
[06:57] <-- frankyboy_ left irc: Read error: Connection reset by peer
[06:58] --> frankyboy_ joined #scummvm.
[07:10] <-- _sev left irc: Ping timeout: 240 seconds
[07:12] --> diehumblex joined #scummvm.
[07:21] <-- TMM left irc: Quit: Ex-Chat
[07:57] --> ajax16384 joined #scummvm.
[07:57] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[08:10] <-- Lightkey left irc: Ping timeout: 240 seconds
[08:23] --> Lightkey joined #scummvm.
[08:41] --> _sev joined #scummvm.
[08:41] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[08:42] <-- LittleToonCat left irc: Remote host closed the connection
[08:45] --> Axy joined #scummvm.
[08:45] <-- Axy left irc: Changing host
[08:45] --> Axy joined #scummvm.
[08:46] <cpasjuste> hi
[08:47] <wanwan> hi
[08:47] <-- Mia left irc: Ping timeout: 245 seconds
[08:49] <-- frankyboy_ left irc: Ping timeout: 276 seconds
[08:50] --> frankyboy_ joined #scummvm.
[08:57] <-- frankyboy_ left irc: Read error: Connection reset by peer
[08:58] --> frankyboy_ joined #scummvm.
[09:07] --> jamm joined #scummvm.
[09:29] <-- _sev left irc: Ping timeout: 245 seconds
[09:31] --> WooShell joined #scummvm.
[09:34] <WooShell> good meowning =^.^=
[09:36] --> _sev joined #scummvm.
[09:36] <-- _sev left irc: Changing host
[09:36] --> _sev joined #scummvm.
[09:36] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[09:51] <-- _sev left irc: Quit: This computer has gone to sleep
[09:56] <-- Deledrius left irc: Ping timeout: 256 seconds
[09:57] --> Deledrius joined #scummvm.
[10:04] <-- goom left irc: Quit: Leaving
[10:11] --> Analogue joined #scummvm.
[10:12] <-- Analogue left irc: Client Quit
[10:18] --> begasus joined #scummvm.
[10:18] Nick change: begasus -> Begasus
[10:25] --> m_kiewitz joined #scummvm.
[10:25] <-- m_kiewitz left irc: Changing host
[10:25] --> m_kiewitz joined #scummvm.
[10:25] #scummvm: mode change '+o m_kiewitz' by ChanServ!ChanServ@services.
[10:31] <-- Begasus left irc: Quit: Ex-Chat
[10:40] <-- criezy left irc: Quit: criezy
[10:41] <-- rootfather left irc:
[10:45] --> Begasus joined #scummvm.
[10:51] <-- diehumblex left irc: Quit: Connection closed for inactivity
[10:51] <-- frankyboy_ left irc: Remote host closed the connection
[10:54] <m_kiewitz> dang
[11:00] <wjp> FOSDEM
[11:15] <Lightkey> FOSDANG
[11:28] --> _sev joined #scummvm.
[11:28] <-- _sev left irc: Changing host
[11:28] --> _sev joined #scummvm.
[11:28] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[11:31] <-- Begasus left irc: Quit: Vision[0.9.8]: i've been blurred!
[11:37] <m_kiewitz> wjp: ah right, why aren't you there too?
[11:39] <m_kiewitz> unless you actually are :P
[11:54] <-- Dominus left irc: Ping timeout: 240 seconds
[11:56] --> Dominus joined #scummvm.
[11:56] <-- Dominus left irc: Changing host
[11:56] --> Dominus joined #scummvm.
[11:57] --> begasus joined #scummvm.
[12:03] --> Wishmaster2 joined #scummvm.
[12:09] <-- _sev left irc: Quit: This computer has gone to sleep
[12:38] <-- begasus left irc: Quit: Ex-Chat
[12:42] --> NuSuey joined #scummvm.
[13:25] --> diehumblex joined #scummvm.
[13:40] --> WinterGrascph joined #scummvm.
[13:40] #scummvm: mode change '+o WinterGrascph' by ChanServ!ChanServ@services.
[14:05] --> _sev joined #scummvm.
[14:05] <-- _sev left irc: Changing host
[14:05] --> _sev joined #scummvm.
[14:05] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[14:08] --> Begasus joined #scummvm.
[14:13] --> salty-horse joined #scummvm.
[14:13] #scummvm: mode change '+o salty-horse' by ChanServ!ChanServ@services.
[14:13] <salty-horse> I'm on windows, launched scummvm via the installer. alt+s doesn't take a screenshot, says nothing in ctrl+d console. is it trying to write to "program files" where it has no permissions?
[14:14] <salty-horse> 2) the readme doesn't state where screenshots are saved to. should it say "current directory" for all platforms? for windows, should we instead save in "my documents" somewhere?
[14:14] <salty-horse> (to circumvent any write permission issues)
[14:17] --> GitHub194 joined #scummvm.
[14:17] <GitHub194> [scummvm] sev- pushed 3 new commits to master: https://git.io/vDcUr
[14:17] <GitHub194> scummvm/master 04a2a8b Eugene Sandulenko: GRAPHICS: Hid noisy debug messages in MacText
[14:17] <GitHub194> scummvm/master e15f2e7 Eugene Sandulenko: DIRECTOR: Hid font test under debug channel
[14:17] <GitHub194> scummvm/master 6d8d398 Eugene Sandulenko: DIRECTOR: Implemented pausing/continuing of playback
[14:17] GitHub194 (GitHub194@192.30.252.41) left #scummvm.
[14:17] --> GitHub118 joined #scummvm.
[14:17] <GitHub118> [scummvm] criezy pushed 1 new commit to master: https://git.io/vDcUo
[14:17] <GitHub118> scummvm/master 87237f6 Purple T: I18N: Update translation (French)...
[14:17] GitHub118 (GitHub118@192.30.252.34) left #scummvm.
[14:17] <-- WinterGrascph left irc: Quit: Leaving
[14:21] <-- Begasus left irc: Read error: Connection reset by peer
[14:21] --> Begasus joined #scummvm.
[14:27] <-- Begasus left irc: Read error: Connection reset by peer
[14:27] --> Begas joined #scummvm.
[15:06] Nick change: Begas -> Begasus
[15:23] <salty-horse> opened a bug about the windows screenshot issue: https://bugs.scummvm.org/ticket/9701
[15:24] <-- Begasus left irc: Ping timeout: 240 seconds
[15:24] --> Begas joined #scummvm.
[15:31] <-- Begas left irc: Read error: Connection reset by peer
[15:44] <-- _sev left irc: Quit: This computer has gone to sleep
[15:44] --> GitHub51 joined #scummvm.
[15:44] <GitHub51> [scummvm] sev- pushed 5 new commits to master: https://git.io/vDcLd
[15:44] <GitHub51> scummvm/master 91d85fe Eugene Sandulenko: GRAPHICS: Correctly process empty lines in MacText
[15:44] <GitHub51> scummvm/master 1a4be95 Eugene Sandulenko: GRAPHICS: Try to generate font names from slant in MacFontManager
[15:44] <GitHub51> scummvm/master 906d94a Eugene Sandulenko: GRAPHICS: Enforce font recomputation in MacText
[15:44] GitHub51 (GitHub51@192.30.252.41) left #scummvm.
[15:45] --> Begasus joined #scummvm.
[16:25] --> _sev joined #scummvm.
[16:25] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[16:35] <-- jamm left irc: Read error: Connection reset by peer
[16:44] --> Farmboy0 joined #scummvm.
[16:44] <-- Farmboy0 left irc: Changing host
[16:44] --> Farmboy0 joined #scummvm.
[16:52] --> GitHub158 joined #scummvm.
[16:52] <GitHub158> [scummvm] sev- pushed 1 new commit to master: https://git.io/vDcYX
[16:52] <GitHub158> scummvm/master a8c9e47 Eugene Sandulenko: DIRECTOR: Removed text cast width hack. It is incorrect.
[16:52] GitHub158 (GitHub158@192.30.252.45) left #scummvm.
[16:54] <-- te_lanus left irc: Read error: Connection reset by peer
[16:55] --> te_lanus joined #scummvm.
[17:01] <-- _sev left irc: Quit: This computer has gone to sleep
[17:09] <-- Wishmaster2 left irc: Read error: Connection reset by peer
[17:10] Nick change: Begasus -> Begasus_bbl
[17:35] --> Littleboy joined #scummvm.
[17:35] #scummvm: mode change '+o Littleboy' by ChanServ!ChanServ@services.
[17:37] <-- te_lanus left irc: Remote host closed the connection
[17:39] --> Wishmaster2 joined #scummvm.
[17:59] <-- NuSuey left irc: Quit: Connection closed for inactivity
[18:06] --> LittleToonCat joined #scummvm.
[18:09] --> _sev joined #scummvm.
[18:09] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[18:22] <-- klusark left irc: Quit: quit
[18:33] --> jamm joined #scummvm.
[18:50] --> kurtwr joined #scummvm.
[18:52] <-- kurtwr2 left irc: Ping timeout: 256 seconds
[18:55] --> TMM joined #scummvm.
[18:55] #scummvm: mode change '+o TMM' by ChanServ!ChanServ@services.
[18:59] --> klusark joined #scummvm.
[19:05] <snover> dang. my approach of performing delayed restores by prefilling save game slot and calling Game object ::restore works everywhere except SQ6&
[19:06] <snover> looks like sq6 has a global guard variable i can possibly abuse&
[19:07] <snover> hmm. it is the current room number global
[19:07] <TMM> snover, add a patch overlay to add another one? :D
[19:08] <fuzzie> this sounds like the kind of fun thing that leads to a few years of fun with different patches/versions
[19:09] <snover> the room number its checking is the sierra logo/main menu room, so i guess the delayed restore is just a little bit early
[19:09] <snover> fuzzie: of course. games with different patch versions are incompatible in ssci :\
[19:10] <snover> among other things, it relies on the initialisation code executing exactly the same every time, otherwise persistent objects arent given the same memory ID and the game crashes
[19:10] <snover> crashes when you try to restore a game*
[19:11] <snover> i still havent thought of how to make delayed (from the launcher) restore work with original save/load enabled
[19:12] <snover> the game script restore method *has* to be called for restores to work correctly because its responsible for rejiggering the VM to accept a new save game state
[19:17] <snover> yay, works now.
[19:19] <-- Begasus_bbl left irc: Ping timeout: 255 seconds
[19:22] <snover> this also fixes the really important bug that the sierra logo was stuck being displayed in pq:swat when loading from the launcher
[19:25] <snover> for original save/load, i wonder if i can just selectively patch the restore code if there is a pending delayed restore, and then it will get fixed up back to the original when the savegame overwrites all the scripts& hmm. lets find out!
[19:29] <TMM> arcane magic!
[19:29] <TMM> I love it :)
[19:29] <snover> TMM: yeah& there is a reason i am segregating all this code into its own class
[19:30] <TMM> snover, is one of the class methods 'add_gnat_eyes(int num);'?
[19:31] <snover> i dont get the joke :(
[19:31] --> Begasus_bbl joined #scummvm.
[19:32] <TMM> snover, oh, it's like a recipe for a magic potion 'gnat eyes'
[19:33] <snover> i think it might be more like `here_be_dragons(int num)` ;)
[19:33] <snover> increase the number, increase the fun
[19:38] --> omer_mor_ joined #scummvm.
[19:40] <-- omer_mor left irc: Ping timeout: 255 seconds
[19:46] --> rootfather joined #scummvm.
[19:46] #scummvm: mode change '+o rootfather' by ChanServ!ChanServ@services.
[20:18] --> dreammaster joined #scummvm.
[20:18] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[20:20] --> GitHub68 joined #scummvm.
[20:20] <GitHub68> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vDc8R
[20:20] <GitHub68> scummvm/master c6f4da1 Paul Gilbert: TITANIC: Fix CMusicParser to produce correct results
[20:20] GitHub68 (GitHub68@192.30.252.42) left #scummvm.
[20:35] <-- ny00123 left irc: Quit: Leaving
[20:38] --> GitHub90 joined #scummvm.
[20:38] <GitHub90> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vDc4L
[20:38] <GitHub90> scummvm/master b78b30c Paul Gilbert: TITANIC: Fix CMusicObject initialization
[20:38] GitHub90 (GitHub90@192.30.252.34) left #scummvm.
[20:39] <snover> dreammaster: something like INT_MAX sure would be nice eh :)
[20:39] <dreammaster> Yes indeed
[20:40] <dreammaster> I was actually thrown for a bit originally, because the minimum they used was 0x80000000, and I couldn't remember if that was a positive or negative signed value
[20:41] <snover> the smallest number in the world of 32-bits
[20:51] <dreammaster> Well, now it's matching exactly what the original did at least. And the class doesn't have any other methods, so nothing more surprising for it. Now that that's all taken care of, I guess it's back to CMusicRoomHandler
[20:53] <snover> i saw what you were saying earlier about it seeming weird, but id guess it is exactly what you said, basically doing some soundfont-like thing to allow a single sample to be used for a range of notes, and also remaining in sync with the rest of the song
[20:53] <snover> if i had to guess
[20:54] <snover> if you like more speculation on your speculation
[20:55] <dreammaster> Well, when it's fully implemented we'll see if it's more understandable then. Worst case scenario, it can just stay as the generic "CMusicObject" with unnamed fields
[20:56] <snover> in other good news, my idea for how to restore with original save/loads also seems to be working
[20:56] <dreammaster> I kind of understand the use of the parser a bit now too. The first string results in 35 8-byte entries, so the string is a more compact way to represent it. And I guess they had some meaningful tool for produce the string to begin with
[20:56] <dreammaster> Excellent. The channel logs have certainly been bursting over the last 24 hours :)
[21:02] <snover> so once i have cleaned all this up, adding a workaround for that harp problem in kq7, which should be a one-liner, means that these games should all be ready to go to testing, once everything lands.
[21:02] --> m-kiewitz joined #scummvm.
[21:02] <-- m-kiewitz left irc: Changing host
[21:02] --> m-kiewitz joined #scummvm.
[21:02] #scummvm: mode change '+o m-kiewitz' by ChanServ!ChanServ@services.
[21:03] <-- m_kiewitz left irc: Ping timeout: 255 seconds
[21:05] <-- jamm left irc: Ping timeout: 240 seconds
[21:11] --> girafe joined #scummvm.
[21:35] <-- dreammaster left irc: Ping timeout: 240 seconds
[21:37] --> dreammaster joined #scummvm.
[21:37] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[21:44] <snover> i wonder if save games below the current save game version should be blocked for sci32, since they are almost certainly corrupt by missing some of the game-specific save code
[21:45] <m-kiewitz> snover: shouldn't be a problem. My own saved games from my gk1 testrun are broken now, so useless.
[21:46] <m-kiewitz> and sci32 was never officially supported, so broken saved games are still allowed to happen.
[21:46] <snover> i have some earlier save games that still work, but are corrupt in subtle ways. i just dont want to get bug reports because someone decided to try loading an old game that kinda works
[21:47] <snover> but i am not sure how much of a problem this really is
[21:47] <-- Begasus_bbl left irc: Quit: Ex-Chat
[21:48] <m-kiewitz> some of mine either error() out because of invalid segment ids or even crash scummvm
[21:48] <m-kiewitz> blocking them would surely would be good.
[21:56] <snover> I have a lsl6 one that a user submitted that seems OK except one of the control icons in the menu is wrong, but certainly has more problems than that
[21:57] <snover> Had it been a problem for other engines in the past at all?
[22:00] <dreammaster> Well, I generally put in a version number as part of the savegame header on engines I work on, and simply ignore the savegame if the version is too old (and it's not feasible to handle the older version)
[22:21] --> GitHub72 joined #scummvm.
[22:21] <GitHub72> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vDcEa
[22:21] <GitHub72> scummvm/master 8e87dc1 Paul Gilbert: TITANIC: Implemented CMusicRoomHandler fn1 and getPitch
[22:21] GitHub72 (GitHub72@192.30.252.34) left #scummvm.
[22:28] Nick change: rootfather -> rootfather|afk
[22:28] <-- dreammaster left irc: Ping timeout: 245 seconds
[22:32] --> GitHub135 joined #scummvm.
[22:32] <GitHub135> [scummvm] sev- pushed 1 new commit to master: https://git.io/vDcum
[22:32] <GitHub135> scummvm/master 76e66a4 Eugene Sandulenko: DIRECTOR: Lingo: Implemented b_quit()
[22:32] GitHub135 (GitHub135@192.30.252.41) left #scummvm.
[22:34] --> GitHub122 joined #scummvm.
[22:34] <GitHub122> [scummvm] sev- pushed 1 new commit to master: https://git.io/vDcuZ
[22:34] <GitHub122> scummvm/master 29ad5a0 Eugene Sandulenko: DIRECTOR: Lingo: Implemented b_shutDown() and b_restart()
[22:34] GitHub122 (GitHub122@192.30.252.42) left #scummvm.
[22:38] <-- salty-horse left irc: Quit: Leaving
[22:50] <-- Henke37 left irc: Quit: ERR_SHUTDOWN
[23:01] <-- ajax16384 left irc: Read error: Connection reset by peer
[23:08] <-- Wishmaster2 left irc: Read error: Connection reset by peer
[23:18] --> WinterGrascph joined #scummvm.
[23:18] #scummvm: mode change '+o WinterGrascph' by ChanServ!ChanServ@services.
[23:20] <-- girafe left irc: Read error: Connection reset by peer
[23:42] --> dreammaster joined #scummvm.
[23:42] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[23:43] --> GitHub34 joined #scummvm.
[23:43] <GitHub34> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vDc2P
[23:43] <GitHub34> scummvm/master b005198 Paul Gilbert: TITANIC: Implemented remainder of CMusicRoomHandler code
[23:43] GitHub34 (GitHub34@192.30.252.34) left #scummvm.
[23:46] <-- kurtwr left irc: Read error: Connection reset by peer
[23:46] --> kurtwr joined #scummvm.
[00:00] --- Sun Feb 5 2017