ScummVM IRC Log - 15 Nov 2017

[Back to Index]

[00:08] --> [md5]_ joined #scummvm.
[00:08] #scummvm: mode change '+o [md5]_' by ChanServ!ChanServ@services.
[00:08] [md5] <-- (~md5@unaffiliated/md5/x-729473) left irc: Disconnected by services
[00:08] Nick change: [md5]_ -> [md5]
[00:23] <-- Strangerke left irc: Ping timeout: 268 seconds
[00:33] --> Strangerke joined #scummvm.
[00:44] --> dreammaster joined #scummvm.
[00:44] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[01:00] <tsoliman> is master frozen for new features now?
[01:00] <tsoliman> (yes if we went with "with testing" right?)
[01:07] --> slipyx joined #scummvm.
[01:07] <snover> i never saw a follow-up so i am not sure. is there some feature you want to add?
[01:08] <tsoliman> no - I was wondering if I missed an announcement on what schedule was decided on
[01:12] <snover> i wish it were so
[01:15] --> ST1 joined #scummvm.
[01:15] <-- ST left irc: Disconnected by services
[01:19] <snover> mem ownership of scenes and modals in fullpipe engine is confusing af
[01:20] <snover> usually scenes are owned by a SceneTag but in one place the scene gets sent to some global and removed from SceneTag
[01:21] <snover> and not having c++11 move semantics is really annoying when trying to unravel this
[01:23] <snover> well, no move semantics and no emplace since emplace needs variadic templates for forwarding, which is also a c++11 feature
[01:25] <snover> looks like the scene where it is getting removed is intentionally removing the scene from its SceneTag and then sticks it back on there when the next scene starts
[01:26] <snover> feels like a ship it hack from the original game
[01:29] <[md5]> snover: regarding a change you made to OSystem...
[01:29] <[md5]> there's a strange crash when exiting ScummVM on Windows
[01:29] <[md5]> it's related to the changes made to the mouse code
[01:31] <[md5]> I figured out what's going on, but I'm unsure of what is causing the behavior - it's related to SDL_FreeSurface
[01:32] <snover> sigh. cant use ScopedPtr because its not copyable, cant create an alias declaration because those are c++11 only too&
[01:35] <snover> tsoliman: i hope this gives you some idea behind my struggle :)
[01:38] <tsoliman> so I quit chatzilla and now it is gone - xul is gone from firefox I think
[01:38] <snover> yes. welcome to the brave new world of firefox 57.
[01:38] <tsoliman> snover: yep - right after the next release I will experiment
[01:38] <tsoliman> I got it to compile with the cross compiler
[01:39] <tsoliman> all I had to do was put the toolchain in the path
[01:39] <snover> heh. well, that was easy.
[01:40] <[md5]> snover: ping
[01:41] <snover> id still love to get the One True ARM Cross-compiler set up so that rpi, samsungtv, and whatever else is ARM Linux with an old kernel can use the same build and get easily updated
[01:41] <snover> builder*
[01:42] slipyx (slip@to1.hashbang.sh) left #scummvm ("WeeChat 1.8").
[01:59] Action: Lightkey is still on Gecko 52.4 - yay SeaMonkey
[02:04] <snover> at least they were smart enough to get rid of australis. :) i understand the need to restrict what extensions can do in order to improve security, and it still boggles my mind that theyre willing to throw away a medium-sized citys worth of users (CTR is not supported and has ~316,000 users).
[02:05] --> GitHub8 joined #scummvm.
[02:05] <GitHub8> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vFPCU
[02:05] <GitHub8> scummvm/master 74612b4 Paul Gilbert: XEEN: Fix some Coverity warnings
[02:05] GitHub8 (GitHub8@192.30.252.40) left #scummvm.
[02:08] <-- SylvainTV left irc: Read error: Connection reset by peer
[02:12] --> GitHub30 joined #scummvm.
[02:12] <GitHub30> [scummvm] bgK opened pull request #1056: COMPOSER: Remove leading dots from file paths read from book.ini (master...perhaps-fix-gregory-fr) https://git.io/vFPCR
[02:12] GitHub30 (GitHub30@192.30.252.42) left #scummvm.
[02:16] <-- user9 left irc: Remote host closed the connection
[02:24] <-- dreammaster left irc:
[02:55] <-- Dominus left irc: Ping timeout: 260 seconds
[02:56] --> Dominus joined #scummvm.
[03:03] --> [md5]_ joined #scummvm.
[03:03] <-- [md5]_ left irc: Changing host
[03:03] --> [md5]_ joined #scummvm.
[03:03] #scummvm: mode change '+o [md5]_' by ChanServ!ChanServ@services.
[03:04] [md5] <-- (~md5@unaffiliated/md5/x-729473) left irc: Ping timeout: 250 seconds
[03:19] <-- ccawley2011_ left irc: Quit: Page closed
[04:39] <tsoliman> snover & criezy: you are on macOS, what client do you use?
[04:39] <tsoliman> (irc client)
[04:39] <snover> tsoliman: adium, which i do not really recommend.
[04:43] <snover> a surprising number of people i know just use irssi
[04:43] <snover> and/or weechat
[04:44] <tsoliman> that's my fallback: irssi
[04:44] <tsoliman> I just downloaded Textual (30 days free) to check it out but I can't even connect to my bouncer
[04:47] <tsoliman> yay it worked now
[04:47] <tsoliman> it is very underwhelming - for a paid app
[04:48] <snover> i think weechat is probably a bit more used, but it has been so long since i have done any surveying
[04:53] <Lightkey> there is always xchat: https://xchataqua.github.io/
[04:53] <snover> no there isnt
[04:53] <snover> quit making things up
[04:54] <Lightkey> okay.. it's almost 6 am anyway, time for bed
[04:54] <snover> see what i mean?
[04:54] <snover> opposite world
[04:55] <Lightkey> just your typical late shift worker :p
[06:18] <fydo> irssi is great!
[06:38] <Endy> Speaking of IRC, LeChuck is going away for 5-10 while I give it more disk space :)
[06:39] <-- Endy left irc: Quit: Rebooting
[06:41] --> LeChuck joined #scummvm.
[06:50] <logix> lies, that was 1 minute
[06:57] <-- _sev left irc: Quit: This computer has gone to sleep
[06:58] --> _sev joined #scummvm.
[06:58] <-- _sev left irc: Changing host
[06:58] --> _sev joined #scummvm.
[06:58] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[07:00] --> Endy joined #scummvm.
[07:00] #scummvm: mode change '+o Endy' by ChanServ!ChanServ@services.
[07:15] <-- _sev left irc: Quit: This computer has gone to sleep
[07:25] <madmoose> Endy: Hola!
[07:32] <-- timofonic left irc: Ping timeout: 255 seconds
[07:33] <Endy> Hey madmoose :)
[07:33] <Endy> Hows it going?
[07:35] --> timofonic joined #scummvm.
[07:46] --> f2k joined #scummvm.
[08:05] --> user9 joined #scummvm.
[08:08] <-- LittleToonCat left irc: Remote host closed the connection
[08:34] --> rootfather joined #scummvm.
[08:34] <-- rootfather left irc: Changing host
[08:34] --> rootfather joined #scummvm.
[08:34] #scummvm: mode change '+o rootfather' by ChanServ!ChanServ@services.
[08:40] <rootfather> morning
[08:42] <-- edheldil left irc: Remote host closed the connection
[08:43] --> edheldil joined #scummvm.
[09:24] <-- |Cable| left irc: Ping timeout: 260 seconds
[09:30] --> kurtwr2 joined #scummvm.
[09:31] <-- kurtwr left irc: Ping timeout: 248 seconds
[09:36] --> |Cable| joined #scummvm.
[10:15] Nick change: [md5]_ -> [md5]
[10:16] --> pilgrim joined #scummvm.
[10:16] <-- pilgrim left irc: Client Quit
[10:21] <[md5]> anyone who can help with an SDL crash I'm experiencing?
[11:08] <-- phyber left irc: Ping timeout: 258 seconds
[11:35] <-- borosky left irc: Ping timeout: 268 seconds
[11:49] --> criezy|Work joined #scummvm.
[11:50] #scummvm: mode change '+o criezy|Work' by ChanServ!ChanServ@services.
[11:50] <criezy|Work> Hi guys
[11:53] <criezy|Work> [md5]: you might want to check that you are watching the scummvm repository on GitHub and that you enabled email notifications and not just web notifications in your personal settings.
[11:54] <criezy|Work> Also in case you did not see it, _sev asked a question on your revert commit of the previously reverted drascula commits this morning.
[11:55] <criezy|Work> And I might be able to help with your SDL crash if you give some more details.
[11:58] <[md5]> thanks criezy|Work
[11:59] <[md5]> no, I did not see _sev's commit
[11:59] <[md5]> er
[11:59] <[md5]> question
[11:59] <[md5]> let me check github
[11:59] --> waltervn joined #scummvm.
[11:59] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services.
[12:00] <[md5]> I am watching the repo
[12:00] <[md5]> and all the checks in the notifications screen are enabled
[12:00] <[md5]> hm
[12:01] <criezy|Work> Strange.
[12:01] <criezy|Work> I did have issues with email notifications at one point, and this was solved quickly after I contacted GitHub about it.
[12:01] <criezy|Work> So you could try to contact them.
[12:03] <[md5]> thanks criezy|Work :) I'll do that
[12:04] <[md5]> regarding SDL:
[12:04] <[md5]> I'm having two reproducible strange crashes with the latest changes
[12:04] <[md5]> I'm using the antialiased renderer, in HQ3x graphics mode
[12:05] <[md5]> I've built ScummVM on MSVC2017 (Windows 10)
[12:05] <criezy|Work> SDL 1.2 or 2?
[12:05] <[md5]> I always get a crash when quitting ScummVM, or when starting a game
[12:05] <[md5]> Sorry, SDL2
[12:06] <[md5]> both crashes are in graphics/surfacesdl/surfacesdl-graphics.cpp
[12:06] <logix> [md5]: there was some chatter here regarding windows and SDL last night (CET)
[12:07] <[md5]> right
[12:07] <[md5]> I'll check the logs, thanks
[12:07] <[md5]> for me, it crashes on exit here:
[12:07] <criezy|Work> logix: wasn't this mostly about the jumping mouse issue though?
[12:08] <[md5]> line 217, inside ~SurfaceSdlGraphicsManager()
[12:08] <[md5]> i.e. here:
[12:08] <logix> criezy|Work: yes, seems so - I just scrolled back and checked what it was about
[12:08] <[md5]> if (_mouseSurface) {
[12:08] <[md5]> SDL_FreeSurface(_mouseSurface);
[12:08] <logix> also, it was about SDL1
[12:08] <logix> so not related
[12:08] <[md5]> same when starting a game
[12:08] <[md5]> in...
[12:08] <[md5]> inside blitCursor()
[12:09] <[md5]> lines 2073-2074
[12:09] <[md5]> if (sizeChanged) {
[12:09] <[md5]> if (_mouseSurface)
[12:09] <[md5]> SDL_FreeSurface(_mouseSurface);
[12:09] <[md5]> MSVC complaints that _mouseSurface is invalid
[12:09] <[md5]> in the SDL_FreeSurface() call
[12:09] <criezy|Work> So it looks like there is something strange happening with the mouse surface.
[12:10] <[md5]> yes
[12:10] <logix> should _mouseSurface() perhaps be set to NULL after calling SDL_FreeSurface?
[12:10] <[md5]> in both cases, _mouseSurface is initialized, but something triggers MSVC to throw an error in this call
[12:10] <criezy|Work> Which reminds me that bgK made a commit recently related to a_mouseSurface issue...
[12:10] <logix> that's "_mouseSurface", not "_mouseSurface()"...
[12:11] <[md5]> I can work around the call if I hack the check to be like this (but this is a hack):
[12:11] <[md5]> if (_mouseSurface && _mouseSurface->pixels)
[12:11] <[md5]> SDL_FreeSurface(_mouseSurface);
[12:11] <logix> I'm just thinking, perhaps "SDL_FreeSurface(_mouseSurface)" gets called twice
[12:11] <criezy|Work> The crash is a recent regression?
[12:11] <[md5]> well, in all places where it's called, _mouseSurface seems to be reinitialized shortly after (apart from the destructor)
[12:11] <[md5]> criezy|Work: yes
[12:11] <[md5]> I'll try and bisect
[12:11] <criezy|Work> Did you try to bisect to find the culprit?
[12:12] <[md5]> not yet
[12:12] <criezy|Work> Ah, you were faster to suggest it :P
[12:12] <[md5]> I was just asking first to see if anyone else is having this issue
[12:12] <[md5]> criezy|Work: :P
[12:12] <[md5]> although, I recently changed to MSVC2017, and perhaps it's complaining about something that I did not see before
[12:12] <criezy|Work> I have not seen it myself. But if that is Windows specific there is no chance I would see it.
[12:12] <[md5]> so... I wanted to ask if this whole crash makes sense to anyone first, of if anyone else is experiencing it
[12:13] <bgK> [md5]: what version of SDL2 are you using?
[12:13] <[md5]> criezy|Work: Windows is great! :P
[12:13] <[md5]> bgK: oh, good question
[12:13] <[md5]> I did not check, one sec
[12:14] <bgK> they made a change to internal reference counting for surfaces between SDL 2.0.5, 2.0.6 and 2.0.7, with SDL 2.0.6 being broken
[12:14] <bgK> (and SDL 2.0.5 having a memory leak)
[12:14] <[md5]> mine's quite old, 2.0.4
[12:14] <[md5]> sorry about that, I'll update and see if I still have the issue
[12:14] <[md5]> 1 sec
[12:15] <wjp> does it need a check _mouseSurface != _mouseOrigSurface?
[12:15] <wjp> that's in all other places _mouseSurface is freed anyway
[12:15] Action: [md5] also checks wjp's suggestion
[12:16] <criezy|Work> In the destructor it does that check a few lines above when freeing the mouseOrigSurface though.
[12:18] <logix> but only for the case of mouseOrigSurface being non-NULL
[12:18] <criezy|Work> But if it is null and _mouseSurface is equal to null, then the _mouseSurface would be null. And this is checked.
[12:19] <criezy|Work> * and _mouseSurface is eqaul to it
[12:20] <[md5]> it's non-null in both cases, if it matters
[12:21] <[md5]> I upgraded to SDL 2.0.7 and I still get the same crash... sec to rebuild everything, just in case
[12:21] <wjp> I'm mostly worried about the lack of this _mouseSurface != _mouseOrigSurface check on line 2073, by the way
[12:21] <wjp> not so much in the destructor
[12:22] <criezy|Work> I agree with wjp. I was just about to write about that one.
[12:22] <[md5]> hm
[12:22] <criezy|Work> The test probably needs to be added there.
[12:22] <[md5]> also, if it matters, the branches for the 32bpp code are not followed in my test case
[12:25] <[md5]> um, so I should try changing the check to if (_mouseSurface != _mouseOrigSurface) instead of if (_mouseSurface)... correct?
[12:27] <criezy|Work> Or if (mouseSurface && _mouseSurface != _mouseOrigSurface) in case SDL_FreeSurface() does not behave well when call with a null pointer.
[12:27] <wjp> you can pass nullptr to SDL_FreeSurface
[12:27] <[md5]> according to the docs, it's OK to call it with a nullptr
[12:28] <[md5]> ah, wjp beat me to it
[12:28] <wjp> but, yes, that check is what I meant
[12:28] <criezy|Work> Good. I was too lazy to check the SDL doc and saw that in most places in that file it was checking the pointer is not null before calling SDL_FreeSurface.
[12:28] <wjp> I'm not sure there's a series of events that can lead to this going wrong, but it's at least slightly suspicious
[12:30] <[md5]> I still get the crash with the change in the check
[12:30] <[md5]> in particular, the error is: "Exception thrown at 0x5AA77CC7 (SDL2.dll) in scummvm.exe: 0xC0000005: Access violation writing location 0x00000044."
[12:31] <[md5]> when calling SDL_FreeSurface(_mouseSurface);
[12:31] <[md5]> I'll try and bisect
[12:35] <wjp> I don't really see any other places where there could be a double free
[12:36] <wjp> is this clean master, or do you have local changes?
[12:36] <[md5]> I have some changes in the engine code, I'll stash them
[12:36] <[md5]> I've just reset to an older (1 month old revision)
[12:37] <criezy|Work> And I don't see other places that could cause a double free either. The code around line 1865-1875 is a bit strange, but should be OK.
[12:38] <wjp> yeah, some of those checks are superfluous, but not harmful
[12:41] <criezy|Work> I will be away for a bit (lunch time!)
[12:41] <[md5]> 7fc86195343adf962054fd52605c3a3cc8b501e9 works
[12:43] --> jamm joined #scummvm.
[12:43] <-- jamm left irc: Changing host
[12:43] --> jamm joined #scummvm.
[12:49] <logix> wjp: I think even if that SDL_FreeSurface() in l. 2074 lacks that check, it's line 212 that should cause problems (2nd free of mouseOrigSurface), not l. 217, no?
[12:50] <wjp> possibly. But it's still the only instance of a potential double free I see
[12:50] <logix> unless it's not really a double free of that surface but a counter for allocated surfaces in SDL or something that causes the issue because that at this point then will be negative
[12:51] <logix> ok - I'm not arguing against that protective check in line 2073 btw, from what I see so far that should be there
[12:52] <wjp> But I have no idea what's going on anyway. I can't reproduce on Windows with Kirben's build either
[12:54] <wjp> I'd probably just start to add debugging output to all FreeSurface calls in there to check
[12:54] <wjp> (and the allocs)
[12:57] <[md5]> e26a677f6214a1c88d63a41e136dc78ad07cca11 works
[12:57] <[md5]> 6b4195a542083c97f696c843b9823d578b018996 is broken
[13:02] <-- user9 left irc: Quit: user9
[13:14] <logix> wjp: that sounds very familiar, and whenever I hear people mentioning valgrid I feel cheap for usually going the printf approach :)
[13:16] <wjp> well, if it would happen on Linux I'd use valgrind :-)
[13:16] <wjp> but printf a lot too
[13:16] <wjp> often the easiest way to get a good global overview of what's happening over time
[13:18] <[md5]> (still testing)
[13:18] <[md5]> bd82345f0b634e5ccf7b2412a0d7cad7232057c5 works
[13:23] <wjp> (you may want to try disabling almost all engines to speed up builds)
[13:23] <wjp> (after first verifying that a broken revision is still broken with engines disabled, of course)
[13:25] <[md5]> thanks wjp :)
[13:25] <[md5]> d8aab6362a82ff9e2424cb7063c78f9b10c4d12a works
[13:26] <-- jamm left irc: Read error: Connection reset by peer
[13:29] <[md5]> almost there.... 8a42959eed458e3ffa913b8e2cce463857cd9dc1 works
[13:30] --> user9 joined #scummvm.
[13:49] <[md5]> OK, I found the commit, but I don't understand why it breaks it
[13:49] <[md5]> it's 6b4195a542083c97f696c843b9823d578b018996
[13:49] <[md5]> "SDL: Use RLE acceleration for SDL2 transparent surfaces"
[13:50] <[md5]> https://github.com/scummvm/scummvm/commit/6b4195a542083c97f696c843b9823d578b018996
[13:50] <[md5]> I don't understand why that messes things up
[13:50] <criezy|Work> One reason why it might break is if we forget to lock the surface before accessing its pixels.
[13:50] <criezy|Work> But I already check that is not the case.
[13:52] <[md5]> yeah
[13:52] <[md5]> "If RLE is enabled, color key and alpha blending blits are much faster, but the surface must be locked before directly accessing the pixels."
[13:56] <[md5]> I've narrowed it down to lines 775-776 in sdl.cpp
[13:56] <criezy|Work> Could you get back to the current master and remove the SDL_RLEACCELL on lines 1902 and 2088 and see if that still crashes?
[13:56] <[md5]> inside SDL_SetColorKey_replacement()
[13:56] <[md5]> i.e.
[13:56] <[md5]> if (flag & SDL_RLEACCEL)
[13:56] <[md5]> SDL_SetSurfaceRLE(surface, 1);
[13:57] <[md5]> let me check if that fixes the crash on master
[13:57] <[md5]> if it does, it might be a place where SetColorKey is used
[13:58] <criezy|Work> Yes, those are calls to SDL_SetColorKey.
[13:58] <criezy|Work> But I am wondering if the same issue also happens with the OSD messages, and thus if we should just avoid using RLE for the mouse surface, or not use it at all.
[13:59] <[md5]> perhaps it would be better to track down the code that calls SetColorKey?
[14:01] <[md5]> ah
[14:01] <[md5]> it seems that the problem is in this line:
[14:01] <[md5]> SDL_SetColorKey(_mouseSurface, SDL_RLEACCEL | SDL_SRCCOLORKEY | SDL_SRCALPHA, kMouseColorKey);
[14:01] <[md5]> line 2088 in surfacesdl-graphics.cpp
[14:02] <[md5]> if I remove SDL_RLEACCEL as you told me, I don't get a crash
[14:03] <[md5]> and that solves both crashes for me (when starting a game, and when exiting)
[14:03] <criezy|Work> I really don't understand why that line is an issue though. And why you are the only one with this issue.
[14:04] <[md5]> wee I'm weird :P
[14:04] <[md5]> hm
[14:04] <criezy|Work> I am thinking that to be on the safe side we could just revert my commit 6b4195a542083c97f696c843b9823d578b018996 and not use RLE accelleration at all with SDL2.
[14:05] <criezy|Work> The worth that can happen is that we would get slightlyless good performances.
[14:05] <criezy|Work> But that's how it was until a few days ago anyway.
[14:06] <[md5]> one question
[14:06] <[md5]> when reading through the SDL wiki:
[14:06] <[md5]> https://wiki.libsdl.org/SDL_SetColorKey
[14:06] <[md5]> it says that the second parameter is either SDL_TRUE or SDL_FALSE
[14:06] <[md5]> or is that an old entry?
[14:07] <[md5]> we have SDL_RLEACCEL | SDL_SRCCOLORKEY | SDL_SRCALPHA
[14:07] <wjp> it goes through that _replacement function (I hope)
[14:07] <[md5]> yeah it does
[14:07] <[md5]> it just takes different parameters
[14:07] <wjp> see how the replacement function calls it
[14:08] <criezy|Work> Yes it used to take flags in SDL 1.2, and now takes SDL_TRUE or SDL_FALSE.
[14:09] <criezy|Work> Which is why we have the replacement function.
[14:18] <[md5]> the only thing I can think of, is if _mouseSurface points to _mouseOriginalSurface, and _mouseOriginalSurface is not locked properly?
[14:18] <criezy|Work> I did check both. But I might have missed something.
[14:25] <[md5]> I tried unlocking and relocking _mouseOrigSurface around the sizechanged block, but no joy - it still crashes when starting a game
[14:25] <[md5]> so, meh :/
[14:26] <[md5]> I'll try an overlay too
[14:26] <[md5]> and see what happens
[14:27] <[md5]> same crash
[14:27] <[md5]> this time in removeOSDMessage()
[14:27] <[md5]> if (_osdMessageSurface) {
[14:27] <[md5]> SDL_FreeSurface(_osdMessageSurface);
[14:29] <[md5]> Perhaps it could be easier to comment out the two lines that check for SDL_RLEACCELL inside SDL_SetColorKey_replacement?
[14:33] <criezy|Work> For the OSD, that would be the one in SDL_SetAlpha (also in sdl.cpp, just above the SDL_SetColorKey_replacement).
[14:34] <[md5]> yes, right
[14:34] <[md5]> hm
[14:34] <[md5]> checking inside SDL_SetSurfaceRLE()... it checks the maps of the surface
[14:34] <[md5]> map info, sorry
[14:35] <[md5]> and it does this:
[14:35] <[md5]> if (surface->map->info.flags != flags) {
[14:35] <[md5]> SDL_InvalidateMap(surface->map);
[14:37] <criezy|Work> I don't have the SDL code at hand right now. I looked at it about a week ago, but my memory is not so good that I remember it ;)
[14:37] <criezy|Work> I can take another look this evening.
[14:38] <criezy|Work> But: [14:04] <@criezy|Work> I am thinking that to be on the safe side we could just revert my commit 6b4195a542083c97f696c843b9823d578b018996 and not use RLE accelleration at all with SDL2.
[14:38] <criezy|Work> Especially now that you confirm the issue also happens with the OSD.
[14:39] <criezy|Work> I am still wondering what the cause of the crash really is though...
[14:39] <[md5]> ok :)
[14:40] <[md5]> I really don't know... it is strange, indeed
[14:40] <[md5]> or... hm
[14:46] <[md5]> nope, I've tried all sorts of wacky things here, just in case, but to no avail
[14:46] <[md5]> and it feels kind of lonely to be the only one experiencing this :P
[14:57] <criezy|Work> There are several reported crash for SDL when RLE is used, but they all are from a long time ago (2000 and 2002).
[14:57] <criezy|Work> I can't find anything recent.
[15:00] <[md5]> does Valgrind show anything for you?
[15:00] <[md5]> it's very easy to debug... just start ScummVM and exit
[15:06] <criezy|Work> I will check this evening.
[15:06] <criezy|Work> I don't remember when was the last time I used valgrind with ScummVM, and it might have been before that commit.
[15:07] <[md5]> ok
[15:08] <[md5]> three scenarios you can test: 1) start/exit ScummVM, 2) start ScummVM, then start a game, 3) start a game with an OSD message (e.g. with the MT-32 emulator)
[15:23] --> ccawley2011 joined #scummvm.
[15:33] <-- timofonic left irc: Ping timeout: 248 seconds
[15:34] <-- kurtwr2 left irc:
[15:37] --> ajshell1 joined #scummvm.
[15:39] <-- edheldil left irc: Remote host closed the connection
[15:40] --> edheldil joined #scummvm.
[15:41] --> kurtwr joined #scummvm.
[15:48] <snover> wjp, criezy|Work, SDL 2.0.6 was crashing all the time in SDL_FreeSurface dereferencing null pointer, though weirdly it was not having such trouble until I upgraded Xcode, 2.0.7 has been fine. _mouseOrigSurface is only == _mouseSurface for 32bpp cursors, so the check on 2073 should be fine since the 32bpp path at 1971 returns early.
[15:52] <snover> i suppose one could recompile SDL2 with -fsanitize=address to detect any use-after-free though if valgrind isnt showing anything then i would expect things to be fine.
[15:55] <-- f2k left irc: Quit: Leaving
[15:59] <criezy|Work> snover: bgK already mentioned 2.0.6 was broken. [md5] was using 2.0.4, and then upgraded to 2.0.7, so broken 2.0.6 is not the issue here.
[16:02] <snover> i understand, and i am just saying that was the only time that i saw some crash with the mouse surface.
[16:33] --> ajax16384 joined #scummvm.
[16:33] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[16:49] --> LittleToonCat joined #scummvm.
[16:52] Nick change: Storm-AFK -> Stormkeeper
[17:18] --> ny00123 joined #scummvm.
[17:29] --> nast joined #scummvm.
[17:31] <snover> criezy|Work: i recompiled sdl with asan and sdl internal assertions on, and tested sci and titanic engines, no crashes. sdl is unhappy that SDL_DestroyTexture is passed a null pointer in deinitializeRenderer, but this is unrelated and causes no crash (and ill fix it momentarily in any case).
[17:32] --> vasc joined #scummvm.
[17:34] <criezy|Work> OK. Thank you for taking a look.
[17:34] <criezy|Work> I will run with valgrind this evening in any case to double check that it is also happy.
[17:36] --> GitHub64 joined #scummvm.
[17:36] <GitHub64> [scummvm] csnover pushed 1 new commit to master: https://git.io/vFXdT
[17:36] <GitHub64> scummvm/master 9bbf7f3 Colin Snover: SDL: Don't pass null pointers to SDL_DestroyTexture/SDL_DestroyRenderer...
[17:36] GitHub64 (GitHub64@192.30.252.34) left #scummvm.
[17:37] --> GitHub180 joined #scummvm.
[17:37] <GitHub180> [scummvm] criezy pushed 1 new commit to master: https://git.io/vFXdt
[17:37] <GitHub180> scummvm/master f43c40f Lothar Serra Mari: I18N: Update translation (German)...
[17:37] GitHub180 (GitHub180@192.30.252.41) left #scummvm.
[17:41] --> nast_ joined #scummvm.
[17:44] <-- nast left irc: Ping timeout: 240 seconds
[17:51] --> Farmboy0 joined #scummvm.
[17:51] <-- Farmboy0 left irc: Changing host
[17:51] --> Farmboy0 joined #scummvm.
[17:55] --> nast__ joined #scummvm.
[17:58] <-- nast_ left irc: Ping timeout: 260 seconds
[17:58] <-- ajshell1 left irc: Quit: Leaving
[18:03] <-- DJW|Home left irc: Read error: Connection reset by peer
[18:03] --> _sev joined #scummvm.
[18:03] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[18:16] <-- nast__ left irc: Quit: Leaving
[18:23] <vasc> font loader is working. now what next...
[18:30] --> rootfather|2nd joined #scummvm.
[18:30] <logix> hm, https://twitter.com/libretro/status/930492761391943680
[18:32] <-- rootfather left irc: Ping timeout: 248 seconds
[18:36] Nick change: rootfather|2nd -> rootfather
[18:36] <-- rootfather left irc: Changing host
[18:36] --> rootfather joined #scummvm.
[18:36] #scummvm: mode change '+o rootfather' by ChanServ!ChanServ@services.
[18:37] --> Henke37 joined #scummvm.
[18:51] <-- criezy|Work left irc: Quit: Page closed
[18:55] [md5] <-- (~md5@unaffiliated/md5/x-729473) left irc: Ping timeout: 250 seconds
[18:59] --> SylvainTV joined #scummvm.
[18:59] #scummvm: mode change '+o SylvainTV' by ChanServ!ChanServ@services.
[19:44] --> girafe joined #scummvm.
[19:56] kusushi[m] <-- (kusushimat@gateway/shell/matrix.org/x-xevcvcwjhnfioqup) left irc: Ping timeout: 276 seconds
[19:57] tomazcuber[m] <-- (tomazcuber@gateway/shell/matrix.org/x-yjkaiiaqjjesmhsg) left irc: Ping timeout: 276 seconds
[19:59] <-- ruskie left irc: Ping timeout: 250 seconds
[19:59] <vasc> i can't find the dialog chat bubble in the game's BMP resources. well so much for that.
[20:00] <vasc> don't tell me it's a built-in draw code...
[20:04] <rootfather> maybe it's a built-in draw code? :P
[20:06] kusushi[m] --> (kusushimat@gateway/shell/matrix.org/x-cxtfaaupcsmnhjix) joined #scummvm.
[20:06] tomazcuber[m] --> (tomazcuber@gateway/shell/matrix.org/x-insbemqfakaarlcx) joined #scummvm.
[20:07] <vasc> it's got at least like 3-4 text surfaces.
[20:07] <vasc> like item descriptions, thought bubble, speech bubble
[20:07] <vasc> cinematic pane
[20:07] <vasc> i expected those to be bitmaps
[20:12] --> disabler joined #scummvm.
[20:13] <-- disabler left irc: Client Quit
[20:32] Nick change: Stormkeeper -> Storm-Gaming
[20:32] <-- ajax16384 left irc: Quit: Leaving
[21:04] <-- _sev left irc: Quit: This computer has gone to sleep
[21:07] --> GitHub173 joined #scummvm.
[21:07] <GitHub173> [scummvm] rootfather pushed 1 new commit to master: https://git.io/vF1CY
[21:07] <GitHub173> scummvm/master 1adc4ac rootfather: WIN32: Add German Start Menu entries to the installer
[21:07] GitHub173 (GitHub173@192.30.252.35) left #scummvm.
[21:07] --> criezy joined #scummvm.
[21:07] #scummvm: mode change '+o criezy' by ChanServ!ChanServ@services.
[21:08] --> _sev joined #scummvm.
[21:08] <-- _sev left irc: Changing host
[21:08] --> _sev joined #scummvm.
[21:08] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[21:10] <_sev> vasc: which game are you talking about?
[21:17] --> ruskie joined #scummvm.
[21:23] <vasc> Rise of the Dragon
[21:24] <-- Henke37 left irc: Quit: ERR_SHUTDOWN
[21:24] #scummvm: mode change '+o Strangerke' by ChanServ!ChanServ@services.
[21:24] --> phyber joined #scummvm.
[21:43] Nick change: rootfather -> rootfather|aslee
[21:43] Nick change: rootfather|aslee -> rootfather|afk
[22:17] <-- waltervn left irc: Quit: Leaving
[22:27] <vasc> this was quite a bad hack..
[22:29] <snover> whose bad hack?
[22:29] <-- ny00123 left irc: Quit: Leaving
[22:30] <-- rootfather|afk left irc: Ping timeout: 255 seconds
[22:30] --> GitHub195 joined #scummvm.
[22:30] <GitHub195> [scummvm] ccawley2011 opened pull request #1057: DS: Fix compilation with devkitARM r47 (master...ds) https://git.io/vF1gz
[22:30] GitHub195 (GitHub195@192.30.252.34) left #scummvm.
[22:31] <logix> oi
[22:32] <logix> hm, -mfloat-abi=soft, interesting
[22:33] <snover> soft abi is not compatible with libraries using hard/softfp
[22:33] <snover> abi
[22:33] <snover> fwiw
[22:35] <logix> probably not that relevant for the DS
[22:35] <snover> well, iirc, 3ds has a hardware fpu
[22:36] <logix> hm, isn't that a separate port?
[22:36] <snover> i dont really know the details. it certainly seems more relevant than a DS :)
[22:36] <logix> or at least a separate makefile or something :)
[22:36] <logix> well, yeah, you have a point there
[22:37] <logix> I'm just saying, for the DS port replacing -mno-fpu with -mfloat-abi=soft sounds better than what I did to get it to compile (s/-mno-fpu//)
[22:38] <snover> does it actually work or does it just compile?
[22:38] <logix> I have no idea, I really just got mine to produce a binary, I didn't get to try it yet - and even less so ccawley's
[22:39] <logix> I can try tomorrow
[22:40] <snover> let me know how it goes!
[22:40] <logix> yup, will do
[22:40] <snover> give me a Dockerfile for a Buildbot worker with a modern compiler that can be kept up-to-date and im pretty much a pushover at this point, i think.
[22:43] <snover> https://github.com/csnover/scummvm-docker/pull/20 oh hey.
[22:44] Action: snover falls over.
[22:48] <vasc> https://www.youtube.com/watch?v=Kh1Xam0scfU
[22:48] <vasc> latest DGDS engine video update.
[22:49] <joostp> is the sega cd version of rise of the dragon also dgds?
[22:51] <vasc> probably
[22:51] <vasc> haven't looked the files yet.
[22:56] <vasc> it likely uses a low color palette like the Amiga port though.
[22:56] <vasc> i think the Sega Megadrive only had 64 color gfx.
[22:57] <vasc> Megadrive/Genesis
[22:57] <joostp> yeah, but it has cd audio and speech
[22:58] <snover> the question you have to ask yourself is whether the recorded 90s MIDI synth will actually sound better than a modern synth playing the MIDI files from the PC release
[22:59] <vasc> the Mac version has MIDI sound with 8-bit sound instrument samples. the PC version has MIDI sound with MT-32 playback.
[22:59] <vasc> i'm willing to support as many ports as possible.
[23:00] <vasc> the Macintosh port has priority for me now, because it's the only one where i can load the image resources.
[23:00] <vasc> or should i say, it's the most well supported right now.
[23:06] <vasc> the SEGA CD files looks obfuscated somehow.
[23:06] <vasc> someone else would have to unobfuscate them to see if it's possible.
[23:06] <-- girafe left irc: Quit: Leaving
[23:09] <vasc> i'm not a Sega CD expert.
[23:09] <vasc> i guess i'll have to look at how Macintosh SCI 1.2 is. they probably are using that.
[23:10] <snover> i dont think that system had enough CPU power to do anything like obfuscation. it would be more likely for them to be in some hardware-specific formats.
[23:11] <snover> but i dont know much about it either, other than that its probably closer to whatever mac version exists since they were both 68ks
[23:11] <vasc> well, i can't even grep a single meaningful string there.
[23:11] <snover> (assuming they didnt pull a Phantasmagoria and rewrite the entire engine just for that system)
[23:14] <vasc> btw, the DGDS engine also can load the Heart of China Mac port images fine.
[23:14] <vasc> so, i think the only real obstacle is understanding how to parse the dialog files and things like that.
[23:15] <vasc> it can already unpack the volumes, decompress them, load images, fonts
[23:15] <vasc> and some sounds.
[23:15] <vasc> and play cinematic sequences to a degree. not all opcodes yet, but seems to work fine on ROTD intro.
[23:16] <vasc> i tried it on Heart of China, but it needs more opcodes.
[23:16] <vasc> lucky looks kinda weird.
[23:17] <vasc> the dialog files are uncompressed, i can read the strings, but i can't understand the file structure.
[23:17] <vasc> and i tried...
[23:18] <vasc> i do know it has like events, event ids, text connected to them.
[23:19] <vasc> as for the game data resources themselves, the text descriptions are in those files, but the modus operandi of them, i don't understand the files yet.
[23:19] <vasc> but most of it seems scripted.
[23:20] <vasc> if there's anything really game mechanics specific there, it must be quite small.
[23:21] <vasc> i haven't seen much hardcoding.
[23:21] <-- _sev left irc: Quit: This computer has gone to sleep
[23:22] --> _sev joined #scummvm.
[23:22] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[23:22] <vasc> then again i dunno. maybe i should just wait for the SCI sound engine rewrite.
[23:23] <vasc> the Mac and PC ports at least are 100% using it.
[23:23] <vasc> the Amiga port I'm less sure.
[23:24] <vasc> i guess i could at least get the Mac sound resource extractor working, like i did for the DOS one.
[23:24] <vasc> and the Amiga one.
[23:26] <vasc> do Amiga SCI games also use AIFF sound samples for instruments and IFF-SMUS music?
[23:28] <snover> i dont know much of anything about that variant of SCI so i cant answer that offhand, unfortunately.
[23:28] <snover> IIRC, they are very very similar, i just dont know the entire details.
[23:28] <vasc> well, is kinda like MIDI with sound samples for instruments
[23:28] <vasc> SMUS is
[23:29] <vasc> http://wiki.amigaos.net/wiki/SMUS_IFF_Simple_Musical_Score
[23:31] <snover> just look at the sci engine code.
[23:33] <vasc> ok
[23:41] <snover> sorry if that came off a little more tersely than i intended it.
[23:41] <snover> waltervn is probably the best person to talk to about SCI sound.
[23:41] <-- Lightkey left irc: Ping timeout: 250 seconds
[23:43] <-- Farmboy0 left irc: Remote host closed the connection
[23:54] --> dreammaster joined #scummvm.
[23:54] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[23:55] --> Lightkey joined #scummvm.
[00:00] --- Thu Nov 16 2017