ScummVM IRC Log - 10 Nov 2017

[Back to Index]

[00:05] --> Lightkey joined #scummvm.
[00:09] <criezy> Oh, actually as soon as I move the mouse it jumps back to its original position...
[00:22] <-- girafe left irc: Read error: Connection reset by peer
[00:52] <snover> good question, i dont think that the mouse position persists across backend switches
[00:53] <snover> the position is stored by the graphicsmanager instance so it would need to get passed through by whatever is responsible for destroying and creating those objects.
[00:55] <snover> i must admit i dont love that opengl is even a selectable option, since whatever is optimal should be what happens, but thats just the ux person in my head talking.
[00:56] <snover> do you have any thoughts on this? https://bugs.scummvm.org/ticket/9967 i feel like i have seen this kind of thing come up in the past.
[00:57] <snover> but i seem to be incapable of search bug trackers successfully these days
[00:57] <criezy> I have a vague recolection of a similar issue on another platform.
[00:59] <criezy> Also I am trying to understand why with SDL2 surfacesdl backend when we blit the mouse cursor and then the OSD message surfaces (both with some transparency) to the screen and they overlap, the transparent part of the mouse cursor surface is no longer transparent.
[00:59] <criezy> This does not happen with SDL 1.2.
[01:00] <snover> what is it, instead of transparent?
[01:00] <criezy> white-ish
[01:01] <snover> is it the underlying alpha-transparent surface doubling up on itself?
[01:01] <criezy> No, actually, it seems to be the color of the backgroud that is behind.
[01:02] <snover> is it the OSD not being composited in between the cursor and the main surface?
[01:02] <criezy> the cursor is composited first, then the OSD
[01:02] <criezy> *the sursor is blitted first to the main surface, then the OSD
[01:03] <snover> i learned the hard way when i was implementing cursors with alpha that the cursor code just redraws the cursor over itself all the time
[01:03] <criezy> I am wondering if the OSD message might do the same. Because as soon as move the mouse it becomes less transparent!
[01:06] <criezy> Both issues are fixed if I just forced a redraw from SurfaceSdlGraphicsManager::updateOSD() whenever _osdMessageSurface exists and not just when changing the alpha value.
[01:08] <snover> things like this make me want to invest energy in just making opengl the sole renderer, then things like that fm towns issue make me want to invest energy in just making surfacesdl the sole renderer :)
[01:11] <criezy> Maybe we should just implement a AAlib-based renderer and ditch both opengl and surfacesdl :P
[01:12] <snover> 80x25 ought to be enough for anybody
[01:13] <-- SylvainTV left irc: Read error: Connection reset by peer
[01:28] <snover> bgK: do you by any chance have version 1.51 of kq7 french?
[01:30] <snover> https://zetafleet.com/i/5a0501763bc88.png yes, yes, yes, yes. can i check this box 10 times?
[01:34] <criezy> That remind me, maybe we should merge https://github.com/scummvm/scummvm/pull/1041 ?
[01:34] --> Cheeseness joined #scummvm.
[01:34] <snover> i never was able to get the lawyers in ##c++ to tell me whether or not that warning was valid
[01:37] <snover> i did manage to poison someone else with similar confusion, though!
[01:37] <criezy> Great! Well done! I hope he enjoyed it,
[01:44] <snover> i guess& maybe i will actually post a question for once on SO and see if someone will give a response with pointers to the standard
[01:45] <snover> probably i should have done that a while ago
[01:47] <snover> i will do that and fix up the detection PR when i get back to my desk later this evening
[01:56] <-- dreammaster left irc:
[02:03] <-- Dominus left irc: Ping timeout: 260 seconds
[02:04] --> Dominus joined #scummvm.
[02:13] --> TMM joined #scummvm.
[02:13] #scummvm: mode change '+o TMM' by ChanServ!ChanServ@services.
[02:18] yashgandhe[m] --> (yashgandhe@gateway/shell/matrix.org/x-ekdtdhctrhsuqimy) joined #scummvm.

