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

[snobes]

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.

Do you have steps on how to launch with breakpoints attached and able to step through the code? What build configuration allow breakpoints? I'm having a hell of a time figuring out how to do it.

Earlier, Kawa, you said

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.

Where is this? I'm looking at "Game/Version detection" but cannot see how to set individual resource files handled separately. Maybe it's already enabled because when I change a polygon the respective .shp file is updated (I see this via git diff), and when I change a message the respective .shm files is updated. However, when I add "Control" or "Priority" commands in the pic editor, only the `resource.000` and `resource.map` files are updated, which are both binary. I'm looking into a way to store these "Control" and "Priority" commands in human readable files. That way I can source control all resources I currently care about (scripts, polygons, and commands). Thoughts on this effort? Already been tried?

[Kawa]

"Game Properties" > "Manage resources as patch files (good for source control)". Hit OK and you should find all your game assets spilled out horrifically into the game's folder.

HOWEVER, control and priority screen data is an intrinsic part of a given Picture resource, unlike its polygons, so if you change that, you change the .pic/.p56 resource file as a whole.

[Kawa]

It took some digging, but I found the problem with the sound previewer. I am right now chilling to the Tandy 3-Voice version of the Space Quest 3 theme, playing from the preview bar. I also went and normalized all user-visible instances of "midi" and "Midi" to "MIDI" while I was at it, correcting that "unknown" to "Base MIDI".

All this will be in the upcoming nightly.

[MusicallyInspired]

It took some digging, but I found the problem with the sound previewer. I am right now chilling to the Tandy 3-Voice version of the Space Quest 3 theme, playing from the preview bar. I also went and normalized all user-visible instances of "midi" and "Midi" to "MIDI" while I was at it, correcting that "unknown" to "Base MIDI".

All this will be in the upcoming nightly.

Nice!

[doomlazer]

I noticed that sometimes SCICompanion doesn't match extended characters when searching in text files. For example, if I start with a clean copy of LSL1VGA and replace several letters with e-acute, rebuild and search all files nothing is found.

Some times it does find them though. In another copy of lsl1 remake it finds them inconsistently between text files. Any thoughts on why that might be? 

[Kawa]

If that's the latest release, that may be the search function not acknowledging the transparent DOS-437 to Win-1252 translation. Or said translation step otherwise messing with search. I dunno.

So lets say you did that, with a clean copy, it'd default to "source is 437, translate it to 1252 so the accent marks are correct". You add those e-acutes, which are byte value 0xE9 (also U+00E9 what a coincidence) in Win-1252. You save the resource, and it gets translated back to DOS-437, so the e-acute is now byte value 0x82.

If the search feature doesn't include that translation step, you're looking for the e-acute with an 0xE9, because that's how Windows does it, but none of the resources actually contain that byte -- it's 0x82, because that's the point in the font resources that looks like an e-acute.

[doomlazer]

FYI, it seems to always find extended characters inserted into scripts. Just something I'll need to be aware of when searching the text files I guess.

Edit: attached a pic of it detecting ? in some text files, but not others.

[Kawa]

This is because .sc files are saved with the DOS to Windows translation baked in. String literals are translated back to DOS-437 on compilation, so it's the script (or heap) resources that have the e-acutes as 0x82, not the source code. Therefore, the e-acute you're entering (0xE9) is actually in the .sc files and can be found.

[doomlazer]

Any idea why in the pic I edited into my last post shows that it's matching ? in text 730 and 725, but not 744?

I probably need to check the bytecode for 730 and 744 to see if the ? are different values.

[Kawa]

Not a single clue!

[doomlazer]

ugh, code pages are terrible to deal with!!

[Kawa]

Why do you think I added a translation layer to begin with?

[AGKorson]

This is because .sc files are saved with the DOS to Windows translation baked in. String literals are translated back to DOS-437 on compilation, so it's the script (or heap) resources that have the e-acutes as 0x82, not the source code. Therefore, the e-acute you're entering (0xE9) is actually in the .sc files and can be found.

Any thoughts on the best approach to handling code pages in saved resources (i.e. script or, in the case of AGI, logics files)? Right now, the current VB6 WinAGI saves the text to files using the DOS code page. So the text in the file is byte-for-byte equivalent to what would be added to compiled resources. It works, but it means the files can't be edited (at least not easily) outside of WinAGI since most text editors assume Windows coded text.

I'm working on my C# implementation, and now am second guessing that approach, and am considering doing what SCICompanion does, which is saving the resources as Windows coded, and only converting to DOS code page on compilation. But that would mean I'd need a way to let users convert VB versions of resources to the C# version (not a big deal, but still more work).

I am not sure which approach is best.

[Kawa]

To clarify, text and message resources are translated to Win-1252 when opening their editors and back to DOS-437 on save. To edit them, they're converted from their original forms to a set of structs or objects or, in the case of text resources, straight, simply strings. Script resources are translated on (de)compiled, so you can take an SC file and open it in... I dunno, VS Code, and have any local strings be correct.

Well, aside from stuff like roman numerals but those should be done as hex escape codes I think.

The main gimmick is that the game properties dialogue box has a native codepage dropdown (it's where the script dialect used to be) that defaults to DOS-437 so the original Sierra games work correctly, while making a new game defaults to Win-1252. So basically if the native codepage isn't Win-1252, the translation layer kicks in.

(Which also means you can load Japanese games by pretending they're Win-1252 so you get unmolested Shift-JIS. Run SCI Companion with AppLocale to see!)

[Collector]

Andrew, are you still using the FastColoredTextBox class for your C# editor?