SQ6 pic mystery

[MusicallyInspired]

Lol, ok. I've been out-pedantificized.

[Kawa]

Good. Can we stick to natively high-res games like SQ6 now?

[ignatus]

From my copy of KQ6 CD:

Obviously the background and characters are scaled, but all the icons and objects in the inventory are in hi-res, in addition to the portraits and Windows cursors, of course.

[Kawa]

Can we stick to natively high-res games like SQ6 now?

[MusicallyInspired]

.....obviously. I think everyone knows that part by heart.

Anyway, hi res. Yeah, that is fascinating that AGS uses a similar coordinate system. I'm not convinced it's to allow for hi and lo res games. I believe LSL6 was the only one that ever offered both for backgrounds. I doubt Sierra would have made plans to offet low and high res versions of all their games going forward. I suspect it was just for ease of use for the programmers/artists. But that just doesn't make sense seeing as offering pixel perfect perfection is easiest in the longrun. Maybe it was just system-intensive?

[troflip]

I suspect it was just for ease of use for the programmers/artists. But that just doesn't make sense seeing as offering pixel perfect perfection is easiest in the longrun. Maybe it was just system-intensive?

I doubt it's any more system intensive. The only way I can think of higher resolutions being more resource is intensive is drawing the graphics... which... are 640x480, obviously.

It may have just been because that way they didn't need to anything else in the script or interpreter code - they only needed to change the rendering paths.

Looking at scripts from SQ6, things are definitely coded for 320x200. Does this mean a character could only ever be at even positions?

[MusicallyInspired]

Perhaps, as far as destination coordinates are concerned, but for the walk path at least it must have taken hi-res pixels into account (drawing the character animation from point A to point B) because look at some of the screens where Roger and other characters are in the distance. The shuttlebay, for instance, or outside the bar on Polysorbate LX. Those are not only pretty smooth and fine animations but movement as well and he's very small on the screen.

BTW, slightly off-topic, but am I the only one that can't stand it when 320x200/240 games are upscaled to 640x400/480 (or higher) and the character sprite is scaled normally when walking in the distance so his/her pixels are smaller than the background's? Kind of hurts the immersion for me. Just looks sloppy. AGS is the worst for this. It used to allow proper scaling to whatever the game was made for for distance-drawn sprites, but now it just scales them to whatever pixels are on the screen. And some people considered this better! Developers included. I can't stand it. Games made for higher resolutions (backgrounds are at least 640x480 natively) don't look as bad with this, but it's murder to my sanity on low-res.

[troflip]

Perhaps, as far as destination coordinates are concerned, but for the walk path at least it must have taken hi-res pixels into account (drawing the character animation from point A to point B) because look at some of the screens where Roger and other characters are in the distance. The shuttlebay, for instance, or outside the bar on Polysorbate LX. Those are not only pretty smooth and fine animations but movement as well and he's very small on the screen.

I agree, it looks smooth to me. Curious, because if the x/y position something were drawn at was taken from the script object itself, when it would have to be clamped to even pixels in a 640x480 game. But maybe the scripts/interpreter work differently for SCI2.

I've attached the SQ6 decompiled source if anyone's interested to browse it. Many of kernel names will be wrong though, because I don't have the proper SCI2 kernels incorporated into SCI Companion. Other stuff may be wrong too, I haven't spent much time trying to get SCI2 decompilation working. Script resources appear to be the same format as SCI1, so once I was able to read SCI2 resource maps, it was fairly straightforward to get working. There were a few differences in opcodes, and additional debug opcodes that needed to be filtered out, but not many changes.

Curiously, SCI2 byte code seems to decompile much more quickly than SCI1.1 (which could suggest I'm reading script resources incorrectly and missing a bunch of stuff).

[MusicallyInspired]

Interesting. Thanks!

[lskovlun]

I've attached the SQ6 decompiled source if anyone's interested to browse it.

Easter egg spotted.

[Kawa]

Easter egg spotted.

They often are, but it really depends on what the artist had in mind.

I tried to make Roger walk around and "break the grid" but I couldn't get him to stand on an odd Y position. Could've been a scaling thing though...

[lskovlun]

This one involves a dedication and typing a phone number on a keypad...