Messages

211

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

« on: September 30, 2020, 10:04:10 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?

So I decided to import the midi file into SCI Companion, and then save it as a sound resource. I discovered that SCI Companion is adding the extra control codes. I assume the import function adds them as default settings, even though the imported midi file already has those commands.

When it imports the file, SCI Companion keeps the original ticks per quarter note settings. But when it saves the data as a sound resource, it recalculates the time values to match 30 ticks per quarter note. That's how the 95/1 values get converted to 6/0.

I was surprised that SCI Companion will let you play the MIDI sound, adjust the tempo and add cues. But you can't edit/add MIDI notes, or change channel parameters? (i.e program/instrument, channel volume, etc). Are there editing commands that I'm not aware of? I have never used SCI Companion before.

212

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

« on: September 30, 2020, 03:55:45 PM »

Very interesting. The sound resource is certainly different from SMF. It definitely is using standard MIDI messages though.

The time differences are due to the ticks per quarter note value; for the sound resource, there are 30 ticks per quarter note (or 60 ticks per second); for the MIDI file, there are 480 ticks per quarter note (or 960 ticks per second). So 96 ticks in the MIDI is 0.1 sec; 6 ticks in the sound is 0.1 sec.

The the total sound length of both files is 0.4 seconds, but interestingly, the MIDI file plays each note for 0.99 sec(95 ticks), then has a 0.01 sec (1 tick) delay before starting next sound. The sound resource plays each note for the full 0.1 sec, with zero delay between them.

