Messages

1

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

« on: October 17, 2020, 12:06:52 PM »

What is quick work, really? Phil added it twelve hours ago at the time I write this, and I finished backporting it three hours ago.

Edit: I'm an idiot who didn't recognize "troflip". I'm too used to "Phil". Awk-ward~

2

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

« on: October 17, 2020, 07:01:31 AM »

Phil added a GIF exporter to SCI Companion, but it only works if there's a 999.pal. Naturally, no SCI0 game would have a palette resource.

So when I copied this feature, I altered it to use the current picture's embedded palette (SCI1 or better) or a hardcoded CGA. And here's the result.

This is not yet available from the link in my signature.

3

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

« on: October 13, 2020, 05:52:39 PM »

Obviously. But if it can render a picture at any point in the command list, and export it to a bitmap, and the animated GIF thing is right there...

4

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

« on: October 13, 2020, 08:00:04 AM »

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

I've found this to be a bit iffier to do than you make it sound, tbh, if you want only the picture and none of the blue border.

Oh god why'd I just think the words "pic menu, export to gif"?

5

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

« on: October 12, 2020, 05:55:32 AM »

Seriously? Just zoom out to 1:1, put the targeting window for GifCam roughly around the edge of the picture frame, hit record, and hold down in the command list. Bam.

Cropping in GifCam is a bit of a chore but if you have anything else like... I dunno, Aseprite? You can just use that to crop away the blue border.

6

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

« on: October 11, 2020, 03:45:18 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.

That's literally what I did five years ago.

7

The Games and other Sierra Adventure stuff / Re: The Legend of ZCI

« on: October 09, 2020, 06:02:01 PM »

Not using the autotracer is a win in my book.

8

The Games and other Sierra Adventure stuff / Re: The Legend of ZCI

« on: October 09, 2020, 04:33:24 AM »

Ha nice!

9

AGI Development Tools / Re: WinAGI Version 1.2.5

« on: October 07, 2020, 12:25:09 PM »

I can't replace the on-site copy, but I can update the rest of it.

In fact, I did so five minutes ago.

10

SCI Development Tools / Re: Error in SCICompanion documentation - fopen

« on: October 06, 2020, 05:55:44 AM »

Looking deeper into this just to confirm, according to the SCI11 source code the FileIO kernel call passes the return values from creat and open, old-school file routines that return either a valid handle or -1.

• If the mode argument is 2 (F_TRUNC in C, fTrunc in Sierra's header, fCREATE in Brian's), call create(buf, 0) and return the handle it returned, which may be -1.
• If it's not 2, try to open(buf, O_RDWR).
  • If that didn't work (it's -1) and the mode is 0/F_APPEND/fAppend/fOPENCREATE (fOPENFAIL in SCI0 because of a mistake), creat the file instead.
  • If it did open the file and the mode is 0/F_APPEND/fAppend/fOPENCREATE, seek to the end. In either case, return the handle, which again may be -1 if the creat call failed.
  • Behavior for 1/F_READ/fRead/fOPENFAIL is implied -- if the file could be opened in the first place, we're done!

Lacking any source code for SCI0, I can only assume its separated file IO kernel calls are the same in actual use. Just make sure to keep in mind that Phil has chosen to keep Brian's mistake in the SCI Companion header file, so fOPENCREATE and fOPENFAIL are reversed. Personally, I'd just use the Sierra names and avoid the collission.

11

SCI Development Tools / Re: Error in SCICompanion documentation - fopen

« on: October 05, 2020, 03:41:59 PM »

Of course, if the program itself uses a local copy of the docs, it's well within my power to correct it that far.

12

SCI Development Tools / Re: Error in SCICompanion documentation - fopen

« on: October 04, 2020, 06:30:42 AM »

The only better place would be GitHub, and even then specifically Phil's if you want the online version to be corrected. But this'll do, and I'll at least update the copy that comes with my branch.

At a closer look, you might want to notice how the SCI Companion doc you linked describes FOpen, a kernel method onto its own, while the original documentation describes FileIO fileOpen, a sub-operator.

13

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

« on: October 01, 2020, 05:43:37 AM »

Sorry, best I can offer is a raw command editor.

14

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

« on: September 30, 2020, 04:42:41 PM »

This was the points jingle from a Sierra game, I don't recall which, that I converted to MID via I think SV, then edited to have the same four notes as the title screen for The Dating Pool in I think it was MuseScore, then imported back with SCI Companion.

At some point in that process, I suppose, extraneous commands snuck in.

Edit: also the header may not match Ravi's docs because this is not an SCI0 sound?

15

SCI Development Tools / Re: SQ3: Where is "Where am I?"?

« on: September 30, 2020, 10:19:40 AM »

From what I can see, SCI Companion does acknowledge there is a digital sample in there. I open sound.100 and I see one row marked "D". This being a MIDI-oriented editor, it doesn't bother trying to draw the waveform like it does the note events, nor does it try to play anything. Exporting the resource and opening it in Audacity as an unsigned 8-bit 11000 Hz raw PCM, playing that gives me a click of the header, and a perfectly fine "where am I?".

Digital samples in SCI0 were simply appended to the end of a sound resource, from what NewRisingSun told me.

All that being a match, you could make do with a hex editor and some smarts. I'd point out some official tool but I can't seem to find any.

The digital sample header is 44 bytes long. Offset 14 in the header contains the frequency as a short integer. Offset 32 contains the sample length, also as a short integer.

But since we're talking about a digital-only sound, without any MIDI in it, we can ignore all that. Looking at the raw sound.100 in a hex editor, I see frequency 11000 (0x2AF8) at offset 0x33 and the sample length 7415 (0x1CF7) at offset 0x45. Selecting everything from 0x51 (a 0x7A) to the end is a span 7415 bytes in size, so that's our sound All else being equal, one should be able to just remove everything from 0x51 on, record a new sound of the proper format, append it in place of the original, and adjust the size field accordingly.

Attached is a proof of concept where I did exactly that, to make Roger sound like a confused Dutchman.