Messages

1

AGI Development Tools / Re: NAGI is not working properly on Windows 10

« on: August 27, 2020, 11:48:50 AM »

SDL2.DLL is not drop-in compatible with SDL.DLL. You likely wouldn't even get an application window if you tried.

I didn't even think of that, thx for pointing it out. I've been doing some reading on SDL to see if I can use it in next version of WinAGI. Obviously I still have a lot to learn! 

2

AGI Development Tools / Re: NAGI is not working properly on Windows 10

« on: August 24, 2020, 03:16:56 PM »

The most recent version of SDL is 2.0.12. NAGI was built using an earlier version.. The SDL wiki says that there are a lot of changes from SDL1 to SDL2, specifically in the graphics area that are not backwards compatible. It could be that notebook has SDL2 on it, but your desktop has SDL1.

3

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.

4

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.

5

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.

6

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?

7

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.

8

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! 

9

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

10

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.

11

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.

12

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

13

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.

14

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.

15

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.