[Back to Index]

[00:01] <snover> almost there. im experiencing fatal brain stupidity disease.
[00:04] <snover> ok. so. first things first, figuring out where the crazy bug is coming from.
[00:06] <snover> depending upon the type of bug, i will frequently start by running the `room` command to learn which game script is responsible for the current room (the room number is a script number), and for visual bugs like these, the `pl` (plane_list) and `pi` (plane_items) commands.
[00:08] <dafioram> is this in the debugger?
[00:08] <snover> yes
[00:09] <snover> (also, check your PMs for a link)
[00:09] <dafioram> it is a bunch of scripts that are room numbers
[00:09] <snover> yes.
[00:09] <snover> well, all room numbers are scripts, but not all scripts are rooms.
[00:10] <snover> high-numbered scripts (in the 64000+ range) are usually the SCI system scripts which tend to be carried across all the different games, and the rest of the scripts are game-specific
[00:13] <-- ccawley2011 left irc: Quit: Page closed
[00:13] <snover> when you run `pl` you get the list of planes, where a plane is basically a container for holding screen items with a configurable background (which can be a specific colour, pic, transparent, or opaque)
[00:14] <snover> the planes are drawn in priority order, higher priority over lower priority. any priority below 0 is invisible, which is done by being behind the kernel-generated opaque -scummvm- plane at priority 0
[00:15] <dafioram> so low priority gets drawn over higher
[00:15] <snover> higher priority draws over lower priority
[00:16] <dafioram> yes
[00:16] <snover> yes. ok.
[00:17] <dafioram> is a room an actual room or can it just be a different situation?
[00:17] <snover> a room number is always a script number, a room script must always export a Room instance in export 0
[00:18] <snover> the Room instance is the actual Room object which has all the properties and methods for the room
[00:19] <snover> the hexadecimal identifier at the start of every plane line is the ID of the plane object within the SCI VM. the SCI VM uses a segmented memory model, where each segment corresponds to objects coming from a specific script, with some additional special segments. segment 0 is always for plain numbers, so anything starting with 0 is not an object but a number.
[00:20] <snover> there are other special segments for data structures like arrays, bitmaps, lists, etc.
[00:20] <snover> (you dont need to know all of these things for this bug, just providing some background so you understand the next things i say :))
[00:20] <dafioram> Are there some games that don't allow the debugger to be opened with ctrl+D?
[00:20] <snover> the SCI debugger opens with ctrl+shift+D because games used ctrl+D
[00:21] <dafioram> yes
[00:21] <snover> so now that we can see all the different planes where screen items are drawn, we can start looking into those planes to find the actual screen items responsible for drawing stuff by running `pi <plane id>`
[00:22] <snover> this command (aka plane_items) will give a list of all the screen items
[00:23] <snover> Phant2 is kind of sucky here because it tends to dynamically allocate a lot of its screen items instead of creating instantiations in the scripts themselves. script instantiations are nice because they actually get unique names. dynamic instantiations just end up with the name of whatever class they are.
[00:25] <snover> so in this case i saw some things called WynTextView which looked relevant, so i then wanted to look at the state of their corresponding VM objects (for whatever reason, screen items on the script-side are called Views), which can be done by running `vo <id>` (aka view_object)
[00:25] <snover> you can run `vo <id>` for the planes, too, and get object information for them, though thats less helpful in this case since the problem is just with a couple of screen items and not with the entire plane
[00:26] <snover> for objects with unique names, you can also just use the name in this command instead of the ID.
[00:28] <snover> so if you look at one of these WynTextView objects with `vo`, you will see a bunch of properties and methods. we can see from the -classScript- property that this objects class definition is in script 63019.
[00:29] <-- chadj left irc: Ping timeout: 240 seconds
[00:29] --> chadj joined #scummvm.
[00:29] <snover> we can also see that it has x, y properties, which are standard SCI View properties corresponding to the origin of the view within its parent plane.
[00:30] <snover> (for clarity, the screen rect you see in the `pi` command is relative to the top-left corner of the screen, not to the top-left corner of the plane.)
[00:31] <snover> are you still with me so far? any questions about any of this?
[00:32] <snover> i know it is a lot of information.
[00:33] <dafioram> I am up to 20:26:11
[00:33] <snover> ok
[00:33] <snover> i will pause until you are ready to continue.
[00:34] <snover> oh, that reminds me, its hugely helpful if you compile with `--enable-text-console`, so you can actually see the game screen while you are interacting with the debugger.
[00:34] <dafioram> ill add that next time
[00:34] <snover> with the text console enabled the debugger interface will be in your command console instead of an overlay of the game screen.
[00:36] <dafioram> WynDocTextView is a plane item and plane line?
[00:38] <snover> it is a screen item in the plane.
[00:38] <snover> in the gamePlane plane*
[00:39] <dafioram> with pi i see the x,y properties, but with vo i dont'
[00:39] <snover> I mean, unfortunately, because of the way SCI works it is actually 3 different things
[00:40] <snover> if the vo command is working correctly you should see x and y at (0009) and (000a)
[00:41] <dafioram> bitmap and picture?
[00:42] <dafioram> vo and pi seem to show different properties
[00:42] <snover> that sounds like something other than a WynDocTextView. what was the vo command you ran?
[00:43] <dafioram> 0017:00bb
[00:43] <snover> it sounds like you are looking at some Plane instance, not a WynDocTextView instance.
[00:44] <snover> is this object gamePlane?
[00:44] <snover> the object name is right after the object ID on the output from `vo`.
[00:44] <dafioram> alright I am back on track
[00:44] <dafioram> i was vo'ing the plane
[00:44] <snover> ok, cool. :) you can also run `help` to get a list of all the debugger commands (there are a lot of them, and it is hard to remember them all!).
[00:46] <dafioram> alright what should I do with this 0017:00ac
[00:46] <snover> so with regards to the different output from `pi` and `vo`, the command `pi` looks up the ScreenItem objects within the kernel (interpreter side) and displays information about that ScreenItem. the `vo` command looks up a VM object within the VM (game side) and displays information about that VM object.
[00:47] <snover> so you can use `vo` for all game objects, not just the graphics things.
[00:47] <dafioram> alright
[00:48] <snover> the game scripts are responsible for updating the kernel by calling to kAddScreenItem, kUpdateScreenItem, or kDeleteScreenItem, and passing the VM object, which the kernel then reads and updates its own representation of the screen item.
[00:48] <snover> so when there is some glitch with graphical stuff, now you can see what the kernel thinks and what the game thinks and see if there is a mismatch there.
[00:49] <dafioram> where do i see what the kernel sees
[00:50] <snover> pl/pi say what the kernel thinks the planes/screen items in the next frame are supposed to be, and vpl/vpi say what the kernel thinks the currently rendered frames planes/screen items are.
[00:52] <snover> (the reason we dont usually look at vpl/vpi is because those only contain a subset of properties which the kernel uses to decide whether or not something has changed, so you will notice if you run those command instead that some properties look invalidbecause they are.)
[00:53] <dafioram> vpi/pi command on the 0017:00bb plane item both look similar and valid
[00:53] <snover> the generation of the output for these debugger commands is in GfxFrameout::printPlaneList and GfxFrameout::printPlaneItemList.
[00:54] <snover> and, all the planes/screen items for the next frame are rendered to the output buffer (and then update the GfxFrameout::_visiblePlanes data) whenever a game script calls kFrameOut.
[00:56] <snover> so getting back to this solving specific bug, because all of these screen items have the same useless default name in the VM, i used the screen rect from the pi list to find the correct object, just to verify that nothing looked weird with it already, and also so that later i could find the object again to look and see what its values were when the rendering was messed up.
[00:58] <snover> another option would be to look at the `text` property of each of the views to find the corresponding text, but thats more tedious here because there are so many of these text objects.
[00:59] <dafioram> you used pi on all the planes to see the different rect properties?
[01:00] <snover> yeah. well, i used a little deduction to eliminate ones that obviously werent going to have this text item. like the planes with no screen items, they obviously wont have it, and the ones named botInterfacePlane and topInterfacePlane are the ones for the bottom and top of the interface (the black bars where the inventory and stuff are), which again dont apply here, and InvPlane is the inventory plane so it wont be there
[01:01] <snover> the one named -scummvm- is the blackout plane for hiding negative planes so of course its not in that one, all the negative priority plane (named&hidePlane&) is invisible so its not that one
[01:01] <dafioram> easy
[01:02] <snover> the generic Plane at priority 2031 could have had it, but the height and y-coordinate of its one WynDocTextView are obviously not it
[01:03] <snover> also, sorry, i have no idea what is going on with my plural verbs tonight
[01:04] <snover> most of the time games either have only like 4 planes (blackout, inventory, control panel, game plane) or they are well-named
[01:04] <snover> phant2 is kind of a hot mess :)
[01:06] <snover> so once i found this object, i saw that none of the properties looked immediately wrong, so then i moved to look to see if it had any interesting-looking methods
[01:07] <snover> the methods list shows methods defined in the class of the object with no prefix, and inherited superclass methods with the name of the superclass
[01:08] <snover> so this also provides kind of a cheaty at-a-glance way to see what the class hierarchy for an object is
[01:08] <snover> in the case of views/screen items, anything View or above is system scripts
[01:08] <snover> so those are basically the same across all sci32 games (and actually probably a lot of sci16 games)
[01:09] <snover> in this case there wasnt anything terribly interesting, so i decided to spend some time looking at the script disassembly instead
[01:09] <snover> (at this point, i am looking for somewhere that i can hook a breakpoint to halt execution during the bad render to see why it is bad)
[01:10] <snover> as i mentioned before games call kFrameOut to render stuff, but that method is called very frequently, so just breaking on it will never give you what you want
[01:10] <snover> well, *mostly*. well use it later :)