The sound resource header is not familiar at all to me (I did a cursory read of Ravi's files, but what he describes as the header doesn't seem to make sense for the resource file you posted; it looks to me like it would result in the MIDI events being completely misaligned, but again, I'm no SCI sound expert.)

The sound resource also has a couple of duplicate/unnecessary control messages (it first sets instrument to grand piano, then later sets it to glockenspiel; it calls channel volume and pan levels twice)

I'm curious, which came first here? Was the sound extracted from a game resource, and converted to MIDI? or was the MIDI file converted to a sound resource and then inserted in the game? I would have expected the conversion to duplicate all control codes exactly regardless if which direction you were going. I wonder why they are so different between the two.

(And if you're interested, I've attached annotated versions of both files breaking down exactly what each midi event does. It helped me parse through all the data.)

213

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

« on: September 29, 2020, 06:51:01 PM »

Who is Ravi Iyengar?

Looking at his comments, I see now that the data are already in MIDI format. OMG, it's been 15+ years since I studied MIDI when I was looking at AGI sounds! I didn't recognize it at first.

The actual music is stored in a series of events. The generic form for an event is:

<delta time> [byte - status] [byte - p1 [p2]]

Delta time is the number of ticks to wait after executing the previous event before executing this event. Ticks occur at 60 Hz. The delta time value is usually a single byte. However, longer delays can be produced by using F8h any number of times before the delta time value. Each F8h byte causes a delay of 240 ticks before continuing playback. For example, the sequence F8 F8 78 FC waits 600 ticks then stops the sequence because of the FCh status. The fact that F8h waits F0h ticks makes me think that E9h is the largest technically allowable delta time.

The number of ticks per second is defined by the MIDI header, and can be any number. Do all SCI MIDI sounds use the same value of 60 Hz? It sounds like that's Ravi's assumption. Unless there's a definitive specification statement from Sierra saying that's true, it's probably not wise to just assume it's so. Should be easy enough to confirm for any given sound resource though.

Also, Ravi is incorrect in how he's interpreting delta time. Delta time is passed as a 'variable-length' value, meaning it can be 1,2,3 or more bytes long depending on how large the time value is. The value is broken up into 7-bit chunks; each chunk is passed as a byte, with the most significant bit set to indicate that there is another chunk to follow. The last chunk has its most significant bit cleared. To actually get 600 ticks, the bytes passed would be  0x84, 0x58. His example of 0xF8, 0xF8, 0x78 would actually give a delta time of 1,981,560 ticks.

Again, that's assuming the data are really in true MIDI format. If so, then based on Ravi's explanation of track events, I still wonder if the tools are converting the sound data correctly.

214

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

« on: September 29, 2020, 10:37:54 AM »

it's well known that the original tools used to convert AGI sounds to MIDI had a timing issue as well. They used a tick duration of 1/64 sec instead of the correct value of 1/60 sec. Is it possible that a similar error exists in the SCI tools? That equates to an error rate closer to 6%.  IDK how sounds are stored in SCI resources, and/or converted to MIDI so this might not be relevant.

215

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: September 25, 2020, 06:39:30 PM »

 DISCLAIMER: I'm an AGI guy, and have never used any of the SCI tools, so this may be of no help at all!

Renaming is probably not the hardest thing to do. In WinAGI, that functionality has been around for awhile now. If you change resource IDs, or rename globally defined variables, it will automatically update all your source code. CosmicR is right that it's more than just find/replace text; you have to find/replace tokens. Whole word search is not the answer, because that will also grab words in strings, words in comments, etc.

I didn't have anything like the Crystal Edit control available in VB, so I wrote my own custom control for the text editor. I figured out it wasn't too hard to add token search (as opposed to word search) by using an approach similar to what the parser uses when it compiles the source. I imagine something similar could be added to your SCI editor - a custom find/replace token function that uses a similar strategy to the compiler to identify tokens.

216

AGI Development Tools / Re: NAGI is not working properly on Windows 10

« on: August 27, 2020, 11:48:50 AM »

SDL2.DLL is not drop-in compatible with SDL.DLL. You likely wouldn't even get an application window if you tried.

I didn't even think of that, thx for pointing it out. I've been doing some reading on SDL to see if I can use it in next version of WinAGI. Obviously I still have a lot to learn! 

217

AGI Development Tools / Re: NAGI is not working properly on Windows 10

« on: August 24, 2020, 03:16:56 PM »

The most recent version of SDL is 2.0.12. NAGI was built using an earlier version.. The SDL wiki says that there are a lot of changes from SDL1 to SDL2, specifically in the graphics area that are not backwards compatible. It could be that notebook has SDL2 on it, but your desktop has SDL1.

218

AGI Community How To's & Tutorials / Creating a Custom Status Line

« on: June 24, 2020, 05:03:00 AM »

I got asked by a new user for help with creating a custom status line, as part of an effort to translate AGI games into other languages.  I thought I'd post my reply here in case anyone else has the same question.

It's not too tough to create a custom status line, but there are a few things that you need to consider to have your custom status bar behave exactly the same as the built in one.

To start with, you need a way to let AGI know whether or not you want the status line to show up or not. A flag is the obvious choice - say fStatusOn. 

With this flag, you can add code that runs in every interpreter cycle that uses the display() command to show your custom status line when fStatusOn is set, or clear it when the flag is not set.

While this is a good start, you will find that your status line will flicker, because it gets drawn in every cycle, even when there are no changes. To solve this, a second flag, fUpdateStatus, can be used to control when to draw the status line.  You can check this flag, and then only display or remove the status line when fUpdateStatus is true.

When you do need to update the status line (for example, score has changed), set fUpdateStatus to true.

This solves the flickering problem. And the result will work almost exactly the same as the built in status line. But there are still a couple more things you need to do to handle a few edge cases.

The first is dealing with the menu. When the menu.input() command is called, AGI will display the menu at the start of the next interpreter cycle. Assuming your menu is on the same line as your status line (as is the case with almost all Sierra AGI games), it will overwrite your status line. After dismissing the menu, your status line is erased. The way to solve this is to use fUpdateStatus after the menu.input() command. To reduce flickering, you also should place your code that draws your status line BEFORE the menu.input() command.

The second thing to consider is any code that implements the text mode. That would be the status() and text.screen() commands. You will need to force your status line to redraw after either of these commands run, because your status line will get erased when AGI switches modes.

A sample logic is attached that contains code (with lots of comments) that demonstrates this. Using this approach, you can create your own status line that is as complex or as simple as you like.

219

AGI Development Tools / Re: WinAGI Version 1.2.5

« on: May 14, 2020, 11:06:18 AM »

OK. I'll send you a PM with a test app.

220

AGI Development Tools / Re: WinAGI Version 1.2.5

« on: May 13, 2020, 01:28:04 AM »

Definitely very strange. All other file operations use lowercase file extensions, so maybe that is the problem. I could try using "words.tok" (lower case) as the filename.

I can build a small test app that tries opening/closing a file with different versions of the file name and extension (upper, lower, title) - if you could run that, it would least confirm or reject the hypothesis that it's related to file extension case. Let me know if you're interested in testing.

221

AGI Development Tools / Re: WinAGI Version 1.2.5

« on: May 11, 2020, 01:24:08 PM »

OK, that message is the WinAGI generated error message. That confirms what I thought was happening; something is maintaining an open file handle to WORDS.TOK, preventing it from being deleted.

I went through all the code again, line by line; there is just no place in WinAGI where that file is opened for longer than three lines of code; it gets opened, data copied to memory, then closed before anything else happens. It's the same process used for all files, including VOL files, DIR files, and OBJECT, also individual resource files. I can't explain why it would behave differently for WORDS.TOK. I also feel confident that the only direct references to "WORD.TOK" are all upper case; there's nowhere in code where it's referred to by lower case letters. I will continue to look to see if I'm missing something - there is a lot of code to look through.

Are you seeing any problems with updating/modifying any other game files? Can you make changes to OBJECT? What about a full recompile? Does that rewrite all the game files correctly?

222

AGI Development Tools / Re: WinAGI Version 1.2.5

« on: May 10, 2020, 01:21:55 PM »

That's certainly odd. To be clear, the error you got was "WORDS.TOK compile error(55: File already open)"? if it was formatted differently then it's not coming from WinAGI.

The compile (save) function for WORDS.TOK is not complicated; it creates a temporary file, adds the content, then replaces the existing WORDS.TOK file with the newly created temporary file.

If the existing WORDS.TOK file has an open handle, then the OS can't delete it in order to copy over the new file. That seems to be what you are experiencing. But WinAGI doesn't hold the WORDS.TOK file open - when the file is loaded for any reason (editing, previewing, etc) it opens the file, extracts the data to memory, then immediately closes the file.

So I don't know why the file has an open handle. If you are doing something else with it (maybe it's selected in a file explorer?) that may be holding it open. Is there anything else you were doing with any of the game files when this happened?

