SCI Companion V3 - alpha build notes/bugs/feature requests

[Kawa]

That's the fun part isn't it? In VB Classic as well as WinForms, you can just go like thisOneMenuItemInParticular.Enabled = false. In raw Win32 you would do something like SetMenuItemInfo(entireMenuHandle, positionOrCommandId, boolMatchingThePreviousArg, weirdStruct);. I can't go into more detail than that because Microsoft's web site is being Very Weird recently.

But in MFC? Sure, you can do the same thing considering it's built on top of Win32 (as are VB Classic and the first version of WinForms' menu bar) but you're supposed to use ON_UPDATE_COMMAND_UI to bind a function that does the actual disabling? It's kinda whack. And there's an ON_WM_CONTEXTMENU message that causes ::OnContextMenu to be called, and then you get to mess with an MFC Menu that in turn wraps a Win32 one and EEEEUUUUGH WOAH I get why it's like that but jegus!

[Kawa]

Does anybody have any thoughts on this idea I had regarding how the original games use DOS-437 text encoding while SCI Companion uses Win-1252??

https://github.com/Kawa-oneechan/SCICompanion/issues/19#issuecomment-1596308677

TL;DR: I have long ago disabled the Studio/Sierra language dropdown in favor of having only Sierra script code. Now I would like to turn that into a codepage dropdown. This way I can hopefully solve the issue without having to mess with MFC in an attempt to add an all new dropdown. Selecting "DOS-437" will make text/message editors convert to and from Win-1252, and (de)compilation will likewise convert string literals. Template games might be set to Win-1252, while the default/fallback is DOS-437.

(?: gross assumption, I know.)

[doomlazer]

I think it's a positive change even if it's mostly only beneficial to translators.

Related to that, but slightly off topic - One of the biggest challenges for SCI0 translators is that players cannot enter extended characters. This greatly limits the commands available to non-english players. I know what you're proposing does not address this, but it got me thinking about the problem.

Most SCI0 interpreters do not allow entering extended characters, the one exception I know of being the French version of LSL3. I tried copying its sierra.com and sciv.exe into the english version of SQ3 hoping it would allow ext chars there too. On launch it complains about the missing French vocab resources (902, 910, 911, 912, 913). I exported those and it tries to start, but freezes on a black screen with the hand cursor. Perhaps, exporting some other scripts from LSL3FR that would allow it to run, or maybe I'm headed down a dead end here.

Even if it were to work, there are other hurdles to overcome in SCICompanion. Typically you can only edit vocab 000 or 900. It seems like one way around that would be exporting, say, vocab 910, importing it as 900, making changes and then exporting again. However, there is yet another problem. SCICompanion will not allow you to enter extended characters into a vocab. If you try, it gives a warning when saving.

Extended characters in player commands is a problem that was recently solved in AGI thanks to AGK's string hack. It would be nice if a solution could be found for SCI0 as well. 

[Kawa]

I have implemented the codepage thing. Last night's nightly is bugged though and the Version Detection window will crash the program because I made a tiny mistake while making the DLGINIT resources more readable. Tonight's release should work fine.

[snobes]

Hello.

I'm new to the forum and am wanting to get familiar with the SCICompanion code base/development. I want to make sure I understand the administrative/flow/history of how the forum/project works. Please correct my assertions or provide more information to my answers if possible.

- The most worked on repo is Kawa's fork (https://github.com/Kawa-oneechan/SCICompanion). Is this now the defactor SCICompanion source code moving forward?
- Was there a reason for the fork? Are the original developers no longer contributing?
- Is there documentation about getting your feet wet? (ie. core logic, example PR, etc...)
- Are there requirements for PR submissions?
- Can any issue just get picked up and worked on?
- I'm brushing off my c++ skills (been a year or two). I primarily work in a linux environment. I figure all development is done in a windows environment, correct? I'm not familiar with windows development. Anyone have any luck with developing on a non-windows environment, or do I need to get exposed to windows development for a better experience?
- Are there rules/guidelines to this forum? (ie. tech questions go here, general questions go there, etc...)

Thanks for the responses and help. 

[Kawa]

Hello.

Hii~

Is this now the defactor SCICompanion source code moving forward?

(de facto) Basically yes, because...

Was there a reason for the fork? Are the original developers no longer contributing?

... Phil mostly changed focus on his own Unity-based SCI games like Cascadia Quest and Snail Trek. His last changes were fixing a pen brush difference and working on a scripted particle animation generator for his games two years ago.

Is there documentation about getting your feet wet? (ie. core logic, example PR, etc...)

I don't understand the question.

Are there requirements for PR submissions?

As far as I care, don't break stuff.

Can any issue just get picked up and worked on?

If you think you can, you're free to try.

Anyone have any luck with developing on a non-windows environment, or do I need to get exposed to windows development for a better experience?

SCI Companion and its predecessor are pretty much the only applications of their kind that I'm aware of and both are very much Windows only. Sorry.

Are there rules/guidelines to this forum? (ie. tech questions go here, general questions go there, etc...)

I'm not gonna answer that one, I was never supposed to have this much power to begin with. Uh... don't be a dick I guess?

[snobes]

Thanks for the response. One last question:

I'm developing a game with my two brothers. While sending individual script files back and forth is doable, are other SCICompanion game files able to be version controlled? (ie. shp files, etc...) I realize anything can be version controlled because it's just file diffs, but many files (other than scripts) are not easily human readable; thus, resolving merge conflicts is tough. Perhaps the answer to this question will make more sense after getting familiar with how the application works under the hood rather than simple familiarity with using it to make games. But if anyone has tried using version control for whole games, then please let me know your experience. Thanks.

