Messages

1

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.

2

AGI Community How To's & Tutorials / Re: AGI CAN support Extended Characters

« on: March 07, 2020, 04:55:55 PM »

It was much easier than I thought to include character 80h. It only takes a couple tweaks to have AGI use character ffh (which is nonprintable anyway) instead of character 80h to manage shading and inverting. Here's a revised logic that does that.

So ALL printable characters are now available ALL the time for ALL foreground/background/shading combos.

Enjoy.

3

AGI Community How To's & Tutorials / AGI CAN support Extended Characters

« on: March 07, 2020, 02:30:02 PM »

I've been experimenting more with the use of the StringHack to improve AGI's functionality. For those of you who wish to use extended characters in messages (for example, French or Spanish), I have written a logic that will modify how AGI displays characters so that the extended characters display correctly.

All you need to do is add the logic (see next post, below) to your game, and run it once when the game first loads. After that, all characters, including extended characters will display correctly in print() messages.

Here's some sample output to see it in action:






A couple of caveats:

• this will ONLY work with the original DOS interpreter (through DOSBOX or running on native DOS system); it won't work with NAGI, SCUMMVM or any other modern interpreter.
• this will ONLY work with AGI interpreter verison 2.917. Each version has slightly different addresses for its internal functions; this logic is hard coded to version 2.917. (If you want to use this on a different interpreter version, let me know; I can help you tweak it so it works).
• There is one character, 0x80 (which is a capital 'C' with cedilla[that's the squiggly tail]) that won't display; it will always show as a black box. This is because AGI uses that code to manage the shading and inversion of characters on menus; the code needed to fix that is too complicated (at least for now). All other extended characters display correctly.no longer a restriction; see post below

Finally, WinAGI v1.2.7 is the only dev environment that supports the use of extended characters while authoring a game. Use CTRL+INSERT to display a popup window in the logic editor to insert any extended character. You can also use "\x" codes to insert hexadecimal characters (which is what I typically do when using string hacks; it's just easier to read and manage code).

4

AGI Syntax Help / Re: DOSBox fails to find smiley faces?

« on: March 01, 2020, 08:46:54 PM »

One other thing, you should use the template games that come with the latest version of WinAGI (which it looks like you have); those older templates may not work. I got some help from Eric Oakford to update those old templates, since they had some legacy issues, and some of the syntax wasn't up to current standards.

5

AGI Syntax Help / Re: DOSBox fails to find smiley faces?

« on: March 01, 2020, 08:35:56 PM »

You need to tell WinAGI where the DosBox executable file is; you are pointing to the Sierra RUN.EXE file instead. (I am not sure what that file even does.)

In the Platform Executable box, you need to instead select your DosBox program. (Looks like in your case, it's in the same directory, named "DOSBOX.EXE" [you have file extensions hidden, so I am only guessing that's the filename.])

What that does is tell WinAGI to run that instance of DosBox when you click 'run' from within WinAGI.

The next thing you have to do is to tell DosBox what DOS program you want it to run in order for your game to work. This is the same program you would use from within DosBox at the C:> prompt; usually it's the main AGI file (AGI.EXE), but it might be a loader file. Looking at your directory listing, it appears to be AGI.EXE (but again, you have extensions hidden; if your main AGI file is named "AGI" with no extension, you should rename it to "AGI.EXE" first [and I'm assuming it's not an encrypted version; if it is, then you have even more things to do to get it to work!])

In the DOS Executable box, you will type "AGI.EXE".

What all this means is that WinAGI will use Windows to start DosBox (by running the program you identify in the "Platform Executable" box, and then DosBox will run the program "AGI.EXE" (or whatever the file is that you named in the "DOS Executable" box).

Try that, and then if you still get errors, let us know and we'll try to walk you through the problem.

6

AGI Development Tools / Re: Can't load the first King's Quest with WinAGI

« on: November 20, 2019, 03:16:17 AM »

Version 1.2.7 is now available; it will load KQ1 (and any other games that have invalid DIR entries) by just skipping those invalid entries.

It's available on the Wiki: http://agiwiki.sierrahelp.com/index.php?title=File:WinAGI_1_2_7.zip

Thx for your patience while I addressed this.

7

AGI Development Tools / Re: No Key is Needed to Decrypt AGI.EXE

« on: November 17, 2019, 03:12:26 AM »

I stumbled across this again and was wondering if you still have the source for this tool. I would be curious to take a look at it.

Sure thing. Here it is:

It's a VB6 project, but only uses one form, and has no complex objects or controls. Should be pretty straightforward to understand.

Let me know if you have any questions.

8

AGI Development Tools / Re: Can't load the first King's Quest with WinAGI

« on: November 14, 2019, 01:52:24 AM »

Hello everyone!

When I try to load the first King's Quest (1984) with WinAGI (1.2.6), I got this error and the software fails to load the content:
"Unhandled error (-2147220852: Unhandled error in LoadSound method(-2147220999: Invalid resource location (134703) in VOL.2)) encountered while loading resources."

Is the problem known? Or maybe my version of King's Quest is corrupted?

Are you saying only that one resource, with the bad pointer won't load? Or is the entire game not loading?  Because WinAGI should load the game and all valid resources, even if it encounters one or more with invalid data.

I only recently became aware that some Sierra games would leave behind invalid DIR file entries that would point to non-existent, unused resources. Since I never encountered it before, WinAGI originally would always try to validate all resources when initially loading, and give up if it detected something like a bad DIR file or VOL file. So I added extra error trapping that now allows the game to continue to load while just ignoring any invalid resources.

But if it's not loading anything, that's a problem I will need to address.

OK, I confirmed that the original KQ1 does indeed have four invalid DIR file entries - there are four sound resource entries in SNDDIR (for sounds 34, 35, 36, 37) that point to invalid locations in VOL.2. Presumably they existed at one time, but were removed before the game was released, without updating the DIR file.

I thought I had a check in the resource loader to catch this, but it is not working as I thought. Good news is that it's an easy fix, so if you can hang on for a few days, I will upload a new release that fixes this.

Sorry for the glitch!

9

AGI Development Tools / Re: Can't load the first King's Quest with WinAGI

« on: November 14, 2019, 01:40:37 AM »

I have noticed that it crashes upon loading some Sierra games, like King's Quest 1 v2.0F int2.917 and some of the other KQ AGI games. The other AGI IDEs seem to have no problems opening them. If I have the other IDEs rebuild the VOL files WinAGI can then open them.

crashes? or just fails to load the game? I've never had WinAGI crash during loading- just fail to load a game or resource. If it's actually crashing, I'd like to have more details so I can track down the issue.

10

AGI Development Tools / Re: Can't load the first King's Quest with WinAGI

« on: November 13, 2019, 03:14:00 PM »

Hello everyone!

When I try to load the first King's Quest (1984) with WinAGI (1.2.6), I got this error and the software fails to load the content:
"Unhandled error (-2147220852: Unhandled error in LoadSound method(-2147220999: Invalid resource location (134703) in VOL.2)) encountered while loading resources."

Is the problem known? Or maybe my version of King's Quest is corrupted?

Are you saying only that one resource, with the bad pointer won't load? Or is the entire game not loading?  Because WinAGI should load the game and all valid resources, even if it encounters one or more with invalid data.

I only recently became aware that some Sierra games would leave behind invalid DIR file entries that would point to non-existent, unused resources. Since I never encountered it before, WinAGI originally would always try to validate all resources when initially loading, and give up if it detected something like a bad DIR file or VOL file. So I added extra error trapping that now allows the game to continue to load while just ignoring any invalid resources.

But if it's not loading anything, that's a problem I will need to address.

11

AGI Development Tools / String Hack

« on: August 15, 2019, 07:47:21 PM »

Sierra was notorious for not including error checks and buffer overflow checks in AGI. Even simple mistakes in source code can result in situations that cause unexpected results and crashing AGI.

But this can actually be used to your advantage to do some really cool advanced coding to 'hack' the interpreter on the fly from within your AGI game.

The key lies in the set.string(str sA, msg mB) command. It's no surprise that AGI does not validate the string number A; it will write the value of mB wherever sA points to. This means that using values larger than 23 will let you overwrite program memory. Of course, this usually crashes AGI, but if you know what's in those areas past the string table and you are careful, you can modify the underlying code to make the interpreter do what you want.

One area that is easy to manipulate is the command function offset table; it is located in memory around the spot where strings '26' through '43' would be. Each command function table entry consists of a two byte offset followed by a byte that tells how many arguments, and another byte with a bit field to tell what kind of argument (number or variable). The only value that AGI uses is the offset; the argument info is not used so you don't need to worry about overwriting those two bytes. By writing a string value that replaces just the two bytes of the offset of the command you want to hijack, you can easily redirect those commands to anywhere in program memory.

To take advantage of this, you can use the set.string command to add bytes anywhere in memory to create a new function, then change the offset in the command table.

I've attached a logic file that you can add to a test game to see this work first hand. A couple of important things to keep in mind:

• the code will only compile in WinAGI 1.2.5 or later; other compilers cannot handle creating logics that have messages with special characters (less than 0x20 or greater than 0x7F)
• this will ONLY work on the original DOS interpeter; if you try to run this in NAGI, SCUMMVM or any other non-Sierra interpreter it will not work
• the code is VERY MUCH version specific; do not try to run this with any interpreter other than v2.917. Each version has slightly different address values for internal functions and data storage
• the set.string command has two quirks to it that you need to be aware of; first of all, you can't write a string longer than 40 characters; if you try, AGI will truncate the string at 39 characters and add a single null character (0x00) to the end; secondly, if the string is less than 40 characters, AGI adds TWO null characters to the end; this makes it a bit trickier to create custom functions (the sample code shows an easy workaround to both of these limitations)
• all string copying gets terminated when a null character (0x00) is found; to create custom functions that have zeros in it, you need to use a series of strings that work backwards, which lets you then control where the null characters show up (the sample code demonstrates this)

If you want to see this in action, create a sample game, setting it's version to 2.917. Find a copy of Sierra's AGI files from that version to run your game in a DOSBox setting. Then import the StringHack.lgc logic into your game, and call it from logic 0 just before calling the game setup logic.

The demo does four things:

• it replaces the init.disk command with a function that prints the value of string s9
• it replaces the set.string command with a modified version that is not limited to 40 characters, and also does not add extra null characters
• it modifies the message displayed when you quit the game
• it modifies the set.game.id command so you can set your game ID without causing AGI to quit (save a game to see it in action)

There really is no limit to what you could do with this hack. The set.string command only lets you modify code following the string table, but you could easily create a bootstrap function there that then lets you modify code anywhere in program memory. You could then completely modify AGI on the fly. Two examples I can think of that this could be useful for would be the AGIMOUSE and the AGIPAL hacks; a single logic, run once at game load up could include all the code needed without needing a special interpeter!

If you have questions about the details on how this works, let me know, I'd be happy to explain the whole thing in more depth. And if you create any hacks that you think others might be interested, it'd be nice to share your code so others can use it too.

Happy hacking!

12

AGI Development Tools / Re: WinAGI Version 1.2.5

« on: August 15, 2019, 07:39:30 PM »

Thanks for updating the Wiki, too, though I see that the source is still is for 1.2.3.

Yeah, I didn't bother. I don't think anybody is actually interested in the source anyway. But I suppose for completeness, I'll upload it eventually.

Or you could build on top of Visual AGI for a bit of a head start. Lance's work should have filled in the logic and sound backend, so it mostly needs the sound editor and compiler.

Maybe. I haven't seen what they've done yet. I would want to make sure all the enhancements of WinAGI are included, especially the additional tools. And I'm not interested in a joint SCI/AGI tool; I think they are too different (and the user bases are also too different).  I figure I will use this exercise as a way to finally learn a modern dev language. It's a bucket list thing. So porting WinAGI as its own program is of interest to me.

13

AGI Development Tools / WinAGI Version 1.2.5

« on: August 14, 2019, 12:29:55 AM »

I got a request to add some shortcut keys to the view editor in version 1.2.3. I also wanted to include some additional support for non-standard characters in message text, so I added an option to insert characters by using 'slash codes'. For example, "\x01" will insert character 0x01, "\x1A" will insert character 0x1A, and so on. There are also a couple more minor bug fixes.

You can find the install file on the AGI Wiki page for WinAGI.

And for those who are hoping for a Linux version of WinAGI, I have decided to begin work on re-writing WinAGI in C#. It is going to take me a lot of time, as I am looking at a pretty steep learning curve. I'm not making any promises on a completion date, but I'll try to provide occasional updates.

14

AGI Development Tools / Re: WinAGI Version 1.2.3 Is Available!!!

« on: July 19, 2019, 10:46:26 PM »

I'm glad that worked for you. Now I know that Linux users at least have an option to run WinAGI.

Regarding MSFLXGRD.OCX, no it's not included in Windows (at least in Windows 10; I'm not 100% sure about earlier versions). But since I have VB6 loaded on all my machines, it was always there. At work we recently upgraded to Windows 10; when I installed WinAGI to test it, that's when I figured out what happened.

Now that you have WinAGI up and running, I'd love to hear any feedback you might have. I'm currently working on a minor update, fixing a few more bugs that I've found. So if you find anything that needs fixing, or anything you'd like added that's not too much work, I can work that in to the next release.

15

AGI Development Tools / Re: WinAGI Version 1.2.3 Is Available!!!

« on: July 19, 2019, 03:59:11 PM »

First off, when you run it you'll get an error about missing MSFLXGRD.OCX.

I figured out what happened with this missing OCX. My install package doesn't include it. But it does include a different grid control OCX that is actually not needed. I don't know how I missed that- it appears to be the case for the last several versions I've released. I never noticed it before because the correct file is already present on all systems that I've ever tested the app on. I wonder how many other people have had this error? Ugh.

I'm going to update the installer for v1.2.3 that's on the Wiki, and the next release will also have the correct file.