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.

Topics - AGKorson

Pages: [1] 2
AGI Development Tools / Mouse move target question
« on: September 29, 2021, 02:44:21 PM »
This is really a more generic question, but I'll ask here because it relates to a current AGI project.

When a mouse is used to move ego, you click a spot on the screen, and ego moves to that spot. However, since ego has a non-zero width, what is the best way to position ego horizontally (in the X plane)? I can think of three options:

  • Easiest option is to just set ego's position to the targetX, regardless of where target is. But this means if you click to the RIGHT of ego, ego's left edge will move to the clicked location. This feels weird though - I expect ego's right edge to go where I click in that case.
  • Another option is to set ego's position to the targetX if clicking to LEFT of ego, but set it to targetX-width if clicking to RIGHT. If clicking in between left /right edges, ego's center is moved to target location. This feels a lot better to me than option 1.
  • A third option, similar to second, but instead of moving the center of ego to the targetX when clicking in between left/right edges of ego, just move ego vertically (ignore targetX in that case).

Any opinions on which option is best? I am leaning toward option 2, but I wonder if option 3 feels more natural to a player. Any other suggestions on positioning ego in the X-plane?

AGI Development Tools / WinAGI Version 2.1.10
« on: March 06, 2021, 02:29:37 AM »
The console mode that I added in version 2.1.6 was a bit of a hack, and I just couldn't leave it that way. So here's an update that includes a separate executable, conWAGI.exe for running a windowless console mode. It's a much cleaner implementation and it supports importing games (creating WinAGI game files from an existing AGI game) and all three compile options. (The main app also includes a couple minor bug fixes.)

You can get the latest version from the AGI wiki. Here's a direct link to the install file:

I am still working on a C# version of WinAGI. I got the all the basic AGI library functions moved over, and have a working app that can display all resources. There are no resource editors or tools added yet, and it's not real stable; there are a ton of bugs, and it's easy to crash right now.

If anyone is interested, I guess I could share a link to the git files. Just don't make fun of my poor C# coding skills...

AGI Development Tools / WinAGI Version 2.1.6
« on: February 14, 2021, 11:31:06 AM »
OK, here's an update that addresses a couple bugs found in 2.1.5 and also adds a couple requested features.

Link to install file

- Fixed bug in settings functions that would not save MsgByNumber value
- Added menu item and toolbar button to show character map dialog on logic and text editors
- Modified error messages when read-only files are encountered so it is more clear to user
- Added command line switches to compile games without running the user interface
- Modified the GameID property to allow lower case letters

AGI Development Tools / WinAGI Version 2.1.5
« on: February 09, 2021, 10:12:13 PM »
This version adds an option to decompile logics with message argument tokens (m1, m2, etc.) instead of literal strings. Also addresses two minor bugs found by pierrelapin (when opening words.tok files with no group zero words and views with bad description pointers).

Link is here:

AGI Development Tools / WinAGI Version 2.1.4 Is Available
« on: December 02, 2020, 02:48:20 AM »
Here it is - the latest update to WinAGI. This version fixes a TON of bugs, a lot of enhancements, and some new features that I've heard folks asking about. I spent a lot of time testing, re-testing and testing again, so hopefully there aren't too many bugs left! :)

Link to the install file is here:

Here's a partial list of the new features:
  • Fixes bug in v 2.1.3 Picture Editor that disabled absolute line draws
  • Support for Apple IIgs sounds- both types of IIgs sounds (PCM sound samples and embedded MIDI) can now be previewed and exported as their native format (.wav and .mid).
  • A new LISTBOX option to display game resources (similar to the old AGI Studio look)- a number of people commented that they didn't like the tree list; now you can choose whichever display works best for you
  • NAVIGATION BUTTONS - when browsing through in game resources, there are now navigation buttons that let you quickly go back to previously previewed resources, and then forward again
  • improved support for multiple monitors; the program's position/size will now be correctly restored on systems with more than one monitor
  • the logic editor now highlights AGI commands as keywords, for improved readability
  • support for code snippets - shortcuts you can use to insert frequently used blocks of code to make coding go faster
  • ability to open resources for editing from within the logic editor; right-click on any resource ID to show the open command in the context menu
  • global defines (aka the 'defines.txt' included file) can now have individual comments for each define entry
  • option to export picture resources as an animated gif to see the picture drawn step by step
  • layout editor is synched to the resource list, making it easy to find a room on the layout editor when your layout is large and complex
  • DIR files now expand or contract based on number of resources, instead of being automatically expanded to full size; this helps keep memory usage to a minimum, since DIR files are part of the room.0 memory block
  • Much improved Help file, especially in the AGI Reference section; more in-depth analysis of the disassembled interpreter has resulted in a lot more knowledge of how the interpreter really works; the help file is now the real definitive source of information on AGI
  • a lot of other minor enhancements/improvements too numerous to mention

