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.

Messages - AGKorson

Pages: [1] 2 3 ... 8
AGI Syntax Help / Re: Questions about ROL and anyword
« on: November 10, 2020, 03:27:09 PM »
I realize I'm addressing a post that is EXTREMELY old, but I wanted to make sure that accurate information is provided in case anyone else comes here looking for an answer to the qestion.

The original problem posted is not an issue with AGI's handling of input; it's an issue of where commands are processed in the game's logic.

Code: [Select]
if (said("why", "rol"))
will return TRUE for any input that begins with "why", including "why" by itself, "why" followed by known words, and "why" followed by an unknown word (as long as haveInput[f2] is TRUE, and haveMatch[f4] is FALSE). The reason the original poster is getting the "I don't know X" message is because the check for unknown words is happening BEFORE the check for "why", "rol".

This is easy enough to demonstrate by putting the 'if' block at the beginning of Logic 0. You will get the desired response. As they say, 'timing is everything', and with AGI, it's even more important to know where you place code to make sure you get the results you want. The cyclic and linear nature of AGI programming can result in really strange results if you don't pay attention to the order of things.

(AND, if you also have an unknown word in your input, keep in mind that even after displaying the response to 'why', you may also get the "I don't know X" response, depending on how your game handles unknown words. The templates that have been around for years will show the "I don't know X" response even if a preceding 'said' command finds a match. You will need to either reset the unknown word value (v9) within your code block responding to "why", or you will need to edit your unknown word handler to not respond if a match has been found.)

I have a new version of WinAGI mostly ready for release. But I would like some fresh eyes on it before I call it good.

Here's a list of the biggest changes/upgrades:
  • LISTBOX option to display resources (in addition to the original treelist option)
  • DIR files expand/contract as resources are added/removed (instead of staying expanded to full size)
  • application size/position saved correctly on systems with more than one monitor
  • NAVIGATION BUTTONS to allow user to step backward and forward through selected resources in the resource list; right-click/hold to scroll through the list
  • all agi commands are now highlighted as 'keyword' type in logics when using syntax highlighting
  • MANY fixes to the rich text box used in logic editor, so it does a better job of handling selections/edits/highlights
  • right-click on a resource ID in a source file, and you now have the option to open it from within the logic editor
  • SNIPPETS! you can use shortcut codes to insert 'snippets' (code fragments) of frequently used code
  • you can right-click on a word in a 'said' command to show a list of all synonyms of the selected word
  • transparency color of a cel is now shown on palette on view editor (ctrl+click to change transparency color)
  • added comment column to the global editor so you can add comments to each defined term
  • searching for vocab words in logics now has option to include search for all synonyms
  • added setting that syncs the resource list to the layout editor; selecting a resource in the list will automatically scroll the layout view so the selected room is centered in the window
  • hold down shift key with left mouse to drag the entire layout drawing surface
  • Find/Replace supports multi-line values
  • ... plus a TON of other minor enhancements, and countless bug fixes

I would like to have the new version ready for release in the next two weeks. So if you are interested in helping with one last good look to make sure there are no glaring issues, please PM me, and I'll send you a link to the install file.

Is there a "recommended IDE" for AGI (like SCICompanion for SCI)?
I may be a bit biased, but I'd say "WinAGI, hands down!"  ;D

Specifically, I want to open KQ4, Apple 2gs version (trying to understand the problem at
I have tried some IDEs (honestly, don't remember which, it was a long time ago), and all failed to open logic 54.
Just tried now AGI Studio, and upon opening logic 54 it says:
Code: [Select]
Error decoding logic (position 0x0E4E): Unknown action command (175)
Is there something special with opcode 175?
Something 2gs specific? KQ4?
Some other complication?
Opcode 175 is the discard.sound command. It was added beginning in version 2.938, but only functions in non-MSDOS games. The MSDOS interpreters all have a stub function in place that was intended to ignore the command, but that stub function does not accept arguments. If you try to run that command on a MSDOS interpreter your game will crash, because the argument value passed to discard.sound gets treated by the interpreter as the next opcode instead of the sound you want to discard.

Anyway, I've just found that with latest WinAGI  ( it opens logic 54 with no problem.
That's great news.

However, when I tried to open any sound resource, it gave an error:
Code: [Select]
Error while loading sound resource

598: Invalid sound data: unable to load sound resource

Is it because of something special with 2gs? or KQ4? or something else?

Any recommendation, suggestion or fixes are welcomed.

MusicallyInspired is correct. Since the sounds aren't in the MSDOS format, WinAGI is currently not able to read or play them. I never had access to non-MSDOS versions of any Sierra games, so I haven't been able to decipher them to see how/if support for them could be added to WinAGI.

WinAGI has VERY limited support for non-MSDOS versions of AGI games. Right now, I think the only thing I added that specifically supports non-MSDOS is the ability to detect and read Amiga OBJECT files (they use four bytes per object entry instead of the 3 that MSDOS games use).

I don't have any non-MSDOS game files, so I am not able to study them to understand their structure/usage. If you have some game files that you are willing to share, I'd be happy to analyze them to see whether or not I can add support for them to WinAGI.

AGI Development Tools / Re: WinAGI help file
« on: October 07, 2020, 10:50:40 AM »
WinAGI help file looks quite impressive.
Is it possible to have it available online?
IMO it deserves more publicity...

Thank you for the compliment! If someone wants to host it online, I'm totally fine with that. It's html-based, so it would be pretty simple to make it a web site. I did update the wiki for all the AGI commands, and made a few corrections in other areas. If I had the time, I would like to do a major overhaul of the wiki to include all the info that's in WinAGI Help. But I just have too many other things I'm working on. Again, if someone else wants to start moving info from the Help file to the wiki, I'm 100% behind that effort!

(And the latest WinAGI update, version 1.3, is coming in a matter of days; the Help file in this new version has added more information, especially on understanding the nuances of the AGI commands, and how to use them most effectively to avoid unwanted results/errors. A beta version will be sent to a few people later this week, and then a release will be out a week or so after that!)

AGI Development Tools / Re: WinAGI Version 1.2.5
« on: October 07, 2020, 10:43:59 AM »
Please update the "quick" link for WinAGI, at
Last I heard, the person who has admin rights to do that is gone, and there's nobody left who has the right access. Maybe that's not the case anymore - the site admins will have to weigh in.

I'd also like to say that I have a new version, WinAGI 1.3 coming out very soon; I have a beta build that I'm planning to send to a few people by end of this week. Adds a lot of improvements and fixes. So keep an eye out for that!

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.

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.)

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.

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.

 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.

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!  ;D

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.

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.

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.

Pages: [1] 2 3 ... 8

SMF 2.0.14 | SMF © 2017, Simple Machines
Simple Audio Video Embedder

Page created in 0.11 seconds with 21 queries.