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

[troflip]

I'm adding a new feature to SCI Companion that auto-generates text resources from strings in the scripts (much of the functionality already existed, it was just disabled - because I was focused on SCI1.1 where this isn't as useful... and I wasn't sure how to expose the functionality).

The plan is to support the following syntax at the top of the script (only in the Sierra syntax):

Code: [Select]

(text# number) ; usually this would be (text# scriptNumber)

When this is done, the compiler will replace all appropriate double-quoted strings with resource/number pairs when it generates the script resource. Then it will write those strings to the text resource number that was specified in the text# directive (overwriting any previous text resource). Curly-brace strings are left alone so that you can still call methods/procedures that don't understand text resource/number pairs.

This saves on heap space when making SCI0 games.

Since this overwrites the existing text resource, it can be pretty destructive - hence why I require an explicit directive.

What is an appropriate string? Strings in method and procedure calls. That's about it. (Possibly I could include array initializers too, but it doesn't really make sense anywhere else).

A nice bonus feature would be to warn when you try to manually edit a generated text resource - perhaps by including some sentinel string in it.

Thoughts/comments? (I know it's not really exciting SCI1.1 stuff).

[Kawa]

A sentinel might be good. And yes, this does seem useless when 99% of your text is in Message resources

[Collector]

One external tool that Gumby made was intended to dump the text resources to a file that could be run through a spell checker. How hard would it be to implement a text import/export function to feed strings through an external spell checker?

[troflip]

I'm not sure... I don't know the right way to interface with external spellcheckers, or what spellcheckers there are.

Text resources can already be exported and imported to/from a text file - but of course you want that to be pushed back into code. I don't think any totally-automated way really makes sense (you'll always need to vet the spell check errors one by one).

Starting with Windows 8, there is a built-in spell-checking API, apparently. I'm still on Win 7, but when I upgrade to 10 I could see if I could integrate with that. Maybe underline text strings with squigglies or something.

[Kawa]

I've interfaced with aspell once.

[Collector]

Dumping to a txt file that could at least be dropped in a word processor would at least catch the typos/misspelled words, even if you had to manually correct them in the code. Simply adding a spell checker to the script editor that could add real time spellchecking for strings and comments would be the ideal solution. I have never looked into any such extensions for C++ and have no idea what is available or how much work it would be to integrate.

By the way, I mentioned SCI Companion to a couple of Sierra alums and Lorelei Shannon (of KQ7, Phat2 and other games) said it was "really freaking cool."

[Kawa]

And that, in turn, is really freaking cool.

[troflip]

Hahahah, that's great :-).  Do these alums have any jobs for me? 

[gumby]

One external tool that Gumby made was intended to dump the text resources to a file that could be run through a spell checker. How hard would it be to implement a text import/export function to feed strings through an external spell checker?

Yes, this would be a great feature to add.  The spellchecking I implemented was done with aspell.  I think I also implemented a grammar checker, but maybe that feature never got completed.  The tool was buggy as hell, I remember running Betrayed Alliance through it while it was in development and I hadn't considered Print()s with additional properties specified.  Or maybe it was Display()s.  Anyway, worked great if you had simple print statements in your game.

[Collector]

I had a spell checker in SCI Developer's script editor. It was designed for the Fast Colored TextBox control, but but it had problems. It was written in VB.NET and used a couple of things exclusive to VB. I tried porting it to C# so I could see what was going on, but could not fully port it. I hate VB.

[MusicallyInspired]

By the way, I mentioned SCI Companion to a couple of Sierra alums and Lorelei Shannon (of KQ7, Phat2 and other games) said it was "really freaking cool."

That is awesome. Nice to have some attention at all, let alone from ex-Sierra employees!

[troflip]

I had a spell checker in SCI Developer's script editor. It was designed for the Fast Colored TextBox control, but but it had problems. It was written in VB.NET and used a couple of things exclusive to VB. I tried porting it to C# so I could see what was going on, but could not fully port it. I hate VB.

Unfortunately there aren't any designed for the crappy old syntax coloring editor I'm using, so integrating anything into the editor would be a lot of work.

Best I could probably do is pick out all the strings in the scripts, and run them through a spell checker and produce a list of "errors" in the output pane at the bottom.

But for the message editor (where strings are never in script files anyway), then there is a path that already works. You can import/export from/to a text file, then run that text file through a spellchecker. I suppose it's not very automated though...

[Collector]

Still better than having to simply proof read it.

[troflip]

Another fix of interest to SCI0 folks (i.e. no one?) in the upcoming SCI Companion "service pack" is the support of gamma correction for dithered images.

Companion currently assumes that, say, blue dithered with black should be matched to a color that is halfway between those two. But that's incorrect because of a monitor's gamma curve. As a result, the "import bitmap to pic" functionality has never produced very faithful colors. With the addition of gamma correction, this should be fixed.

In the attachment, the top image is the original. Below that, on the left is the non-gamma-corrected image. In the middle is the gamma-corrected image. The bottom row shows what it looks like after being undithered (say in ScummVM).

The right hand side shows the "non-smooth" option in "import bitmap to pic", where dithered colors with very different component colors are allowed. Looks terrible dithered, but more accurate when undithered (look at the ice on the lake).


Note that this only affects dithering, so doesn't apply to the SCI1+ case at all.

[troflip]

Actually, I take that back, it is slightly used for SCI1.1 - it affects the accuracy of the color matching. But it's definitely more useful for EGA, where you'd use dithering and the difference between the intended color and the chosen color is greater (because of the limited palette).

Here's another example.

At the top left is the original image. Top center is what the dithered EGA image would look like before if you imported it into a view. Top right is with gamma correction - a huge improvement!

The bottom row is VGA using the default KQ5 static palette (64 colors), undithered. Left is without gamma correction, right is with. The difference here is more subtle, but still somewhat noticeable.