Messages

1

AGI Syntax Help / Re: Global Variables/Flags Possible?

« on: October 12, 2021, 10:43:15 PM »

Good catch. When a new.room command is encountered, any sound that is playing is stopped, which will reset the flag associated with the sound. When a sound is stopped for ANY reason, its flag is reset. If no sound is playing, no flag would get reset.

The complete list of affected flags and variables when a new.room command is executed are:

• reserved variable v0 is set to ROOMNUM argument of the new.room command
• reserved variable v1 is set to previous room number (what was in v0)
• reserved variable v2 (ego edge code) is set to zero
• reserved variables v4 (object touching edge) and v5 (object edge code) are set to zero
• reserved variable v9 (unknown word number) is set to zero
• reserved variable v16 (ego view number) is set to current ego view number
• reserved flag f2 (input received) is reset to FALSE (but reserved flag f4 (said found match) is not modified; this appears to be a minor bug, but it usually not an issue)
• reserved flag f5 (new room) is set to TRUE
• if a sound is playing, it is stopped and the 'done' flag is set to TRUE

Any other changes that you see are because there's a specific line of code somewhere in your logics that's doing the change.

In the template games, the reset logic is usually logic #92 (lgc.RoomInit).

2

AGI Syntax Help / Re: Global Variables/Flags Possible?

« on: October 12, 2021, 11:07:17 AM »

Most AGI games (especially fan games that use the common templates) have a logic that runs with each new room call that resets/clears a range of flags and variables- usually from 220 -255. If you want a variable/flag to persist across rooms, don't use one from that block. Or modify/get rid of the reset script.

A bit of history - original source code from Sierra reveals that they treated flags and variables as one of four scopes:

• reserved - those used by the AGI engine internally (v0-v26, and f0-f16, f20)
• global - which were used/accessed/modified across all logic scripts (usually v27-v219 and f21-f219)
• local - used within a specific room only (usually v220-v239 and f220-f239)
• dynamic - used within a specific logic script, but not associated with a room (usually v240-v255 and f240-f255)

Keep in mind that in fact there is only one scope for all flags and variables in AGI- that's 'global', i.e. all variables and flags are visible to all logic scripts and the game engine at all times. The scopes described above are an entirely artificial construct used by Sierra (and fanmade) game programmers to make it easier to manage them. Which is why they needed to include a script to reset/clear them every time a new room was encountered.

3

AGI Development Tools / Re: Mouse move target question

« on: October 01, 2021, 10:42:52 AM »

I recall AGI Mouse and NAGI weren't quite as elegant and would cause Ego to move in such a way that it would traverse the x and y distances at the same time at the same intervals instead of dividing the smallest distance evenly between the longest distance. So if ego was moving 4 pixels up and 10 pixels right he would move in a perfect diagonal line by 4 pixels to the upper right and walk the rest of the 6 pixels straight across horizontally. SCI/ScummVM's method is much better.

It's not just mouse movement - that's how all movement is handled in AGI - move.obj, follow.ego, etc. all move that way. It's because in each cycle, the interpreter 'forgets' where the original starting point was. I created my own algorithm to calculate the straightest path between two points, that is similar to the AGI line drawing algorithm- it uses only integer arithmetic, is extremely compact and works for any dx/dy, also handling different step sizes.

I've never heard of the Bresenham algorithm. I'll have to go check that out.

4

AGI Development Tools / Re: Mouse move target question

« on: September 30, 2021, 10:34:11 AM »

Oh yes, of course. That does make the most sense.   thx Kawa!

5

AGI Development Tools / Mouse move target question

« on: September 29, 2021, 02:44:21 PM »

This is really a more generic question, but I'll ask here because it relates to a current AGI project.

When a mouse is used to move ego, you click a spot on the screen, and ego moves to that spot. However, since ego has a non-zero width, what is the best way to position ego horizontally (in the X plane)? I can think of three options:

• Easiest option is to just set ego's position to the targetX, regardless of where target is. But this means if you click to the RIGHT of ego, ego's left edge will move to the clicked location. This feels weird though - I expect ego's right edge to go where I click in that case.
• Another option is to set ego's position to the targetX if clicking to LEFT of ego, but set it to targetX-width if clicking to RIGHT. If clicking in between left /right edges, ego's center is moved to target location. This feels a lot better to me than option 1.
• A third option, similar to second, but instead of moving the center of ego to the targetX when clicking in between left/right edges of ego, just move ego vertically (ignore targetX in that case).

Any opinions on which option is best? I am leaning toward option 2, but I wonder if option 3 feels more natural to a player. Any other suggestions on positioning ego in the X-plane?

6

AGI Syntax Help / Re: Need help adding text to parser

« on: May 21, 2021, 11:29:53 AM »

