Messages

1

SCI Development Tools / Re: Sierra's Internal SCI Tools

« on: Yesterday at 09:20:46 AM »

I'm not an expert on compression, but I know the biggest gain from 7zip is the file format and not the compression algorithm.  Both 7z and zip are largely based on the LZ77 compression algorithm, but the reason 7zip often gives much better results is because it's a solid-archive format.

That means it treats all the files as a single entry, whereas zip compresses each file individually. There's ups and downs to each approach. The place where 7z really shines is when you're compressing several similar files together.

Like for example, rom hacks. You could 7z up 100 different Super Mario World rom hacks together and because the variation between each file is pretty minimal, you'd get a file that's not much larger than compressing a single rom with zip.

The downside is if you want to add a file to an existing archive, you need to decompress then re-compress the whole thing. Plus, I assume, if there's a data corruption issue, the entire archive is compromised instead of just a single file.

2

SCI Syntax Help / Re: Heap Space Fun

« on: September 22, 2025, 04:32:06 PM »

How robust is it compared to SCI1 pathfinding?

I recall in QFG2 when walking left/right in the desert ego would walk around large rocks that were in it's path, instead of just coming to a standstill.

3

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

« on: May 06, 2025, 09:45:23 AM »

Which is the correct one, a or b?

4

The Games and other Sierra Adventure stuff / Re: King's Quest 4 - Did you know they replaced background pictures??

« on: January 28, 2025, 02:37:25 PM »

That's really interesting to see how much attention they put into this one game...

Not just making it completely in two different engines, but making two sets of backgrounds for each engine.

Did any other games get this special treatment, or was King's Quest special because it was their flagship series?

5

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:32:46 PM »

Well, if I was aiming to fix it in Windows 3.1 and had full control (which honestly I couldn't give a care about), I'd just hide the title bar, like they ultimately did with the SCI2/SCI32 versions. Hide the title bar and resize frame. Then you've just got game window at 640x480.

6

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:10:28 PM »

Yes, I noticed that. Only when you select the "Enable high resolution graphics" option.

And I didn't mean to imply nobody had known this before. Only that I just learned it (or relearned it... I'm sure I knew it at one point).

I wonder what it would take to remaster this in SCI to use the correct aspect ratio and the high-res graphics.  Probably need to use a custom build of ScummVM, as this doesn't look like the kind of modification that usually falls under their mandates.

7

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

« on: December 19, 2024, 03:23:59 PM »

So I've been playing around with the Windows 3.1 versions of Sierra games, and I've discovered (re-discovered?) something that's really bugging the perfectionist in me.

Basically the "enhanced" CD version of King's Quest 6 has conflicting aspect ratios all throughout.

It's fairly widely recognized today that the 320x200 DOS games were designed to use rectangular pixels on CRT screens, rather than square pixels. These rectangular pixels were taller by 20% (or had a pixel ratio of 5:4 aka 1.2:1)  This resulted in the games being displayed at a 4:3 aspect ratio... effectively equivalent to 320x240 in square pixels.

When Sierra first ported their games to Windows, it was clearly a learning experience and they made some compromises. In KQ5 (their first windows game), it would only run if your screen resolution was set to 640x480x256 (no higher, no lower). And when it ran, presumably in order to accommodate the windows title bar, instead of stretching the game to fit 640x480, it was only stretched to fit 640x440.  A full 40 pixels shorter (or ~9% shorter), resulting in a slightly squashed game.


Because the game was maximized, the sides of the window were off screen, allowing the full 640 width, but the height has 19 pixels for the title bar, 440 pixels for the game, and an additional 21 black pixels at the bottom.  (Interestingly, despite not allowing it to run in higher resolutions (like 800x600), you can still restore the game to a moveable window.)

The rest of the games in the SCI1 and SCI1.1 era made steps to correct the issue, while still staying fully compatible with 640x480 screens.  They introduced a Small Window and Large Window mode. That includes SQ4, LSL6-lores, Pepper's Adventures in Time, Freddy Pharkas, EcoQuest1 CD, EcoQuest2, Laura Bow 2, etc.



The Large Window mode worked just like KQ5, stretching the game to only 640x440 (or ~9% shorter height that intended).

Small Window mode shrank the game down to 320x240, displaying it at the proper aspect ratio.


It wasn't until the SCI2/SCI32 era that they started to show their Windows versions of games at the full 640x480 resolution and correct 4:3 aspect ratio. QFG4, Gabriel Knight 1, LSL6-Hires, LSL7, KQ7, Police Quest 4 etc. Often times they even removed the title bar completely.

