Messages

1

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.

2

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.

3

AGI Development Tools / Re: WinAGI Version 1.2.5

« on: May 13, 2020, 01:28:04 AM »

Definitely very strange. All other file operations use lowercase file extensions, so maybe that is the problem. I could try using "words.tok" (lower case) as the filename.

I can build a small test app that tries opening/closing a file with different versions of the file name and extension (upper, lower, title) - if you could run that, it would least confirm or reject the hypothesis that it's related to file extension case. Let me know if you're interested in testing.

4

AGI Development Tools / Re: WinAGI Version 1.2.5

« on: May 11, 2020, 01:24:08 PM »

OK, that message is the WinAGI generated error message. That confirms what I thought was happening; something is maintaining an open file handle to WORDS.TOK, preventing it from being deleted.

I went through all the code again, line by line; there is just no place in WinAGI where that file is opened for longer than three lines of code; it gets opened, data copied to memory, then closed before anything else happens. It's the same process used for all files, including VOL files, DIR files, and OBJECT, also individual resource files. I can't explain why it would behave differently for WORDS.TOK. I also feel confident that the only direct references to "WORD.TOK" are all upper case; there's nowhere in code where it's referred to by lower case letters. I will continue to look to see if I'm missing something - there is a lot of code to look through.

Are you seeing any problems with updating/modifying any other game files? Can you make changes to OBJECT? What about a full recompile? Does that rewrite all the game files correctly?

5

AGI Development Tools / Re: WinAGI Version 1.2.5

« on: May 10, 2020, 01:21:55 PM »

That's certainly odd. To be clear, the error you got was "WORDS.TOK compile error(55: File already open)"? if it was formatted differently then it's not coming from WinAGI.

The compile (save) function for WORDS.TOK is not complicated; it creates a temporary file, adds the content, then replaces the existing WORDS.TOK file with the newly created temporary file.

If the existing WORDS.TOK file has an open handle, then the OS can't delete it in order to copy over the new file. That seems to be what you are experiencing. But WinAGI doesn't hold the WORDS.TOK file open - when the file is loaded for any reason (editing, previewing, etc) it opens the file, extracts the data to memory, then immediately closes the file.

So I don't know why the file has an open handle. If you are doing something else with it (maybe it's selected in a file explorer?) that may be holding it open. Is there anything else you were doing with any of the game files when this happened?

I'm pretty sure it's not being held open within WinAGI. There is literally only one place where a file handle is opened for WORDS.TOK - in the Load function - and it only opens it long enough to copy the file data into memory. Also, even if there was an error on opening, the error handler makes sure the file is closed and the handle released.

Oh, and regarding the .agw format, don't bother- it's basically a text dump of the words. Fifteen years ago, when I first made this program, I had this idea of creating an updated AGI interpreter, that would support improved graphics, sound, mouse support, etc. I've long since given up on that idea. The alternate formats for words and inventory objects were one of the first things I played around with. I left them in, but they really don't have any useful purpose, other than providing a human-readable version of words and objects.

6

AGI Development Tools / Re: AGI2HD Picture Redrawing Script Creator

« on: April 22, 2020, 03:17:54 PM »

Oops! Good catch!

I've probably read that a million times and never noticed it. Goes to show that the best proof reader is someone OTHER THAN the author! 

7

AGI Development Tools / Re: AGI2HD Picture Redrawing Script Creator

« on: April 22, 2020, 12:32:30 PM »

@MusicallyInspired,

That looks like an interesting idea. There are certainly a lot of challenges.  I noticed in your rendering, you can see where in some cases they like to use lines as a way to 'fill' smaller areas (like the blue console on the right for example); that'll be a tough one to figure out.

The image has a really cool 'concept art' feel to it though. I like it!

Regarding the Help file entry for Relative Lines - sorry for not making that clearer; I should have been more specific about the individual bits and exactly what they mean. I will include that in the next version of the Help file.

If you come across anything else in the file that is not clear, please ask. If not me, you can always count on the other AGI 'regulars' to help clarify anything that I didn't explain well in the Help file.

cheers!
Andrew

8

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.

9

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.

10

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

11

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.

12

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.

13

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.

14

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.

15

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!