Recent Posts

1

AGI Development Tools / Re: String Hack

« Last post by OmerMor on Yesterday at 05:04:20 PM »

That's really cool! Nice work!

2

AGI Development Tools / Re: String Hack

« Last post by Collector on August 15, 2019, 08:50:09 PM »

Might be nice to add to the Wiki, too.

3

AGI Development Tools / Re: WinAGI Version 1.2.5

« Last post by Collector on August 15, 2019, 08:48:49 PM »

I'll email Lance and see if he'll give you access to his branch since it probably has a more complete backend for his C# interpreter.

4

AGI Development Tools / String Hack

« Last post by AGKorson 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!

5

AGI Development Tools / Re: WinAGI Version 1.2.5

« Last post by AGKorson 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.

6

AGI Development Tools / Re: WinAGI Version 1.2.5

« Last post by Collector on August 14, 2019, 12:09:30 PM »

Thanks for updating the Wiki, too, though I see that the source is still is for 1.2.3.

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.

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.

7

SCI Syntax Help / Re: Loading External Scripts on the Fly?

« Last post by lskovlun on August 14, 2019, 02:00:49 AM »

Though, admittedly, from SCI01 on, the way heap was stored had been changed.

Let alone SCI1.1 (file format redesign) and SCI32 (complete memory manager redesign).

8

AGI Development Tools / WinAGI Version 1.2.5

« Last post by AGKorson 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

SCI Syntax Help / Re: Loading External Scripts on the Fly?

« Last post by EricOakford on August 12, 2019, 11:57:15 PM »

cramming things like the game's icon bar, control panel, and inventory

All of these will be required often to semi-often in normal use. There's a risk in not being able to pull them up if you're low on memory because their memory footprint was not accounted for earlier. What if you're prevented from saving/restoring/quitting? Putting up a death message? Using a critical object?

They will still be initialized in the game's init using the ScriptID kernel function (so they will still be loaded in heap at startup), so I don't think that will be a problem.
I just thought it was a good idea given that by the time of SCI1, it became standard for the inventory to be placed in its own script, and the control panel soon followed, then the icon bar in the SCI32 era.

Though, admittedly, from SCI01 on, the way heap was stored had been changed.

08/13/2019 UPDATE: I've decided to just move the inventory for SCI0 and SCI01 back into MAIN.SC. It's more memory-efficient that way.
I've further been making sure that the free heap and largest pointer are as close as possible (only a 2 byte difference!)

10

SCI Syntax Help / Re: Loading External Scripts on the Fly?

« Last post by lskovlun on August 12, 2019, 03:19:24 PM »

cramming things like the game's icon bar, control panel, and inventory

All of these will be required often to semi-often in normal use. There's a risk in not being able to pull them up if you're low on memory because their memory footprint was not accounted for earlier. What if you're prevented from saving/restoring/quitting? Putting up a death message? Using a critical object?