[01:11] <-- Dominus left irc: Ping timeout: 260 seconds
[01:11] <snover> http://wiki.scummvm.org/index.php/SCI/Specifications/SCI_virtual_machine/The_Sierra_PMachine documents all of the PMachine opcodes pretty well
[01:12] --> Dominus joined #scummvm.
[01:13] <snover> one thing to note here is that SC was influenced a lot by lisp & smalltalk, so while we normally talk about reading/writing properties or calling methods, fairly frequently this gets expressed in code as sending messages using selectors instead
[01:14] <dafioram> alright
[01:15] <snover> and, because reasons, they expressed call arguments in different orders depending upon the type of call which can be confusing when you are trying to learn how to read the disassembly.
[01:15] <snover> but thats not too important right now
[01:15] <-- Mia left irc: Ping timeout: 248 seconds
[01:15] <snover> looking through Script63019.txt i noticed this `subclass randomVisions` pretty much right away
[01:16] <snover> since this bug is related to the, uh, random visions, that seemed like a fruitful place to look :)
[01:16] <dafioram> easy
[01:16] <snover> and createVision looked most promising so i just searched randomvisions::createvision: to jump to its definition
[01:18] <snover> the PMachine operates most of the time using a single 16-bit accumulator and a stack which is always 16-bytes per entry
[01:19] <snover> er, sorry. 16-bits per entry.
[01:20] <snover> (the ScummVM implementation works somewhat differently, but for the purposes of reading the disassembly, just remember the previous statement and youll be OK)
[01:20] <dafioram> alright
[01:21] <snover> and because of this design, objects and numbers were indistinguishable; an object reference would just be a 16-bit number which was an index into an object array
[01:22] <snover> and similarly, selectors are just numbers, so the disassembler shows you some possible options in comments on the right if the game is sending using a selector, instead of using a direct property access.
[01:23] <snover> so pushi $269 could either be pushing 0x269 to the stack as a number for something, or it could be the restoreVision selector. based on the context, we can see that its being used as a selector because that value is consumed by the `self` opcode a couple lines later.
[01:25] <snover> so the thing that really takes the longest is just internalising the opcodes. there arent a ton of them and a lot of them are just space-savers (push0/push1/push2 in a single byte instead of having to use two bytes for push + 0/1/2)
[01:25] <snover> in this case i mostly just scanned looking for interesting possible selector names in the comments
[01:25] <snover> right at the end of this function is an interesting-looking call to `refresh`
[01:26] <dafioram> wait what line is consuming that pushed value
[01:26] <snover> `self $4`
[01:26] <dafioram> alright
[01:26] <snover> `self` means to send selectors to the current object
[01:27] <snover> $4 is the number of bytes consumed from the stack
[01:27] <snover> pushi $269 is the restoreVision selector, and push0 is the number of arguments sent to the selector (0)
[01:28] <snover> (the reason for all of this is that you can send multiple selectors in one send/self/super operation)
[01:28] --> GitHub165 joined #scummvm.
[01:28] <GitHub165> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/v511W
[01:28] <GitHub165> scummvm/master fc0396f Paul Gilbert: TITANIC: Fix freeze panning away from Parrot cage
[01:28] GitHub165 (GitHub165@ left #scummvm.
[01:28] <snover> (so if you are doing something like setting x and y and width and height, you can just do that all with one send call instead of having to have a send call after each property)
[01:29] <dafioram> whats a selector?
[01:30] <snover> you can think of a selector as being a number that corresponds to either a method *or* a property
[01:31] <dafioram> and they are always 2 bytes?
[01:32] <snover> yes. again for space-saving reasons, it is possible to express a selector in the PMachine bytecode using a single byte if the value is small enough to be represented in a single byte, but when it is pushed onto the stack it is sign extended to 2 bytes.
[01:32] <dafioram> got it
[01:33] <snover> on that wiki page, thats why you will see W/B and 3 bytes or 2 bytes: because the representation in bytecode can be smaller.
[01:33] <snover> but on the stack its 2 bytes always.
[01:33] <snover> and in the disassembly there is no need for such differentiation.
[01:34] <snover> so this refresh call. opcodes `pushi $24d; push0; lag global[$2]; send $4;` are selector 'refresh', zero arguments, load global 2 to the accumulator, and then send to the object in the accumulator.
[01:34] <snover> we can look up what global 2 is in the debugger by running `vv g 2`
[01:35] <snover> (aka `vm_vars global 2`)
[01:35] <snover> (or `vm_vars global 0x2` if you dont feel like converting to decimal in your head)
[01:36] <dafioram> alright
[01:36] <snover> global vars below 100 are usually system globals which dont change across different games, you can see a partial list in enum GlobalVar in sci/engine/vm.h
[01:37] <snover> in this case we can see that global var 2 points to some curtisCubicleRoomCH1SR5 object (maybe a little different depending on which computer/chapter youre looking at the possessed computer in)
[01:37] <dafioram> i see that
[01:37] <snover> so we can run `vo curtisCubicleRoomCH1SR5` again to inspect that object (or use the ID if you dont feel like typing so much :))
[01:38] <dafioram> could we find this screen item in a plane item?
[01:39] <snover> this object is a Room, not a View, so it has no directly corresponding screen item or plane
[01:39] <snover> this object is also a static (aka script) instance, so we see at the bottom of the output that it is in script 4051
[01:39] <snover> unlike the earlier objects which were dynamically created instances
[01:41] <snover> one of the possibly unexpected features of SCI is that script instances can actually redeclare methods, as this one does
[01:42] <snover> so at this point we have a pretty good idea about a couple of places to add some breakpoints, so lets actually start doing that so we can capture the game at a moment where the screen is busted
[01:43] <dafioram> why did room give 63019 before?
[01:44] <snover> room was 4051 before, but WynDocTextView is defined in 63019, so that is where we got 63019
[01:45] <dafioram> lets break it
[01:45] <snover> we started at the screen item list, looking for the affected screen item. once we found that we looked up that screen items VM object and learned it was defined in script 63019. in script 63019 we saw this randomVisions code, which called to global 2, which was an object defined in script 4051.
[01:46] <snover> so now we are back in 4051.
[01:46] <snover> which is the room we are in in the game.
[01:46] <snover> (usually things are not quite so circuitous.)
[01:47] <snover> so there are a few different ways we can break in the debugger, but what well do here is actually break back on this call to createVision
[01:47] <snover> we could break on refresh, but at this point there are some conditions and jumps in createVision so we might not get there
[01:47] <snover> so we will run bpx (aka bp_method), `bpx randomVisions::createVision`
[01:48] <snover> that will create a default breakpoint. we could also append `log` or `bt` at the end of the command if we just wanted to log it or generate a backtrace without actually breaking.
[01:48] <snover> but by default&it breaks.
[01:48] <snover> so now we have this breakpoint, just type in `go` to return to the game and wait until the method is called
[01:49] <snover> this will take however long the RNG decides, probably just a couple of seconds
[01:49] <dafioram> not tripping
[01:49] <snover> once the breakpoint hits, we are back in the debugger
[01:49] <snover> what does `bplist` show?
[01:50] <dafioram> #0: Execute randomVisions::createVision
[01:50] <snover> and your game is at the point where the computer is showing the random visions and glitching?
[01:50] <dafioram> yes
[01:52] <snover> hmm. it *should* be triggering.
[01:52] <-- Lightkey left irc: Ping timeout: 246 seconds
[01:53] <snover> try running `bpdel 0` to remove the breakpoint and then add it in again, taking care to make sure the case is correct and that you dont hit any non-printable characters (i dont know if this is just a global input issue or just a text console input issue or just an xcode issue but sometimes i manage to get non-printable characters into the console and it gets confused)
[01:54] <snover> (this happens for me when i hit page up/page down)
[01:55] <dafioram> my room is 4674
[01:55] <snover> oh, different room.
[01:56] <snover> well, lets just try running `room 4051` to force-switch rooms and see if anything explodes
[01:57] <snover> otherwise, heres save game at room 4051: https://www.dropbox.com/s/z1wiyxed8ysl4gk/phantasmagoria2-cd-win.024?dl=0
[01:59] <snover> ill be back in a moment, but just so you have something to keep going, once you get into the debugger you can run `bt` to learn the backtrace, and then after that breakpoint triggers well use `snk FrameOut` (aka step_callk) to continue execution until kFrameOut is reached, and then `s` (aka step) to allow kFrameOut to run, at which point we should be paused right after the glitched out render happens
[01:59] <dafioram> The bug I was talking about is in the top left corner
[02:00] <-- kgbme left irc: Quit: Connection closed for inactivity
[02:01] <dafioram> I see it
[02:05] --> Lightkey joined #scummvm.
[02:09] <snover> yes
[02:09] <snover> thats the one!
[02:10] <snover> dafioram: so were you able to get into the debugger with the bug triggered?
[02:10] <dafioram> yes
[02:10] <snover> awesome.
[02:11] <snover> so the bad news is that all that stuff i had you do earlier to find the object id isnt going to work because the game is different, but the good news is it wouldnt have worked anyway because this stupid game recreates objects all the time. surprise! but you can just apply the same process again now to find the glitched out text field
[02:11] <snover> which will have a screen rect starting at 0,0
[02:11] <snover> let me know when you find it and `vo` its VM object
[02:13] <dafioram> there
[02:14] <snover> ok cool
[02:14] <snover> so what i noticed when viewing this object was that x and y looked OK, but left and top were zero
[02:15] <snover> i ran `snk FrameOut` again until the glitch fixed itself and then `vo` the object again and saw that left and top were now the same as x and y
[02:16] <snover> something important to note here is that in phantasmagoria 2, for whatever reason, they decided that these selectors would be called left/top/right/bottom. in *every other game* these selectors are actually nsLeft/nsTop/nsRight/nsBottom.
[02:16] <snover> NS stands for NextST no wait sorry, wrong programming language
[02:17] <snover> NS stands for now seen which is basically the draw rectangle for a screen item
[02:18] <-- dreammaster left irc:
[02:20] <dafioram> so I see MATRICIDE, is that what you were looking for?
[02:21] <dafioram> I don't see it in that same high prority plane item
[02:21] <snover> looking for the file title
[02:22] <snover> though i *think* what is happening in this case is that the file title gets reset to 0,0 and then the game tries to take its position for the random text and you just happened to get lucky and have the random text draw where the file or note titles are
[02:22] <snover> file & note titles get reset*
[02:23] <snover> the file and note titles get reset even if they arent the target of the random vision text so just keep looking until you find one of those
[02:24] <snover> its unfortunate that you managed to get this random roll which confuses things somewhat :)
[02:25] <snover> were very close to the end though.
[02:26] <dafioram> So there is some text that is a particular phrase and it occasionally is correct on the folder and sometimes it appears to the top left?
[02:26] <snover> oh, oh. sorry. i forgot to mention (reproducibility, argh! :)) to open the veniman_sagawa file
[02:27] <snover> but, good, this gives me an option to tell you how to change breakpoint actions
[02:27] <snover> to temporarily disable the breakpoints without having to recreate them later, `bpact * ignore`
[02:28] <snover> (or replace * with a number from bplist if you want to only disable one of them)
[02:28] <snover> then when you want to turn them back on, `bpact * break`
[02:29] <snover> so disable the breakpoints, open the veniman file, re-enable the breakpoints, wait for createVision, snk FrameOut to the bad point, you should see the file name and note shift to the top-left corner
[02:29] <snover> then find one of those screen items and look at it
[02:35] <snover> most of the rest of this process is just the usual process of troubleshooting and deduction to isolate the defect code
[02:35] <dafioram> so I keep seeing the text in the top let and occasionally I see some other folder names but never just the folder renamed with no top left text
[02:36] <dafioram> MATRICIDE is the folder name I see sometimes
[02:37] <snover> https://zetafleet.com/i/59b7489817b2e.png you currently have this output?
[02:38] <dafioram> I don't have that folder, but I get top left text like that
[02:38] <snover> are you using the save game i linked above?
[02:38] <dafioram> sorry file I see veniman
[02:39] <snover> ok
[02:39] <snover> cool
[02:39] <snover> er, i guess the screen rect is at 0,70 because of the top bar. i keep forgetting that. sorry if that caused confusion.
[02:41] <snover> you should find some object at that coordinate which looks like this https://zetafleet.com/i/59b7497dd43fa.png
[02:42] <snover> so x = 70 and y = 10 (remember these are plane-relative coordinates, and the plane is at 0, 70)
[02:45] <snover> and if we do `snk FrameOut` (to continue until kFrameOut) and then `s` (to step one instruction, executing kFrameOut), checking again, things are mostly the same but the NS rect is correctly updated https://zetafleet.com/i/59b74a3e9a8cf.png
[02:46] <dafioram> I don't see that screen object
[02:46] <snover> since these are dynamically generated, the IDs are not deterministic
[02:48] <dafioram> is the last plane item?
[02:48] <snover> they are in gamePlane
[02:48] <snover> https://zetafleet.com/i/59b74b0f47058.png
[02:50] <dafioram> how do u know those are the same text objects
[02:51] <snover> they are the only screen items at 0, 70. but also to verify, you can look and see the text they reference
[02:51] <snover> for the sake of expedience, you can run `vo <object> text data`
[02:52] <snover> or&you probably can do that. i might not have pushed that yet.
[02:52] <snover> the long way is, `vo <object>`, look at the text property, `vo <id in the text property>`, look at the data property `vr <id in the data property>`. note that last one is `vr`, for view reference, since that is a reference to either a string array or a raw string in a script, not an object.
[02:53] <dafioram> I looked at the high priority plane screen item which was the document and it gave me that text
[02:54] <snover> yeah, thats right. that high priority plane is the viewport for the scrolling document text
[02:54] <snover> the glitchy text is the file and note lines above that, which isnt in the scrolling viewport
[02:55] <dafioram> gameplane?
[02:55] <snover> yes
[02:55] <snover> the file and note lines are in gamePlane.
[02:58] <snover> there is no rendering tree in SCI, just a list of planes, so when they want to render things like viewports new planes appear and the list can get confusing because theres no logical grouping of related elements.
[02:58] <snover> let me know if that makes sense or you have questions. this is a lot of information to take in at once.
[02:59] <dafioram> does the screen id stay the same for my game?
[03:00] <snover> the gamePlane ID should be consistent but the viewport plane is dynamically created so it will probably be different all the time
[03:01] <snover> static instances will always have the same offset (the number to the right of the colon) for a given script and if you load scripts in the same order every time the segment (the number to the left of the colon) will also always be the same
[03:01] <snover> its only these dynamic objects which lose determinism
[03:02] <snover> i didnt want to overload you more talking about clones (dynamic objects)
[03:02] <dafioram> so I can see the screen item with top and left with zero
[03:02] <dafioram> but then how do I follow it?
[03:03] <snover> the ID will stay the same until the game deletes and recreates it, which wont happen until after it gets repositioned, thankfully
[03:03] <snover> so you can hold onto that ID, run `snk FrameOut; s` and then check it again using the same ID
[03:04] <snover> but i think the game is programmed so that once the vision goes away it recreates all the text objects :\
[03:04] <dafioram> my top is 30 and urs was 10, but the lefts are both 70
[03:04] <snover> ok, you are just looking at the note and i was looking at the file
[03:05] <snover> they both screw up in the same way so thats fine
[03:05] <dafioram> I think its the authoer
[03:05] <dafioram> author
[03:06] <snover> yes. when i say file and note i am referring to the labels to the left of the text areas, because the VM objects dont have usable names :)
[03:07] <dafioram> okay so the game is just showing the file name and author in note field both at top left corner
[03:07] <snover> yes
[03:08] <dafioram> i got this
[03:08] <snover> and, as i think you discovered accidentally, also one of the visions if it is replacing one of those fields :)
[03:09] <snover> the code as written in this game makes like no sense, so prepare to experience some amount of confusion on a regular basis. the other games are way less crazy.
[03:09] <snover> this is definitely the hardest one ive worked on.
[03:10] <dafioram> alright lets patch this sucker
[03:11] <snover> ok. so, blah blah blah, eventually i discovered in the bowels of this machine looking at the curtisblahblahCH1SR5 object, that this object has a titleText property which is where this WynTextView gets assigned, so i searched for titleText in the disassembly to find where it was being messed with
[03:14] <snover> i am re-experiencing the confusion i had the first time figuring out where the hell this object was getting updated
[03:14] <snover> i guess i should just look at my patch :)
[03:15] <snover> so what i ended up doing when i was confused the first time was i used `bpw curtisblahblah::titleText` to find the place where that property was being set with the new WynTextView
[03:16] <snover> the first couple times it was being set to null, eventually it was set to an object and i used `bt` to figure out where
[03:16] <snover> (the answer is WynNetDoco::open)
[03:16] <dafioram> in 63019?
[03:16] <snover> yeah
[03:18] <snover> the reason why i could not find it is because they dynamically construct the WynTextView object, so its ID is in the accumulator, then they store it to a temp variable (their word for a function-local variable), then they push the temp variable to the stack and load a parameter which is the curtisblahblah object to the accumulator and then send it
[03:18] <snover> lots of stupid worthless indirection
[03:18] <snover> you can see this at the top of WynNetDoco::open
[03:19] <dafioram> yes
[03:19] <snover> selector sends go in order from top to bottom, so first setSize is called, then init is called, then posn is called
[03:20] <snover> this seemed weird so i looked at setSize
[03:21] <snover> trying to find stuff in the separate script files is sometimes boring, so we can ask the debugger to disassemble a method for us
[03:21] <dafioram> okay
[03:21] <snover> so i just ran `disasm WynTextView setSize`
[03:22] <dafioram> waht did u get?
[03:22] <snover> and then it complained there was more than one object by that name, so i just picked the first id it listed (it doesnt matter which one you use) and reran `disasm <id> setSize`
[03:22] <snover> and got the disassembly
[03:23] <snover> and saw that the code was setting left and top from the x and y properties
[03:23] <snover> but x and y properties are not set until posn is called
[03:23] <dafioram> rookie mistake
[03:23] <dafioram> so you just swtiched the order?
[03:23] <snover> yes
[03:24] <snover> this setSize function is bad news no matter what since the NS rect is really only supposed to be set by the kernel
[03:24] <snover> (i.e. the game scripts are not supposed to be messing with left/top/right/bottom itself)
[03:25] <snover> so the final step was just getting the bytecode and writing the script patch into script_patches.cpp
[03:25] <snover> getting the bytecode is easy, you just run `disasm <id> setSize bc` (note the `bc` on the end)
[03:25] <snover> paste that into a new script patch
[03:26] <dafioram> i c
[03:26] <snover> SIG_MAGICDWORD is a marker that the script patcher users when deciding whether or not a patch might apply
[03:27] <snover> basically it sees if the next 4 bytes after the marker exist or not, in order to decide whether to run the full comparison of the entire patch
[03:27] <snover> so you just pick some 4 bytes that seem unique-ish and put the marker before them
[03:27] <dafioram> I will have to see what this disasm give me
[03:28] <snover> the SIG_SELECTOR and PATCH_SELECTOR are used because sometimes sierra liked to recompile games and rewrite the selector vocabulary, so if that ever happens the patch will still apply because the selector values will be looked up from the vocab file instead of using literal values
[03:28] <snover> SIG_ADDTOOFFSET means i dont care what these next N bytes are
[03:30] <snover> for 16-bit values, SIG_UINT16 and PATCH_UINT16 are used to make sure the correct endianness is used since game scripts were compiled to host machine endianness
[03:30] <snover> this is the first time i ever used PATCH_GETORIGINAL*, which just reads the bytes from the pre-patched script starting N bytes from the start of the signature
[03:31] <snover> the signature must be at least as long as the patch but may be longer than the patch, in which case anything after PATCH_END is left as-is
[03:32] <snover> in this case, the reason why I used PATCH_GETORIGINAL* and SIG_ADDTOOFFSET was because the bytecode for the two text fields initialisation was identical except for the selectors used for the X and Y values, so i made it apply to both by reading the selector data out of the original script
[03:33] <snover> in the patch table, the unlabelled mystery number after the patch description is how many times to apply the patch to the script
[03:33] <snover> most of the time its a one-off patch so you apply it 1 time, but sometimes&you apply it more than one times.
[03:34] <dafioram> twice
[03:34] <snover> it depends on how copy-paste happy the game script devs were
[03:34] <snover> and those are pretty much the essentials of what you need to know in order to fix game scripts.
[03:35] <dafioram> i may have some questions
[03:35] <snover> SCI3 is different from everything else because it has a memory overlay system for scripts to allow larger-than-16-bit offsets without actually changing anything about the bytecode, and because selectors and property offsets were the same
[03:36] <snover> in previous versions, property offsets were actually indexes (so you unfortunately lose the lovely named property names in the disassembler)
[03:36] <snover> and there was no memory overlay so all offsets were never bigger than 16-bits
[03:37] <snover> also, SCI Companion can actually *decompile* SCI2.1-and-earlier scripts, so the file i sent you has decompiled scripts for all the games prior to SCI3.
[03:38] <snover> as you may expect, that is often quite a bit easier to read than disassembly, though it is lisp-based, (so (you (will (have (to (deal (with (that))))))))
[03:39] <dafioram> phant1 is sci2.1?
[03:39] <snover> yes
[03:39] <snover> phant2, lsl7, lighthouse, rama are the only SCI3 games
[03:39] <snover> well, and shivers 2, but that one is C++ SCI3.
[03:40] <dafioram> where is sci companion?
[03:40] <snover> the decompiled/disassembled scripts are not always 100% correct because the tools used to generate those files dont fully understand SCI32, but that is mostly only a problem for GK2 (because it gained the new RESSCI.PAT patch file type and put scripts in there) and SCI3.
[03:41] <snover> http://scicompanion.com/download/
[03:42] <snover> i had to finagle it somewhat to generate decompiled scripts for SCI32.
[03:42] <snover> officially it only supports SCI16.
[03:43] <snover> the SCI3 scripts came from some version of SCI Viewer which occasionally got confused about where the selector vocab went
[03:45] <snover> (but which actually had a primitive command-line interface to let me dump all the scripts instead of having to click through one by one in the UI or do something crazy like use some macro recorder)
[03:45] <dafioram> so thats how you got the files in sci3/?
[03:45] <snover> yes
[03:46] <snover> some of the obviously broken ones i manually re-exported from the newer GUI-only SV as needed
[03:46] <snover> the debugger can also disassemble an arbitrary memory address if you ever run across a localproc you want to look at, since those cannot be named
[03:47] <snover> (`disasm_addr`)
[03:47] <snover> `segment_table` is also useful for finding the segments for given scripts, and `segment_info <segment number>` will list all the things inside of a segment
[03:48] <dafioram> alright I think I need to digest this all
[03:48] <snover> yep. its a lot.
[03:49] <snover> i am around for questions, pithy remarks, sarcastic remarks, etc.
[03:49] <dafioram> top tips?
[03:49] <snover> yes.
[03:49] <dafioram> excellent
[03:50] <snover> my newsletter is also available to SGT passengers
[03:51] <dafioram> I don't read below 2nd class
[03:52] <snover> good choice.
[03:52] <dafioram> why don't you push ur phant2 fix?
[03:53] <snover> i dont know. obsessive batching of fixes locally.
[03:53] <snover> or, well, on my working branch.
[03:54] <snover> i try to do this to avoid committing obviously broken stuff to master.
[03:55] <snover> there are still some glitches with the visions stuff so im still working on those and i am not sure if it will uncover a deeper underlying issue that can fix all of them at once
[03:55] <snover> since, i dont know if you could tell from the screenshot, but the open folder icon became closed and the active document icon became inactive also
[03:56] <snover> so maybe it turns out that those calls ordering was broken, but also their super calls are in the wrong order too&
[03:57] <dafioram> just graphics
[03:57] <snover> im sure this is fine. lets go write some more easter eggs.
[03:58] <snover> i also noticed that phant2 is causing abnormally high cpu usage while it is sitting doing nothing so i spent part of my day reviewing every single call to kGetTime
[03:59] <dafioram> want me to run phant2 on the raspberry pi?
[03:59] <snover> i havent removed all of the spin loops yet
[03:59] <snover> so i dont think further testing is needed yet
[03:59] <snover> there are a lot of them.
[04:00] <dafioram> alright
[04:02] <snover> though i dont see anything with kGetTime triggering breakpoints
[04:03] <snover> and yet sitting here staring at the veniman document 90% CPU
[04:03] <snover> unfortunately as far as i am aware the SCI VM does not have anything for profiling stupid games that spin loop in other stupid ways, like just using cycle counters
[04:04] <snover> CPU throttling relies on calls to kFrameOut or kGetEvent and if the game is spinning in some way other than by kGetTime Im not sure how to find it right now
[04:05] <snover> especially in phant2 which has layers of different sub-game-loops
[04:06] <snover> i was thinking about implementing a call counter or something to try to track it down.
[04:09] <snover> https://zetafleet.com/i/59b75e1ab422b.png CPU usage on an optimised build when in the computer interface doing nothing. this should be like 10% CPU at most.
[04:10] <snover> instead its 4060%.
[04:10] <dafioram> single cpu computer?
[04:11] <snover> uh, yeah. using *nix CPU time calculation (100% = 1 CPU), not Windows.
[04:15] <dafioram> alrigh i'll sci ya later
[04:16] <snover> good night!
[04:16] <-- dafioram left irc: Quit: Leaving
[04:27] Nick change: Stormkeeper -> Storm-AFK
[05:18] --> abrcdbr_ joined #scummvm.
[05:19] <-- abrcdbr left irc: Ping timeout: 240 seconds
[05:20] <-- abrcdbr_ left irc: Remote host closed the connection
[05:45] --> GitHub102 joined #scummvm.
[05:45] <GitHub102> [scummvm] csnover pushed 4 new commits to master: https://git.io/v51dD
[05:45] <GitHub102> scummvm/master eb284c4 Colin Snover: SCI32: Replace spin loop with kWait in Phant2 alien password screen
[05:45] <GitHub102> scummvm/master f9c4314 Colin Snover: SCI32: Fix janky document scrolling in Phant2 computer interface
[05:45] <GitHub102> scummvm/master a7ede0c Colin Snover: SCI32: Fix bad positioning of text in Phant2 computer on first render...
[05:45] GitHub102 (GitHub102@ left #scummvm.
[05:48] <snover> so many script bugs&
[05:49] <snover> the computer interface was super janky before. i am glad that i was able to patch most of the crappiness away.
[05:56] --> _sev joined #scummvm.
[05:56] <-- _sev left irc: Changing host
[05:56] --> _sev joined #scummvm.
[05:56] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[05:59] --> waltervn joined #scummvm.
[05:59] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services.
[05:59] <waltervn> morning
[06:13] <wjp> Morning
[06:13] <wjp> Lots of sci work tonight I see :-)
[06:21] <-- waltervn left irc: Ping timeout: 248 seconds
[06:40] --> m_kiewitz joined #scummvm.
[06:40] #scummvm: mode change '+o m_kiewitz' by ChanServ!ChanServ@services.
[06:43] --> waltervn joined #scummvm.
[06:43] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services.
[07:30] --> HTTP_____GK1wmSU joined #scummvm.
[07:31] HTTP_____GK1wmSU (DEEP-BOOK@ left #scummvm.
[07:49] --> _sev|work joined #scummvm.
[07:49] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[07:53] <-- _sev|work left irc: Client Quit
[07:54] <-- TMM left irc: Quit: Ex-Chat
[08:15] --> Mia joined #scummvm.
[08:15] <-- Mia left irc: Changing host
[08:15] --> Mia joined #scummvm.
[08:50] --> _sev|work joined #scummvm.
[08:50] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[08:55] Nick change: antlarr2 -> antlarr
[09:05] <-- _sev|work left irc: Quit: This computer has gone to sleep
[09:08] <-- LittleToonCat left irc: Remote host closed the connection
[09:11] --> _sev|work joined #scummvm.
[09:11] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[09:15] <-- _sev|work left irc: Client Quit
[09:15] --> TMM joined #scummvm.
[09:15] #scummvm: mode change '+o TMM' by ChanServ!ChanServ@services.
[09:29] --> _sev|work joined #scummvm.
[09:29] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[09:29] --> GitHub63 joined #scummvm.
[09:29] <GitHub63> [scummvm] yinsimei pushed 1 new commit to master: https://git.io/v5Mqo
[09:29] <GitHub63> scummvm/master e1c33a6 Simei Yin: SLUDGE: Use Mod/Xm/S3m decoder in Sludge
[09:29] GitHub63 (GitHub63@ left #scummvm.
[09:30] <-- _sev|work left irc: Client Quit
[09:41] --> _sev|work joined #scummvm.
[09:41] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[09:44] <-- _sev|work left irc: Client Quit
[09:59] --> _sev|work joined #scummvm.
[09:59] <-- _sev|work left irc: Changing host
[09:59] --> _sev|work joined #scummvm.
[09:59] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[11:12] --> Strangerke_ joined #scummvm.
[11:14] <-- Strangerke left irc: Ping timeout: 252 seconds
[11:14] Nick change: Strangerke_ -> Strangerke
[11:42] --> jamm joined #scummvm.
[11:42] <-- jamm left irc: Changing host
[11:42] --> jamm joined #scummvm.
[11:49] <-- _sev|work left irc: Ping timeout: 240 seconds
[11:58] --> _sev|work joined #scummvm.
[11:58] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[12:02] <-- _sev|work left irc: Client Quit
[12:11] --> _sev|work joined #scummvm.
[12:11] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[12:14] <-- _sev|work left irc: Client Quit
[12:19] --> _sev|work joined #scummvm.
[12:19] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[12:20] <-- _sev|work left irc: Client Quit
[12:23] --> _sev|work joined #scummvm.
[12:23] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[12:30] --> criezy|Work joined #scummvm.
[12:30] #scummvm: mode change '+o criezy|Work' by ChanServ!ChanServ@services.
[12:53] <-- _sev|work left irc: Quit: This computer has gone to sleep
[13:02] --> _sev|work joined #scummvm.
[13:02] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[13:23] <-- _sev|work left irc: Quit: This computer has gone to sleep
[13:46] --> ccawley2011 joined #scummvm.
[14:19] --> abrcdbr joined #scummvm.
[14:21] <-- ccawley2011 left irc: Ping timeout: 260 seconds
[14:21] --> ccawley2011 joined #scummvm.
[14:23] --> _sev|work joined #scummvm.
[14:23] <-- _sev|work left irc: Changing host
[14:23] --> _sev|work joined #scummvm.
[14:23] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[14:26] <-- _sev|work left irc: Client Quit
[14:34] --> _sev|work joined #scummvm.
[14:34] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[14:39] --> waltervn_ joined #scummvm.
[14:39] #scummvm: mode change '+o waltervn_' by ChanServ!ChanServ@services.
[14:42] <-- waltervn left irc: Ping timeout: 248 seconds
[14:45] <-- waltervn_ left irc: Ping timeout: 260 seconds
[14:49] <-- vv222 left irc: Ping timeout: 252 seconds
[14:49] --> waltervn_ joined #scummvm.
[14:49] #scummvm: mode change '+o waltervn_' by ChanServ!ChanServ@services.
[14:56] --> vv222 joined #scummvm.
[15:02] <-- vv222 left irc: Ping timeout: 255 seconds
[15:03] --> Henke37 joined #scummvm.
[15:07] <-- _sev|work left irc: Quit: This computer has gone to sleep
[15:18] <-- DrMcCoy left irc: Remote host closed the connection
[15:23] --> mankeli joined #scummvm.
[15:30] <-- jamm left irc: Ping timeout: 255 seconds
[15:30] --> _sev|work joined #scummvm.
[15:30] <-- _sev|work left irc: Changing host
[15:30] --> _sev|work joined #scummvm.
[15:30] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[15:40] <logix> https://kotaku.com/nintendo-bringing-back-the-nes-classic-in-2018-1803771394
[15:41] <logix> I'm starting to agree with reggie - don't overpay for the snes classic mini (this assumes ninty isn't just bullshitting in that announcement)
[15:41] Nick change: Storm-AFK -> Stormkeeper
[15:44] <mankeli> mal: is the sailfish os port ready yet?
[15:53] <-- _sev|work left irc: Quit: This computer has gone to sleep
[15:55] <-- TMM left irc: Quit: Ex-Chat
[16:04] --> GitHub129 joined #scummvm.
[16:04] <GitHub129> [scummvm] csnover pushed 2 new commits to master: https://git.io/v5Mjh
[16:04] <GitHub129> scummvm/master 2228ae2 Colin Snover: SDL: List supported 32bpp pixel formats when using SDL2...
[16:04] <GitHub129> scummvm/master 533bb5b Colin Snover: SCI32: Improve chance of rendering non-8bpp AVIs...
[16:04] GitHub129 (GitHub129@ left #scummvm.
[16:05] --> GitHub95 joined #scummvm.
[16:05] <GitHub95> [scummvm] criezy pushed 1 new commit to master: https://git.io/v5Dee
[16:05] <GitHub95> scummvm/master fac7797 Thierry Crozat: I18N: Update translations templates
[16:05] GitHub95 (GitHub95@ left #scummvm.
[16:05] --> GitHub188 joined #scummvm.
[16:05] <GitHub188> [scummvm] csnover closed pull request #1008: SDL: List supported 32bpp pixel formats when using SDL2 (master...add-32bpp-formats) https://git.io/v5EZO
[16:05] GitHub188 (GitHub188@ left #scummvm.
[16:18] <ScummBot> Port build status changed with 533bb5b2: Failure: master-psp2
[16:21] --> ny00123 joined #scummvm.
[16:21] <snover> &
[16:24] <wjp> oh, usually it's amigaos giving that one
[16:27] --> GitHub82 joined #scummvm.
[16:27] <GitHub82> [scummvm] csnover pushed 1 new commit to master: https://git.io/v5DJ8
[16:27] <GitHub82> scummvm/master c2a4784 Colin Snover: SDL: Fix compilation on PSP2
[16:27] GitHub82 (GitHub82@ left #scummvm.
[16:34] --> ajax16384 joined #scummvm.
[16:34] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[16:34] <ScummBot> Port build status changed with c2a47847: Success: master-psp2
[16:36] --> GitHub11 joined #scummvm.
[16:36] <GitHub11> [scummvm] csnover pushed 4 new commits to master: https://git.io/v5DUP
[16:36] <GitHub11> scummvm/master eb4e9fe Colin Snover: GUI: Remove mostly-broken audio output sample rate control...
[16:36] <GitHub11> scummvm/master 4a75fba Colin Snover: SDL: Reduce audio playback latency...
[16:36] <GitHub11> scummvm/master fa52df0 Colin Snover: SDL: Fix DoubleBufferSDLMixerManager doubling audio latency...
[16:36] GitHub11 (GitHub11@ left #scummvm.
[16:36] --> GitHub127 joined #scummvm.
[16:36] <GitHub127> [scummvm] criezy pushed 1 new commit to master: https://git.io/v5DU1
[16:36] <GitHub127> scummvm/master 6a38fdf Thierry Crozat: I18N: Update translations templates
[16:36] GitHub127 (GitHub127@ left #scummvm.
[16:46] <mal> mankeli: no, because I started doing it with Qt instead of SDL, it takes a while to write a whole new backend
[16:49] <snover> mal: after you said that, i looked and its unclear to me why sdl cannot be used, as it appears to be an officially supported abstraction layer for sailfish os. what was the problem?
[16:54] <mal> snover: for example dynamic orientation doesn't seem to be possible, sailfish occasionally complains the app is not responding, manually rotating the scummvm UI to get landscape orientation seems to be a bit hacky, also it depends on the device what is the framebuffer orientation so some detection would be needed
[16:54] <mal> and so on
[16:55] Nick change: Stormkeeper -> Storm-AFK
[16:56] <snover> what engine were you testing where it gave a non-responsive warning? many engines have situations where they dont call to poll the event queue frequently enough and this causes non-responsive warning in all OS (because the app is legitimately acting non-responsively)
[16:56] <mal> snover: even the main UI

[16:57] <m_kiewitz> so possibly 10 NES Mini :p
[16:58] --> DrMcCoy joined #scummvm.
[16:58] #scummvm: mode change '+o DrMcCoy' by ChanServ!ChanServ@services.
[17:00] <snover> mal: what do you mean by dynamic orientation?
[17:01] --> abrcdbr_ joined #scummvm.
[17:01] <mal> snover: that scummvm would show as landscape or portrait depending on how the user is holding the device
[17:03] <snover> is there some problem with the SDL_WINDOWEVENT_SIZE_CHANGED event on those devices?
[17:03] <-- abrcdbr left irc: Ping timeout: 248 seconds
[17:05] <snover> and/or the SDL_HINT_ORIENTATIONS hint?
[17:05] <mal> snover: I couldn't see any of those
[17:05] <-- abrcdbr_ left irc: Quit: Textual IRC Client: www.textualapp.com
[17:05] <mal> not sure about that hint, I think that is only for macos?
[17:07] <snover> the documentation says iOS but some other people suggest it also works for android so i dont know if those people are wrong or the documentation is wrong or both :)
[17:07] <snover> to be clear, when you are looking for SDL_WINDOWEVENT_SIZE_CHANGED you are looking first for an event with type SDL_WINDOWEVENT and then checking the events window.event property for SDL_WINDOWEVENT_SIZE_CHANGED and you never see those?
[17:12] <mal> snover: I do get two SIZE_CHANGED events and some WINDOWEVENTs at start but nothing when I rotate the phone
[17:13] <mal> snover: I think it might be that the wayland backend of SDL is not very good
[17:14] <snover> interesting. certainly the quality of SDL on the major platforms and their development process does not fill me with a lot of confidence that it is not broken elsewhere :)
[17:15] --> LittleToonCat joined #scummvm.
[17:15] <criezy|Work> snover: Is DoubleBufferSDLMixerManager still used somewhere after your changes? Otherwise what was the reason to keep it?
[17:16] <snover> criezy|Work: yeah, it is used on some of the other ports
[17:16] <bgK> I can attest the wayland mode in SDL is "not very good" even on a desktop computer
[17:16] <criezy|Work> Ah OK. Then the GitHub "Search in this repository" is not working very well :P
[17:17] --> TMM joined #scummvm.
[17:17] #scummvm: mode change '+o TMM' by ChanServ!ChanServ@services.
[17:17] <snover> well, now i cant find them when i search either&
[17:17] <snover> im sure i saw it on some other ports
[17:18] <snover> oh, maybe i assumed because of this #if defined(MACOSX) || defined(GP2X) || defined(CAANOO) || defined(GP2XWIZ) line
[17:19] <snover> and it is not actually used, and you are totally correct about that
[17:20] <criezy|Work> Also I see you added those advanced config options to the wiki, but maybe they should also be mentioned in the README?
[17:20] <criezy|Work> And the screenshotpath that is mentioned in the README should probably be added to that wiki page :P
[17:20] <criezy|Work> I think there are a few other options than cannot be set from the GUI. I will try to remember what they are.
[17:20] <criezy|Work> Maybe something related to teh taskbar code, such as the path where to look for the game icons.
[17:21] <snover> i wonder if it is worth just reviewing README, moving everything relevant from there into wiki pages, and then replacing README with a stub pointing to the wiki?
[17:22] <snover> manually trying to keep information in sync between the two is probably always going to end up where one place or the other is out of sync somewhere
[17:22] <criezy|Work> Maybe. There is a lot dupplicated, which is not very good, especially as we are not very good at keeping the wiki and README synchronized :P
[17:23] <criezy|Work> Rather than a stub I would mabe reduce it to what is currently the QuickStart though (the first section of the README I think).
[17:23] <snover> that seems also reasonable
[17:24] --> heroux joined #scummvm.
[17:27] <mal> snover: isn't the android port of scummvm also always landscape? I think I tried it before
[17:27] <snover> i gotta run, i guess i will eliminate doublebuffer entirely if someone doesnt get to it before me, when i get back
[17:27] <snover> let me know any other thoughts and i will take care of them
[17:39] <-- criezy|Work left irc: Quit: Page closed
[17:44] --> rootfather joined #scummvm.
[17:44] #scummvm: mode change '+o rootfather' by ChanServ!ChanServ@services.
[18:05] --> Farmboy0 joined #scummvm.
[18:05] <-- Farmboy0 left irc: Changing host
[18:05] --> Farmboy0 joined #scummvm.
[18:28] --> GitHub130 joined #scummvm.
[18:28] <GitHub130> [scummvm] bgK pushed 6 new commits to master: https://git.io/v5DnM
[18:28] <GitHub130> scummvm/master 6506b95 Bastien Bouclet: PEGASUS: Call OSystem::updateScreen on each frame...
[18:28] <GitHub130> scummvm/master 64967c6 Bastien Bouclet: PEGASUS: Reset the Pegasus biochip when toggling the shared screen space...
[18:28] <GitHub130> scummvm/master 7310284 Bastien Bouclet: PEGASUS: Ignore events occuring while the GUI is visible...
[18:28] GitHub130 (GitHub130@ left #scummvm.
[18:28] --> GitHub87 joined #scummvm.
[18:28] <GitHub87> [scummvm] criezy pushed 1 new commit to master: https://git.io/v5Dn9
[18:28] <GitHub87> scummvm/master 738e562 Thierry Crozat: I18N: Update translations templates
[18:28] GitHub87 (GitHub87@ left #scummvm.
[18:51] --> vv222 joined #scummvm.
[18:58] <-- ajax16384 left irc: Quit: Leaving
[19:02] --> ajax16384 joined #scummvm.
[19:02] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[19:21] <-- vv222 left irc: Quit: WeeChat 1.9
[19:21] --> vv222 joined #scummvm.
[19:29] --> criezy joined #scummvm.
[19:29] #scummvm: mode change '+o criezy' by ChanServ!ChanServ@services.
[19:45] <tsoliman> snover: how can I tell if I have a not-big-enough audio buffer? Will I see buffer-underruns or something in the console output?
[20:06] <m_kiewitz> PSA: Humdle Bundle this week with Tex Murphy (Tesla Effect)
[20:12] #scummvm: mode change '+o Strangerke' by ChanServ!ChanServ@services.
[20:12] <-- DrMcCoy left irc: Quit: reboot
[20:25] <-- ajax16384 left irc: Read error: Connection reset by peer
[20:27] --> DrMcCoy joined #scummvm.
[20:27] #scummvm: mode change '+o DrMcCoy' by ChanServ!ChanServ@services.
[20:30] <-- DrMcCoy left irc: Remote host closed the connection
[20:38] --> DrMcCoy joined #scummvm.
[20:38] #scummvm: mode change '+o DrMcCoy' by ChanServ!ChanServ@services.
[20:47] --> GitHub167 joined #scummvm.
[20:47] <GitHub167> [scummvm] criezy pushed 4 new commits to master: https://git.io/v5Dr5
[20:47] <GitHub167> scummvm/master 3607b79 Thierry Crozat: MACOSX: Remove mixer init from derived class for macosx backend...
[20:47] <GitHub167> scummvm/master 629ea05 Thierry Crozat: GPH: Remove unused include...
[20:47] <GitHub167> scummvm/master f7436a9 Thierry Crozat: OPENPANDORA: Remove unused include...
[20:47] GitHub167 (GitHub167@ left #scummvm.
[20:58] <-- Farmboy0 left irc: Read error: Connection reset by peer
[21:11] --> Dubberino joined #scummvm.
[21:14] <-- Dubbins left irc: Ping timeout: 248 seconds
[21:21] <-- rootfather left irc:
[21:26] <-- Henke37 left irc: Quit: ERR_SHUTDOWN
[21:28] --> abrcdbr joined #scummvm.
[21:30] --> GitHub190 joined #scummvm.
[21:30] <GitHub190> [scummvm] criezy pushed 1 new commit to master: https://git.io/v5DXz
[21:30] <GitHub190> scummvm/master e489e1c Thierry Crozat: README: Add some more config parameters
[21:30] GitHub190 (GitHub190@ left #scummvm.
[21:37] <-- ny00123 left irc: Quit: Leaving
[21:41] <-- waltervn_ left irc: Quit: Leaving
[21:43] <snover> tsoliman: youll just notice by way of experiencing audio drop-outs. im unaware of any way to get such information out of SDL and SDL is responsible for the calls to fill the buffer.
[21:43] Nick change: Storm-AFK -> Stormkeeper
[21:46] <wjp> does anyone see a reason why director and sludge do a whole SearchMan dance in fallbackDetect() instead of just opening the file directly using its FSNode *file?
[21:48] <wjp> or maybe I should just remove it and ask if anyone can test the result
[21:48] <snover> director, no, i dont
[21:49] <snover> sludge& oh, its doing the same thing. so also no.
[21:50] <snover> all i could think of would be related to the default addition of the cwd but IIRC the added directory would have a higher priority and its looking for a filename that is already known to be in the added directory
[21:51] <wjp> and as you mentioned before, you don't really want to look in the cwd for detection
[21:51] <wjp> (especially in these cases)
[21:58] <criezy> Is it me of is the JOY_ANALOG defined not handled properly.
[21:58] <criezy> Apparently it is not set by configure but is set in the code itself in backends/events/sdl/sdl-events.cpp (when not on symbian) and in backends/events/psp2sdl/psp2sdl-events.cpp.
[21:58] <criezy> And if thats the case I dont see how it can be defined when tested in backends/platform/sdl/sdl.cpp.
[21:58] <criezy> Also in sdl-events.cpp it is actually checked (for the math.h include) before being set :/
[21:58] <criezy> Hopefully that means this math.h include is not needed.
[21:59] <-- m_kiewitz left irc: Quit: technology isn't intrinsically good or evil. It's how it's used. Like the Death Ray.
[21:59] <wjp> that does seem highly suspicious
[22:01] <mankeli> mal: i remember that sdl port for harmattan was also rather bad (ie. didn't gave those rotation events etc)
[22:03] <mankeli> it might be also that the display memory layout is always the same, and sdl accesses it so low level that you would have to implement the rotation yourself
[22:03] <wjp> criezy: all those JOY_* defines are rather suspicious in fact
[22:03] <wjp> seems like a case of the gph and psp2sdl backends copy-pasting code without quite realizing its impact
[22:09] <-- abrcdbr left irc: Remote host closed the connection
[22:09] <criezy> I think its too late for me to understand how that joystick code is supposed to work. I cant quite wrap up my head around it. :(
[22:13] <-- demonimin left irc: Ping timeout: 248 seconds
[22:22] <snover> wjp: did the briefly discussed plan to move things from readme to wiki to deduplicate information sound reasonable to you?
[22:24] <snover> im going to work on criezy and bgKs feedback to my SDL PRs first so theres some time to think about it
[22:24] --> demonimin joined #scummvm.
[22:24] <-- demonimin left irc: Changing host
[22:24] --> demonimin joined #scummvm.
[22:24] <wjp> which plan was that?
[22:25] <snover> basically just to review and move any information from README to the wiki that isnt already in the wiki, and then remove everything but the quick-start information the README and replace it with a link to the wiki, so were not trying to keep information in sync in multiple places
[22:26] <wjp> hm, that's a rather big change
[22:26] <wjp> I guess nowadays webpages are more likely to be read than a README, but still
[22:28] <snover> its such a large file at this point i doubt even people that think of reading it end up reading it
[22:29] <snover> the TL;DR effect is pretty powerful these days.
[22:32] <snover> maybe there is some better other option. in any case its not something i am going to look at for at least a week, so theres not much urgency about it.
[22:32] <wjp> there's this eternal Manual help request on the wiki front page too
[22:34] <snover> heh. yeah. trying to improve the new user experience with things like that is something on my backlog list.
[22:35] <snover> since that GSoC applicant didnt get very far, that was the end of my thinking about it for a while now.
[22:36] <wjp> I wonder if a not-too-ambitious approach to this would be doable quickly
[22:36] <wjp> polish up the user manual, move the README contents in there
[22:38] <snover> it seems to have more information in it than the big warning boxes imply
[22:38] <wjp> however, it's way past my bedtime
[22:38] <wjp> so good night
[22:38] <snover> good night :)
[22:44] <logix> snover: I'm not sure if this is a better option, but an alternative would be to generate both README and wiki from the same source (in markdown or something)
[22:45] <logix> it might be tricky do have that handle formatting in a way that looks at least half-way decent, I don't know...
[22:45] <logix> s/do/to/
[22:46] <snover> logix: yeah, i had some thought about that too, but im not sure what would be the long-term positive of something like that
[22:46] <logix> also, even if it doesn't count for much, I'll just add that I like having relevant info in README
[22:46] <snover> what information is relevant though?
[22:46] --> dreammaster joined #scummvm.
[22:46] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[22:48] <logix> this is not the best example, but something like the various mouse modes in the mobile versions (ios/android/ds/...) comes to mind - although I suppose that when I think of looking at README, I'm picturing me on my laptop without internet access somewhere
[22:49] <logix> I assume I'd google all questions I have regarding mobile versions
[22:49] <snover> i can appreciate wanting access to documentation without internet access
[22:50] <logix> that actually happened with something related to mouse modes - I had a short "d'oh" moment when I realized that my google search came up with essentially an online version of README :)
[22:52] <criezy> I looked at wiki extensions in the past that could be used to generate pdf, but none was practical. Things have probably progressed thougth,
[22:52] <criezy> I should probably take a look at https://www.mediawiki.org/wiki/Extension:Collection for example.
[22:53] <snover> my mind was being broken by not immediately finding a standard way to export mediawiki to static html
[22:55] <snover> it seems really weird to me that this would not be a built-in part, given how wikipedia is frequently talked about as being critically important to learning in developing countries
[22:58] <snover> i guess the solution is just use wget
[23:01] <criezy> Or use something like https://github.com/openzim/mwoffliner
[23:03] <snover> that projects issues list does not fill me with confidence
[23:05] <snover> from issue #2: This would avoid the requirement to have the remote wiki to have visual editor installed.
[23:05] <logix> what doesn't fill me with confidence is that a wget clone that only works on wikis (yes, yes, I'm exaggerating and simplifying at the same time...) requires node.js
[23:05] <snover> that too.
[23:06] --> GitHub4 joined #scummvm.
[23:06] <GitHub4> [scummvm] dreammaster closed pull request #1013: IMAGE: Support rendering Indeo videos at 15bpp (master...15bit-indeo) https://git.io/v52le
[23:06] GitHub4 (GitHub4@ left #scummvm.
[23:06] --> GitHub177 joined #scummvm.
[23:06] <GitHub177> [scummvm] dreammaster pushed 2 new commits to master: https://git.io/v5DQQ
[23:06] <GitHub177> scummvm/master 7846d09 Cameron Cawley: IMAGE: Support rendering Indeo videos at 15bpp
[23:06] <GitHub177> scummvm/master 2b745ac Paul Gilbert: Merge pull request #1013 from ccawley2011/15bit-indeo...
[23:06] GitHub177 (GitHub177@ left #scummvm.
[23:07] <snover> i mean, oh well. there are options.
[23:07] <criezy> This one then: https://www.mediawiki.org/wiki/Extension:DumpHTML
[23:07] <criezy> DumpHTML required a lot of work and is permanently broken since August 2008 < I am sure this is boosting your confidence level :P
[23:07] <snover> yeah, that was the page that broke my mind
[23:07] <-- DJWillis left irc: Read error: Connection reset by peer
[23:09] <snover> ideally there is enough information and feedback in the main UI that most users dont actually need documentation but were a ways away from that.
[23:38] <-- Mia left irc: Ping timeout: 248 seconds
[23:47] --> rrebello_ joined #scummvm.
[23:48] <-- dos1 left irc: Ping timeout: 240 seconds
[23:48] <-- rrebello left irc: Ping timeout: 240 seconds
[23:48] <-- enthusi left irc: Ping timeout: 240 seconds
[23:48] --> enthusi joined #scummvm.
[23:48] --> dos1 joined #scummvm.
[23:49] <-- dos1 left irc: Changing host
[23:49] --> dos1 joined #scummvm.
[23:51] --> Mia joined #scummvm.
[23:51] <-- Mia left irc: Changing host
[23:51] --> Mia joined #scummvm.
[23:55] <-- criezy left irc: Quit: criezy
[00:00] --- Wed Sep 13 2017