So this Windows 3.1 compromise wouldn't be a problem, except for the enhanced graphics for the Windows version only of KQ6 CD. As with all the other SCI1/SCI1.1 releases, it has a Large Window and a Small Window mode, and like the others, the Small Window is the correct aspect ratio, and the Large Window is 9% squished.

BUT, they updated the icon bar, the talking portraits, the inventory icons, and a couple of assorted other graphics for the Large Window mode only, and they didn't adjust the aspect ratio to match... in fact, based on the size of the icon bar, it looks like they based the new hi-res icons on the incorrect 320x200 aspect ratio of the original DOS icons. I've created a gif that switches between the windows hires version and the same one with the icon bar from the DOS version applied, without any aspect ratio correction. They're nearly identical.



So yeah, that's disappointing that there's pretty much no definitive version of KQ6... you can either have the correct aspect ratio and low-res graphics, or you can have a squished version with better quality (but also differently squished) graphics.

8

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

« on: December 18, 2024, 09:01:51 AM »

It's exciting to see you switch to C# from such a mature VB6 project.

I know from personal experience it's a steep learning curve, but C#'s a great choice from a personal development perspective -- I did VB.net myself years ago, and while I'm proficient in C# it doesn't come as naturally to me as VB syntax does... unfortunately C# is preferred in most circles.

Anyway, I know you'll get to a point where it becomes second-nature, and you'll wonder how you ever survived in VB6 for so long.

9

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

« on: December 12, 2024, 04:14:59 PM »

There we go!  I imaging at the time, they considered it an extension of the standard Size ability of windows.

10

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

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

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

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

I mean the window title bar. Running the game in a window in Win3.1.

11

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

« on: December 12, 2024, 08:55:46 AM »

Even worse: the Windows portraits weren't views.

Oh, that's really interesting... what were they? Because it's been a long while, but I seem to recall that in Win3.1 you could choose between the high-res version and the low-res version on the fly (by right-clicking on the title bar or application icon, maybe?), and it would change the character portraits to match the version you selected... I always preferred the low-res versions because the high-res ones always looked too red to me. But it would still keep the lip syncing regardless of the ones you picked.

12

SCI Development Tools / Re: [KQ5CD] Issue when compiling script

« on: December 02, 2024, 05:10:23 PM »

It's not my intention to be assigning blame or calling anybody right or wrong. I'm just trying to make sure we're talking the same thing, to be able to better help you troubleshoot.

The decompiler is not perfect. By definition if it's returning any source code when you decompile, it has decompiled successfully. However, successful =/= correct. I believe it is decompiling successfully, but that the decompiled code is not correct.

Are you able to post your full decompiled source for room 200?  Is room 200 the only code being changed that is causing problems?  Like every other script is the original KQ5CD, but adding in your recompiled 200.scr as a patch file is breaking things?

13

SCI Development Tools / Re: [KQ5CD] Issue when compiling script

« on: December 02, 2024, 02:30:56 PM »

Note there is a difference between "decompiles successfully" and "decompiles correctly."

In this case it's not throwing an error when decompiling, so it is decompiling successfully, but it fully appears that the decompiled code is not an accurate representation of the original bytecode, I.e. not decompiling correctly.

14

SCI Development Tools / Re: [KQ5CD] Issue when compiling script

« on: December 01, 2024, 05:49:22 PM »

I?m not suggesting you should init the variables that way; I was only giving that as an example that it makes no difference to the compiler.

Can you describe in more detail how the game freezes?

15

SCI Development Tools / Re: [KQ5CD] Issue when compiling script

« on: December 01, 2024, 05:08:32 PM »

I think the variables changing is a red herring.

There's no bounds-checking for arrays in SCI.  In either example, you could replace references to local1 with [local0 1] and it'd work just the same.

Here, the 2nd decompile is just taking the 1st two variables of each 9 variable array and declaring them as individual variables... but that doesn't really change anything.

If the game is breaking when you re-compile, then I would assume despite it looking correct, it's not actually decompiling correctly the first time. Try comparing your decompile with sluicebox's https://github.com/sluicebox/sci-scripts/blob/main/kq5-cd-dos-1.000.052/src/witchRegion.sc or Eric's https://github.com/EricOakford/SCI-Decompilation-Archive/blob/master/kq5cd/src/witchRegion.sc.

I've personally seen incorrect decompiling when there are nested arrays, so it could be that but who knows.