Author Topic: SCI Companion V3 - alpha build notes/bugs/feature requests  (Read 449821 times)

0 Members and 2 Guests are viewing this topic.

Offline snobes

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1020 on: August 15, 2023, 11:16:15 AM »
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?

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1021 on: August 15, 2023, 11:26:45 AM »
"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.

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1022 on: August 15, 2023, 04:02:20 PM »
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.

Offline MusicallyInspired

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1023 on: August 20, 2023, 02:49:15 PM »
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!
Brass Lantern Prop Competition

Offline doomlazer

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1024 on: June 07, 2024, 03:25:56 PM »
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? 

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1025 on: June 07, 2024, 03:43:10 PM »
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.
« Last Edit: June 07, 2024, 03:49:31 PM by Kawa »

Offline doomlazer

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1026 on: June 07, 2024, 09:02:06 PM »
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.
« Last Edit: June 08, 2024, 02:19:27 AM by doomlazer »

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1027 on: June 08, 2024, 02:58:29 AM »
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.

Offline doomlazer

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1028 on: June 08, 2024, 03:32:45 AM »
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.
« Last Edit: June 08, 2024, 03:36:15 AM by doomlazer »

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1029 on: June 08, 2024, 03:34:33 AM »
Not a single clue!

Offline doomlazer

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1030 on: June 08, 2024, 03:37:24 AM »
ugh, code pages are terrible to deal with!!

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1031 on: June 08, 2024, 03:48:32 AM »
Why do you think I added a translation layer to begin with?

Offline AGKorson

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1032 on: June 08, 2024, 02:29:56 PM »
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.


Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1033 on: June 08, 2024, 03:09:32 PM »
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!)

Offline Collector

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #1034 on: June 08, 2024, 04:16:48 PM »
Andrew, are you still using the FastColoredTextBox class for your C# editor?
KQII Remake Pic


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.037 seconds with 23 queries.