[02:27] <-- TMM left irc: Quit: Ex-Chat
[02:43] <-- joostp left irc: Ping timeout: 250 seconds
[02:45] --> joostp joined #scummvm.
[02:45] #scummvm: mode change '+o joostp' by ChanServ!ChanServ@services.
[02:45] --> TMM joined #scummvm.
[02:45] #scummvm: mode change '+o TMM' by ChanServ!ChanServ@services.
[02:58] --> DominusExult joined #scummvm.
[03:02] <-- Dominus left irc: Ping timeout: 260 seconds
[03:02] Nick change: DominusExult -> Dominus
[03:10] <-- ccawley2011 left irc: Ping timeout: 260 seconds
[03:25] <snover> criezy: are you still conscious? im looking at the standard right now on va_start.
[03:26] <snover> the relevant part is a type that is not compatible with the type that results when passing an argument for which there is no parameter.
[03:26] <criezy> I am. But I was about to go to bed.
[03:26] <snover> do you know what that resulting type is?
[03:30] <criezy> I have difficulties understanding what that bit means.
[03:31] <criezy> Until now I have mostly relied on the "passing an object of a type that undergoes default argument promotions produces undefined behavior in C++" information available in several places related to that.
[03:32] <criezy> For example here: https://www.securecoding.cert.org/confluence/display/cplusplus/EXP58-CPP.+Pass+an+object+of+the+correct+type+to+va_start
[03:33] <criezy> With the non-compliant example using a float and the complient one a double.
[03:34] <snover> i will try to figure out the right question(s) to ask online and post them so this can be figured out finally.
[03:35] <snover> this is a good argument for c++11 variadic templates, perhaps&
[03:38] <criezy> I really should go to sleep now, if I don't want to feel like a zombie when it's time to go to work.
[03:38] <criezy> So good night
[03:38] <-- criezy left irc: Quit: criezy
[05:09] <snover> man. i feel like a superhero after figuring out that Wvarargs thing.
[05:10] <snover> the first tentative step into actually becoming a c++ language lawyer.
[05:37] <wjp> :-)
[05:54] <snover> im also pretty darn happy with the direction microsoft has been taking lately with their developer/oss stuff. since i had to do a little sleuthing on what the right incantation was for opting in to the standard static_assert for https://bugs.scummvm.org/ticket/10154 i also found some of their blog posts about MSVC 2017.
[05:55] <bgK> snover: I don't have KQ7 french 1.51, mine is 1.65c
[05:57] <snover> their compiler is on godbolt now, it has a new standards conformance mode flag /permissive-, it has a standard revision flags /std:c++14 or /std:c++latest, it is reportedly feature-complete through c++14 except for the c++11 preprocessor and expression sfinae.
[05:58] <snover> so it took them over 20 years but finally two-phase name lookup is a thing.
[05:59] <snover> bgK: ok, thanks. in that case, i guess that bug wont get fixed any time soon, unless the reporter comes back with the defective script so i can patch it&
[05:59] <snover> luckily they might be the only person in the world with a copy of that version
[06:05] <bgK> there's no detection entry for that version .. does the fallback detector even setup the engine correctly for it to work?
[06:07] <bgK> BTW, the VC++ compiler is available as a conventient zip file on nuget now, I was wondering about using it to create a buildbot worker running it through wine
[06:07] <snover> that would be neat!
[06:08] <snover> i have been assuming that 1.51 had matching bundle resources and 1.65 just came with some resource patches but i guess i should be careful with those assumptions.
[06:12] <snover> i was working on the windows buildbot a little more tonight because i realised i hadnt made SDL a shared library, and now im realising that i either need a better split-dwarf check since dwp only works on elf binaries, or i need to explicitly pass all the object names instead of having it get them from the unstripped executable.
[06:12] <snover> since right now with the split-dwarf enhancements, compilation fails at the final dwp step :\
[07:27] --> ny00123 joined #scummvm.
[07:52] <-- _sev left irc: Quit: This computer has gone to sleep
[08:38] <-- edheldil left irc: Remote host closed the connection
[08:39] --> edheldil joined #scummvm.
[08:42] <-- kurtwr left irc: Ping timeout: 248 seconds
[08:50] --> ajax16384 joined #scummvm.
[08:50] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[08:53] <-- LittleToonCat left irc: Remote host closed the connection
[09:15] <rootfather> snover I have to wait for scummvm to recompile before I can re-validate my bugreports
[09:15] <rootfather> might take another 30 minutes just for the compilation
[09:15] <rootfather> heck I have to get a new PC.
[09:23] --> _sev|work joined #scummvm.
[09:23] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[09:54] <-- TMM left irc: Quit: Ex-Chat
[09:58] <-- _sev|work left irc: Quit: This computer has gone to sleep
[09:58] --> frankyboy_ joined #scummvm.
[10:02] --> waltervn joined #scummvm.
[10:02] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services.
[10:09] --> f2k joined #scummvm.
[10:15] --> _sev|work joined #scummvm.
[10:15] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[10:51] <-- _sev|work left irc: Quit: This computer has gone to sleep
[11:08] --> GitHub25 joined #scummvm.
[11:08] <GitHub25> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vF2aV
[11:08] <GitHub25> scummvm/master 600fe74 Paul Gilbert: XEEN: Fix animation of wall torches
[11:08] GitHub25 (GitHub25@192.30.252.42) left #scummvm.
[11:18] <-- user9 left irc: Ping timeout: 268 seconds
[11:18] <-- frankyboy_ left irc: Remote host closed the connection
[11:40] <-- edheldil left irc: Remote host closed the connection
[11:40] --> edheldil joined #scummvm.
[12:03] <-- ajax16384 left irc: Quit: Leaving
[12:07] --> user9 joined #scummvm.
[12:08] --> _sev|work joined #scummvm.
[12:08] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[12:11] --> jamm joined #scummvm.
[12:23] --> TMM joined #scummvm.
[12:23] <-- TMM left irc: Changing host
[12:23] --> TMM joined #scummvm.
[12:23] #scummvm: mode change '+o TMM' by ChanServ!ChanServ@services.
[13:05] --> Littleboy joined #scummvm.
[13:05] #scummvm: mode change '+o Littleboy' by ChanServ!ChanServ@services.
[13:44] --> frankyboy_ joined #scummvm.
[13:56] --> dreammaster joined #scummvm.
[13:56] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[14:54] --> Henke37 joined #scummvm.
[15:05] <-- ny00123 left irc: Quit: Leaving
[15:06] --> ccawley2011 joined #scummvm.
[15:09] <-- _sev|work left irc: Quit: This computer has gone to sleep
[15:26] <snover> rootfather: are you using make?
[15:47] --> ajax16384 joined #scummvm.
[15:47] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[15:54] <-- TMM left irc: Remote host closed the connection
[15:54] <-- ccawley2011 left irc: Ping timeout: 260 seconds
[15:56] --> GitHub82 joined #scummvm.
[15:56] <GitHub82> [scummvm] csnover pushed 4 new commits to master: https://git.io/vFaIN
[15:56] <GitHub82> scummvm/master 2de83e0 Colin Snover: COMMON: Use C++11 static_assert when available...
[15:56] <GitHub82> scummvm/master 51329c0 Colin Snover: ALL: Fix misuse of comma operator
[15:56] <GitHub82> scummvm/master 972c453 Colin Snover: BBVS: Remove all bit shifts of potentially negative integers...
[15:56] GitHub82 (GitHub82@192.30.252.42) left #scummvm.
[15:56] <-- f2k left irc: Quit: Leaving
[15:58] --> GitHub15 joined #scummvm.
[15:58] <GitHub15> [scummvm] csnover pushed 3 new commits to master: https://git.io/vFaLO
[15:58] <GitHub15> scummvm/master dda0f77 Colin Snover: COMMON: Add basic fixed-width word wrap to Common::String
[15:58] <GitHub15> scummvm/master 66826a8 Colin Snover: ENGINES: Continue to check file presence after a hash/size mismatch...
[15:58] <GitHub15> scummvm/master a2bdff0 Colin Snover: ENGINES: Improve output of unknown game variant detection...
[15:58] GitHub15 (GitHub15@192.30.252.45) left #scummvm.
[15:58] --> GitHub192 joined #scummvm.
[15:58] <GitHub192> [scummvm] criezy pushed 1 new commit to master: https://git.io/vFaLn
[15:58] <GitHub192> scummvm/master 417528b Thierry Crozat: I18N: Update translations templates
[15:58] GitHub192 (GitHub192@192.30.252.42) left #scummvm.
[15:59] --> GitHub159 joined #scummvm.
[15:59] <GitHub159> [scummvm] csnover closed pull request #1042: ENGINES: Improve output of unknown game variant detection (master...unk-detect) https://git.io/vdzg9
[15:59] GitHub159 (GitHub159@192.30.252.42) left #scummvm.
[16:03] --> Stormkeeper joined #scummvm.
[16:04] <-- Stormkeeper left irc: Client Quit
[16:04] <-- ajax16384 left irc: Quit: Leaving
[16:18] --> ccawley2011 joined #scummvm.
[16:18] --> GitHub132 joined #scummvm.
[16:18] <GitHub132> [scummvm] criezy pushed 1 new commit to master: https://git.io/vFaqS
[16:18] <GitHub132> scummvm/master 7cc03fc George Kormendi: I18N: Update translation (Hungarian)...
[16:18] GitHub132 (GitHub132@192.30.252.45) left #scummvm.
[16:31] <snover> rootfather: in any case, you might consider reducing the number of engines youre compiling to speed up development. this is usually what i do. :)
[16:32] <snover> or, buy two threadrippers and give one to me
[16:36] --> ajax16384 joined #scummvm.
[16:36] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[16:39] <rootfather> snover buying a threadripper is on my agenda
[16:39] <rootfather> *one* threadripper :P
[16:41] <snover> awh.
[16:42] <snover> its ok, you can get one for yourself too.
[16:42] <rootfather> *g*
[16:44] <rootfather> I'm unsure if my new system should be based on threadripper or the i9... it should last at least for the next 5 years
[16:44] <rootfather> with just minor upgrades after two years or so
[16:45] <rootfather> but I guess for stuff like scummvm and development thingies a PC that's rather powerful nowadays might last more than a decade
[16:50] <snover> this mid-2012 MBPr is usually fine except for when i need to run hundreds of builds to test buildbot
[16:56] <waltervn> my desktop has an AMD Phenom II X4..
[16:57] <waltervn> I mainly use my laptop these days, but plan to switch back to desktop as soon as the kids stop needing constant supervision
[16:57] <Deledrius> yeah, the treadmill isn't moving as lightning-fast as it once did, thankfully.
[16:57] --> GitHub116 joined #scummvm.
[16:57] <GitHub116> [scummvm] criezy pushed 1 new commit to master: https://git.io/vFacs
[16:57] <GitHub116> scummvm/master 3bd1a5a Lothar Serra Mari: I18N: Update translation (German)...
[16:57] GitHub116 (GitHub116@192.30.252.41) left #scummvm.
[17:06] --> GitHub170 joined #scummvm.
[17:06] <GitHub170> [scummvm] criezy pushed 1 new commit to master: https://git.io/vFaCB
[17:06] <GitHub170> scummvm/master aee98ba Timo Mikkolainen: I18N: Update translation (Finnish)...
[17:06] GitHub170 (GitHub170@192.30.252.45) left #scummvm.
[17:10] --> girafe joined #scummvm.
[17:11] --> LittleToonCat joined #scummvm.
[17:21] --> kurtwr joined #scummvm.
[17:22] --> GitHub166 joined #scummvm.
[17:22] <GitHub166> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vFalC
[17:22] <GitHub166> scummvm/master 0ffbce5 Paul Gilbert: XEEN: Fix rendering of town messages
[17:22] GitHub166 (GitHub166@192.30.252.45) left #scummvm.
[17:26] <-- girafe left irc: Ping timeout: 260 seconds
[17:55] <-- dreammaster left irc:
[17:55] --> SylvainTV joined #scummvm.
[17:55] #scummvm: mode change '+o SylvainTV' by ChanServ!ChanServ@services.
[17:58] --> Strangerke_ joined #scummvm.
[18:00] <-- Strangerke left irc: Ping timeout: 268 seconds
[18:00] Nick change: Strangerke_ -> Strangerke
[18:04] <-- jamm left irc: Ping timeout: 250 seconds
[18:28] <snover> UBSan finds its first problem. StaticPlugin gets reinterpret-casted to unrelated sibling class PluginSubclass.
[18:29] --> rootfather|2nd joined #scummvm.
[18:29] <-- rootfather|2nd left irc: Client Quit
[18:32] <-- rootfather left irc: Ping timeout: 260 seconds
[18:44] <snover> well, and PluginObject child types too.
[18:45] <wjp> Where does that happen?
[18:45] <snover> EngineManager::getPlugins, MusicManager::getPlugins
[18:47] <wjp> it's casting one type of List to another type of List?
[18:49] <snover> yes. the original list is Common::Array<Plugin *>, when using static plugins it will contain StaticPlugin *, then these functions C-style cast that to Common::Array<PluginSubclass<MetaEngine> *> or Common::Array<PluginSubclass<MusicPluginObject> *>
[18:49] <snover> StaticPlugin is not a PluginSubclass<MetaEngine> or a PluginSubclass<MusicPluginObject>
[18:50] <wjp> This is certainly creative
[18:50] <wjp> Even casting one list into another is already ... odd
[18:50] <wjp> s/list/List/
[18:53] --> rootfather joined #scummvm.
[18:53] #scummvm: mode change '+o rootfather' by ChanServ!ChanServ@services.
[18:54] --> dreammaster joined #scummvm.
[18:54] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[18:54] <snover> creative, yes.
[18:56] <snover> so i *think* the only way to solve this correctly is to make StaticPlugin a templated subclass of PluginSubclass and then change all of the static plugin registration to also pass the MusicPlugin or MetaEngine types.
[18:57] <snover> or&
[18:57] <snover> i guess generate new filtered arrays
[18:58] <snover> i guess i have to look at these plugin providers more to see if theyre doing the right thing or not with their dynamic plugins.
[19:05] <-- rootfather left irc:
[19:07] --> Farmboy0 joined #scummvm.
[19:07] <-- Farmboy0 left irc: Changing host
[19:07] --> Farmboy0 joined #scummvm.
[19:41] --> criezy joined #scummvm.
[19:41] #scummvm: mode change '+o criezy' by ChanServ!ChanServ@services.
[19:44] <criezy> Good evening
[19:44] <madmoose> criezy: Good evening to you
[19:51] --> rootfather joined #scummvm.
[19:51] <-- rootfather left irc: Changing host
[19:51] --> rootfather joined #scummvm.
[19:51] #scummvm: mode change '+o rootfather' by ChanServ!ChanServ@services.
[19:51] <rootfather> snover, one of the SDL2 rendering bugs still persists :/
[19:51] <rootfather> I updated the bugs on the tracker
[19:55] --> GitHub182 joined #scummvm.
[19:55] <GitHub182> [scummvm] criezy closed pull request #1050: SDL: fix OSD message artifacts (master...fix_osd_artifacts_on_pandora) https://git.io/vFgSx
[19:55] GitHub182 (GitHub182@192.30.252.42) left #scummvm.
[19:55] --> GitHub130 joined #scummvm.
[19:55] <GitHub130> [scummvm] criezy pushed 1 new commit to master: https://git.io/vFaD8
[19:55] <GitHub130> scummvm/master bf85ad8 Patrik Dahlstrom: SDL: fix various OSD message artifacts...
[19:55] GitHub130 (GitHub130@192.30.252.35) left #scummvm.
[19:55] --> GitHub162 joined #scummvm.
[19:55] <GitHub162> [scummvm] criezy pushed 1 new commit to master: https://git.io/vFaDR
[19:55] <GitHub162> scummvm/master 1b955ae Thierry Crozat: I18N: Update translations templates
[19:55] GitHub162 (GitHub162@192.30.252.42) left #scummvm.
[19:57] --> girafe joined #scummvm.
[19:58] <snover> rootfather: thanks!
[20:02] <rootfather> no need to thank me... I want a perfect windows release of ScummVM :P
[20:02] <rootfather> So I have to thank *you* for investigating this because it is way beyond my skills
[20:04] <rootfather> btw I think we should make openGL the default renderer for Windows... it has a better performance, at least for me
[20:04] <rootfather> cursor movements are way smoother
[20:07] <snover> it has problems with vsync.
[20:08] <snover> there are really just all sorts of fundamental problems with the way the renderer runs on the same thread as the game engine
[20:08] <snover> the same sorts of problems that would happen if the sound ran on the same thread as the game engine
[20:10] <rootfather> so at one point we will have to move the renderer in a separate thread?
[20:11] <snover> for things to really work correctly, probably. for instance, https://github.com/scummvm/scummvm/pull/1039.
[20:13] <rootfather> sounds like a huge task
[20:13] <snover> yes, i would say so.
[20:14] --> _sev joined #scummvm.
[20:14] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[20:14] <snover> it would actually be less moving the renderer to a separate thread and more moving the game engines to a separate thread, since SDL apparently really doesnt like it if you try to do graphics and events stuff off the main thread.
[20:15] <rootfather> ouch
[20:15] <rootfather> this would involve touching the code of all engines, right?
[20:15] <snover> i am sure it would break an awful lot.
[20:17] <criezy> In my Qt backend I am actually doing just that. Because the Qt event loop runs in the main thread, I moved the scummvm loop into a separate one.
[20:18] <criezy> Rendering to surfaces (QImage actually) is done in that separate thread, but I had to keep actual rendering to screen in the main thread.
[20:18] <rootfather> you have a Qt backend?!
[20:18] <criezy> A partial one yes. It is very low priority, so progress is slow.
[20:19] <rootfather> that sounds cool
[20:19] <rootfather> any possibility to check it out? :D
[20:20] <snover> i had to hack things in the opposite direction for SCI engine; mouse movement in DOS is handled via interrupt, so the engine expects that the hardware will just interrupt execution to move the mouse around, so the mouse would become non-responsive when the game was running an inner loop checking the mouse position that didnt cause any rendering updates
[20:21] <snover> the audio fades in phant2, the menus in lsl6, various other smaller places&
[20:21] <criezy> rootfather: Soon hopefully. I would like to clean it a bit before sharing. I am planning to spend some time on it during my christmas holidays.
[20:22] <snover> in the end i would have had to make most of the changes anyway since otherwise the game would just be at 100% CPU all the time in spinloops
[20:22] <snover> but it was still annoying and it still glitches out every once and a while.
[20:22] <snover> oh, the cant interact here cursor in KQ7
[20:23] <snover> the click to continue in phant2
[20:23] <snover> so many memories!
[20:24] Action: criezy wonders why we have a --disable-c++11 option in configure that doesn't do anything (and certainly doesn't disable c++11).
[20:25] <criezy> And I don't really see why we might want to disable c++11 either for compilers that do support it.
[20:25] <snover> probably emulating the symmetric API of traditional autoconf configure
[20:26] <rootfather> criezy that sounds interesting
[20:26] <rootfather> count me in for beta testing
[20:27] <snover> there are syntaxes valid in c++11 that are not valid in c++98 like Foo<a<b>> so, theoretically, in that time between where c++11 is the default mode and c++98 is still supported (if this ever actually is a thing) it would be good to be able to disable c++11 on buildbot to make sure its not broken.
[20:27] <snover> for one worker.
[20:27] <snover> the opposite of now where it is enabled for one worker.
[20:28] <snover> but of course it has to actually *do* something.
[20:34] --> GitHub66 joined #scummvm.
[20:34] <GitHub66> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vFaQq
[20:34] <GitHub66> scummvm/master b73892e Paul Gilbert: XEEN: Fix event handling for town messages
[20:34] GitHub66 (GitHub66@192.30.252.34) left #scummvm.
[20:37] --> vasc joined #scummvm.
[20:37] <vasc> trying to understand the midi driver...
[20:37] <vasc> but i wonder how to actually play something with it
[20:38] <vasc> Dynamix's Rise of the Dragon PC seems to use Midi similar to SCI 1.2 (Jonas in the Fast Lane CD).
[20:39] <vasc> but... it's a pain to include the SCI code. i mean, i don't want to include a resource manager. if i even know how to do it.
[20:39] <vasc> i just want to create a MidiPlayer and pass it a buffer with the .snd file.
[20:39] <snover> well thats unfortunate, since the SCI MIDI parser is currently broken and is second on my list of things to do in SCI.
[20:39] <snover> hopefully dynamix actually used standard SMF instead of the custom one that SCI used?
[20:40] <vasc> i can send you a raw dump of a file for you to analyze if you want.
[20:40] <vasc> i wonder how to actually use test it.
[20:40] <snover> well, can MidiParser_SMF parse it?
[20:40] <vasc> hm