To be clear, in MSDOS, running on a monochrome monitor, AGI completely ignores the input prompt (i.e. it doesn't matter what you set string s0 to). The input box is hard coded to include the phrase "ENTER COMMAND" centered at the top of the box, with  the single input line that displays only the input text and the cursor just below. No input prompt is included, but you can change the cursor character (using set.cursor.char).

The buffer for the input text is in the same location as for any other video mode, but it is just as inaccessible. So you can't modify it through code, in HGC mode, or any other mode*.

@Kawa, btw, in your image the input box has the caption "Enter input" not "ENTER COMMAND". I assume that screen shot is from SCUMMVM then? Because in all the MSDOS versions I have, the caption is "ENTER COMMAND".

I don't know a lot about SCUMMVM, but my experience has been that the modern interpreters don't accurately capture all the nuances of the original DOS interpreter, because errors and edge cases tend to be ignored in modern systems (they don't let you overrun memory, for example). So there are things you can do in MSDOS (or using DOSBox) that modern interpreters just can't handle.

*I have a 'secret project' that I'm just about ready to release that will demonstrate some of the cool things you can do with the original DOS interpreter by taking advantage of some of their poor coding practices in AGI. (Spoiler: the functionality that klownstein is looking for is easily doable if you know the secret!)

7

AGI Syntax Help / Re: Need help adding text to parser

« on: May 19, 2021, 07:53:12 PM »

Unfortunately, the input line is not accessible in AGI through commands. The input line buffer is actually maintained in memory at the end of the code segment, just before the main memory heap - it's part of the data overlay, agidata.ovl.

But there are no commands that let you interact directly with that buffer. The get.string command uses a different buffer.

You might be able to fake it by changing the input prompt to include 'ask about', and then get input as usual. This might be a start:

Code: [Select]

if (controller(c49) {
  set.string(inputPrompt, ">ask about ");
  cancel.line();
  accept.input();
  set(f123);
}
I did a quick test of this and it works. When you test for 'said' input, you can check the flag; if it's set, you can respond appropriately. Then reset your input prompt (and the flag). You will also need to make sure you put the check for this flag before any other said tests to avoid unwanted results.

A limitation of this approach is that you can't backspace over 'ask about', because it's part of the input prompt. It might be possible to work around that too, but I'd have to think about it some more.

8

AGI Development Tools / Re: conWAGI.exe output redirection fails

« on: May 03, 2021, 09:47:40 PM »

Thanks for the tip Kawa! Maybe this will be easier than I thought.

9

AGI Development Tools / Re: WinAGI: feature request - batch import/export

« on: May 03, 2021, 09:38:41 PM »

I'll see what I can do. Exporting should be really easy. Importing might be a bit more work, because of the need to handle possible errors.

10

AGI Development Tools / Re: conWAGI.exe output redirection fails

« on: May 03, 2021, 12:07:58 PM »

Console apps are not my strong suit. There's probably a compile switch that is needed to allow output redirection? Or maybe I'm supposed to include something in the source code to enable it? I don't know for sure.

I'll add it to the bug list, but unfortunately, it will be way down at the bottom.

11

AGI Development Tools / Re: Should WORDS.TOK have even number of bytes?

« on: May 03, 2021, 12:05:04 PM »

The trailing zero is required. That's how the word search function knows it's reached the end of the file. If you strip that off, the word search function will continue looking at data from the heap that immediately follows the words.tok file (the OBJECT file), thinking it's valid word data; eventually, a null value will be found, which AGI interprets as the end of words. In most cases, this will happen without the player ever even knowing, because there is almost always a zero value (0x00) byte in the OBJECT file's header. That byte will cause the word search to end.

Even in the unlikely event that you have more than 85 inventory items (which means the header WON'T have a zero value byte), it would be even more unlikely that the rest of the OBJECT file header and item data would contain the exact characters needed to create a false word match before a zero value is eventually encountered.

I don't know the exact algorithms, but I would not be surprised if NAGI and SCUMMVM ignore the trailing null character; they most likely use array indices to keep track of the end of the word list (this is just speculation on my part though).

So, technically, you could have a WORDS.TOK file without the null character at the end, it will work 99.99999% of the time. But it's better to have that ending character, so WinAGI enforces it.

12

AGI Development Tools / Re: Sierra had keys to control sound volume in Tandy

« on: April 05, 2021, 10:51:02 PM »

Cool, thx.  I'll include this in the next update of the help file.

13

AGI Development Tools / Re: Sierra had keys to control sound volume in Tandy

« on: April 05, 2021, 12:28:18 AM »

I think this is pretty much well known in the AGI community. Support for volume control has been included in template games going back to the early AGI Studio days.

I have not tested on original hardware, but using DOSBox, (while writing the first versions of WinAGI) I confirmed that both PCJr and Tandy do in fact control sound by using reserved variable v23. I assume that the DOSBox implementation of the Tandy and PCJr machines is accurate. You can easily test this by creating a template game, and set platform to DOSBox, and then use platform command line switch option to use "-machine pcjr" or "-machine tandy". I never had access to any other platforms or game files for testing (Amiga, Apple, Atari, PS2), so I only included information that I learned from other sources, mostly from the source code provided here over the years.

I don't know for certain if any Sierra games included sound volume control for any machine types other than Tandy, but as I said, I do know it works for PCJr as well. I would assume it would also work for some of the other platforms, but again, I've never been able to test it.

I have never heard of machine type 20 being referred to as 'AmigaOld'; that's a new one to me. (I never spent a lot of time with ScummVM; I always preferred NAGI when I needed a modern AGI engine (and I usually prefer to use the original Sierra binaries in DOSBox anyway). If someone has some more definitive information to confirm it, I don't mind adding it to the help file for completeness.

As far as differences between Tandy and 'regular PC', the binary files are the same; when AGI loads on either platform, after determining the type of machine its running on, the same graphics overlays get loaded for both machines; in the binaries, there are separate functions in various places where graphics are handled that use the appropriate video control codes and interrupts to correctly display images. But at the AGI resource level, there are no differences. Sound is handled the same way; internally, the interpreter uses different functions to handle playback of sound depending on which machine type is present even though the same program and overlay files are used on both systems.

It is strange that they (Sierra) didn't include the sound controls in their help screens. The template files do.

14

AGI Development Tools / Re: WinAGI Version 2.1.10

« on: April 02, 2021, 11:10:43 AM »

Unfortunately, I know very little about SCI games. I spend enough time studying AGI, and have never had the time or interest to delve into the world of SCI.

As for converters, I'm not sure what exactly you mean. WinAGI is able to extract both MIDI and PCM sounds from IIgs games, which you can then export (i.e. convert) to the corresponding modern format. I admit that I don't have definitive answers as to exactly what each byte of data means in the sound headers, but using the assumptions I made, all IIgs sounds I've extracted sound legitimate. Here are my notes on both sound types, and how WinAGI handles them for doing the extraction:

Code: [Select]

  ' IIgs MIDI sounds:

  ' this function extracts the raw MIDI data from the IIgs sound
  ' and creates a new MIDI stream that is compatible with modern
  ' MIDI player format 

  ' length value gets calculated by counting total number of ticks
  ' assumption is 60 ticks per second; nothing to indicate that is
  ' not correct; all sounds 'sound' right, so we go with it
 
  ' the raw midi data embedded in the sound seems to play OK
  ' when using 'high-end' players (WinAmp as an example) but not
  ' Windows Media Player, or the midi API functions; even in
  ' WinAmp, the total sound length (ticks and seconds) doesn't
  ' calculate correctly, even though it plays;
  ' this seems to be due to the presence of 0FCh commands
  ' it looks like every sound resource has them; sometimes
  ' one 0FCh ends the file; other times there are a series of
  ' them that are followed by a set of 0Dyh and 0Byh commands
  ' that appear to reset all 16 channels
 
  ' eliminating the 0FCh command and everything that follows
  ' plays the sound correctly (I think)
 
  ' a common 'null' file is one with just four 0FCh codes, and
  ' nothing else, so ANY file starting with 0FCh is considered empty

  ' time values are supposed to be a 'delta' value
  ' but it appears that AGI used an absolute value; so if time
  ' is greater than 07Fh, it will cause a hiccup in modern midi
  ' players (we need to convert them to a valid delta time value)

  ' treat 0FCh as an end mark, even if found in time position
  ' 0F8h also appears to cause an end


  ' IIgs PCM (wav file) sounds:

  ' this function extracts the raw PCM data from a IIgs sound and
  ' adds a properly formatted WAV file header to it
   
  ' AGI header is 54 bytes for pcm, but its purpose is still mostly
  ' unknown; the total size is a word value at positon 08h; the rest of
  ' the header appears identical across resources, with exception of
  ' position 02h- it seems to vary from low thirties to upper 60s,
  ' maybe it's a volume thing?
 
  ' at position 06h is a word value of 02Ch = 44; this might be size
  ' of an internal header; there are 44 bytes of data, followed
  ' by 00-00 before the raw pcm data starts? (probably not - because at
  ' position 02Ah, there are six word values; 0C07Fh, 0236h, 0000h,
  ' 0C07Fh, 0236h, 0000h; this has the feel of two channel info,
  ' where both channels use the same data; 0C07Fh=49279; 0236h=566;
  ' 0C0h=192; 07F=127; 036h=54 not sure if any of these values
  ' are significant)
 
  ' at position 022h, there is a word value of 0203h = 8195; this
  ' might be the actual sample rate? it's close to 8000 (which was my
  ' original assumption) and it's really hard to tell the difference when either
  ' value is used for the exported sound
 
  ' all resources appear to end with a byte value of 0; not sure
  ' if it's necessary for wav files, but we keep it anyway

I figure it's a good idea to make this public information so others who are interested or are working on this can compare notes and (hopefully) improve on it.

Maybe this will be of use to you? Let me know if you become aware of any further information, especially if it affects how to correctly extract and convert the sounds for true replication. That way I can update WinAGI as well.

15

AGI Development Tools / Re: WinAGI Version 2.1.10

« on: March 30, 2021, 10:55:55 AM »

That's a tough one. I know very little about Apple IIgs and how AGI actually works on that platform. I do have the binary files, and if I could find a decent dissassembler, I could probably figure it out. I did some searching, but haven't come across anything like IDAPro Free that would be useful. So unfortunately, I can't help much. I suspect there are some people out there who know more about Apple IIgs who might be able to answer that question for you.