I'm pretty sure it's not being held open within WinAGI. There is literally only one place where a file handle is opened for WORDS.TOK - in the Load function - and it only opens it long enough to copy the file data into memory. Also, even if there was an error on opening, the error handler makes sure the file is closed and the handle released.

Oh, and regarding the .agw format, don't bother- it's basically a text dump of the words. Fifteen years ago, when I first made this program, I had this idea of creating an updated AGI interpreter, that would support improved graphics, sound, mouse support, etc. I've long since given up on that idea. The alternate formats for words and inventory objects were one of the first things I played around with. I left them in, but they really don't have any useful purpose, other than providing a human-readable version of words and objects.

223

AGI Development Tools / Re: AGI2HD Picture Redrawing Script Creator

« on: April 22, 2020, 03:17:54 PM »

Oops! Good catch!

I've probably read that a million times and never noticed it. Goes to show that the best proof reader is someone OTHER THAN the author! 

224

AGI Development Tools / Re: AGI2HD Picture Redrawing Script Creator

« on: April 22, 2020, 12:32:30 PM »

@MusicallyInspired,

That looks like an interesting idea. There are certainly a lot of challenges.  I noticed in your rendering, you can see where in some cases they like to use lines as a way to 'fill' smaller areas (like the blue console on the right for example); that'll be a tough one to figure out.

The image has a really cool 'concept art' feel to it though. I like it!

Regarding the Help file entry for Relative Lines - sorry for not making that clearer; I should have been more specific about the individual bits and exactly what they mean. I will include that in the next version of the Help file.

If you come across anything else in the file that is not clear, please ask. If not me, you can always count on the other AGI 'regulars' to help clarify anything that I didn't explain well in the Help file.

cheers!
Andrew

225

AGI Syntax Help / Re: AGI and changing font

« on: March 07, 2020, 05:21:36 PM »

I tried out the latest version of WinAGI - great AGI-ide. One thing though - I want to localize some strings in my Kings Quest translation with non ASCII like ?,?,?, Is this possible with an AGI-game, and how do i do it - with WinAGI if possible. Thankful for any help.

As of now, YES, it is possible. See this thread for an explanation and source code to do it.