[Kawa]

There's an option in the game-specific settings specifically for source control purposes, it causes all the individual resource files to be handled separately. Not entirely unlike how the Sierra people originally made 'em.

The only real problem is that only the script source files are plaintext. Polygon editor's shp and message editor's shm files are just source code in a tightly controlled format though.

[snobes]

There's an option in the game-specific settings specifically for source control purposes, it causes all the individual resource files to be handled separately. Not entirely unlike how the Sierra people originally made 'em.

Cool. I did not know that. Thanks.

The only real problem is that only the script source files are plaintext. Polygon editor's shp and message editor's shm files are just source code in a tightly controlled format though.

Yeah. I've noticed this. Makes it tough to share shp files (and shm) when working on polygons (or messages) separately then want to combine them.

Continuing with the questions to show my Windows inexperience, would there be any issue building SCICompanion from source on a mac by getting a Windows vm or using parallels (https://www.parallels.com/products/desktop/)? I partitioned my mac for bootcamp Windows and was able to build it, but a vm would be less hassle, so I'm gonna try that out.

[Kawa]

Well there certainly ain't no way you're gonna compile it as a native Mac application, that's for damn sure.

[MusicallyInspired]

So I made a discovery today while perusing the SQ4CD sound resources that I wanted to share (unless someone else already knew this). We know that some early games doubled the sound resources for Windows starting with resource numbers 1000 and up (like KQ5CD and SQ4CD). The scripts add 1000 to the sound resource calls if running in the Windows interpreter. There are two "music devices" flagged in these sound resources much like the music devices in DOS (for PC Speaker, Tandy, Adlib, MT-32, etc). In the Windows resources it uses two flags. Flag $07 is for "Extended MIDI" (which uses MIDI channels 1-10) and flag $0b is for "Base MIDI" (which uses MIDI channels 13-16).

You probably well know that Extended MIDI and Base MIDI aren't something we deal with now, but in early Windows and the early days of GM and synth hardware/keyboards there were MIDI devices that used either only Extended or only Base as their implementation. Base puts percussion on channel 16 instead of 10. When installing Windows versions of Sierra games the setup utility outright asks you if you have extended or base MIDI and depending on which one you select it will save configuration to make the Windows interpreter use the appropriate "device". This is why the Windows resources are separate from the DOS resources because there aren't enough channels to delegate to share with PC Speaker, Tandy, Adlib, MT-32, etc and General MIDI Extended and General MIDI Base.

Now, if you inspect these sound resources you'll notice that the "Base MIDI" music device actually flags channel 11 for the percussion and not 16. Why? Because (in SCI sound resources) channel 16 is reserved for cue and loop data as well as program changes and other MIDI controllers and can't be used for melody. So the Windows interpreter must take the percussion MIDI notation from channel 11 and remap it to channel 16 on output when it's configured for Base MIDI.

So in light of that, we come to my feature suggestion. Currently device flag $07 in Companion is defined as "General MIDI" while $0b is defined as "Unknown" (in the SCI Sound driver dropdown menu when previewing/editing sounds). I propose changing the label for $07 to "General MIDI / Extended MIDI" and $0b to "Base MIDI" in those dropdown menus since we now know what they're for.


I'd also like to report an issue where when selecting an SCI Sound driver device in the dropdown menu of Game Explorer when previewing sound resources (not opening them in the sound editor), the selected device seems to be ignored when playing back. It doesn't do this in the sound editor, it seems to work properly there. I'm not sure if this is an old bug that's since been fixed or if we just never noticed it before.

[Kawa]

I'll gladly change those labels, and can confirm that the preview panel ignored the device selection since version 3.0.1.7 (the last official release).

[snobes]

Hello. I'm trying to build and run the application from the github repository. I'm running into some issues that I can't figure out and would appreciate help.

After downloading the repo and installing all the necessary build components (Windows 8.1 SDK, VS 2015 Build Tools), I can successfully clean and rebuild the solution. However, when I launch the Local Windows Debugger (using Kawa / Win32 as the build configuration), I get "path/SCICompanion.sln is not a valid Win32 application". I'm running Visual Studio 2022 on Windows 11. I've seen SO posts saying the issue is the .sln file is not selected when debugging, but I'm pretty sure it is selected. Is my issue is that I'm not launching with the correct build configuration? Or is my issue that Windows 11 can't execute Win32 applications? Or perhaps is it something else entirely?

As a side question, are there pros/cons to setting the Solution Explorer to "Solution View" vs. "Folder View"? "Folder View" makes sense to me as the structure of the files matches what's on disk, but "Solution View" has many configurations supposedly already set and ready to use.

My goal right now is just to get the application launched in a debugger mode via Visual Studio. If there is a guide that I can follow, then please pass it along if it exists. Thanks.

[snobes]

Okay, so I was misunderstanding what these build configurations do. I realize setting "Kawa/Win32" compiles and packages the code into the target directory (this case the "Kawa" directory). I can compile, create, and run the executable from the target directory.

Perhaps, I'm misunderstanding what "run the application in debug mode" means. To me, that means being able to launch the application via the "Local Windows Debugger" and able to set breakpoints in the code. Is that an incorrect assumption? Thanks for any help.

[Kawa]

The "Kawa" configuration is also a kind of "Release" build so you don't get the ability to properly step through. You can use breakpoints, sure, but the cursor will do what it wants because of optimizations.

I know you can because that's how I traced out how strings work when I added codepage translation support.