ScummVM IRC Log - 23 Jun 2016

[Back to Index]

[00:54] <-- Gentle left irc: Ping timeout: 258 seconds
[00:54] <-- SylvainTV left irc: Read error: Connection reset by peer
[00:54] <-- bgK left irc: Ping timeout: 272 seconds
[01:01] --> Gentle joined #scummvm.
[01:04] --> bgK joined #scummvm.
[01:04] #scummvm: mode change '+o bgK' by ChanServ!ChanServ@services.
[01:04] --> Strangerke_ joined #scummvm.
[01:05] --> DominusExult joined #scummvm.
[01:06] <-- Strangerke left irc: Ping timeout: 244 seconds
[01:06] Nick change: Strangerke_ -> Strangerke
[01:10] <-- Dominus left irc: Ping timeout: 272 seconds
[01:10] Nick change: DominusExult -> Dominus
[01:35] <-- salty-horse left irc: Quit: Leaving
[01:50] <-- abruanese left irc: Quit: ZNC 1.6.3+deb1 - http://znc.in
[02:30] <-- snover left irc: Quit: Leaving.

[02:35] --> gsivori joined #scummvm.
[02:48] --> GitHub179 joined #scummvm.
[02:48] <GitHub179> [scummvm-sites] alexbevi created gamesdb (+1 new commit): https://git.io/voX7Z
[02:48] <GitHub179> scummvm-sites/gamesdb bc3d9f5 Alex Bevilacqua: BASE: migrate code to scummvm-sites repository
[02:48] GitHub179 (GitHub179@192.30.252.34) left #scummvm.
[02:50] --> GitHub20 joined #scummvm.
[02:50] <GitHub20> [scummvm-sites] alexbevi force-pushed gamesdb from bc3d9f5 to f4cea19: https://git.io/voX7R
[02:50] <GitHub20> scummvm-sites/gamesdb f4cea19 Alex Bevilacqua: GAMESDB: migrate code to scummvm-sites repository
[02:50] GitHub20 (GitHub20@192.30.252.40) left #scummvm.
[02:57] --> GitHub85 joined #scummvm.
[02:57] <GitHub85> [scummvm-sites] alexbevi pushed 1 new commit to gamesdb: https://git.io/voX7h
[02:57] <GitHub85> scummvm-sites/gamesdb ce2a88d Alex Bevilacqua: GAMESDB: stub out readme
[02:57] GitHub85 (GitHub85@192.30.252.41) left #scummvm.
[03:31] <-- gsivori left irc: Quit: Leaving
[04:04] <-- Cruel` left irc: Ping timeout: 244 seconds
[04:14] <-- Axy left irc: Read error: Connection reset by peer
[05:03] <-- jammm left irc: Read error: Connection reset by peer
[05:03] --> jamm joined #scummvm.
[05:25] <-- Strangerke left irc: Ping timeout: 272 seconds
[05:36] --> uruk-hai joined #scummvm.
[05:36] #scummvm: mode change '+o uruk-hai' by ChanServ!ChanServ@services.
[05:51] --> _sev|work joined #scummvm.
[05:51] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[05:55] --> t0by joined #scummvm.
[05:55] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services.
[06:09] <-- DJWillis left irc: Read error: Connection reset by peer
[06:09] --> DJWillis joined #scummvm.
[06:09] #scummvm: mode change '+o DJWillis' by ChanServ!ChanServ@services.
[06:21] <-- _sev|work left irc: Quit: This computer has gone to sleep
[06:29] --> wanwan joined #scummvm.
[06:30] <-- t0by left irc: Ping timeout: 244 seconds
[06:36] --> girafe joined #scummvm.
[06:59] --> Strangerke|work joined #scummvm.
[06:59] <Strangerke|work> hi guys
[07:10] <rootfather> hello there Stranger
[07:12] <Strangerke|work> what's up dude? :)
[07:16] --> t0by joined #scummvm.
[07:16] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services.
[07:28] <rootfather> struggeling with the perfect organisation of the Homescreen of my new smartphone
[07:29] --> NuSuey joined #scummvm.
[07:29] --> m_kiewitz joined #scummvm.
[07:29] #scummvm: mode change '+o m_kiewitz' by ChanServ!ChanServ@services.
[07:37] <Harekiet> remove all apps and it's perfect
[07:47] <-- uruk-hai left irc: Quit: Leaving
[07:48] <Strangerke|work> shut it down and it's perfect
[07:54] <Harekiet> fling it all the wall and it's perfect?
[07:56] <rootfather> lol guys :D
[07:57] <-- gus left irc: Ping timeout: 250 seconds
[07:57] --> gus joined #scummvm.
[08:11] --> uruk-hai joined #scummvm.
[08:11] #scummvm: mode change '+o uruk-hai' by ChanServ!ChanServ@services.
[08:21] <-- uruk-hai left irc: Quit: This computer has gone to sleep
[08:22] --> uruk-hai joined #scummvm.
[08:22] #scummvm: mode change '+o uruk-hai' by ChanServ!ChanServ@services.
[08:38] <-- girafe left irc: Read error: Connection reset by peer
[08:53] --> _sev|work joined #scummvm.
[08:53] <-- _sev|work left irc: Changing host
[08:53] --> _sev|work joined #scummvm.
[08:53] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[08:54] --> TMM joined #scummvm.
[09:26] <-- Lightkey left irc: Ping timeout: 272 seconds
[09:39] --> Lightkey joined #scummvm.
[10:21] <-- _sev|work left irc: Quit: This computer has gone to sleep
[10:42] <-- uruk-hai left irc: Quit: This computer has gone to sleep
[10:44] --> uruk-hai joined #scummvm.
[10:44] #scummvm: mode change '+o uruk-hai' by ChanServ!ChanServ@services.
[11:13] <-- t0by left irc: Ping timeout: 244 seconds
[11:32] --> Mia joined #scummvm.
[11:42] --> snover joined #scummvm.
[11:42] #scummvm: mode change '+o snover' by ChanServ!ChanServ@services.
[11:58] --> blorente joined #scummvm.
[11:58] #scummvm: mode change '+v blorente' by ChanServ!ChanServ@services.
[12:30] --> t0by joined #scummvm.
[12:30] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services.
[12:45] --> _sev|work joined #scummvm.
[12:45] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[12:46] <-- _sev|work left irc: Client Quit
[12:50] --> Henke37 joined #scummvm.
[13:04] --> jammm joined #scummvm.
[13:06] <-- jamm left irc: Read error: Connection reset by peer
[13:13] --> Littleboy joined #scummvm.
[13:13] #scummvm: mode change '+o Littleboy' by ChanServ!ChanServ@services.
[13:19] <-- Littleboy left irc: Read error: Connection reset by peer
[13:19] --> Littleboy joined #scummvm.
[13:19] #scummvm: mode change '+o Littleboy' by ChanServ!ChanServ@services.
[13:26] <-- snover left irc: Quit: Leaving.
[13:33] <-- t0by left irc: Ping timeout: 240 seconds
[13:35] --> heroux_ joined #scummvm.
[13:35] <-- heroux left irc: Read error: Connection reset by peer
[13:36] Nick change: heroux_ -> heroux
[13:41] <-- jammm left irc: Quit: Leaving
[13:41] --> jamm joined #scummvm.
[14:01] <m_kiewitz> OH MY GOD
[14:01] <m_kiewitz> http://www.aliexpress.com/wholesale?catId=0&initiative_id=SB_20160623051927&SearchText=monkey+island+pillowcase
[14:03] <Strangerke|work> nice! :)
[14:11] <Henke37> I bet that those aren't official
[14:13] --> heroux_ joined #scummvm.
[14:15] <Strangerke|work> me too
[14:15] <-- heroux left irc: Ping timeout: 244 seconds
[14:15] Nick change: heroux_ -> heroux
[14:31] --> t0by joined #scummvm.
[14:31] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services.
[14:33] --> abruanese joined #scummvm.
[15:00] <-- t0by left irc: Ping timeout: 260 seconds
[15:03] <-- Strangerke|work left irc: Quit: Bbl
[15:39] --> Cruel` joined #scummvm.
[15:44] --> exhpqv joined #scummvm.
[15:48] --> ny00123 joined #scummvm.
[15:56] <-- uruk-hai left irc: Quit: This computer has gone to sleep
[15:56] --> uruk-hai joined #scummvm.
[15:56] #scummvm: mode change '+o uruk-hai' by ChanServ!ChanServ@services.
[15:56] <-- jamm left irc: Read error: Connection reset by peer
[15:57] --> jamm joined #scummvm.
[16:33] --> SylvainTV joined #scummvm.
[16:33] #scummvm: mode change '+o SylvainTV' by ChanServ!ChanServ@services.
[16:38] <-- blorente left irc: Quit: http://www.kiwiirc.com/ - A hand crafted IRC client
[16:42] <-- Henke37 left irc: Read error: Connection reset by peer
[16:42] --> WooShell joined #scummvm.
[16:52] <-- Gentle left irc: Ping timeout: 276 seconds
[16:53] <-- NuSuey left irc: Quit: Connection closed for inactivity
[16:54] --> Gentle joined #scummvm.
[16:56] --> p1r473 joined #scummvm.
[16:57] --> NuSuey joined #scummvm.
[17:01] <-- uruk-hai left irc: Quit: This computer has gone to sleep
[17:12] <-- TMM left irc: Quit: Ex-Chat
[17:12] --> snover joined #scummvm.
[17:12] #scummvm: mode change '+o snover' by ChanServ!ChanServ@services.
[17:15] --> Henke37 joined #scummvm.
[17:44] --> Strangerke joined #scummvm.
[17:49] --> waltervn joined #scummvm.
[17:49] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services.
[18:01] --> criezy joined #scummvm.
[18:01] #scummvm: mode change '+o criezy' by ChanServ!ChanServ@services.
[18:05] --> uruk-hai joined #scummvm.
[18:05] #scummvm: mode change '+o uruk-hai' by ChanServ!ChanServ@services.
[18:06] <-- snover left irc: Quit: Leaving.
[18:17] --> GitHub67 joined #scummvm.
[18:17] <GitHub67> [scummvm] bluegr pushed 3 new commits to master: https://git.io/voMXg
[18:17] <GitHub67> scummvm/master 97c50fc Filippos Karapetis: SCI32: Const correction in Audio32's readBuffer() implementation
[18:17] <GitHub67> scummvm/master e80f1bb Filippos Karapetis: SCI32: Fix potentially uninitialized variable
[18:17] <GitHub67> scummvm/master 1798350 Filippos Karapetis: SCI32: Fix usage of the C++11 override keyword with MSVC...
[18:17] GitHub67 (GitHub67@192.30.252.42) left #scummvm.
[18:23] [md5] --> (~md5@unaffiliated/md5/x-729473) joined #scummvm.
[18:23] #scummvm: mode change '+o [md5]' by ChanServ!ChanServ@services.
[18:33] <ScummBot> Port build status changed with 17983508: Success: master-mingw-w64-cplusplus11. Nice work, all ports built fine now
[18:50] <-- waltervn left irc: Quit: Leaving
[18:57] <-- criezy left irc: Ping timeout: 272 seconds
[18:57] --> criezy_ joined #scummvm.
[18:57] #scummvm: mode change '+o criezy_' by ChanServ!ChanServ@services.
[18:58] --> GitHub50 joined #scummvm.
[18:58] <GitHub50> [scummvm] bluegr pushed 1 new commit to master: https://git.io/voM9R
[18:58] <GitHub50> scummvm/master 5eaea05 Filippos Karapetis: SCI32: Properly initialize AudioChannel inside Audio32::play()...
[18:58] GitHub50 (GitHub50@192.30.252.42) left #scummvm.
[18:59] --> waltervn joined #scummvm.
[18:59] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services.
[19:13] <-- NuSuey left irc: Quit: Connection closed for inactivity
[19:21] --> NuSuey joined #scummvm.
[19:25] --> uruk_hai joined #scummvm.
[19:25] #scummvm: mode change '+o uruk_hai' by ChanServ!ChanServ@services.
[19:25] <-- uruk_hai left irc: Client Quit
[19:39] <m_kiewitz> does anyone have Space Quest 1 VGA saves for the original interpreter?
[19:40] <m_kiewitz> there is some spider droid issue, but it seems it doesn't happen for every room (it seems to also depend on in which room the droid landed)
[19:47] --> snover joined #scummvm.
[19:47] #scummvm: mode change '+o snover' by ChanServ!ChanServ@services.
[19:50] --> Strangerke_ joined #scummvm.
[19:52] <-- Strangerke left irc: Ping timeout: 244 seconds
[19:52] Nick change: Strangerke_ -> Strangerke
[19:56] <[md5]> snover: bitmap handles in SCI32 should get a special treatment
[19:57] <[md5]> like arrays and strings
[19:58] <-- uruk-hai left irc: Read error: Connection reset by peer
[19:58] <[md5]> currently, bitmap handles are using hunk memory
[19:58] <[md5]> which is supposed to be volatile
[19:58] <[md5]> e.g. screen contents
[19:58] <[md5]> and is not saved or loaded
[19:59] <[md5]> the original interpreter has a different kind of memory for bitmaps
[19:59] <[md5]> so, at the moment, bitmaps are not preserved when saving
[19:59] <[md5]> and the interpreter bombs out when loading a game
[19:59] <[md5]> in SCI32
[20:00] <[md5]> we could either reinitialize scene bitmaps when loading
[20:00] <[md5]> or store them in a different memory segment
[20:05] --> TMM joined #scummvm.
[20:08] <snover> where are bitmaps being stored to savegame in sci32?
[20:08] <[md5]> nowhere
[20:08] <[md5]> at the moment
[20:08] <snover> will they ever be?
[20:09] <[md5]> well, I can't find any way of recreating them when loading a game
[20:09] <[md5]> but, I think I found a way, which doesn't require any major changes
[20:09] <[md5]> just a minute
[20:09] <snover> seems like a bridge worth crossing once there is actually something trying to save bitmaps?
[20:10] <snover> i dont know why the code would be changed to support something that is never done
[20:11] <[md5]> well, it is being done now
[20:11] <[md5]> hm
[20:11] <snover> where?
[20:11] <[md5]> the text scroll code
[20:11] <snover> i just asked and you just said that they werent&
[20:11] <[md5]> no, I said that currently the engine does not save the bitmap information
[20:11] <-- p1r473 left irc:
[20:12] <[md5]> in saved games
[20:12] <snover> scrollwindows arent returning bitmaps to the VM, this was something discussed back when wjp was working on it
[20:12] <snover> it returns integers
[20:13] <[md5]> there are screen items with text
[20:13] <[md5]> which is where this code is triggered
[20:14] <snover> screen items arent common::serializable
[20:14] <[md5]> scummvm.exe!Sci::BitmapResource::BitmapResource(Sci::reg_t bitmap) Line 109 C++
[20:14] <[md5]> scummvm.exe!Sci::CelObjMem::CelObjMem(const Sci::reg_t bitmapObject) Line 1014 C++
[20:14] <[md5]> scummvm.exe!Sci::ScreenItem::getCelObj() Line 432 C++
[20:14] <[md5]> > scummvm.exe!Sci::ScreenItem::calcRects(const Sci::Plane & plane) Line 241 C++
[20:14] <[md5]> scummvm.exe!Sci::Plane::redrawAll(Sci::Plane * visiblePlane, const Sci::PlaneList & planeList, Sci::DrawList & drawList, Sci::RectList & eraseList) Line 683 C++
[20:15] <[md5]> so it does:
[20:15] <[md5]> _bitmap(g_sci->getEngineState()->_segMan->getHunkPointer(bitmap))
[20:15] <[md5]> and it bombs out
[20:15] <snover> oh, so this is about the vm garbage collecting bitmap handles because it thinks they are unused
[20:15] <snover> ok
[20:16] <[md5]> pretty much, yeah
[20:16] <[md5]> but
[20:16] <[md5]> hunk pointers are not saved
[20:16] <[md5]> so this returns nothing
[20:17] <m_kiewitz> uh oh some issues in SQ1 may have been caused by fan-patches :/
[20:18] <[md5]> which ones?
[20:18] <snover> so, GfxControls32::listObjectReferences is supposed to make this not be a problem for ScrollWindow
[20:18] <[md5]> I thought we blacklisted all the NRS patches
[20:19] <[md5]> snover: no, we should not be using hunk memory for these at all
[20:19] <[md5]> savegame.cpp:442:
[20:19] <[md5]> void HunkTable::saveLoadWithSerializer(Common::Serializer &s) {
[20:19] <[md5]> // Do nothing, hunk tables are not actually saved nor loaded.
[20:19] <[md5]> }
[20:20] <snover> yes, thats true, all the bitmaps that i am aware of are transient
[20:20] <m_kiewitz> [md5]: spider droid stuff
[20:20] <[md5]> m_kiewitz: is there a patch for that? We blacklist the NRS patch for SQ1
[20:20] <m_kiewitz> [md5]: you blacklisted them?
[20:21] <[md5]> um... years ago? :P
[20:21] <m_kiewitz> need to ask the bug reporter about it
[20:21] <m_kiewitz> yeah well i think some were missing? idk
[20:21] <[md5]> there's a big warning when the games start
[20:21] <m_kiewitz> QfG3 was fan-patched to hell too and that one isn't blacklisted
[20:21] <[md5]> and a fan patch is used
[20:21] <[md5]> oh
[20:21] <[md5]> hm
[20:21] <m_kiewitz> warning? so the user can still continue?
[20:21] <[md5]> yeah
[20:21] <m_kiewitz> qfg3 patches can't be blacklisted anymore, because that would break saved game compatibility
[20:22] <[md5]> how so?
[20:22] <m_kiewitz> well, someone thought he was super smart and literally recompiled the scripts
[20:22] <m_kiewitz> so all the offsets are different
[20:22] <[md5]> O_o
[20:22] <[md5]> aha
[20:22] <m_kiewitz> and we save offsets of all sorts of things
[20:22] <[md5]> that's... odd
[20:22] <m_kiewitz> well, i want to change the saved game code, so that this wouldn't matter anymore
[20:23] <m_kiewitz> wjp and I gave up after some point trying to patch the mess
[20:23] <m_kiewitz> there are all sorts of new issues and the only proper solution would be: "delete the fan patches"
[20:23] <[md5]> the check is in sci.cpp:407
[20:23] <[md5]> gameHasFanMadePatch()
[20:23] <[md5]> and it pretty much does this:
[20:23] <[md5]> showScummVMDialog("Your game is patched with a fan made script patch. Such patches have "
[20:23] <[md5]> "been reported to cause issues, as they modify game scripts extensively. "
[20:23] <[md5]> "The issues that these patches fix do not occur in ScummVM, so you are "
[20:23] <[md5]> "advised to remove this patch from your game folder in order to avoid "
[20:23] <[md5]> "having unexpected errors and/or issues later on.");
[20:23] <m_kiewitz> the bug reporter says for example the droid doesn't explode when touching ego
[20:23] <m_kiewitz> and that doesn't happen for me at all
[20:24] <m_kiewitz> and im pretty sure the fan patches said all sorts of things of patching the droid in all sorts of ways
[20:24] <[md5]> do you remember that other guy who tried to patch the Spanish version of LSL1 with the English patch? He broke the whole game. Fun times...
[20:24] <m_kiewitz> well, i hope the guy replies, so that i know which patches he used
[20:24] <m_kiewitz> yeah thats another problem
[20:25] <m_kiewitz> although i think there is no solution for that one
[20:25] <snover> [md5]: can you tell me how to reproduce this bug with the bitmaps?
[20:25] <[md5]> snover: start SQ6, save, exit, load
[20:25] <-- exhpqv left irc: Ping timeout: 276 seconds
[20:26] <m_kiewitz> [md5] lol
[20:26] <snover> [md5]: i did that and it didnt crash. are you using the original save/load dialogues?
[20:27] abruanese (~a@c-67-190-234-214.hsd1.fl.comcast.net) got netsplit.
[20:27] kurtwr (~kurtwr@c-73-12-209-100.hsd1.ca.comcast.net) got netsplit.
[20:27] fydo_ (~fydo@li337-251.members.linode.com) got netsplit.
[20:27] bouncy (~BouncingB@2001:630:206:16:95b2:7bd1:d75d:7d60) got netsplit.
[20:27] wjp_ (~wjp@hmm.wantstofly.org) got netsplit.
[20:27] Tomaz^W (~tompsson@84.216.7.40) got netsplit.
[20:27] wysiwtf (arvenius@whatyouseeis.wtf) got netsplit.
[20:27] snow_bckspc (~snow_bcks@ganon.dot-server.net) got netsplit.
[20:27] [vEX] (~vex@h95n22-spaa-a12.ias.bredband.telia.com) got netsplit.
[20:27] skymandr (~skymandr@h-5-150-255-103.na.cust.bahnhof.se) got netsplit.
[20:27] <snover> uh-oh
[20:27] Tomaz^W (~tompsson@84.216.7.40) returned to #scummvm.
[20:27] kurtwr (~kurtwr@c-73-12-209-100.hsd1.ca.comcast.net) returned to #scummvm.
[20:27] fydo_ (~fydo@li337-251.members.linode.com) returned to #scummvm.
[20:27] --> wjp joined #scummvm.
[20:27] [vEX] (~vex@h95n22-spaa-a12.ias.bredband.telia.com) returned to #scummvm.
[20:27] abruanese (~a@c-67-190-234-214.hsd1.fl.comcast.net) returned to #scummvm.
[20:28] <snover> [md5]: i did that and it didnt crash. are you using the original save/load dialogues?
[20:28] snow_bckspc (~snow_bcks@ganon.dot-server.net) returned to #scummvm.
[20:29] <snover> i doubt the scummvm save/load will work at all correctly right now
[20:29] <[md5]> hm
[20:29] Action: [md5] tries
[20:29] <snover> or ever, i think i suggested in the past to disable scummvm save/load forever
[20:29] <snover> because each game is a unique snowflake
[20:29] #scummvm: mode change '+o wjp' by ChanServ!ChanServ@services.
[20:29] <m_kiewitz> snover: did you also try closing ScummVM and loading the save afterwards?
[20:30] --> bouncy joined #scummvm.
[20:30] wysiwtf (arvenius@whatyouseeis.wtf) returned to #scummvm.
[20:30] <m_kiewitz> hunk memory shouldn't be restored in any case, it doesn't depend on ScummVM dialogs or not
[20:30] <m_kiewitz> and the dialogs worked properly, at least last time i implemented them
[20:31] <[md5]> snover: ScummVM save/load dialogs have nothing to do with the way that bitmaps are stored
[20:31] <snover> yes, i closed scummvm
[20:32] <m_kiewitz> [md5] does original SCI32 save bitmaps?
[20:32] --> girafe joined #scummvm.
[20:33] <snover> loading the save game turns palette into a hot mess for some reason but it doesnt crash
[20:34] <-- ny00123 left irc: Quit: Leaving
[20:34] <snover> i have CLASSES turned on, so i start the game, go to Polysorbate liquor store, talk to the dude at the counter, save game, quit, restart, go to prologue, choose to restore a game, load game
[20:34] <snover> using original save/load
[20:34] <[md5]> I get the same crash with the original save/load
[20:35] <snover> sq6 clears the scrollwindow prior to saving
[20:35] <snover> as far as i can tell
[20:38] skymandr (~skymandr@h-5-150-255-103.na.cust.bahnhof.se) got lost in the net-split.
[20:38] wjp_ (~wjp@hmm.wantstofly.org) got lost in the net-split.
[20:40] <m_kiewitz> maybe you are both saving in different locations?
[20:41] <[md5]> I'm just saving in the first screen
[20:41] <[md5]> without the game's debugger
[20:44] <snover> the transporter scene?
[20:48] <snover> I run through the transporter scene and get a halt with a use-after-free bug pointing to ResourceManager&
[20:50] <snover> what an odd bug&
[20:52] <snover> looks like a race condition between threads in the audio mixer, but the mutex should be protecting against that, unless I did something horribly wrong (which is definitely a possibility!)
[20:56] <snover> audio32 unlocks the audio resource for a finished audio channel, the resource manager tries to put the audio resource into the LRU list, Common::List::insert tries to read a member off the `pos` pointer, but the address pointed to by `pos` was freed when a pic resource was requested
[20:57] <snover> i suppose ResourceManager is not actually thread safe&hm.
[20:58] <snover> so i guess i cant try to free resources from when the audio buffer is being filled&
[20:58] <m_kiewitz> it took ages until wjp made the audio code fully thread safe
[21:00] <snover> well, the audio code *is* thread-safe& :)
[21:03] <[md5]> the audio code itself is
[21:03] <[md5]> the rest isn't :P
[21:04] --> jammm joined #scummvm.
[21:06] <snover> well, now i know whats going on here, and knowing is half the battle. well see if i can make this part of resourcemanager threadsafe or if i will just need to move freeUnusedChannels to somewhere else
[21:07] <-- jamm left irc: Ping timeout: 246 seconds
[21:12] <wjp> by the way, the recompilation of qfg3 scripts didn't just change the offsets, it even changed all opcodes from their 8 bit immediate to their 16 bit immediate form
[21:12] <wjp> (which kind of made things at least safer, because there's no chance at all of our patches accidentally matching despite changed other code...)
[21:12] <wjp> and I'm not sure if I made the audio code fully thread safe
[21:18] <[md5]> changing the bitmap code to use dynamic instead of hunk memory fixes all the issues for me
[21:18] <[md5]> (dynmem is saved during save/load)
[21:19] <wjp> which bitmaps should be saved?
[21:20] <[md5]> the ones used by CelObjMem, by the looks of it
[21:20] <[md5]> which is odd
[21:20] <snover> celobjs arent serializable
[21:20] <[md5]> I gave a stack trace further up
[21:21] <snover> maybe bitmaps from kBitmap&
[21:21] <[md5]> snover: your messages show up with a weird character in the end
[21:21] <snover> turn on utf-8 in your irc client
[21:22] <[md5]> it is on
[21:22] <wjp> (I see the ellipsis normally)
[21:23] --> Axy joined #scummvm.
[21:23] <[md5]> it's shown as a black box here (utf8 decoding error)
[21:23] <[md5]> anyway
[21:24] <snover> very odd.
[21:24] <-- Mia left irc: Ping timeout: 240 seconds
[21:25] <wjp> for ScrollWindow, the GC interaction for bitmaps is via GfxControls32::listObjectReferences()
[21:26] <wjp> are there any other bitmaps with handles floating around we don't register yet?
[21:26] <[md5]> the issue here is that bitmaps are stored in memory that is not preserved in saved games (hunk memory)
[21:27] <[md5]> so, that is not an issue of the GC itself, I think
[21:27] <wjp> which bitmaps?
[21:27] <snover> you keep saying that, but have you identified what these bitmaps are?
[21:27] <wjp> since I'm not immediately aware of any bitmaps that expect to be saved
[21:27] <[md5]> I believe that it's the bitmaps related to the control window
[21:27] <[md5]> let me check
[21:28] <snover> returns from kBitmapCreate, kAddLine (GfxPaint32::makeLineBitmap), and kCreateTextBitmap (GfxText32::createFontBitmap)
[21:30] <snover> kEditText uses a bitmap internally
[21:30] <snover> in the hunk area
[21:30] <[md5]> but it destroys it
[21:30] <[md5]> that's used in the original save/load dialog
[21:30] <[md5]> (well, save dialog)
[21:31] <wjp> does kEditText run scripts internally?
[21:32] <snover> nope, it actually has its own event loop
[21:32] <wjp> yeah, but via selector callbacks or anything?
[21:32] <snover> hm.
[21:32] <wjp> but I don't see any at first glance
[21:33] <snover> it only reads selectors, but i dont know much about the vm
[21:33] <wjp> you'd have to call them explicitly
[21:34] <snover> in that case, no, i am not doing that
[21:34] <snover> er. *it is* not doing that.
[21:34] <wjp> (for instance kAnimate calls the "doit" method of objects it processes)
[21:34] <snover> fun!
[21:34] <wjp> loads :-)
[21:34] <snover> definitely none of that. minimal shenanigans!
[21:35] <wjp> quite a bit of infrastructure in the debugger/vm for supporting running the VM inside a kernel function running in the VM
[21:37] <[md5]> here's the patch, btw:
[21:37] <[md5]> http://pastie.org/private/4gfkxdvnhzsjleoxkqbdw
[21:37] <wjp> but bitmaps still shouldn't have to be saved
[21:38] <wjp> (AFAIK)
[21:38] <snover> im more disturbed by the fact that i cant seem to reproduce the problem here
[21:39] <snover> it may be that bitmaps generated via kBitmap need to be persistent
[21:39] <snover> but without having reproducibility on the bug its really hard to say
[21:42] <wjp> is that the liquor store recipe snover gave an hour ago?
[21:43] <[md5]> it happens in the very first screen
[21:43] <[md5]> there's a text in plane 000f:0002 (the game screen)
[21:44] <wjp> very first screen is?
[21:44] <snover> street #3
[21:44] <[md5]> name is DText, address is 000f:0450
[21:44] <wjp> what do you do with the intro?
[21:44] <snover> its probably the cinema marquee
[21:44] <[md5]> I skip the intro
[21:44] <[md5]> I just start the game, skip the intro, wait till all the blah blah ends and save the game
[21:45] <snover> yeah its the cinema marquee.
[21:45] <[md5]> ah
[21:45] <snover> i can reproduce now.
[21:45] <[md5]> most probably
[21:45] <[md5]> so that gets created on startup
[21:46] <[md5]> so, that kind of bitmap should be saved
[21:46] <[md5]> therefore, keeping it in dynmem makes sense, no?
[21:46] <snover> (1) Load Street #3 (2) Save game (3) Load game. Expected: Works! Actual: Invalid Text bitmap <selector>
[21:47] <[md5]> yeah, it's the marquee in the top left
[21:48] <snover> I feel like perhaps the best approach here is probably to add a 'persist' flag to the GfxText32::createFontBitmap that puts the bitmap into dynmem if it is true, and then make sure it is true for the kernel calls that make and return bitmaps.
[21:49] <snover> so, kBitmapCreate, kCreateTextBitmap, and& i think theres a third one
[21:49] <[md5]> well, that would be all the calls?
[21:49] <snover> no, not even close
[21:49] <[md5]> ?
[21:49] <[md5]> I don't see why we should add a flag, when we can store them all?
[21:50] <snover> because thats a waste of resources and not all bitmaps need to persist?
[21:51] <[md5]> we're talking about bytes here...
[21:51] <m_kiewitz> what's the original interpreter doing?
[21:51] <m_kiewitz> if it saves all of those bitmaps, we should do the same
[21:52] <m_kiewitz> otherwise i'm pretty sure that at some point some unexpected bitmap is expected to be saved
[21:52] <[md5]> the original interpreter seems to save all bitmaps in a separate kind of memory
[21:52] <m_kiewitz> including font bitmaps?
[21:52] <m_kiewitz> then we should do the same
[21:55] <wjp> hm, the script of DText is still confusing me a bit
[21:56] <wjp> how are (added) ScreenItems restored again after loading?
[21:58] <snover> uhh.
[21:58] <snover> good question!
[21:59] <wjp> this marquee looks like it's a DText, which does CreateTextBitmap in its draw method (which gets called in its init method which gets called in the rm340 init method)
[21:59] <wjp> DText::draw also calls kBitmapDestroy first on the old bitmap
[22:00] <-- criezy_ left irc: Quit: criezy_
[22:00] <[md5]> hm
[22:00] <[md5]> btw, the original marks specific memory types as "saveable"
[22:03] <[md5]> there's a custom call in gamestate_restore()
[22:03] <[md5]> line 1100
[22:03] <[md5]> if (getSciVersion() >= SCI_VERSION_2) {
[22:03] <[md5]> if (!s->_delayedRestoreFromLauncher) {
[22:03] <[md5]> // Only do it, when we are restoring regulary and not from launcher
[22:03] <[md5]> // As it could result in option planes etc. on the screen (happens in gk1)
[22:03] <[md5]> g_sci->_gfxFrameout->syncWithScripts(false);
[22:03] <[md5]> }
[22:03] <[md5]> }
[22:04] <[md5]> (but then again, that also happens with the original save/load dialogs)
[22:04] <snover> m_kiewitz wrote that
[22:05] <[md5]> yep
[22:05] <m_kiewitz> [md5] that's what the scripts are doing normally, we patch us into the scripts so that script code isn't executed
[22:06] <[md5]> m_kiewitz: yeah, I remember that
[22:06] <[md5]> anyway, it's not that code
[22:07] <[md5]> cause the crash also happens when I comment it out
[22:08] <wjp> right, so this does kind of start to sound like DText expects the bitmap to persist :/
[22:09] <m_kiewitz> [md5] without that code you actually could get way more issues when using GMM
[22:10] <[md5]> anyway, the solution is simple enough, IMHO
[22:22] <-- waltervn left irc: Quit: Leaving
[22:23] <snover> ok, if it needs to all be persisted then I guess that hunk usage should be changed to dynmem usage& but also it looks like the right SegManager API for this would be derefBulkPtr(bitmapObj, 0) since that already does sanity checking
[22:24] <wjp> if we want to persist them it might be nicer to add a bitmap segment?
[22:24] <-- WooShell left irc: Quit: Zu gotdy od mpy nrmy stpimf. Zu drvpmf zrsmd aogy jrt iq pt viy jrt yp yjr htpimf.
[22:24] <snover> yes, that would probably seem to make the most sense
[22:24] <wjp> that way we get automatic type checking too
[22:24] <[md5]> we could add a separate segment, yes. But in that case, it would make sense to handle all the object wrapping and unwrapping in the segment manager
[22:25] <snover> im not sure i understand
[22:26] <snover> ill be back later
[22:29] <[md5]> check how arrays are saved and loaded
[22:33] <-- NuSuey left irc: Quit: Connection closed for inactivity
[22:36] --> Deledrius_ joined #scummvm.
[22:39] <[md5]> anyway, here's the updated patch:
[22:39] <[md5]> http://pastie.org/private/tkenyaxwk5gkexf74tynya
[22:39] --> frankyboy_ joined #scummvm.
[22:40] <-- Deledrius left irc: Ping timeout: 250 seconds
[22:42] <-- fydo_ left irc: Quit: Lost terminal
[23:01] --> nealwrang joined #scummvm.
[23:08] <-- m_kiewitz left irc: Quit: technology isn't intrinsically good or evil. It's how it's used. Like the Death Ray.
[23:16] [md5] <-- (~md5@unaffiliated/md5/x-729473) left irc:
[23:34] <nealwrang> :sev how to create accoun on scummvm wiki
[23:43] --> girafe2 joined #scummvm.
[23:46] <-- girafe left irc: Ping timeout: 244 seconds
[23:59] --> Deledrius joined #scummvm.
[00:00] --- Fri Jun 24 2016