Messages

1

SCI Development Tools / Re: Batch export vector draw commands one by one

« on: October 17, 2020, 11:21:35 AM »

You made quick work of that!

2

SCI Development Tools / Re: Batch export vector draw commands one by one

« on: October 14, 2020, 03:22:54 PM »

Real support for this would include sub-command frames. For instance a large fill operation could take up several frames. So it draws slowly just like AGI did on computers back in the day. (Or was that just on the Apple II?)

3

SCI Community How To's & Tutorials / Re: Global animations using changeState

« on: October 12, 2020, 05:33:47 PM »

I can't think of any reason it would not work in the main script. But it seems like this would belong more in a Rgn (region).

I don't exactly understand your original problem:

This works fine except it will only run the case which I call from the said statement without going to the next case after =cycles x or =seconds x.

... but it sounds like you might be calling changeState on a script that already has cycles or seconds set on it. You probably want to zero those out before calling changeState.

4

SCI Development Tools / Re: Batch export vector draw commands one by one

« on: October 12, 2020, 05:29:54 PM »

That sounds incredibly tedious. Maybe a hundred or more drawing “frames” and cropping et al.

I've done this many times before for making twitter gifs, I don't find it hard at all. It takes about as long as it takes to hold down the down arrow key in the cmd window, or slide the horizontal slider across the screen. Then bam, save gif and you're done.

Not sure what cropping you'd need to do. Just position gifcam over the portion of the pic window that has the pic?

5

SCI Development Tools / Re: Batch export vector draw commands one by one

« on: October 11, 2020, 01:27:16 PM »

There's no way to animate the steps, no. That would be neat though.

You can just use a gif capture tool (like GifCam) and either manually move the pic slider, or put focus at the top of the piccommand cmd window and arrow down.

6

SCI Syntax Help / Re: editing PICs

« on: October 10, 2020, 09:51:37 PM »

Unfortunately there's no way to do that 

And yes, there are still some crashing bugs in the pic editor when cutting/pasting/transforming coords. Still haven't been able to track it down.

7

SCI Syntax Help / Re: editing PICs

« on: October 10, 2020, 12:40:13 PM »

There's a "transform coords" button in the toolbar, to the right of the Toggle Priority Lines button.

If this is checked, then when you hover over the image, the "control points" of whatever drawing tool is selected (pen, line, fill) will light up and you can drag them.

That only works for individual points though.

To move groups of things, select the cmds in the cmd window on the left, then cut (ctrl-x) and paste back (ctrl-v). Then you should be able to drag them as a group in the image area (there are also hotkeys, on the numpad I think, to stretch/shrink them).

8

The Games and other Sierra Adventure stuff / Re: I just wanted to record some MIDI...

« on: September 29, 2020, 11:48:30 AM »

I was going to switch to SCI Companion, but that has an even dumber problem. The MIDI playback tool has a very silly bug in it. It plays at the right speed, but it only plays notes AFTER the loop point, and not the ones ON the loop point like it should. This results in a lot of sound cutting out.

Looking at the code, it seems this is quite explicit, I even added a comment to that effect:

Code: [Select]

void MidiPlayer::_OnStreamDone()
{
    if (!_fStoppingStream)
    {
        // There is more to this stream... keep going.
        if (_cRemainingStreamEvents)
        {
            _CuePosition(_cTotalStreamEvents - _cRemainingStreamEvents);
        }
        else
        {
            if (_dwLoopPoint != SoundComponent::LoopPointNone)
            {
                // Cue the loop point. We start playing events *after* the loop point, not at the loop point.
                CueTickPosition(_dwLoopPoint + 1);
            }
            else
            {
                Stop();
            }
        }
    }
}

I'm not sure why I thought that though. Maybe it's true for some SCI versions and not others? I wonder what ScummVM does.

9

SCI Syntax Help / Re: Sci.0 wish-list: diagonal movement, title-bar colour, and parser questions

« on: September 20, 2020, 04:23:24 PM »

1 - In certain rooms up and down arrow will result in diagonal movement. Codename: Iceman has this in one or two of the beach rooms at the beginning. it's subtle, but saves a lot of up-left-up-left movement to get through a narrow 45 degree angle path.

In the Rm properties, assign values to vanishingX and vanishingY. They indicate where the vanishing point (https://en.wikipedia.org/wiki/Vanishing_point) of the room is. Pressing up will make the player walk towards the vanishing point, pressing down will make them walk away from it. (Assuming it's all hooked up properly in the SCI0 template - not sure it is because it was based off LSL3, which maybe didn't use this feature.)

Typical values might be

Code: [Select]

vanishingX 160 ; right in the middle
vanishingY -200 ; 200 pixels above the top of the screen

You could probably make the player walk at close to 45 degrees if you placed it way off to the side, like I dunno, (-1000, 1160) or something.

10

SCI Syntax Help / Re: Old SCI0 Template Save Bug

« on: July 18, 2020, 04:45:24 PM »

Wow! You should feel good about finding that one! 

11

SCI Syntax Help / Re: Old SCI0 Template Save Bug

« on: July 17, 2020, 12:15:39 AM »

I think the thread took a turn and stopped being about the save bug 

12

SCI Syntax Help / Re: Old SCI0 Template Save Bug

« on: July 14, 2020, 12:14:18 AM »

Troflip, do you think it might be possible to hack around it with some custom post-processing that would (re)create the .dir file with the correct values?

I think you could hack around it by limiting the save game count to 19 instead of 20.

I haven't tried it, but if you change this to a 19, it should limit the save game count to 19, and then I think the bug doesn't repro:

Code: [Select]

(procedure (CheckForFreeSpace)
(if (< local2 20) (CheckFreeSpace gSaveDirPtr))
)


13

SCI Syntax Help / Re: Old SCI0 Template Save Bug

« on: July 13, 2020, 02:58:22 PM »

It looks like the values returned by the GetSaveFiles kernel are wrong (or at least don't match the files). It always has 0 in the first slot. These are the contents of strPtrs just after the GetSaveFiles call in SRDialog:init.

14

SCI Syntax Help / Re: Old SCI0 Template Save Bug

« on: July 13, 2020, 02:24:48 PM »

Back to the original issue:

After saving 20 games, A-T, the beginning of gamename.dir will look like:
13 00 73 0a 12 00 72 0a      slot 19 (T), slot 18 (S), ...
That's basically, slot number (in hex) followed by string that appears to be 0a-terminated.

Then I save over S (2nd in the list). And I get:

12 00 72 0a 13 00 73 0a      slot 18 (S), slot 19 (T), ...

Looks great, exactly as it should look.
The time stamp on the file shows gamename.dir and gamename.018 written to, which is correct.

But now if I delete gamename.018, I can still load S (but actually it's not S, see below)

However, if I delete gamename.000, I can no longer load S. Which means loading S is actually trying to load the wrong save.

So what's going on: S is being saved properly (to gamename.018), but when we load we are loading gamename.000. This is despite gamename.dir linking S to slot 18. This isn't some kind of memory corruption, it persists even if I close and reopen the game.
If I rename gamename.000 to gamename.018, then I can load the "missing" S save.

So somehow, it appears the save games get into a state where the first slot number in gamename.dir is always getting treated as 0 by the game, despite the data in gamename.dir.

15

SCI Syntax Help / Re: Old SCI0 Template Save Bug

« on: July 13, 2020, 02:06:59 PM »

I took a quick look at this.

It seems like even if you save over the most recent, it doesn't work properly. For instance,
- I save 20 games, A through T
- Then I try to save over T and give it the same name
- The result is that it deletes game A, and now there are two game T's.