[20:44] <vasc> that's what I get with MidiParser::create_SMF()
[20:45] <vasc> it's supposedly the exact same as an SCI 1.2 .snd file.
[20:46] <vasc> or how can i include the SCI player and play a dump without much fuss?
[20:46] <vasc> given a bytestream
[20:46] <vasc> or a byte * buffer.
[20:47] <snover> as a hack, just include it. if its a common format, then it needs to be broken out to common code for any final release.
[20:47] <vasc> or, alternatively, how to test with the SCI player to see if at least the data is as i expect it to be
[20:47] <vasc> like, replace the JONAS in the fast lane music with one of these
[20:48] <vasc> to see if it plays it
[20:48] <Lightkey> Jonas in the Fast Lane :-D
[20:48] <vasc> in DGDS games you just need to place the files in the current directory, like put the .SND file there
[20:48] <vasc> yeah it's Jones
[20:48] <vasc> and it replaces the one in the game archives
[20:49] <Lightkey> <-- Jonas
[20:49] <logix> in the lightspeed lane?
[20:49] <snover> if it is indeed a sierra snd resource patch file you can just put it into the game directory as <number>.snd and then use& one of the sci debugger commands to play it
[20:49] <vasc> hm
[20:49] <snover> open the sci debugger with ctrl+shift+d and type 'help'
[20:49] <vasc> ok
[20:49] <snover> i cant remember what it is and i am in the middle of a refactor so i cannot start scummvm right now quickly to check
[20:58] <vasc> do the numbers need to be in a particular format?
[21:01] <snover> decimal number.
[21:01] <snover> the debugger command for playing sounds accepts a number.
[21:06] <vasc> uh, i can't quite figure it out
[21:06] <vasc> yep
[21:06] <vasc> it works
[21:06] <vasc> it's the same format
[21:07] <snover> well then move onto something else for a while since that parser needs to be rewritten :\
[21:08] <vasc> it plays nice
[21:08] --> Strangerke_ joined #scummvm.
[21:08] <snover> i mean, it will work mostly and then occasionally it doesnt do things exactly right, and so if you rely on it for audio-timed signals as sci does, those might not fire and the game might softlock.
[21:09] <vasc> well i don't have a game interpreter for DGDS yet. so it's not like i know that yet.
[21:09] <snover> criezy: fwiw, with the new buildbot, the oldest gcc version for an active port is 4.9.1.
[21:09] <vasc> i figured out the cinematic sequence format somehow but the game machine is another thing.
[21:10] <vasc> i'm assuming it uses a virtual machine.
[21:10] <-- Strangerke left irc: Ping timeout: 240 seconds
[21:10] Nick change: Strangerke_ -> Strangerke
[21:17] <vasc> https://drive.google.com/file/d/1fsDJ_2SLkmzNG_IrKfaHc6goZhygoNkH/view?usp=sharing
[21:17] <vasc> that's the title music.
[21:18] <vasc> i renamed it as 1005.snd, put it into the Jonas in the Fast Lane (CD) directory
[21:18] <vasc> then in ScummVM i used CTRL+Shift+D like you said
[21:19] <vasc> then did: stopallsounds
[21:19] <vasc> startsound 1005
[21:19] <vasc> kewl, thanks
[21:20] <vasc> i still have a lot of other tasks to do
[21:20] <vasc> but now you know you got another user for the SCI 1.2 midi driver if you want one
[21:20] <vasc> :-)
[21:20] <vasc> i'll try to figure out some way to untangle the midi driver from the code
[21:21] <vasc> or hack it somehow
[21:21] <vasc> that's the issue with C++. too many classes and it becomes a Lasagna fest.
[21:21] <vasc> you can't take one piece away from the rest.
[21:29] <-- demonimin left irc: Remote host closed the connection
[21:36] <snover> thats not really any issue here
[21:38] <vasc> well
[21:38] <vasc> you can do a lot of things with callbacks and things like that.
[21:38] <snover> im not sure how that is relevant here?
[21:38] <vasc> the way the IFFParser in ScummVM works for example.
[21:39] <vasc> well it's just that having classes do memory allocating and memory handling, for example, can often be an issue when trying to refactor the code for something else.
[21:39] <snover> eh?
[21:39] <vasc> well nevermind.
[21:40] <vasc> i was trying to write my own midi parser and player, but i think i can't quite figure it out.
[21:42] <snover> did you see the documentation in midiparser.h?
[21:42] <vasc> still, it must have been a lot of work to write that midi player for SCI. it has more lines of code than what i have on DGDS alone.
[21:43] <vasc> hm
[21:43] <vasc> well i guess i could try loading a regular midi file with the SMF player and see if that works
[21:44] <vasc> and go from there
[21:44] <vasc> i was copying the one from parallaction
[21:45] <snover> yes, there are tons of different variants of MIDI in SCI. different versions of the engine changed the MIDI code, and it supported many different sound cards and each of them had their own separate driver and separate music stream from the snd file
[21:45] <wjp> and then there's the whole channel (re)mapping and corresponding state tracking
[21:46] <vasc> yes. the resource files in Rise of the Dragon for example have their own sound drivers.
[21:46] <vasc> and their own VGA driver even.
[21:46] <vasc> that's causing me issues with reverse engineering some of the graphics code.
[21:46] <wjp> not sure why you say "even" :-)
[21:47] <vasc> the Macintosh port for example has a SOUNDS.P file with sound samples in it, and the Midi .SND file is separate
[21:47] <wjp> you need drivers to talk to hardware...
[21:47] <vasc> i'm having issues decoding some images because of that.
[21:48] <vasc> i can only load the images in the MacOS port for example, because they're uncompressed.
[21:48] <vasc> or should i say they're LZW compressed, but packed differently.
[21:50] <wjp> things were typically just much closer to the hardware in those days
[21:51] <vasc> well, the images are in like two linear 4-bit buffers for example
[21:51] <wjp> (although I suppose nowadays that's the case again with GPUs)
[21:51] <vasc> so yeah
[21:51] #scummvm: mode change '+o Strangerke' by ChanServ!ChanServ@services.
[21:51] <wjp> planar vga I suppose
[21:51] <vasc> yeah
[21:52] <vasc> the Amiga port uses 5-bit bitmaps, but i haven't figured out the file format yet.
[21:52] <vasc> it seems to use RLE compression, because of the file sizes, i think it does
[21:53] <vasc> thanks for the help with testing the audio snover
[21:53] <vasc> at least i know i don't need to reverse engineer this bit.
[21:54] <snover> no problem!
[21:55] <snover> man, these updates for ASan/UBsan are finding all sorts of bugs.
[21:55] <snover> bugs bugs bugs.
[21:55] <snover> const char *fileName = file->getName().c_str(); getName returns a String, not a reference to a string, so that pointer is garbage after the statement.
[21:56] <wjp> ah, that's always a nice one
[21:56] <snover> figuring out what is the best thing to do with these plugins is burdensome today. my brain is just not functioning.
[21:56] <wjp> prince's text handling is one big bug of that type IIRC
[21:57] <snover> the list, or at least the plugin objects in the list returned by getPlugins, need to be owned by something else because pointers to the returned plugin objects are retained
[22:00] <-- ajax16384 left irc: Read error: Connection reset by peer
[22:00] <snover> so just making PluginSubclass a wrapper around the original Plugin and returning an Array isnt quite good enough
[22:01] <snover> an Array<PluginSubclass>*
[22:01] <snover> i hate that anyway so this is fine.
[22:02] <snover> i think maybe ill just change this so the _pluginObject can be retrieved at call sites with a cast, similar-ish to how std::variant works.
[22:02] <snover> instead of operator* / operator-> overloads
[22:03] <snover> wjp: if you have any better ideas, please let me know, i am not feeling confident today :)
[22:03] <snover> bbiab.
[22:03] <wjp> I'm not sufficiently here to think about things right now
[22:19] --> GitHub122 joined #scummvm.
[22:19] <GitHub122> [scummvm] criezy closed pull request #1041: Fix undefined behaviour in variadic functions (master...variadic-undefined) https://git.io/vd0JW
[22:19] GitHub122 (GitHub122@192.30.252.42) left #scummvm.
[22:19] --> GitHub181 joined #scummvm.
[22:19] <GitHub181> [scummvm] criezy pushed 7 new commits to master: https://git.io/vFVfy
[22:19] <GitHub181> scummvm/master 99abd64 Thierry Crozat: HUGO: Fix undefined behaviour in variadic functions...
[22:19] <GitHub181> scummvm/master 51df065 Thierry Crozat: KYRA: Fix undefined behaviour in variadic functions...
[22:19] <GitHub181> scummvm/master 448779a Thierry Crozat: LURE: Fix undefined behaviour in variadic functions...
[22:19] GitHub181 (GitHub181@192.30.252.34) left #scummvm.
[22:28] <-- frankyboy_ left irc: Remote host closed the connection
[22:30] --> TMM joined #scummvm.
[22:30] <-- TMM left irc: Changing host
[22:30] --> TMM joined #scummvm.
[22:30] #scummvm: mode change '+o TMM' by ChanServ!ChanServ@services.
[22:32] <-- TMM left irc: Read error: Connection reset by peer
[22:33] --> TMM joined #scummvm.
[22:33] <-- TMM left irc: Changing host
[22:33] --> TMM joined #scummvm.
[22:33] #scummvm: mode change '+o TMM' by ChanServ!ChanServ@services.
[22:41] <criezy> I have a SDL2 question: in SurfaceSdlGraphicsManager we use the SDL_RLEACCEL flag when calling SDL_SetAlpha, SDL_SetColorKey and SDL_CreateRGBSurface for the cursor and osd surfaces.
[22:41] <criezy> However the first two go through wrapper in backends/platform/sdl/sdl.cpp as they were removed from SDL2, and the flag is not passed to SDL.
[22:42] <criezy> The last one is documented as saying that the flag passed to is is not longer used and should be 0.
[22:43] <criezy> Thus I am wondering if we should add calls to SDL_SetSurfaceRLE in our SDL_SetAlpha and SDL_SetColorKey_replacement function in sdl.cpp...
[22:45] <snover> i guess so. it might be worth doing a performance profiling to see if it actually makes a difference in rendering performance as it claims.
[22:45] --> Strangerke_ joined #scummvm.
[22:47] <-- Strangerke left irc: Ping timeout: 240 seconds
[22:47] Nick change: Strangerke_ -> Strangerke
[22:49] #scummvm: mode change '+o Strangerke' by ChanServ!ChanServ@services.
[22:51] --> Strangerke_ joined #scummvm.
[22:54] <-- Strangerke left irc: Ping timeout: 268 seconds
[22:54] Nick change: Strangerke_ -> Strangerke
[23:14] <criezy> It might be marginally faster, but it doesn't make much of a difference on my iMac.
[23:19] <-- Henke37 left irc: Quit: ERR_SHUTDOWN
[23:27] <snover> & this UBSan might take a while to make happy.
[23:28] <snover> I finally fixed enough that I could add the demo to work on https://bugs.scummvm.org/ticket/10116. I hit the save hotkey and run right into a misaligned pointer use.
[23:28] <TMM> criezy, it may be worth asking icculus
[23:28] <snover> though this might actually be masking the crash.
[23:29] <snover> since it is trying to access 0x2a :)
[23:31] <criezy> Interestingly it takes twice the CPU to use the OSD message rect as a dirty rect vs. updating the full screen.
[23:33] <criezy> Hmm, no, not twice. I am mixing graphics mode here. With HQ3C it uses ~23% CPU with a dirty rect and ~16% with a full screen update.
[23:33] <snover> somewhere recently i read that its faster on modern architectures to just send contiguous block of data instead of doing random access jumps around
[23:33] <snover> even if it is more data
[23:33] <snover> i assume there is some threshold for this but i wonder if that is what you are experiencing.
[23:34] <criezy> Possibly yes,
[23:34] <snover> since a dirty rect is going to skip the areas of the memory within each row that arent changed, that could be more work than just sending all the rows including the unchanged pixels
[23:34] <criezy> I wonder if there is a way to monitor CPU while in fullscreen.
[23:34] <snover> get two monitors ;)
[23:35] <snover> Instruments will give you a recording that you can go back and review later.
[23:36] <criezy> Ah, thanks. Let's try that.
[23:36] <criezy> That should be faster than get out and buy a monitor (and all shops around here are probably closed at this time).
[23:37] --> krautguy joined #scummvm.
[23:37] <krautguy> hellooo dear channel
[23:38] <logix> or ssh in from a second machine and run "top" there
[23:38] <krautguy> i startet a game with scummvm but it runs way to fast. is there a possibility to slow it down?
[23:38] <snover> or set up a web cam, and point the webcam at the computer, and then connect it to your phone, and then put the phone on a flatbed scanner, and then
[23:39] <snover> im sure this will work out eventually
[23:39] <criezy> logix: Yes, I do that with my laptop from time to time. But I am too lazy to boot my laptop right now :P
[23:39] <criezy> krautguy: hello
[23:39] <criezy> What game is it?
[23:39] <snover> find an infrared thermometer and measure the cpu usage by checking the temperature of the case
[23:40] <krautguy> it is maniac mansion enhanced dos version
[23:40] <krautguy> even the intro music is to fast
[23:42] <snover> too fast compared to what?
[23:42] <criezy> I don't have Maniac Mansion and I am not familiar with the SCUMM engine, so I don't really know if there is a way to slow it down, or even if there are know speed issues with it.
[23:42] <logix> sync your update routine with the CRT refresh, change the background color to white when you start and then to black when your code is done then CPU usage == percentage of screen that's white (ignoring the beam reset time)
[23:43] <logix> it's almost TOO easy
[23:43] <criezy> Oh, actually I do own Maniac Mansion. Maybe I should play it some day.
[23:43] <TMM> beam reset time? :P
[23:43] <logix> wait, you're saying you don't have a CRT screen?
[23:43] <TMM> freesyncing lcd
[23:43] <snover> vbi
[23:43] <TMM> :P
[23:43] <logix> TMM: movement back from the lower right position to the upper left
[23:44] <-- _sev left irc: Quit: This computer has gone to sleep
[23:44] <criezy> I was thinking of measuring the time it take to cook an egg on the computer.
[23:44] <krautguy> snover, it is too fast compared to the original on a non-emulated system. i do own Maniac Mansion for the Amiga, so i know very well how fast the music has to be
[23:44] <TMM> on my computer only 1 minute!
[23:44] --> _sev joined #scummvm.
[23:44] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[23:44] <krautguy> i fear there might be an timing issue with my scummvm
[23:45] <waltervn> maybe it's a PAL vs NTSC music timing thing?
[23:45] <snover> yeah, my first gut reaction is to say that you cant compare music across such different platforms
[23:45] <krautguy> the cursor is blinking to fast either.. and the guys are running
[23:46] <waltervn> I don't know the details of SCUMM, but for SCI, on PAL machines the music is too slow
[23:46] <TMM> it's hard to determine what 'arcade perfect' means if you're on such different machines :-/
[23:46] <criezy> Er, my maniac mansion is in French...
[23:46] <criezy> not surprising actually since it was extracted from my French DOTT
[23:46] <TMM> copy the files from dott?
[23:47] <snover> according to youtube, the music is faster in the DOS version than the Amiga version
[23:47] <snover> so thats normal.
[23:47] <krautguy> but can that be right?
[23:47] <snover> assuming these videos are accurate.
[23:49] <snover> it absolutely can be right. the amiga was totally different hardware.
[23:49] <waltervn> it's possible that on NTSC Amiga the music is the same speed as DOS. That's the case for SCI (which means little here, I know)
[23:50] <TMM> if you read the reasons why ntsc and pal are different at all it really makes you angry :P
[23:50] <krautguy> mhhh
[23:50] <TMM> especially since we still have to deal with it today
[23:50] <logix> what speed difference are we talking of anyway?
[23:50] <snover> https://www.youtube.com/watch?v=ydij0byAzfc amiga version in amiga emulator, https://www.youtube.com/watch?v=p7Ppl5wb1u0 dos version in dos emulator
[23:51] <-- Lightkey left irc: Ping timeout: 258 seconds
[23:51] <waltervn> 50Hz vs 60Hz usually
[23:51] <snover> i saved you guys the hassle of having to listen to a pc speaker rendition.
[23:51] <logix> if it's (say) a 50% difference, I'm not sure if I'd put my money on PAL v NTSC...
[23:51] <waltervn> so quite significant
[23:52] <snover> itd be about 16% faster on NTSC.
[23:52] <logix> waltervn: yes, right, the question is if krautguy's problem fits those numbers, i.e., if he estimates the difference to be in the range of say 10-25%
[23:52] <waltervn> right, I wasn't sure who you were asking :P
[23:52] <krautguy> i'll watch some videos from the dos version
[23:52] <snover> you guys dont have to guess, since i gave links to the non-scummvm versions of the two games for comparison :)
[23:53] <snover> i mean. dont let me stop you.
[23:53] <logix> waltervn: right, I should have made that clearer
[23:53] <krautguy> i am not saying that there is no difference between the platforms
[23:54] <krautguy> but i am talking about two or three times as fast as on the amiga. the music feels like an completely different song. may it be that i use a raspberry pi for running ScummVM?
[23:56] <krautguy> but i really wonder why, cause i played Zak McKracken on the same ScummVM-Installation with the same settings before and it went perfect.
[23:56] <snover> krautguy: did you go to the videos that i linked?
[23:57] <snover> the music in the PC version is different. it is faster. this is normal. not a scummvm bug. this is how ports used to be.
[23:58] <waltervn> BTW, has anything been decided yet regarding the release schedule?
[23:59] <snover> waltervn: only what was said so far on the ML.
[23:59] <waltervn> ok, thanks
[23:59] <TMM> I'm kind of hoping for a 2.0 with a little more testing. I'll happily test a bunch of games if necessary myself
[00:00] --- Sat Nov 11 2017