Messages

1

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: January 17, 2025, 03:52:26 AM »

Supporting Japanese in SCI Companion is a hack and a half that won't cover SQ4, but it will work on for example PQ2, because all of them except SQ4 use Shift-JIS. So what you wanna do is claim the game uses Windows 1252 which bypasses the code page translation, then use AppLocale or some such to make SCI Companion itself run in Shift-JIS. Because it was never a Unicode application and for most of us can be assumed to run on Win-1252.

And that means the encoding used in PQ2-JP can match SCI Companion's... by making SCI Companion match PQ2's instead.

As for the font data: the Japanese games run on a system that has such beautiful features as "an entire Shift-JIS kanji character set in ROM" and "can display higher-res fonts on top of low-res graphics". The actual SCI font data only contains some katakana in the upper moby.

And then there's my SCI1.1+ which has UTF-8 support, entirely inspired by the fact that in the font data, it says "number of characters" instead of "highest character number". So "256 characters" instead of "up to #255". It's a 16-bit number and Unicode at the time hadn't developed into the astral planes yet. But I just said SCI Companion is not Unicode aware, so how do you use it with SCI1.1+? That's the best part: you don't! I wrote a command line tool to handle message resources in UTF-8. The only thing SCI Companion knows is that the max amount of characters isn't 256.

2

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: January 16, 2025, 06:29:53 AM »

CP-850 is the DOS Latin-1 codepage, used in Western Europe. I, being Dutch and old know it well, and it'd be a nice little challenge to try and extend things to support European games as well as American ones. (And Japanese if you know how, it's a trick.)

3

The Games and other Sierra Adventure stuff / Re: King's Quest 6 Hires's Aspect Ratio is completely wrong [RANT]

« on: December 19, 2024, 04:21:49 PM »

When you said the title bar takes about 19 pixels, I figured one way to solve it maybe could be to have the 10 pixel status line, which would be at least 20 pixels in hi-res mode, not count at all so as to make room for the title bar. But then there's the "large fonts" video drivers that'd make the title bar way thicker than that.

Oh well :3

4

AGI Development Tools / Re: WinAGI Version 3.0.0-alpha8.0

« on: December 18, 2024, 04:00:22 AM »

Not quite that simple in C#... But I did finally figure it out.

graphics.DrawString("Hello world!", someFont, Brushes.Black, rectangle) may have more arguments, sure, but...

I tried to check out your code sample to see some better examples but the link is broken (do you work for Microsoft?  )

My bad, it's a private repo.
It's mostly just stuff like

Code: [Select]

private void roomPreviewPictureBox_Paint(object sender, PaintEventArgs e)
{
var g = e.Graphics;
g.DrawImage(anotherImage, 0, 0, targetWidth, targetHeight);
g.DrawRectangle(Pens.White, (obim.Left * zoom) - 2, (obim.Top * zoom) - 2, (obim.Width * zoom) + 1, (obim.Height * zoom) + 1);etc.

5

AGI Development Tools / Re: WinAGI Version 3.0.0-alpha8.0

« on: December 17, 2024, 06:14:39 AM »

I expect the graphics based editors to be especially difficult.

Having done graphics editors in both VB Classic and C#, I can tell you this much: it's not that hard to use System.Drawing.

Your picture box control's OnPaint event gives you a PaintEventArgs, and that in turn gets you a Graphics object. And that? Oh, you can draw anything from there. Here's the code from my attempt at a SCUMM room editor, specifically the paint event. I can't imagine doing arbitrary polygons (the walk so-called-boxes) in VB Classic as easily as I had it there.

Note that I've developed an interesting aversion to how the WinForms designer produces, well, designer files, and create all the controls for that room editor myself, by hand. That's entirely my own code, my own choice, and none of that really matters but it might throw you off a bit so I thought I'd mention it. The important thing is how to use Graphics to draw stuff to Bitmaps.

6

SCI Syntax Help / Re: Adding a fourth loop to talker portraits?

« on: December 16, 2024, 12:56:24 PM »

I've been running into crashing issues whenever a conversation starts to begin

If I were a betting cat, my first guess would be that none of the talkers actually provide a fourth argument and a lack of proper argc checks and/or null reference checks messes up the part where they're actually drawn and cycled.

7

SCI Syntax Help / Re: Adding a fourth loop to talker portraits?

« on: December 13, 2024, 04:05:34 AM »

Now consider: they also bought Coktel Vision, for their animation system. If you look at the leaked SCI32 code you can see that the video player code retains its original French comments, including a whole card at the top with ASCII checkboxes and text fields.

Now consider this was once about Talker portraits only having three parts.

8

SCI Syntax Help / Re: Adding a fourth loop to talker portraits?

« on: December 12, 2024, 04:28:08 PM »

Now it makes sense. If you pick "small", the high-res assets, including the Rave portraits, wouldn't fit.

Anyway, we've gone way off track!

9

SCI Syntax Help / Re: Adding a fourth loop to talker portraits?

« on: December 12, 2024, 09:38:46 AM »

It was clear what element you were talking about. I'm just saying it doesn't make sense to put such a toggle there.

10

SCI Syntax Help / Re: Adding a fourth loop to talker portraits?

« on: December 12, 2024, 09:12:15 AM »

(by right-clicking on the title bar or application icon, maybe?)

I'm sorry but that does not make any sense.

Anyway, I believe they may have been called Rave portraits, and regardless of the tech name they allowed talkers to be more visually expressive if I recall correctly. More information in the relevant ScummVM code.

No other SCI game used them to my knowledge.

11

SCI Syntax Help / Re: Adding a fourth loop to talker portraits?

« on: December 12, 2024, 07:51:52 AM »

Even worse: the Windows portraits weren't views.

12

SCI Syntax Help / Re: Adding a fourth loop to talker portraits?

« on: December 11, 2024, 02:57:27 PM »

It's too bad my game doesn't use talker portraits or I'd have a very good reason to implement it myself.

13

SCI Syntax Help / Re: Adding a fourth loop to talker portraits?

« on: December 11, 2024, 02:37:52 PM »

Basically, yeah. Good luck!

14

SCI Syntax Help / Re: Adding a fourth loop to talker portraits?

« on: December 11, 2024, 02:02:43 PM »

You are entirely correct. Blink is the right file to look at -- it's confusingly named because Blink is the first class found inside script #928, so the decompiler named it that instead of Talker.sc, which would be the correct, canonical name.

As for how familiar I am with KQ6's code... that doesn't matter! The 900-999 scripts are generally the same between SCI games of a given vintage, so you might as well speak of Larry 6 (the low-res version), or Freddy Pharkas, or whatever.

15

SCI Syntax Help / Re: Adding a fourth loop to talker portraits?

« on: December 11, 2024, 01:05:25 PM »

If you alter the Talker class, or preferably subclass it, you can theoretically animate as many parts as you want. Of course, if you don't actually have support for a fourth (or fifth, sixth...) portrait part, of course characterEars gets ignored.

Assuming for a second you correctly implement your specific characters' talkers as subclasses of Talker, you'll notice if you look at the Talker class' init that it indeed takes only three parameters: theBust, theEyes, and theMouth. And the class' properties include the same trio without the article. Then in the show method, each of these (if set) is drawn, and in doit they are cycled. And of course in dispose each of the three parts are disposed of.

So if you want your characters to support animated ears, you'll want to adapt each of these methods in Talker (or again preferably a subclass) accordingly.