Messages

1

The Games and other Sierra Adventure stuff / Looking for an AGI Picture Artist

« on: July 26, 2022, 10:33:06 AM »

I'm working on a demo game to show off some advanced AGI coding techniques. But I need a bit of help with the art.

SPOILER ALERT: Imagine native support (i.e. no hacked interpreter files needed) in AGI for things like mouse support, 80 column text mode, MIDI and FM synth (e.g. Adlib, SoundBlaster) sound support, extended characters, full control of color palette, dynamic menus, data file input/output, customizable status line, and much more! Just drop the AGI Power Pack logic script into your game, and you get it all! Without using any resource memory!

I am not an artist. (If you've seen the WinAGI template game rooms you know what I mean.) So I'm looking for someone to help with 8 - 10 rooms so this demo will not look like a two-year old drew it with crayons.

The setting is an office building- I need some offices, a reception area, hallways, stairwells, a closet, stuff like that. If this is something you can help me with, send me a PM.

THX!!!

2

AGI Development Tools / WinAGI 2.2.3 goes International (sort of)

« on: June 04, 2022, 07:52:17 PM »

Here's the newest version of WinAGI: http://agiwiki.sierrahelp.com/index.php?title=File:WinAGI_2_2_3.zip

The big change in this version is support for non-English MSDOS codepages, which makes it much easier to edit resources in other languages. If you never intend on using extended characters or working in a language other than English, there's no reason to change from the default MSDOS codepage (437). (But I would still advise upgrading to this version; it also fixes a few more minor bugs, including the issue that causes it to fail on older versions of Windows.)

AGI doesn't contain any native support for non-English text/fonts. And showing extended characters on screen (other than in the text.screen mode) is not normally possible. So why bother adding this feature to WinAGI?

Using the string hack technique, it is possible to get AGI (when running on DOSBox, or on an actual MSDOS machine) to show all characters in whatever codepage the environment is set to. You can also get AGI to allow inputting letters with diacritics on the input line to let players use non-English words to play a game.

The logic code needed to make this work is very complicated, and formatting foreign words in your WORDS.TOK file is also quite complicated, but if you are interested in doing this, WinAGI now lets you edit your resources in the same codepage that your game will use, making translations (or creating new games in non-English) much simpler. It will also create word lists with non-English words (which are simply ignored in 'normal' AGI but work perfectly when paired with the codepage string hack technique).

3

AGI Development Tools / Re: WinAGI Version 2.1.16 Available for Download

« on: June 04, 2022, 07:00:48 PM »

I just finished testing on a Windows Vista system. The issue with the WORDS.TOK editor was there as well. After getting VB6 installed and running, I discovered that the icon property for one of the picture boxes is seen as corrupt in Vista, even though it works just fine in Windows 11. After deleting and re-loading that resource, everything seems to work fine. I have no idea why this was a thing, but there you go.

Version 2.2.3 is now available for download here: http://agiwiki.sierrahelp.com/index.php?title=File:WinAGI_2_2_3.zip

Hopefully this fixes the issue in all older versions of Windows. And Linux users should now be good to go again too.

4

AGI Development Tools / Re: WinAGI Version 2.1.16 Available for Download

« on: May 24, 2022, 10:33:10 PM »

That is an impressive amount of testing. I think I would have given up after 10 minutes.

I do see the irony in WinAGI being 100% compatible with Windows 10 and 11, but not running on earlier versions, given that VB6 was released around the time of Window 98.

To be fair, WinAGI makes extensive use of APIs, and I didn't intentionally look for backwards compatibility for any function calls; I chose whatever functions are currently available that met my needs.

I do have a couple of old cpus sitting around, and I have original install disks/CDs for most Windows versions (somehow I lost my MSDOS 6.22 install disks though- I kinda wish I still had those.) But I have so much stuff going on right now I don't know if I'll ever get around to doing any serious testing. It might be interesting to see if I could get the latest version to run in the VB6 dev environment on an older system to see if those issues could be debugged.

5

AGI Syntax Help / Re: Understanding how goto and else work

« on: May 05, 2022, 12:38:19 AM »

It would be nice to have scripting for the modern AGI IDEs/compilers use the same scripting as the original Sierra used, like Phil did with SCI.

Have you seen this post?

The original Sierra scripting syntax is completely known. 'else' and 'goto' are both supported. There are some significant differences between 'fan syntax' and 'Sierra syntax'.

And there are some really good reasons for not going back to 'Sierra syntax' for serious programming. Having that as an option for nostalgia and completeness might be worth doing at some point, but it's not a priority for me.

6

AGI Syntax Help / Re: Understanding how goto and else work

« on: May 05, 2022, 12:27:58 AM »

Hmm... isn't that just an if/else inside an if?

Sorry, my example was a bit too simple. I didn't specify that there are additional statements between the end of testA block and the destination for the goto statement. The code block should actually be

Code: [Select]

if (A)
{
  if (B)
  {
    statement1;
    goto(Label1);
  }  [endif B
  statement2;
} [ endif A
statement4;
Label1:
statement3;

Now you can see how it fails:

Code: [Select]

if (A)
{
  if (B)
  {
    statement1;
  }
  else
  {
  statement2;
} [ endif A
statement4;
  }  [endif B
statement3;
The closing curly brace for ending block A happens BEFORE the end of block B. If you tried to compile this, the compiler would think that the 'endif A' curly brace is 'endif B', and vice versa. Blocks have to be fully nested.

7

AGI Syntax Help / Re: Understanding how goto and else work

« on: May 03, 2022, 11:17:10 PM »

That particular 'goto' does not create a well formed 'else' block. If you tried to make it an 'else', the code between it and the 'end-if' would not align.

By 'well-formed', I mean a block of code that immediately follows the end of the 'if' block it's associated with, and that ends at the same block level as the original 'if' statement. An 'else' block can't 'jump' levels. A 'goto' can.

You are talking about logic 42 (rm.ShipSternInterior). Here's the fully decompiled section that contains that 'goto' statement:

Code: [Select]

[ go fishing
if ((said("go", "fish") ||
    said("go", "fishing") ||
    said("fish") ||
    said("acquire", "fish") ||
    said("catch", "fish")))
  {
  [ Jerrod has to be on the aft deck
  if (posn(ego, 40, 30, 65, 52))
    {
    [ if already fishing
    if (isset(fFishing))
      {
      print("You are already fishing.");
      goto(Done);
      }
     
    [ if sick
    if (isset(SickAtSea))
      {
      [ too weak to fish
      print("That is a wonderful idea, but you just can't muster the strength "
            "to do it!");
      }
    else
      {
      [ check for all the required pieces needed to fish
     
      [ paperclip for a hook
      if (PaperclipStatus != 1)
        {
        print("This is the place to fish, but how can you fish without "
              "something to use as a hook?");
        goto(Continue);
        }
      [ string for line
      if (StringStatus != 1)
        {
        print("This is the place to fish, but you are going to need some "
              "fishing line!");
        goto(Continue);
        }
      [ metal for weights
      if (MetalStatus != 1)
        {
        print("This is the place to fish, but you need some weight to attach to "
              "the fishing line!");
        goto(Continue);
        }
      [ ham for bait
      if (!isset(HasHam))
        {
        print("This is the place to fish, but the fish are going to want to see "
              "some bait at the end of that line!");
        goto(Continue);
        }
      [ shovel handle for pole
      if (HandleStatus != 1)
        {
        print("This is the place to fish, all you need now is something to use "
              "as a fishing pole!");
        goto(Continue);
        }
     
      [ ready to go fishing!
      print("Well you've done it!");
      print("You have found the perfect place to fish, and you have everything "
            "you need to do it!");
      [ move into position on the stern deck
      move.obj(ego, 56, 52, 1, fFishMoved);
      [ initiate fishing status
      vFishingStatus = 1;
     
      [ score 8 points
      if (!isset(ScoreFishing))
        {
        sound(s.AddToScore, fSoundDone);
        set(ScoreFishing);
        currentScore  += 8;
        }
      }
    }
  else
    {
    print("You're getting close to the ideal fishing spot, but you're not quite "
          "there!");
    }
  }
 
Continue:
.
.
.
.
Done:
[ call the main timing logic
call(lgc.CapeTripTiming);

return();


You will notice that the 'goto' statement jumps past the end of the if-block that it is inside of. So it can't be an 'else'. To reduce it to a simpler set of lines that are easier to see, this is what is happening:

Code: [Select]

if (testA)
  {
  if (testB)
    {
    statement1;
    goto(Label1);
    }  [endif testB
  statement2;
  } [ endif testA

Label1:
statement3;
If you try to make that an 'else' block, you would get this:

Code: [Select]

if (testA)
  {
  if (testB)
    {
    statement1;
    } else 
    {
******   
*  statement2;
*  } [ endif testA
******
    }  [ endif testB
statement3;
You can see how the block levels don't work. The testA block can't end inside the testB block. Blocks have to be fully nested.

For a more technical definition of 'else' vs. 'goto' in terms of actual code, you could take a look at the WinAGI source, in the 'LogDecode.bas' module.  Basically, decompiling is a two-pass process. The first time through, all jump points (labels), code blocks and their levels are determined, and stored in an array. Then the decompiler goes through the logic code a second time, identifying all commands and if tests. Using the information gathered during the first pass, labels are added as needed, and blocks are confirmed to be either 'else' or 'goto' depending on where they jump to.

WinAGI may not be authoritative, but it's pretty damn smart, and has a very good pedigree. It's based on original code from Peter Kelly's first AGI Studio. His decompiler code was pretty good, and since I did not know much about AGI at the time, I just copied what he had, porting it to VB but mostly following the same approach. I've made a few tweaks to it over the years, but the basic decompilation algorithm is pretty much the same as Peter's original.

And size doesn't matter (yeah, that's what she said...). Unless it's larger than an Integer. Then it would be a Long, and clearly, that would matter.

8

AGI Development Tools / Re: WinAGI Version 2.1.16 Available for Download

« on: April 27, 2022, 12:58:10 AM »

OK, thx.
I can tell from your video that WinAGI is able to open the WORDS.TOK file, because it shows the word and group counts in the properties window. I think there's a problem with the words editor form- maybe a control on it that is not compatible with Windows XP or a property being set incorrectly. But why it would do that in XP but not any other Windows versions, I don't know.

I might have access to a Windows XP machine. I'll try to do some testing to see if I can figure this out.

9

AGI Development Tools / Re: AGI extended character support

« on: April 26, 2022, 12:35:56 AM »

The reason your characters aren't showing correctly when printing black-on-white is because of the approach Sierra used to deal with how EGA handles character drawing when in graphics mode - it's not the same way characters are drawn in text mode.

In text mode, the character attributes allow you to independently set background and foreground colors. When a character is drawn to the screen the EGA card will replace pixels at the character location based on the glyph bitmap.

But in graphics mode, the 'background' attribute doesn't work the same. Basically, only the high bit of the 'background color' value matters. If it's clear, you get a black background, and the character draws the same as on the text screen. If that bit is set, the character is XORed onto the screen with the existing pixels. So, in a nutshell, you can't (easily) draw black characters on a white background in graphics mode. (This applies to ALL graphics modes on the EGA card, and it's a 'feature' of the EGA card, and not an MSDOS thing.)

Sierra decided to solve the problem by inverting the glyph bitmap, and then drawing it as white-on-black; since the glyph is inverted, it gets drawn as if it were a 'black-on-white' character. To invert the glyph, they copy the glyph bitmap from the standard character interrupt location. And since this is hard-coded into the AGI character drawing function, extended characters don't work.

The hack that I wrote to address this checks the value of the character, and if it's extended, it grabs the glyph from the extended character interrupt instead of the standard interrupt.

I don't know much about how MSDOS handles fonts and code pages. I think it's updating the interrupt values to point to the correct glyphs (which is why the extended characters are displaying correctly). But since AGI is hard coded to the location of the default glyphs, and not the current glyphs, it's not working for standard characters.

I think this might be an easy fix. The hack just needs to modify the location used for standard character glyphs from the default (F000:FA6E) to whatever value is actually located at INT 43h. But I'd have to do some testing.

10

AGI Development Tools / Re: ScummVM support for translating/modifying games

« on: April 18, 2022, 07:35:59 PM »

If the loader is 'sierra.com, then the default WinAGI GameID will be 'SIERRA'. If no valid loader file is found, then the default WinAGI GameID will be 'AGI'.

Not to nitpick, but if I change SQ.COM to sierra.com and import, the resulting default WinAGI GameID is AGI. At least that is what's happening with my v2.2 copy of SQ1. My copy of SQ2, which uses sierra.com also comes in as AGI.

No, go ahead and nitpick! You are absolutely right. There is a line of code in WinAGI that specifically changes the GameID to 'agi' if the file is named 'SIERRA.COM'. I got that wrong! In my (lame) defense, it's been a long time since i wrote that code, and I happened to have a few test games where I named the wag file 'SIERRA.wag'. It made me think that the GameID was also 'SIERRA'. Thx for the reminder to make sure I know what I'm talking about before I go correcting someone else's post! 

I'll edit my post accordingly.

11

AGI Development Tools / Re: WinAGI - "Invalid or Missing WinAGI file"

« on: April 18, 2022, 02:55:58 AM »

Good catch, that's a bug.

When you change the GameID, the file name of the WAG file is not changed to match. I made a decision a while back to separate the name of the WAG file from the GameID value. That way, you can give your WAG file a long filename. If the WAG file name was linked to the GameID, you'd be limited to 6 characters for your WAG filename.

But it looks like I also forgot to make sure that when you do change the GameID, the filename in the Most Recent Files list should NOT be changed anymore.

The workaround is to use the Game|Open Game menu option. Once you do that, the game will be added to the Most Recent Files list correctly.

It's easy to fix this, so I'll add it to my TODO list.  I think I'll add a dialog box asking user if they want the filename to changed to match if they do change the GameID, in case they really want that.

I wonder if I should have added a separate parameter to the Game Property form to let users change the WAG filename separately from the GameID, but I think that might take more effort than I want to spend right now. So I'll leave that for later. You can edit the name of your WAG file in Explorer if you really want to change it.

12

AGI Development Tools / Re: ScummVM support for translating/modifying games

« on: April 18, 2022, 02:39:10 AM »

• The game's GameID in WinAGI is determined by the .com file's name, or `AGI` if it's `sierra.com`

Not quite true. If a valid game loader (*.COM file) is detected when importing a game, the loader's file name is used as the default WinAGI GameID, which is usually 'KQ1', SQ1' or whatever the install batch file named the loader. If the loader is 'sierra.com, then the default WinAGI GameID will be 'SIERRA'. If no valid loader file is found, then the default WinAGI GameID will be 'AGI'.
Doomlazer pointed out correctly below that the default WinAGI GameID is 'agi' if the game loader is 'sierra.com'.

• ScummVM tries fallback detection, based on GameID's value in WinAGI

To be clear, this will only be the case if your game includes the WinAGI game properties file (*.wag) in your game's directory. If you don't include the WAG file, then SCUMMVM will (obviously) use a different method to determine what game (and version) is running.

• Note that Space Quest 1 (for example) might have 'sq.com' in some distributions, which will make its GameID in WinAGI to be 'SQ', while scummvm expects it to be 'sq1'. Just modify it in WinAGI

(emphasis added)
THIS! The WinAGI GameID property can easily be changed to whatever you want it to be. You don't have to accept whatever it gets set to when a game is imported.

The WinAGI GameID has no intrinsic value to an AGI game; it is there to help identify your game while you are editing. There is a built-in feature that let you easily use that property as an argument for the 'set'game.id' command, but that's it.

The SCUMM folks have decided to also use the WinAGI GameID  in their detection functions- while I am generally OK with that, I must say I'm mildly annoyed that their implementation seems to be a source of confusion regarding what's going on with WinAGI. I don't think it has to be this complicated. If it were me, I would have assumed any game that includes a WinAGI game file is either a fan-made game, if the WinAGI GameID is not a known Sierra gameid, or a variant of a Sierra game if it is known.

I don't normally use ScummVM when runnig/testing games. So did a small bit of testing (using v2.5.1). First, by running ScummVM directly, and then trying to Add and then Start a game.

If I modify SQ1, and leave 'sq1.wag' file in the game directory, with a WinAGI GameID value of 'sq1, and then Add the game to ScummVM, it shows a list of games to choose from, including

• Space Quest I: The Sarien Encounter ("<description>" "<version>" "<datetime>"/DOS)

where <description>, <version> and <datetime> correspond to the Description, GameVersion and LastEdit fields from the sq1.wag file. And the game runs in ScummVM.

Changing the WinAGI GameID to any other 'Sierra' gameid ('kq1', pq1', etc) also shows a similar option, and the game will run.

If I modify the WinAGI GameID value to 'TEST' (or anything other than a Sierra gameid or 'AGI'), I get the option to add

• ("<description>" "<version>" "<datetime>"/DOS)

but when trying to run the game, it fails, saying "Could not find any engine capable of running the selected game."

If I modify the WinAGI GameID value to 'AGI', then I get this option:

• Sierra AGI game ("<description>" "<version>" "<datetime>"/DOS)

and the game runs. So, using a WinAGI GameID of 'AGI' or a Sierra gameid will allow a game with a .WAG file to run in ScummVM. Using any other WinAGI GameID won't.

Next, I tried to run ScummVM from within WinAGI, by selecting ScummVM as the game platform.

The first thing I noticed is that there's a bug in how WinAGI builds the command line to add to ScummVM. It uses a hard coded value of 'agi' for the [game] parameter. I'm pretty sure I tested that when I added this feature, and I recall thinking that 'agi' as a command line [game] parameter meant to run the game using the AGI engine. Either I'm mis-remembering, or something changed in ScummVM since I added that.

The effect of this is that if the WinAGI GameID is *not* 'agi', then the game won't run when you click the 'Run' button. You'll get a message from ScummVM saying the game data files can't be found.

That was easy enough to fix. (I'll try to get a new version out shortly.) But it exposes the same issue as noted above - if the WinAGI GameID is not 'agi' or a Sierra gameid, then the game will not run in ScummVM when you click on the 'Run' button.

That kinda sucks, and I hope the fix you submitted to ScummVM will fix that.

13

AGI Development Tools / Re: WinAGI Version 2.1.16 Available for Download

« on: April 12, 2022, 11:30:22 PM »

AGKorson, I'm not sure you noticed, but that looks a lot like it's running in WinXP! Maybe that's part of the problem?

Good catch. I think that might actually be Windows running on Linux- obscurenforeign has been the primary user/tester of WinAGI on Linux.

@obscurenforeign, is that the case here?

14

AGI Development Tools / Re: WinAGI Version 2.1.16 Available for Download

« on: April 12, 2022, 10:52:06 AM »

It isn't technically crashing... though I did get it to properly crash too, I think by trying to import a words.tok file. But trying to open the editor simply isn't doing anything... but with the strange caveat that it makes WinAGI unable to close the currently open game, otherwise still seeming to function normally. In this state I can't close WinAGI either, I have to terminate it in task manager.

That is very strange. I can't seem to reproduce the problem. I have discovered that if your WORDS.TOK file is missing, and you try to open it, WinAGI offers you a chance to create a new blank file. But if you decline, there's a bug that hangs up WinAGI. But you would get a dialog box with a yes/no question in that case, which isn't what's happening with your game here.

I have a bunch of questions that might help me track down what's going on:

• Does it do this for all games, or just this one? Does it have this problem for existing games (i.e. a Sierra game that you import) or just games you create?
• If it is just this one game, can you zip everything in the game directory and share it with me? That'd be super helpful.
• It looks like you created a sample game from the template. Did you do anything else to the game after creating it?
• Did this behavior start immediately after creating the game, or did you close it, re-open it and then it started doing this?
• Can you open the template game and edit the template's WORDS.TOK file?
• Is your WORDS.TOK file actually present in the game directory?
• Does it have any file attributes set, such as hidden or read-only?
• If you close your game, and open the WORDS.TOK file individually (choose 'Resource|Open Resource|WORDS.TOK File' on main menu), does it open?
• Does the game run, in DOSBox or any other interpreter? Is the WORDS.TOK file recognized as valid by the interpreters?
• Have you tried to open your game and WORDS.TOK file in other IDEs (i.e. will it open in AGI Studio)?
• Can you try copying a WORDS.TOK file that you know is valid to your game directory, and then try opening the word editor? (Rename the old file to something like WORDSbad.TOK first.)
• As a last ditch effort, have you tried uninstalling and then re-installing WinAGI?
• To make sure I'm looking at the right code, can you confirm what version of WinAGI you are using (click Help-About to see the version.)

I'm sorry that it's not working for you right now. I'll do what I can to get it fixed.

15

AGI Syntax Help / Re: Some Logics have blank messages?

« on: April 11, 2022, 10:44:48 AM »

Yeah, the only valid comment markers are '[' and '//'

The single quote comment marker was only allowed in VB syntax (which was removed a couple years ago).  I don't recall ever supporting it for the 'normal' AGI syntax. If I did, it was by accident.

The only thing that I removed from the syntax rules was support for block comments '/*  ... */'. If you have those in your code, you will need to replace them with a comment at the start of each line. The Block Comment feature in the text editor will handle that for you easily.