Community
SCI Programming => SCI Development Tools => Topic started by: troflip on October 27, 2015, 01:37:52 PM
-
I'm trying to just get some basic support for SCI2 pics (viewing, not editing) in SCI Companion, and I've been running into some curious issues.
640x480 pics are composed of a bunch of image layers. I've attached an example (there are more than just 4 layers in this one, but I got lazy).
The thing that's troubling is the coordinate system. The cels that comprise the layers come with a placement value (just like view cels), and so my first attempt was to just draw them at that location. It was clear though, that the x coordinate needed to be doubled (first strange thing). i.e. if the cel was at (101, y), then I needed to draw it at (202, y).
The y coordinates were also wrong, and it took me a long time to figure out how to fix it. I scoured the ScummVM code, but didn't see any adjustments made to the coordinates (including double the x). So I dunno if I just missed it, or the SCI32 support is just not far along enough to support 640x480. Anyway, through much trial and error, I discovered the y coordinates need to be doubled, and then multiplied by 1.2. At least, that seems to work so far.
I'm guessing the 1.2 is some kind of aspect ratio thing, but for the life of me I can't imagine why there would be these limitations on 640x480 pics. Any guesses? It's kind of annoying, since it limits where you can place image layers. They would have to be on even x boundaries, and "multiples of 2.4" y boundaries. Actually come to think of it, I guess (*if* there were an SCI2 pic editor), you could just add an addition line or 2 of transparent pixels to get things where you want.
The author of SV.exe clearly new about this, since the pics come out ok there. But... no source code...
-
OOPS: OH crap, I just edited your post instead of replying! ooops... is there a way to undo that? - troflip
*Kawa reopens old tab*
I'm trying to just get some basic support for SCI2 pics (viewing, not editing) in SCI Companion, and I've been running into some curious issues.
yaaaay!So I dunno if I just missed it, or the SCI32 support is just not far along enough to support 640x480.
Considering I just watched the first few seconds of the SQ6 intro cutscene -- up to the point where Rog is beamed through the ground -- in glorious 640x480...
I'll take a look at it myself, see if I can confirm anything.
Edit: Apparently there's something about script resolution vs display resolution?
void GfxCoordAdjuster32::setScriptsResolution(uint16 width, uint16 height) {
_scriptsRunningWidth = width;
_scriptsRunningHeight = height;
}
void GfxCoordAdjuster32::fromDisplayToScript(int16 &y, int16 &x) {
y = ((y * _scriptsRunningHeight) / g_sci->_gfxScreen->getHeight());
x = ((x * _scriptsRunningWidth) / g_sci->_gfxScreen->getWidth());
}
void GfxCoordAdjuster32::fromScriptToDisplay(int16 &y, int16 &x) {
y = ((y * g_sci->_gfxScreen->getHeight()) / _scriptsRunningHeight);
x = ((x * g_sci->_gfxScreen->getWidth()) / _scriptsRunningWidth);
}
(Troflip's post:)
Hmm... interesting. So maybe 640x480 resolution games still operate as 300x200 in script? That would account for the (2, 2.4) multipliers, and would also make sense for games like LSL6 which (I believe) had both low-res and high-res versions.
-
If it means anything, hi-res AGS games also only use a 320x200 coordinate system, IIRC. SCI Studio VGA could open some hi-res pics, couldn't it? Check the source for that?
-
If it means anything, hi-res AGS games also only use a 320x200 coordinate system, IIRC. SCI Studio VGA could open some hi-res pics, couldn't it? Check the source for that?
Interesting about AGS...
SCI Studio VGA can't seem to open hi-res SCI games, unfortunately. I tried SQ6 and KQ7 and it claims they are corrupt.
From looking at ScummVM, it looks like there is a kernel function that lets the scripts set the "resolution".
-
If it means anything, hi-res AGS games also only use a 320x200 coordinate system, IIRC. SCI Studio VGA could open some hi-res pics, couldn't it? Check the source for that?
I just tried and failed to open SQ6 in SCI Studio 4/3.+(+). But let's look there for more confirmation anyway.
Edit: yeah that's a shit lead. But Mu's right about AGS, which would be an interesting little bit of convergent evolution in action right there.
-
Edit: yeah that's a shit lead. But Mu's right about AGS, which would be an interesting little bit of convergent evolution in action right there.
Well, yeah, I think the mystery's solved. It let Sierra write a single set of scripts for games that were offered in dual resolutions (although other than LSL6, which games are in both lo-res and hi-res?)
-
although other than LSL6, which games are in both lo-res and hi-res?
Not many. GK1 and possibly PQ4 (at least PQ4 included both a VESA.DRV and VGA.DRV drivers). LSL6 packaged two separate games on the CD in separate folders, "HIRES" and "LORES". GK1 had a "RESOURCE.ALT" and "ALT.MAP" for the hi-res. These graphics were just the GUI and a few Views while the same Pics were scaled, depending on which driver is used.
Outside of these and QfG4 most of the SCI2+ games are hi-res/VESA only.
-
The Windows version of KQ6 CD is a mixture too, the backgrounds and characters are scaled but the GUI, objects and portraits are in hi res, even the intro and sierra tittle are .avi files. It's a late SCI 1.1 game, but maybe an interesting case.
-
The dialog portraits from KQ6 Win and cursors are about the only graphical difference between the DOS and Win versions. Those dialog portraits are not available for the DOS interpreter as there is no VESA driver. Otherwise the game's graphics are merely scaled to 640x480 from 320x200.
-
The dialog portraits from KQ6 Win and cursors are about the only graphical difference between the DOS and Win versions. Those dialog portraits are not available for the DOS interpreter as there is no VESA driver. Otherwise the game's graphics are merely scaled to 640x480 from 320x200.
Also the icon bar. How could you forget the icon bar?
-
And don't forget the inventory:
-
Still, that's enough of that side-track.
-
Here's a plot twist for you, all SCI games in Windows were hi-res because they were all upscaled to 640x400.
-
Except you are pointing out the differences between the diskette version (int. 1.001.054) and CD (int 1.001.069), not DOS vs Win of the same release. The DOS CD version has the same icon bar and inventory as the Win. The question is what games included both lo and hi-res in the same release.
-
Here's a plot twist for you, all SCI games in Windows were hi-res because they were all upscaled to 640x400.
Noted that the Windows games were hi-res, but not all needed to be upscaled, only the 320x200 DOS games. The VESA games like Torin did not need to be upscaled.
-
Lol, ok. I've been out-pedantificized.
-
Good. Can we stick to natively high-res games like SQ6 now?
-
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.
-
Can we stick to natively high-res games like SQ6 now?
-
.....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?
-
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?
-
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.
-
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).
-
Interesting. Thanks!
-
I've attached the SQ6 decompiled source if anyone's interested to browse it.
Easter egg spotted.
-
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...
-
This one involves a dedication and typing a phone number on a keypad...