I was also able to do some testing with Linux. WinAGI actually runs virtually bug-free when run in the WINE environment. It does require a configuration fix in WineTricks (due to a bug in WINE's implementation of riched.dll), but once that's done, it runs just fine. So Linux users have access to WinAGI too.

Things seem to have really quieted down around here, especially in the AGI forums. I fear that the golden age of fan games may be at an end. I'm hoping that tools like WinAGI will help people who might be interested in creating their own games, but didn't know where to start.

So if there is anybody out there who still has interest in AGI, please take a look at this latest release. I think you'll be pleased with how much it helps in creating your next AGI masterpiece.

I have a new version of WinAGI mostly ready for release. But I would like some fresh eyes on it before I call it good.

Here's a list of the biggest changes/upgrades:
  • LISTBOX option to display resources (in addition to the original treelist option)
  • DIR files expand/contract as resources are added/removed (instead of staying expanded to full size)
  • application size/position saved correctly on systems with more than one monitor
  • NAVIGATION BUTTONS to allow user to step backward and forward through selected resources in the resource list; right-click/hold to scroll through the list
  • all agi commands are now highlighted as 'keyword' type in logics when using syntax highlighting
  • MANY fixes to the rich text box used in logic editor, so it does a better job of handling selections/edits/highlights
  • right-click on a resource ID in a source file, and you now have the option to open it from within the logic editor
  • SNIPPETS! you can use shortcut codes to insert 'snippets' (code fragments) of frequently used code
  • you can right-click on a word in a 'said' command to show a list of all synonyms of the selected word
  • transparency color of a cel is now shown on palette on view editor (ctrl+click to change transparency color)
  • added comment column to the global editor so you can add comments to each defined term
  • searching for vocab words in logics now has option to include search for all synonyms
  • added setting that syncs the resource list to the layout editor; selecting a resource in the list will automatically scroll the layout view so the selected room is centered in the window
  • hold down shift key with left mouse to drag the entire layout drawing surface
  • Find/Replace supports multi-line values
  • ... plus a TON of other minor enhancements, and countless bug fixes

I would like to have the new version ready for release in the next two weeks. So if you are interested in helping with one last good look to make sure there are no glaring issues, please PM me, and I'll send you a link to the install file.

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.

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

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

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.

AGI Development Tools / No Key is Needed to Decrypt AGI.EXE
« on: March 26, 2019, 06:34:27 PM »
I was poking around the AGI Wiki, and came across an entry talking about different tools used to decrypt the AGI file in Sierra games. And I'm surprised to see that there a pervasive, mistaken belief that in order to decrypt the file you need a copy of the key from the notorious hidden track of original Sierra disks (either from an original disk, or made available from some other source).

That is NOT TRUE.

The key is already in the encrypted file. The MSDOS executable for AGI includes a large chunk of bytes near the beginning that are all zeros, specifically including from bytes 257 to 384. Since the encryption is a simple XOR function, the corresponding bytes in the encrypted file are exactly the entire key for the third iteration of decryption. To determine the original key, just rotate the the value of those bytes to the left twice. You don't need anything other than the encrypted file.

I created a small app that did this years ago. I think I shared it on MegaTokyo, but of course that's long since gone. The app is still available though, and is also bundled with the latest version of WinAGI. It will quickly and easily decrypt any AGI file without needing any original disk or key string.

AGI Development Tools / WinAGI Version 1.2.3 Is Available!!!
« on: March 14, 2019, 12:37:09 AM »
After a long, long hiatus, an updated version of WinAGI is finally available. This release adds a ton of new features and improvements, as well as fixing a lot of bugs.

You can download the install file from the AGI Wiki WinAGI Page.

It includes AGI version 2 and version 3 templates (THANK YOU to Eric Oakford for your help!) that were written in WinAGI. I encourage everyone to check it out, as the enhancements to the various resource editors, and other tools (such as the Layout Editor and the built-in support for ScummVM, DosBOX and/or NAGI to allow for easy testing of games during development, to name just two) make this the best AGI game development tool ever produced. I would be happy to answer any questions regarding capabilities and usage of WinAGI.

I hope that you find this to be a useful tool, and that it encourages the creation of more fan based AGI games.


AGI Development Tools / Musings on Original AGI Game Source Code
« on: January 13, 2019, 04:57:24 PM »
I spent a lot of time going through the samples of game source code that Omer provided in this post.

Here are a few random things I gleaned from those files:

-  Their coding style and even syntax varied quite a bit from game to game; Al Lowe appears to have preferred camelCase, and also had his own set of preferred names for some of the commands. Other programmers used the dot.separator style. All of the examples were consistent in using ALL_UPPER_CASE for defined numerical constants

-  Command names used in source code were defined on a game by game basis; apparently the compiler did not use text values for game code- the preprocessor is where command names got converted to numbers.

-  In one game, 'variable' commands (for example isset.v, were actually defined with an 'f' (isset.f, I wonder why they used an 'f'?

-  increment and decrement functions used 'pre-assignment' syntax (++v1, --v1) not 'post-assignment syntax (v1++, v1--). Since you can't write complex statements in AGI script it doesn't really matter. (WinAGI handles either syntax.)

-  All of the examples were consistent in the naming conventions for resources; prefix of 'r' for logics representing a location, 'lgc' other logics, 'm' for sounds designated as music, 's' for sound effects, 'v' for views.

-  logics not associated with a location (not a room) were consistently referred to as 'dynamic'.

-  The file extension for logic source files was 'CG'. I tried to think what that might refer to, but I can't think of anything. Anybody have a guess as to why 'CG'?

-  All the examples had comments that identified variable and flag numbers 0-29 as 'use by compiler only', 220-239 as 'local variables and flags', used by rooms, and 240-255 as 'dynamic', used by 'dynamic logics'. Most of them had a check so that whenever the new room flag was set, these variables and flags would be reset.

-  Local and dynamic flags and variables were given relative number values. For example, a variable might be defined as '#define thisVar lv0'. They included a header file that would convert 'lv0' to 'v220'. It worked, but that seems like a bit overcomplicated; why not just define it as v220?

-  They all say that numbers 0-29 are for use by compiler only, but we know that not all of them were actually in use. Looks like they wanted to make sure they had room to grow (but then never did, eventually switching to SCI.)

-  Although the style varied, the names for reserved flags and variables was consistent. (I have updated WinAGI to use the values listed here as default names instead of the fan-created names that have been around forever.)

-  In addition to allowing testing of flags by using just the flag ('if(f10)' is compiled as 'if(isset(f10))'), their compiler would also allow testing of variables ('if(v10)' would compile as 'if(greatern(v10,0)'). I'm looking at adding support for that syntax to WinAGI.

-  None of their logics include a return() command at the end. Apparently the compiler would add that automatically. I prefer enforcing it to make sure the programmer really meant the logic was done.

-  Their room logics were all very well structured; the initialization section at the top, a section for handling input, a section for non-input things, and then checking for room exits at the end. I'm going to try and redo the template game to match this structure

-  In their source code, words in the said() command were not enclosed in quotes, and dollar signs ($) were used as spaces. So 'said( dirty$word, rol)' instead of 'said( "dirty word", "rol")'

-  Based on their coding and comments, only Tandy computers used volume controls. I didn't know that; I assumed all non-PC systems could adjust volume. And they used the names 'crescendo' and 'decrescendo' for their volume controllers - I wouldn't have figured their programmers to be so 'sophisticated'.

-  In their game defines file, they all had a name of 'error' defined as a value of '-1'. This suggests their compiler could handle negative numbers.  There's not much use for negative numbers(the reposition() command is the only command that used them), but apparently they could use them if they wanted to? BTW, WinAGI will allow use of negative numbers (converting them to the appropriate 2s complement value) to make working with the reposition command easier.

-  In their list of constants for machine type, all the examples include 'CORTLAND', assigned a value of 8, but with a question mark as a comment. In AGI Specs, the value of 8 is identified as 'Apple IIgs'. The Cortland is a variety of apple, derived from the McIntosh. So I wonder if 'CORTLAND' was a pre-release codename for the Apple IIgs (or even some other computer from Apple). I find that interesting from a historical perspective.

Here are a few comments I found in the examples that I found entertaining. It must have been fun working at Sierra back in those days.

In Black Cauldron:
Code: [Select]
%define df1 [ the end

In KQ3:
Code: [Select]
current.status = sleeping; [ nightie, night sweet ego
if (ego.location == 9) [ do the "get out of bed" schtick
if (!edge.ego.hit && ego.y < 20) [ sweep up after Jeff's bugs
load.logics( lgc.PO'd.wiz); [ Bring on that little wizzer!

In PQ:
Code: [Select]
if ((said( show, belt) || said( show, gun))) [ Funny, you don't look Oriental!
Oh, in KQ3, the phrase to enter debug mode was originally 'rat shit', not 'rats ass'. Although due to synomyms 'rats ass' works, the source code clearly shows 'rat shit' is what was intended.

AGI Development Tools / Need Testers for WinAGI
« on: December 19, 2018, 04:17:54 PM »
I finally have a version ready. But I don't want to do a general release until I get a chance to have it tested by a few other people to work out any last minute fixes.

I would like to get four people who are willing to do an indepth review/test of the program. As a thank you, I am offering $10 (via paypal) to the first four people who agree to help. (I'd love to offer more, but I'm not that rich!  :D ) As a bonus, I'll offer an extra $10 to whichever tester provides the best and most helpful feedback.

If you are interested, send a PM, and I'll provide a link to download the installer.

My goal is to release a public version before end of the year, so if you do want to help, I'd appreciate if you could get comments back to me as soon as possible.

Thanks in advance!

AGI Community How To's & Tutorials / Fonts in MSDOS AGI
« on: October 02, 2018, 11:11:55 PM »
I'm trying to finish up the help file and iron out the last few bugs (that I know of; I'm sure there are plenty that others will find) in WinAGI v1.2.3. In the meantime, I saw a few posts talking about fonts, so I thought I would share some of what I've learned about how AGI handles fonts. These notes are for MSDOS versions; I have not spent any time studying other platforms.

Where do font glyphs come from?
The 'glyphs' are the actual bitmap representation of each character as it is displayed on the screen. On MSDOS systems using EGA monitors, AGI uses the MSDOS built in fonts, available using standard MSDOS interrupts.

The original font set developed for MSDOS was the 7 bit ASCII standard. Since characters were stored as eight bit numbers, it didn't take long for people to develop an extra set of 128 characters (known as 'extended characters').

The full set of characters (including extended characters) included in MSDOS was known as IBM Code Page 437.  It included letters with diacritics so other languages such as Spanish and French could be represented. There were also a set of characters added that could be used to draw simple boxes and shapes. (Code Page 437 is no longer the standard for extended characters; unicode values for 80h-FFh are not the same. This is why most text editors will show nonsensical characters if you try to display native 8 bit MSDOS text.)

MSDOS stored the character glyph data in two places; for the original 7-bit ASCII characters, glyph data are stored at location F000h:FA6Eh (INT 43h). The extended character glyph data are stored at INT 1Fh.

On the Hercules Graphics Card (HGC) things were significantly different. The HGC only had one text mode (720 x 350 pixels) and one graphics mode (720 x 348 pixels). For technical reasons, in graphics mode, number of rows had to be a multiple of 4. AGI did not use the text mode, because that mode used an 80 x 25 character format to be compatible with the Monocrhome Display Adapter; AGI needed a 40 x 25 text display. So Sierra used the HGC's graphics mode, and wrote custom code to handle display of text.

Since they were not using built-in glyphs, Sierra created a set of custom font glyphs in a file called HGC_FONT, but it only included glyphs for the 7 bit ASCII characters; no extended characters. The format of the HGC_FONT file matches the native format that HGC would use to draw pixels on screen, which was an interleaving format where rows of pixels were not written sequentially. Each glyph used 24 bytes (twelve rows of two bytes, for a 16 wide by 12 high bitmap; interesting choice since each line of text on the HGC display uses 14 pixels). To extract the glyph bitmaps, arrange each character's 24 bytes in this format:

If you do the math, you will see that at 14 pixels high, 25 rows will result in 350 total pixels of height. But as mentioned above, in the graphics mode HGC only displays 348 pixels; Sierra addressed this by clipping the top and bottom rows of text by one pixel. It is almost impossible to detect when visually inspecting the screen output.

How does the character get drawn to the screen?
On HGC screens, AGI included custom built routines in the HGC_GRAF.OVL file that would extract the correct glyph from the HGC_FONT file and draw it directly on the display. If an extended character was encountered, it was just ignored. This means that on an HGC system, it is impossible to display any extended characters.

On EGA screens, Sierra took advantage of the MSDOS built in glyphs. But they didn't keep it simple.

On the text screen (using the text.screen() command) Sierra stuck to using MSDOS interrupts to handle cursor positioning and drawing glyphs; this means that on the text screen, all characters, including the extended characters will draw correctly, regardless of colors chosen for foreground and background. As an example, in Goldrush, extended characters are used to simulated pages in a book when the bible verses are displayed.

On the graphics screen, Sierra decided to complicate things. For one thing, regardless of color values passed with the set.text.attribute (FG, BG) command, background would only be black (if BG == 0) or white (if BG != 0). When the background was white, foreground color would always displayed as black, regardless of the value of FG. If background was black, the displayed foreground color would match the FG value.

In the code that handles character input to the screen, if the background color is black, then AGI uses the standard interrupts to display the character, so all characters including extended characters display correctly. But if the background is not black, AGI does something weird - it copies the character glyph from the MSDOS interrupt for 7 bit ASCII characters (INT 43h), inverts it (creating a black-on-white character, instead of white-on-black) and stores it in a separate location. AGI then reassigns INT 43h so that it will find this new location when the character drawing interrupt (INT 10h AH=09) is called. So if an extended character is encountered, AGI copies glyph data from the place where only the 7 bit characters are stored, reading data that belongs to other functions in MSDOS. This explains why glyphs for extended characters appear garbled when displayed on a non-black background on the graphics screen.

So, why did Sierra do this? It appears to be related to the methods they use to force black-on-white on the graphics screen. I can't figure out why they felt the need to limit color choices though.

Is it possible to get any other color combinations on the graphics screen?
Yes. AGI is notorious for failing to validate the values of arguments used in various commands. Due to a bug in how colors are handled, you can actually get AGI to display black text on non-white backgrounds by passing a FG value is greater than 127 to the set.text.attribute (FG, BG) command. BG must be zero. When you do this, the upper four bits of FG overflow into BG when the character is drawn, resulting in black text on colored background. Extended characters are still garbled in this scenario.

What about character byte values less than 32?
It is not well known, but if you include character values less than 32 in AGI messages, AGI will display the original MSDOS glyphs for these characters. AGI actually does this in order to get the arrow to show up in the save/restore game windows when you are selecting a slot. The only exceptions to this are characters 8,9,10 and 13; AGI moves the cursor as appropriate for these characters.

Pages: [1] 2

SMF 2.0.14 | SMF © 2017, Simple Machines
Simple Audio Video Embedder

Page created in 0.155 seconds with 19 queries.