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

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

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


4
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 value  of those bytes three bits back to the left. 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.

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

Enjoy!

6
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, print.at.v) were actually defined with an 'f' (isset.f, print.at.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 ego.is.a.dead.mother df1 [ the end
.
.
[*****
:no.input
:no.fucking.input
:also.no.mother.fucking.input
[*****

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.

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

8
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:
    byte02:byte03
    byte00:byte01
    byte06:byte07
    byte04:byte05
    byte10:byte11
    byte08:byte09
    byte14:byte15
    byte12:byte13
    byte18:byte19
    byte16:byte17
    byte22:byte23
    byte20:byte21

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.

9
AGI Development Tools / WinAGI 1.2.2 BETA
« on: January 17, 2018, 11:59:40 AM »
I'm attaching the most recent WinAGI build. (with a proper installer file so there should not be any problems with file compatibilities)

For some reason, changes to pictures, sounds and views were not enabling the Save option. I have no idea why, because I have not touched any of the code associated with that. Regardless, this version (1.2.2) appears to correct the problem, at least for me on a Windows 10 and a Windows 7 box.

There are a lot of fixes between this version and 1.2.1 that I loaded last spring. I would greatly appreciate as much feedback as possible on this latest version. Let me know what works, what doesn't. (NOTE that I haven't released an updated Help File, so if you are looking for something in the Help File and it's not there, or you find errors in the Help File, be aware that I'm working it, and will release a new Help file with the next version)

Thx for all the help

10
AGI Development Tools / Looking for specific versions of AGI files
« on: October 09, 2017, 10:34:40 PM »
Seems awful quiet here in the AGI forum. I guess everyone had a busy summer.

I've made a ton of progress on WinAGI v1.2.2. I'm working on the help file now. To make sure it's as accurate as possible, I've been working with a decompiler on the AGI files. I've been working with primarily with version 2.917, and have it almost fully decompiled, which has led to a ton of new information and corrections regarding the AGI specs.

I've been able to check other versions I have to look for differences among versions, but unfortunately I'm missing a few versions that I would like to have in order to validate my assumptions about what's different.

Years ago, I got a zip file with most DOS versions from someone (I think from MegaTokyo days). But I found out that three of the versions included are not what they seem. The files for v2.425,2.439 and 2.903 all include a version stamp of "2.CBC" in the AGIDATA.OVL file, and have a bit of extra code at the end of the executable that's associated with a Sierra loader for Windows 98 - other than that, they're byte for byte equal to v2.936. It looks like they're from a Windows 98 compatible version of Space Quest that included both SQ1 and SQ2.

So if anyone has the 'real' versions 2.425, 2.439 and 2.903, I'd love to have them for comparison against the other versions I have. Oh, and I don't have any version 1 files; I wouldn't mind getting my hands on those too, but they're less of a need for me.

thx!

11
AGI Development Tools / WinAGI 1.2.1 BETA available for download
« on: May 18, 2017, 07:25:07 AM »
Took a bit longer than I had planned, but here is next version of WinAGI:
WinAGI 1.2.1 BETA

There are a lot of improvements since last version. Here's a short list of the more significant changes:

  • converted Interpreter Version property to string type, so no more errors when trying to open templates when using non-US country settings
  • Better validation of default settings on startup so no more 1 point fonts in editors
  • Colors can be edited in Settings, so custom palettes can be created for pictures and views
  • Graphics features make more use of API calls to manage transparencies, masking. Should improve overall performance as API calls much faster than native VB graphics methods
  • Layout Editor overhauled, significantly improved performance and features; editor is now much more resilient to changes made by user both inside and outside of the editor to rooms and exits
  • added ability to show pics on layout editor as inset to room boxes
  • a ton of picture editor improvements:
  • added ability to resize/reposition background image on picture editor
  • background feature now includes transparency option for drawn image (to see background through the drawn picture)
  • Test Mode in picture editor does not force background to hide and switch to full draw state; user can do tests on partially drawn pictures, and background image can be visible during testing
  • added mousewheel support to Picture Editor to zoom in/out
  • added export feature for picture images (export as bmp, gif, png, tif, jpg), you can export visual image, priority or both
  • new option for cursor highlighting in picture editor: small square for current coordinate; all others marked with x OR original WinAGI, with flashing cursor around selected coordinates and all others not marked
  • added new gif export feature for view loops - you can convert any loop into an animated gif
  • fixed menu editor to extract actual message strings if arguments in the menu commands are local/global defines or variable tag(e.g. m1, m2)
  • double-clicking menu editor lets you change background picture so you can see your how your menu looks against actual in-game pictures
  • compiler warnings are displayed in a separate window; double-click a warning to go directly to corresponding line in logic source
  • made improvements to argument tips feature
  • when using reserved names, they can be viewed in the global defines editor on a separate tab (can't be edited, but can be copied, search-in-logic enabled)
  • diasbled VB syntax as an advertised option. (It is still available as an undocumented feature: on settings form, use Ctrl+Shift+? to show vb option checkbox on Logics tab. In Logic editor, use Alt+S to switch a logic to/from VB syntax)

I haven't updated the Help file yet; I'll do that after I polish things up for full release. I'd love to get as much feedback as I can. If you find a problem/bug, let me know here. The more information you can give to help me reproduce any errors or bugs the better.

If you have any questions about features (old or new),  I'd love to hear those too. WinAGI has a ton of capabilities that many of you probably aren't aware of. Please post those questions in a separate thread, or PM me directly.







12
AGI Development Tools / WinAGI is Back
« on: March 12, 2017, 06:50:36 PM »
Hi all!

I'm the creator of WinAGI. After the last release in 2007, I've been completely away from the AGI scene (RL sent me in a different direction). I've recently found interest in AGI again, and more specifically WinAGI, and have dusted off the dev files to see where I left off. A number of issues that were reported in the last release (1.1.22) I believe are fixed. And I have added a few more things to an update that's pretty much ready to release.

While I was creating WinAGI, I spent a lot of time disassembling the original AGI interpreters; if y'all have questions about the interpreters, I may have already found the answer for you. And there are some things that are still in the AGI spec files that are wrong (which WinAGI [and it's help files] have right, for example, the algorithm for drawing lines in PIC resources, the definition of splatter codes, the function of reserved flag f11[it's set if a particular platform supports the noise channel - it's not 'logic0 is run for first time']). I also learned a lot about commands, and how the interpreter handles data passed to them which would be really useful for game developers to know and included that in the WinAGI Help file). I may try to upload what I've learned to the Wiki, but only if moderators are cool with it.

I am not an IT guy in my day job dev and programming have always been just a hobby for me. I knew enough to be dangerous 10-15 years ago, but I have never been able to keep up-  most of the dev world has blown by me. I can do simple java scripts, and I've played around with some of Microsoft's latest Visual Studio dev environments (I created a simple phone app that solved a collectible card puzzle game just to see if I could do it), but I'm woefully ignorant of most modern dev tools. My expertise is VBA for Office and VB6 so I tend to stick with what's familiar. With the kids grown up and out of the house now, maybe I'll have more time to learn about all these other tools, and I might even try to port WinAGI to a more modern environment.

I know there's not a lot of love for VB6 and programs created in it, but it's an incredibly resilient programming environment that has worked extremely well even as Windows has gone through many major revisions. (I'm running VB6 on Windows 10 with no issues at all, and WinAGI runs perfectly on my Windows 10 Surface Pro.)  And I also know that Windows doesn't seem to the OS of choice for a lot of AGI aficionados. So maybe a Windows based app developed in VB6 is not the most sought after AGI tool.

But I really hope that people won't discount WinAGI just because of the dev tool used to create it. If you are looking to create a full featured AGI game, I submit that there is no better tool than WinAGI; it's not just a resource editor - it has built in tools that allow you to manage creation of your game from start to finish. And it also has the best editors for ALL agi resources, IMHO.

The VB syntax that I included in WinAGI seems to have been a huge turnoff for many, and caused confusion for many more. I think for my next release, I'll hide that feature so only the original Sierra programming language is shown/discussed. (I'll leave it there as an undocumented feature for myself and anyone else who doesn't believe that VB is the spawn of the devil).

I will probably issue a new release by end of the month, but if anyone has anything in particular that they like/don't like about WinAGI, I'll entertain requests, recognizing that time constraints to make code changes are the biggest factor. And if you have any WinAGI questions, message me or post in the forums.



Pages: [1]

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

Page created in 0.113 seconds with 20 queries.