Possible new version of SCI Companion

[troflip]

Oh yes, that's true. There's no reason to use Express now though, since Visual Studio Community Edition 2013 is free (and SCI Companion requires the c++11 features implemented in VS 2013).

MS also deprecated the non-unicode MFC libraries for VS 2013, so to build you need to also download the MBCS MFC libraries here: http://go.microsoft.com/?linkid=9832071

(I suppose I could at some point switch SCI Companion to unicode, but given that Sierra games aren't unicode, it wouldn't be trivial to make this switch).

[Collector]

Seems like I heard that MS was starting to deprecate MFC in general.

I'm still using 2010 VS Express. I hadn't moved on as there seemed to be an emphasis on "apps" for the Windows Store. I was halfway waiting for the version that would be more oriented to Windows 10 before upgrading. Though I have heard of a couple of features in the latest C# that would be nice. I work primarily C#. My dabblings in C++ are mostly just to create some GDFs, compile newer versions of certain open source projects or to make some minor tweaks. The lack of MFC is something that has stymied me more than once in the past. I have not been able to do much with Soundbox because it was done with MFC. We had just wanted to add an argument to directly open a SOUND resource by calling Soundbox.

I have not done anything with MFC, but for UIs, how much of an advantage is it over simply doing a Win Forms application?

[troflip]

I'd probably rather use winforms, but for a strictly native code app there aren't really any good alternatives to MFC. So it's not like it has "advantages" - it's old and crufty - but it's just what you use for native c++ on windows desktop.

[Collector]

My VS2010 has WinForms for C++, at least the designer. The generated script ends up as a header file as opposed to C#'s partial classes.

[troflip]

That's c++/CLI, not standard c++. It's still managed code (or at least all the winforms stuff will still be managed code).

c++/CLI is intended mainly for managed/native interop scenarios. So yes, using winforms through that could be a stepping stone to transforming SCI Companion into a fully managed code application. But I'd rather just go full C# if that happened. MS doesn't recommend writing new apps in C++/CLI, and apparently the winforms C++ template has been removed from VS 2012 and newer.

[troflip]

Here is some sample output from the decompiler, for a few of the rooms/scripts in Space Quest 5.

I notice some of the kernels are incorrect. For instance, room 110 (the opening room) transitions palettes, and it ends up being identified as Joystick kernel call.  I know various kernel functions moved/changed between SCI versions, but looking at the SCUMMVM source code, there was never any palette-related kernels that were in the Joystick slot (0x6d), so it's a bit strange.
Anyway, I'll need to provide some kind of config file to allow for differences in kernel functions in different versions.

This is a lot more powerful that Brian's decompiler was going to be, since it does control flow analysis and attempts to recover higher level constructs like if/else, compound conditions, loops and switch statements. There are still some flow control structures I can't identify though, so I'll have to leave those odd functions as assembly.

[MusicallyInspired]

Nice! This is fascinating stuff! I'm going to have to mull through these. I'm excited to peruse through Sierra's scripts when this is completed. Great work and progress so far, troflip! Awesome awesome.

[troflip]

One weird thing you'll notice is that there are a bunch of class names that start the init method of the SQ5 game class (in main script). I'm guessing "using" the class like with (without doing anything with it) perhaps loaded the scripts into memory or something? That way there wouldn't be any pauses when that code was actually needed later on and the game needed to load the script from the relatively slow hard drives of the time.

[OmerMor]

Amazing job troflip!

[troflip]

I'm taking a short break from the decompiler work, and today I implemented some very basic sound effect support (currently only tested with the SQ5 interpreter). You can drag a wav file into SCI Companion, and assuming it's the right format (uncompressed, 8 or 16 bit), it will add it to the game as an audio resource. I managed to test this successfully by replacing a sound effect in SQ5.

It currently only supports SCI versions that have separate audio resources (as opposed to a digital track embedded in the midi snd resources, which I think even some SCI0 games support?).

