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.


Messages - AGKorson

Pages: [1] 2 3 ... 6
1
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.

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

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

4
AGI Development Tools / Re: Can't load the first King's Quest with WinAGI
« on: November 14, 2019, 01:40:37 AM »
I have noticed that it crashes upon loading some Sierra games, like King's Quest 1 v2.0F int2.917 and some of the other KQ AGI games. The other AGI IDEs seem to have no problems opening them. If I have the other IDEs rebuild the VOL files WinAGI can then open them.

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

5
AGI Development Tools / Re: Can't load the first King's Quest with WinAGI
« on: November 13, 2019, 03:14:00 PM »
Hello everyone!

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

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

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

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

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

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

7
AGI Development Tools / Re: WinAGI Version 1.2.5
« on: August 15, 2019, 07:39:30 PM »
Thanks for updating the Wiki, too, though I see that the source is still is for 1.2.3.
Yeah, I didn't bother. I don't think anybody is actually interested in the source anyway. But I suppose for completeness, I'll upload it eventually.

Or you could build on top of Visual AGI for a bit of a head start. Lance's work should have filled in the logic and sound backend, so it mostly needs the sound editor and compiler.
Maybe. I haven't seen what they've done yet. I would want to make sure all the enhancements of WinAGI are included, especially the additional tools. And I'm not interested in a joint SCI/AGI tool; I think they are too different (and the user bases are also too different).  I figure I will use this exercise as a way to finally learn a modern dev language. It's a bucket list thing. So porting WinAGI as its own program is of interest to me.

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


9
AGI Development Tools / Re: WinAGI Version 1.2.3 Is Available!!!
« on: July 19, 2019, 10:46:26 PM »
I'm glad that worked for you. Now I know that Linux users at least have an option to run WinAGI.

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

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

10
AGI Development Tools / Re: WinAGI Version 1.2.3 Is Available!!!
« on: July 19, 2019, 03:59:11 PM »
First off, when you run it you'll get an error about missing MSFLXGRD.OCX.

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

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

11
AGI Development Tools / Re: WinAGI Version 1.2.3 Is Available!!!
« on: July 17, 2019, 08:33:19 PM »
I isolated the relevant console output in Wine, though it's probably incomprehensible to you anyway. (I didn't see a way to insert it into the post without making it annoying, so I'll try as an attachment.)
According to your error log, it appears the problem lies in the WINE implementation of the riched20.dll library; on an assertion in the source code:
Code: [Select]
Assertion `~para->member.para.nFlags & MEPF_REWRAPSo it's not the OCX, it's the underlying WINE implementation of the dll.

I found a discussion thread on sourceforge.net in which another app using riched20.dll has this same error in WINE. The thread suggests using a thing called 'Winetricks' as a way to use the actual Windows dll file instead of WINE's file. According to that post it solves the problem. Unfortunately, I don't have any idea how to make Winetricks work. I'm hoping you can figure that out!

I hope that helps. And I'm sorry that I don't know enough about Linux to be able to port my source so that WinAGI could run natively in it. It's a vastly superior IDE in any OS environment, but that means nothing if you can't run it.


12
AGI Development Tools / Re: WinAGI Version 1.2.3 Is Available!!!
« on: July 15, 2019, 10:33:30 PM »
Good to see this is still going! It's been a while for me.

These days I'm primarily using Linux (Ubuntu, might change in the future) and I've been trying to make as much work this way as possible. So, I decided to try getting WinAGI to work in Wine. (Well, again I guess, but more seriously this time.)

First off, when you run it you'll get an error about missing MSFLXGRD.OCX. To fix it, you'll need to install msflxgrd with winetricks. The VB6 runtime might be needed too, I had it installed prior because I thought it was the culprit.
Picture, View, and Sound editors all appear to work from a cursory look, I was able to compile and build the template game, and it ran fine in ScummVM. However,
Minor problem: the splash screen displayed black.
Much more major: trying to open the code editor crashes WinAGI. I guess something about it disagrees with Wine. Of course, trying to make an AGI game without being able to edit the logic would be rather difficult!
(I also couldn't get MIDI playback of Sounds to work, but I think there might be a way to make MIDI playback work in Wine.)

(I know, this probably isn't even worth figuring out WHY it doesn't work, let alone fixing.)
Hi!

I wish there was an easy way to port this to another platform so it could run natively. I don't know much about Wine, so I probably can't offer too much in the way of help.

But with regards to the code editor, it's most likely caused by the RichEdAGI.ocx not loading. You can check that by trying to preview logics; preview uses the same OCX, but without highlighting. If the preview also doesn't work, try manually installing the RichEdiAGI.OCX file like you did with MSFLEXGRID. If they preview OK but it still crashes, it might be that syntax highlighting is causing the problem. In that case, try turning off syntax highlighting; on the Logic Settings tab, uncheck the box for "Enable Logic Editor Syntax Highlighting". That should allow you to edit logics (but no highlighting).

I have no idea why the splash screen is all black; it might be a timing thing with regard to fully opening the main window. But you can disable the splash screen on the General Settings tab so you don't have to see it again.

Let me know if you are able to get it running!

13
AGI Development Tools / Re: No Key is Needed to Decrypt AGI.EXE
« on: March 26, 2019, 09:58:30 PM »
His program stores a copy of the entire key track from the original Sierra disks. The key track was the same on all disks; the offset was the only thing different. His program uses the offset found in the loader (SIERRA.COM) and then gets the key from the stored key data. If you don't have the loader, his program won't work.

But you don't need the loader; everything you need is in the encrypted file itself, as I described above. The tool I wrote will decrypt the AGI file whether you have the loader or not.

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

15
AGI Development Tools / Re: Save game specification
« on: March 23, 2019, 07:06:24 PM »
Hello everyone, it's been a very long time since I have played around with AGI/SCI. I used to run agigames.com many many years ago.

I am working on some tools and libraries for AGI and in the save game specification, I noticed something in the general state section that does not make much sense to me. The "Text Attribute value" which is 2 bytes "1489-1490" would be 16 bits, however it only mentions:
Quote
background color in top 4-bits, foreground in bottom 4-bits
So it only talks about 8 of the 16 bits. Is there something I am not understanding or am missing? Hopefully somebody here with more experience might be able to shed some light.

The game state section of the save file is actually a literal dump of memory; it varies from version to version, so I'd be careful about treating it as a 'format'. The size of the game state memory dump goes from 987 bytes in v2.089 to 1528 bytes in v3.002.149.

That being said, regarding the text attribute memory location, it is a 16 bit word, but only the lower 8 bits are used.

Keep in mind this value gets recalculated everytime AGI prints text on the screen, regardless of display mode. When in graphics mode, if BG is 0 (black),  FG is stored at this location. If BG is non-zero, AGI stores a value of 0x008F in this location. (The graphics routines use this value of 0x008F to display black text on a white background).

If in text mode, AGI combines the FG and BG values into a single 16 bit number, by shifting the BG left by four bits, then AND-ing it with FG.

Also note that this value is only used internally to support the graphics subroutines. While it is stored in the save file (because it's in the block of memory that gets dumped), it isn't really needed because AGI recalculates it everytime it needs it when drawing text on the screen.

Pages: [1] 2 3 ... 6

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

Page created in 0.145 seconds with 22 queries.