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 ... 14
1
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.



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

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

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

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


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

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

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

9
  • 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.


10
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?

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


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


13
Is anyone else having problems with the words editor crashing WinAGI? No, probably not...

Can you elaborate on this? If there's an issue with the words editor, I'd like to know so I can fix it.

14
AGI Syntax Help / Re: Max characters in a single logic file?
« on: April 11, 2022, 02:13:46 AM »
Hi klownstein, sorry to hear you had some troubles with WinAGI. There was a limit of approximately 32K characters in the logic editor at one point (I can't remember the exact version where I fixed that, but I think it was around 2.1.1). If you check the readme.txt file that is in your WinAGI program directory it should tell you if it's a version that has that limit.

With all the testing I've done, I have had a couple times where the rich text window (which is used by the logic editor) has done some weird stuff - usually it has just frozen, where it seems to ignore all input, but the text is actually being updated even though you can't see it) but that has been extremely rare- no more than once a year or so. And I've never been able to duplicate it. I feel comfortable blaming that on Windows...

I strongly encourage you to upgrade to the most recent version of WinAGI. And if you have this happen again, best suggestion I have is to save your work in progress, quit WinAGI and restart it. If that still doesn't fix it, try a reboot (OMG, I sound like a Help Desk Tech!) and then restart WinAGI.

And if you ever happen to have something happen that you're able to duplicate, please let me know so I can track down whatever might be causing it.



15
AGI Syntax Help / Re: Some Logics have blank messages?
« on: April 11, 2022, 01:44:55 AM »
Or you could look at the full decompilation of Gold Rush that I posted in this thread.

Logic 42 in GR (rm.SternShipInterior) does have messages that go up to #134. But several of them (42, 47, 48, 53, 56, 67, 73-76, 87, 96-112, 121, 132) have invalid pointers. Specifically, they have an offset value of zero.

This happens a lot in Sierra logics. It's a result of how their original compiler handles messages that are not defined when a logic was compiled.

The message section of a logic is formatted as follows (where X is offset to last byte of command data):
Code: [Select]
offset(bytes)       data
X+1         | highest index of messages in the logic
X+2, X+3    | word offset to last byte of actual text data (measured from start of message section, X+1)
X+4 - X+4+Z | message text offset table, equals highest index value times 2 (i.e. two bytes per message)
              Z = (highest message index * 2) - 1
X+Z+1 - EOR | message text, encrypted with 'Avis Durgan'

The values in the offset table are relative to the location of the offset to last byte of actual text data, i.e. X+2. What this means is to calculate the start of a message, you add the value from the offset table to X+2.

For logic 42 in GR, X = 4671, so the message section starts at 4672. The reference point for calculating offsets (and pointer to end of text data) is at 4673. The message text offset table starts at 4675 and runs through 4942 (268 bytes for 134 messages). The text data starts at 4943.

The offset values for the invalid messages listed above are all zero. Which means if you tried to use them in a logic, they would point to 4673 (X+2). This is because when Sierra's compiler (CG.EXE) creates a logic, it defaults to a value of zero for message text offsets, and only updates it if a message was assigned in source code using the #message command.

Note that if a null string was assigned, the compiler would add a zero length string (a single \x00 byte), and adjust the message table offset value accordingly. So invalid messages are not the same as null messages.

Also, the interpreter actually checks for cases where a logic tries to access a message that hasn't been defined; if the offset of a message passed in a command is zero, AGI will raise trappable error 14 (the WinAGI Help file contains a detailed description of that error code). So you can't access an undefined message. This is one of the rare instances where AGI actually validates data used in AGI commands.


While original Sierra source files do use a separate, included file for messages, it was not required. But unlike modern compilers, messages could only be referenced in commands by their number, i.e. 'm1', 'm2'; you couldn't compile messages in line (i.e. this would NOT compile in CG.EXE):
Code: [Select]
print("sample message");
The original AGI specs describe a convention for AGI source syntax that AGI Studio and WinAGI both conform to.( I also added additional features to WinAGI that aren't in AGI Studio - if interested, see the WinAGI help file or ask me for details.)

The syntax rules for original Sierra compiler can be found in the agiwiki, or in this post. They are derived from a full disassembly of CG.EXE. There are several significant differences between original Sierra syntax rules and what the AGI Specs consider 'canon'. But since the specs have been around for so long, and most non-Sierra compilers are based on the AGI Specs, there doesn't seem to be much reason to change. I am considering adding a 'CG.EXE compatible' mode to WinAGI at some point just for nostalgia, which would allow it to compile original Sierra source with no modifications. But it would only be for nostalgia, and wouldn't be of much practical use.

Pages: [1] 2 3 ... 14

SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.173 seconds with 21 queries.