Is anyone familiar with the logic SCI uses to play these audio resources? It looks like there is often a sound resource equivalent for an audio resource... (e.g. midi sound resource 109 kind of sounds like audio resource 109) - but not always. Lots of midi resources don't have sound effect equivalents of course - but the reverse is often true too. And some equivalents don't sound alike at all.

[Collector]

There weren't too many of the games that used the embedded wav in the SOUND resource. Mostly just the SCI01 games (KQ1SCI, KQ1SCI demo, SQ3, Some versions of LSL3, QfG2 and QfG2 Demo) and the early SCI1 games (KQ5 floppy, LSLVGA Demo, Mixed-Up Fairy Tales VGA, 1990 XMas Card EGA & VGA, SQ4 floppy). There is the old AddWav that appended a wav file into a SOUND resource for those. That said, is it really worth the effort to add support for these appended resources if there is support for later SCI1 and SCI1.1?

[MusicallyInspired]

Yes. Yes it is. What if we want to be like Sierra sometimes and make 4 different versions of our games (like Mixed Up Mother Goose)? EGA Parser SCI0, EGA parserless SCI1, VGA parserless SCI1, and VGA SCI1.1? Or we could just do it ourselves with AddWave.exe...

As far as how Sierra implemented pairing of MIDI/digital sfx, I only know how they handled it for SCI0 and early SCI1, which is obvious at this point. Never really delved into that aspect for later versions as we had no tools to make anything with them anyway. One area I was never curious about....now you've made me curious. I wonder if it's as simple as having a conditional block of code in the scripts calling for whether the game is running with digital sounds or not? I do know that some games do not have any MIDI equivalents of sound effects at all. There isn't a variation for SQ5's "Doh!", for instance. But there is for when the janitor closet contents spew onto the floor. Maybe it's just as simple as that? Not having equivalents if there are no sounds with the same number for both MIDI and digital?

Is there also a sampling rate limit, troflip?

[MusicallyInspired]

I know you're not working on palette stuff right now, but I was just fooling around with SCI Viewer here and I noticed that in the colour palette cycling animation feature, you can set two or more isolated colour selections to cycle through with the use of a comma. For instance, in SQ4's title screen the colours 128-159 cycle independently of colours 160-191. But they're also cycled backwards through the palette rather than forward. So in SCI Viewer's "Colors" field when viewing 1.P56 you'd enter:

Code: [Select]

159-128,191-160
And the colour cycling animation would appear as it does in-game. It would be useful if this preview feature were also in SCI Companion. Also, I had another thought. It'd be easier than entering exact numbers if we could select a series of colours in the palette manually with the mouse (much like text in a word processor) to cycle and Companion would create the palette entry number sequence from that. Manually typing in the numbers in a text field a la SCI Viewer would also be handy, though, as well as it doubling as an output feature which we could quickly extrapolate which palette entries are used in the cycling so that we can more quickly enter them in a script.

Also, if possible please add an optional checkbox for a palette entry ID field to each block of colour so that each colour has its palette number inside the box. Or even just have the numbers beside or beneath the colour. I hate having to count rows, multiply by 16, and then subtract backwards from the last entry in the row to get the colour number lol.

EDIT: Also, I just realized that in SQ4 the "IV" is actually a VIEW but the colours are still cycling. Would it be possible to, in addition to adding VIEWs to a PICTURE when editing it (as we already can), have the colours of the VIEW cycle along with the PICTURE? Or even implement colour cycle previewing in the VIEW editor as well as the PICTURE editor.

Just typing this gives me another idea. What if we could add as many VIEWs (within reason or memory consumption economics) as we wanted to a PICTURE when editing and then click a button to generate a SCRIPT or code blocks which would add every item we've put on the screen into the PICTURE's room SCRIPT with basic info like X/Y location, Loop/Cel values, and Priority value? This might make it easier for some people (especially newcomers) to build their game rooms quickly. Extra info like animation and moving an actor across the screen would obviously be scripted manually, but it'd be a great starting point. You could even do this with other handy room-related things like background music or sound effects with "play on entry" checkboxes or something akin to AGS's interface.

