1
SCI Community News / Re: SCUMMVM SCI Engine "HiRes Upscale" Support Mod
« on: Today at 03:47:52 PM »
I like how the priority screen is still 320x200 😸
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
SCI Community News / Re: SCUMMVM SCI Engine "HiRes Upscale" Support Mod
« on: Today at 02:14:25 PM »
What they did in that LSL2 video is far beyond simple undithering.
3
SCI Development Tools / Re: QFG1VGA - picture format problem?
« on: Yesterday at 03:25:56 PM »
Taking a clean picture 300 and using SCI Companion to slightly mess up the palette, then exporting that to 300.p56 again had the game hang. This file started with 81 81 00 00 26. So I took the header (81 80, 0x26 at offset 0x1A) from 84.p56 and put it in 300.p56 with the altered palette... and guess what?
4
SCI Development Tools / Re: QFG1VGA - picture format problem?
« on: Yesterday at 02:52:57 PM »
It's funny.
If I force SCI Companion to assume the pictures are in SCI1 format, they end up displayed as blanks, because they're not that format. Set the version detection to 1.1, and they appear fine. Same with SV's picture viewer. So mark that one down.
Looking at any random QFG1 picture's raw bytes in SV set to hex view, they all start with 0x26, marking them as SCI11 VGA, as per your code snippet, including #300.
Looking at my remade 300.p56 as a loose resource file, in a plain hex editor, I see this:
An SV-exported, otherwise clean 300.p56 has this:
I've always found the loose resources to be a little odd in that supposedly, the big difference between a loose resource and a packed one is that the loose one has a type identifier at the start, which is only two bytes. The header size is supposedly at 0x00, as per your ScummVM snippet, but much like with views it does not actually start at that point in the file, unlike for example vocabs, text, messages... Both of these are SCI11 pictures, too, so why do neither of them have the 0x26 where you'd expect it to be?
Y'know what actually fixed it and let me have a 300.p56 (the SV-exported one) without hanging? Changing the 81 80 at the start to 81 81.
But what's particularly interesting is that SV-exporting 84.p56 and renaming that to 300.p56 works fine without further trouble. For reference, it has 81 80 and the 0x26 byte is at offset 0x1A. Just like the hanging SV-exported 300.p56 has. Weird, huh?
If I force SCI Companion to assume the pictures are in SCI1 format, they end up displayed as blanks, because they're not that format. Set the version detection to 1.1, and they appear fine. Same with SV's picture viewer. So mark that one down.
Looking at any random QFG1 picture's raw bytes in SV set to hex view, they all start with 0x26, marking them as SCI11 VGA, as per your code snippet, including #300.
Looking at my remade 300.p56 as a loose resource file, in a plain hex editor, I see this:
Code: [Select]
00000000: 81 81 00 00 26 00 10 0E 01 00 A0 00 F0 D8 46 00
00000010: 9E 01 00 00 87 BE 00 00 00 00 00 00 00 00 00 00The 0x26 appears at offset 0x04.An SV-exported, otherwise clean 300.p56 has this:
Code: [Select]
00000000: 81 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000010: 00 00 00 00 00 00 00 00 00 00 26 00 10 0E 01 00Note that the 0x26 doesn't appear until offset 0x1A.I've always found the loose resources to be a little odd in that supposedly, the big difference between a loose resource and a packed one is that the loose one has a type identifier at the start, which is only two bytes. The header size is supposedly at 0x00, as per your ScummVM snippet, but much like with views it does not actually start at that point in the file, unlike for example vocabs, text, messages... Both of these are SCI11 pictures, too, so why do neither of them have the 0x26 where you'd expect it to be?
Y'know what actually fixed it and let me have a 300.p56 (the SV-exported one) without hanging? Changing the 81 80 at the start to 81 81.
But what's particularly interesting is that SV-exporting 84.p56 and renaming that to 300.p56 works fine without further trouble. For reference, it has 81 80 and the 0x26 byte is at offset 0x1A. Just like the hanging SV-exported 300.p56 has. Weird, huh?
5
The Games and other Sierra Adventure stuff / Re: King's quest IV: door out of place
« on: Yesterday at 09:59:29 AM »
Por que no los dos?
Also, if it fit together harmoniously, we wouldn't have this thread now, would we? 😹
Also, if it fit together harmoniously, we wouldn't have this thread now, would we? 😹
6
SCI Development Tools / Re: QFG1VGA - picture format problem?
« on: Yesterday at 09:18:30 AM »
Indeed. For a background picture, all you'd need is the .p56 resource, much like with a view. It's the scripts that eventually got funky.
The strangest thing is, I just went through the effort to remake the picture from scratch (export bitmap, create new, import bitmap, remake priority and control screens by hand) and that also crashed the game. And a totally blank picture, with no commands in it at all? Also crashes the game. Even a blank made in Sierra's own picture editor (start, save, exit) does.
I'm starting to think it's not a format thing.
The strangest thing is, I just went through the effort to remake the picture from scratch (export bitmap, create new, import bitmap, remake priority and control screens by hand) and that also crashed the game. And a totally blank picture, with no commands in it at all? Also crashes the game. Even a blank made in Sierra's own picture editor (start, save, exit) does.
I'm starting to think it's not a format thing.
7
The Games and other Sierra Adventure stuff / Re: King's quest IV: door out of place
« on: January 23, 2021, 06:51:28 PM »or messes.Mashes makes more sense in context. At least, mashing it up is the patch author's intent, and messing it up is what results considering the door's gone wonky.
8
The Games and other Sierra Adventure stuff / Re: King's quest IV: door out of place
« on: January 23, 2021, 05:40:32 PM »Maybe it's an issue with NRS's "Ultimate King's Quest 4" version? It meshes up resources from the various KQ4 versions.That's "mashes up". (My turn~)
9
The Games and other Sierra Adventure stuff / Re: King's quest IV: door out of place
« on: January 23, 2021, 10:16:03 AM »
I'm out of ideas.
10
The Games and other Sierra Adventure stuff / Re: King's quest IV: door out of place
« on: January 23, 2021, 09:40:41 AM »
The door is view 600, which has two loops of one cel each. For its closed state, the hotspot is at [0,0], so right in the center bottom. When it's open, the hotspot is at [-8,3], right next to the bottom hinge. If global100 is set, the door in room 28 is instantiated at [289, 137], which fits perfectly into the picture. Otherwise, it's instantiated at [284, 131]... which is also exactly right:
For comparison, I checked out the 1988 version. The coordinates are a little different (open hotspot at [-8, 0], positioned at [289, 139] and [283, 139]) among various irrelevant changes but otherwise there's still nothing here that could cause the door to be misplaced.
If I take the door view from 1988 and use it in the 1989 version, set it to loop 1 (open) and place it at [284, 131]... it ends up too far up.
...But guess what happens when you place the 1989 door in the 1988 background, at the 1988 coordinate?
That's right. Positioning-wise, it matches robingravel's screenshot. But the trees indicate that's the 1989 version. Closed doesn't seem quite right either, but not as obviously as when it's open.
Code: [Select]
(= door (View new:)) ; it's a local, don't ask me why.
(if global100
(door
view: 600 loop: 0 cel: 0
setPri: 9
posn: 289 137
ignoreActors: init: stopUpd:
)
(gEgo observeControl: ctlYELLOW) ;patch on the inside of the doorway
else
(door
view: 600 loop: 1 cel: 0
ignoreActors: true
setPri: 9
posn: 284 131
init: stopUpd:
)
)The rest of Room28::init is to handle the day/night cycle and where Rosella should appear, and that's the only place the door object itself is touched (saying "door" doesn't count). I honestly can't find anything here that could cause the door to be misplaced like this.For comparison, I checked out the 1988 version. The coordinates are a little different (open hotspot at [-8, 0], positioned at [289, 139] and [283, 139]) among various irrelevant changes but otherwise there's still nothing here that could cause the door to be misplaced.
If I take the door view from 1988 and use it in the 1989 version, set it to loop 1 (open) and place it at [284, 131]... it ends up too far up.
...But guess what happens when you place the 1989 door in the 1988 background, at the 1988 coordinate?
That's right. Positioning-wise, it matches robingravel's screenshot. But the trees indicate that's the 1989 version. Closed doesn't seem quite right either, but not as obviously as when it's open.
11
SCI Community How To's & Tutorials / Re: Must Print pause the game in SCI.?
« on: January 23, 2021, 09:05:41 AM »I've been banging my head against the wall trying to figure out that LSL3 code, then I just started trying random things.That's exactly right. The LSL3 code calls it in a state machine so that state machine can then also wait long enough and pop up the next plot dump, and the PrintPlot wrapper returns how long it told Print to wait plus another three seconds. That's what the roomscript then uses as a delay until the next state/plot dump.
it turns out if I add #time 3 and #dispose 0, the print window will linger on the screen for 3 seconds as the gameplay continues.
This seems like a pretty simple way of doing this?
12
Everything-Else / Re: Dialogue Interface
« on: January 22, 2021, 08:05:34 PM »
No. The #button thing is just a number that Print recognizes. It has no inherent meaning of "place a button control", that's just how Print reacts to it.
I'd rather make my own dialog box, put whatever control I want in it, like custom buttons. Think of the save/restore window, for example.
I'd rather make my own dialog box, put whatever control I want in it, like custom buttons. Think of the save/restore window, for example.
13
The Games and other Sierra Adventure stuff / Re: King's quest IV: door out of place
« on: January 22, 2021, 08:00:29 PM »
If nobody else answers before I do, I may just look into this tomorrow.
For my own reference, this is the 1989 release.
For my own reference, this is the 1989 release.
14
Everything-Else / Re: Dialogue Interface
« on: January 22, 2021, 06:10:33 AM »Is there a simple way to take away the button borders of the deselected options, kind of like in the inventory?Both of these could be done by using custom buttons. Make your own (class CustomButton of DButton and give it a Draw method. You should now be able to draw the button any way you want, using the ns____ rectangle for positioning.
Also I've been looking for a way to align the button text to the left rather than centered?
15
SCI Development Tools / Re: Changing message - fails
« on: January 22, 2021, 06:06:13 AM »
I find the reference idea unlikely. For version 4000+, every entry without a reference has the reference bytes set to zero, and all entries that do use a reference have blank text. But in QFG1, the mystery values are non-zero.
If it's an audio link, I suppose the values should be preserved. What game would you suggest I test that on?
And if it's timestamps (in three bytes?) that'd mean that's the only version of the Message resource that has those. And personally I think it'd make more sense to put that sort of metadata at the end, in the Comments section.
If it's an audio link, I suppose the values should be preserved. What game would you suggest I test that on?
And if it's timestamps (in three bytes?) that'd mean that's the only version of the Message resource that has those. And personally I think it'd make more sense to put that sort of metadata at the end, in the Comments section.
SMF 2.0.14 |
SMF © 2017, Simple Machines
Simple Audio Video Embedder
Page created in 0.112 seconds with 21 queries.