This is all stuff that could come after the actual important features are implemented, though. I'm just brainstorming here. Hopefully I'm not overwhelming you lol. Heck, this doesn't even have to be in the Picture editor (although that'd be easiest). You could create a sort of Room Preview feature which you could add the basic ideas I've listed here among maybe even more, which could then be exported to the SCRIPT. Maybe it could even read the current SCRIPT and extrapolate a preview from it, again with only simple features like actor/prop X/Y locations, Room music, etc. Conditional expressions and other more advanced code blocks would just be ignored. You might as well rewrite the whole interpreter if we were to go that route.

[Collector]

Yes. Yes it is. What if we want to be like Sierra sometimes and make 4 different versions of our games (like Mixed Up Mother Goose)? EGA Parser SCI0, EGA parserless SCI1, VGA parserless SCI1, and VGA SCI1.1? Or we could just do it ourselves with AddWave.exe...

I already mentioned AddWave, which is included in the SCI Sound Utilities, along with Gumby's ExtractWav. If it is not that big of a deal to include it in the IDE, that would be great, but I would give it a lower priority than other features since it was only used for a few games. This might be nice for creating patches for the official games, but for game creation using  SCI1.1 should not be that much different esthetically than SCI1 and would give the advantage of discrete digital sounds.

That does bring to mind features of SCI on other platforms. Having Amiga sounds for PC SCI0 would be nice, much like the KQ4 Amiga sound patch for the PC version.

As far as how Sierra implemented pairing of MIDI/digital sfx, I only know how they handled it for SCI0 and early SCI1, which is obvious at this point. Never really delved into that aspect for later versions as we had no tools to make anything with them anyway. One area I was never curious about....now you've made me curious. I wonder if it's as simple as having a conditional block of code in the scripts calling for whether the game is running with digital sounds or not? I do know that some games do not have any MIDI equivalents of sound effects at all. There isn't a variation for SQ5's "Doh!", for instance. But there is for when the janitor closet contents spew onto the floor. Maybe it's just as simple as that? Not having equivalents if there are no sounds with the same number for both MIDI and digital?

I don't think that they did it for more than SCI0 and early SCI1. SQ5's interpreter has both a flag for soundDrv and audioDrv, so there would be little reason to embed digital samples in the sound resources. You had to have SB capable hardware to hear the samples, whether embedded or a discrete resource.

[troflip]

Yes. Yes it is. What if we want to be like Sierra sometimes and make 4 different versions of our games (like Mixed Up Mother Goose)? EGA Parser SCI0, EGA parserless SCI1, VGA parserless SCI1, and VGA SCI1.1? Or we could just do it ourselves with AddWave.exe...

Well, it might be fairly trivial to add it. But I won't have that as a goal.

I do know that some games do not have any MIDI equivalents of sound effects at all. There isn't a variation for SQ5's "Doh!", for instance. But there is for when the janitor closet contents spew onto the floor. Maybe it's just as simple as that? Not having equivalents if there are no sounds with the same number for both MIDI and digital?

I tried adding audio resources for some of the sounds in the opening of SQ5. The midi sounds for the corresponding resource numbers stopped playing, but my sound was also not played. So it looks like it's not quite as simple as that. Maybe the sound resource needs to be modified slightly too? I tried looking through the SCUMMVM code to see how they handle it, but it wasn't obvious. Or maybe the midi sound and the digital audio need to be exactly the same length?

Is there also a sampling rate limit, troflip?

I'm sure there is. The sounds in SQ5 are all 11025Hz. I tried using a 22050Hz one and that worked too. I think the main limit will be the total byte size of the audio though. Everything in SQ5 is under 64KB, which means the samples are only a few seconds long at most. LSL6 (which I think is a slightly later game than SQ5) has several sounds larger than that (and it also uses 16 bit audio instead of 8 bit).

So for music, you may still need to use midi, or something like sciAudio.