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 4 ... 20
AGI Development Tools / Re: CrafterCMS (Online AGI tools)
« on: February 21, 2024, 04:21:08 PM »

AGI Development Tools / Re: Introducing Sierra Quest: Power Pack Demo
« on: January 30, 2024, 10:18:48 AM »
On the ScummVM forrum, one of the admins asked me about the Power Pack code, and what it might take to add support for it to ScummVM. He never replied to my follow up messages though.

I think it would be simple to add Power Pack support. You could either add a property to a game so that the interpreter knows the Power Pack is active when the game loads, or you could add a check to see if the code injection is attempted, and then set the property that way. Once the interpreter knows the Power Pack is active, it's just a matter of using a switch block in each of the modified commands to respond to the Power Pack commands correctly. It might take a bit of work, but I don't think it would be that complicated.

I know about Flag Quest because I wrote it!  ;D

I don't think you need to go as far as adding a byte array to check for injected code - once the Power Pack hacks the interpreter, the entire MSDOS memory space is available for read/write, so you'd have to model the entire MSDOS environment, including BIOS. I'm guessing that's not very practical. If one of the version check strings is checked, you could modify your compare.strings function to send back whatever is needed to tell the game what version the interpreter is currently emulating. Everything else in the Power Pack could be supported as described above.

Where this approach would break down is if someone decides to write their own code to inject. There's really no way to model that without modeling the original MSDOS environment, which is what DOSBox with the original interpreter does. In that case, the person writing the custom code would need to provide relevant information to the other interpreter dev teams so they could code appropriately to add support.

I don't think you need to worry about that though. I put the odds that someone else will write their own Power Pack code at around 1,000,000 to 1.

What is the AGI "hello world"?

At its simplest: in logic 0:
Code: [Select]
print("Hello world");

to feel more 'AGI-like', in logic 0:
Code: [Select]
if (v0 == 0) {;
in logic 1:
Code: [Select]
if (isset(f5)) {
    display(12, 33, "Hello world");

if (have.key()) {

AGI Development Tools / Re: Introducing Sierra Quest: Power Pack Demo
« on: January 30, 2024, 12:03:25 AM »
Here is a link to version 1.0d, which fixes a few more minor bugs.!AioUx5fucQP0nYgXP2UNKUK1yByFLQ?e=3eMumW

And if anyone wants to look at the source code, it's on github, and can be found here:

Running a custom cycle within a single logic is definitely very doable. I used that technique in the Power Pack Demo game, to show the walkman. It's very useful when you need to interrupt the main cycle, for example to show a cutscene or other animation, but don't want to use a command because of other considerations (usually to temporarily avoid cycling of the main story's animation).

The challenge is that you have to manage all the animation manually. Basically, you are replacing all the overhead activities that the interpreter does with equivalent manual code.

As a proof of concept, you could certainly create a game that never leaves logic 0, but I don't think there are many scenarios where that would be preferable to letting AGI do the heavy lifting between cycles. That's kind of the whole point of the interpreter.

I'd be happy to continue the discussion in another topic if there's further interest.

Good catch! I revised my post to reflect that. The next version of WinAGI will include the updated snippet text. In the meantime, it's super easy to update any snippet (or add new ones) by using the Code Snippets tool.

I was recently asked this question in a separate conversation. AGI is a very primitive language that does not include any flow control statements except 'if-else' and 'goto'.

But you can easily write code to duplicate the 'for' loop structure.
A standard 'for' loop in more complex languages looks like this:
Code: [Select]
for (<init-expression>; <condition-expression>; <update-expression>)
  [ statements to repeat in each loop

Here is an AGI template that will do the same:
Code: [Select]
if (<condition-expression>) {
  [ statements to repeat in each loop

Here's an actual example to see it in action:
Code: [Select]
v99 = 10;
if (v99 > 0) {
  [ statements to repeat in each loop
  print("Countdown: %v99");

WinAGI includes a snippet that handles creating the 'for' loop template. All you have to do is type
Code: [Select]
#for(v99 = 10, v99 > 0, --v99)#

and the code block is automatically inserted!

Snippets are a powerful tool in WinAGI that can help with a lot of other coding tasks. Check out the WinAGI Help File for more information, or post a question here, and I'd be happy to help.

AGI Development Tools / Re: WinAGI Version 2.3.5 - Fixes Game Import Bug
« on: January 24, 2024, 03:56:16 PM »
Ugh!! I didn't do any testing of fan games, just Sierra originals. I'll try a few right now, but if you know some specific ones that are problematic, that'd help.

I guess I'm not doing very good job of testing these releases... smh

AGI Development Tools / WinAGI Version 2.3.6 - Fixes Game Import Bug
« on: January 24, 2024, 10:40:30 AM »
Version 2.3.6 is available here:

It fixes the bug in earlier versions that caused WinAGI to crash when importing a game.

EDIT: version 2.3.6 fixes one more minor bug in import game function

AGI Development Tools / Re: WinAGI Version 2.3.4
« on: January 24, 2024, 10:02:59 AM »
That would be awesome! I will get that to you shortly. Thank you so much for that!

AGI Development Tools / Re: WinAGI Version 2.3.4
« on: January 24, 2024, 02:14:30 AM »
Most of the installers I have written have been with NSIS. With NSIS it would be a trivial matter to check the Registry for previous versions or to uninstall a previous version. It also usually has a lighter footprint on the registry. You could easily have it use no more than uninstall information and file associations. It is easy to register DLLs, etc.
I recall giving NSIS a try in the past, but I struggled to master it. I'm sure you're right about it being a better installer authoring tool, but I just don't have the energy to figure it out.

The SysWOW64 folder is a redirect folder where 32-bit versions of DLLs and drivers are sent to keep them separate from the 64-bit versions. These are used by the x64 version of WOW (x64 version of Windows on Windows or WOW64  x86 emulator/subsystem) so 32-bit programs can run on x64 Windows.
Thx for that explanation. I figured it had something to do with 32 vs 64 bit, but didn't know for sure.

Perhaps just add a link to the GitHub on the WinAGI Wiki page instead of the zip?
I haven't made the repository public yet. I will do so at some point, but not until I'm ready. In the meantime, I don't mind sharing it privately if asked. I suppose I could update the zip files, but it's not like tons of people are clamoring to get the source code. I think I've had two requests for it in the past 15 years.

AGI Development Tools / Re: WinAGI Version 2.3.4
« on: January 24, 2024, 01:51:53 AM »
I haven't used WinAGI much, but out of curiosity, are there many known bad resource files of the official sierra AGI games? Like, are they few enough that you could detect them and put an additional message warning that the file decompiled etc properly, that these are just bugs present in the official game releases?  Or is that just an insane amount of work for minimal payoff?
Yeah, most Sierra original games have at least one resource with minor errors/non-conformities. I did imports for my copies of Sierra games (I only own one version of each, so I haven't tried all the different versions). Among the 18 games I checked, only GR, KQ2, LLLLL, MMUG, SQ1, DEMO2, DEMO3 and DEMO5 have completely clean resources. BC, DDPG, KQ1, KQ3, MH1, MH2, PQ1, SQ2, DEMO1 and DEMO4 have at least one resource issue. None of them prevent the games from running though.

When importing a game, if any resource issues are detected, WinAGI will show this dialog:

Maybe I could change that to make it clearer? If you have any suggestions, I'd love to hear them.

I'm also seeing problems running v2.3.4 vs 2.3.2.  In 2.3.4 if I try and import a new game (KQ3 specifically), it hangs after decompiling but before opening the window where you select the ID name, the interp, the folders... all that stuff.

v2.3.2 works fine.  I did a full uninstall and re-install of each version before testing that.
Thanks for the confirmation. Version 2.3.4 is the one that I effed up. I rewrote the file retrieval functions for text files to handle different end-of-line markers, but failed to realize the changes would hang up if an empty file is encountered.  I've got it fixed and will upload a version that works correctly shortly.

AGI Development Tools / Re: WinAGI Version 2.3.4
« on: January 23, 2024, 06:47:46 PM »
Hi macca,

thx for the post, and welcome to the AGI programming boards!

The warnings when you import PQ1 are just that - the original resources in Sierra's released version of PQ1 had a couple of 'glitches' in their resources that don't affect the game at all, but are non-standard. WinAGI is just letting you know in case you want to rebuild/modify things that those warnings should be addressed.  You can ignore them completely if you want.

BUT, you have identified a very serious bug. The lock up is because of a change I made in 2.3.4 to address different types of text files and how they might indicate end-of-line. I thought that was a straightforward fix, but due to how the import function sets up the globals.txt file, the change causes WinAGI to lock up as you describe.

I am very sorry about that, and will get a fix for it ASAP, probably tonight.

In the meantime, you can work around it by manually creating (or editing if it already exists) a 'globals.txt' file in your game directory, and add at least one blank line (by pressing enter, then saving it). Do that before importing and then it will open correctly.

Again I am very sorry for that bug!

AGI Development Tools / Re: WinAGI Version 2.3.4
« on: January 23, 2024, 02:04:22 AM »
Good point about the installer - writing installers is not my strong suit, so it's important to uninstall the old version using its installer and THEN installing the new version. I don't know how to make an installer that does removal/updating of an existing version.

If the installer was giving a warning about some of the DLLs, that'd be the first place I'd look. If you happen to know specifically which DLLs, and what version of them are on your system, I'd love to have that info to do some testing.

SysWOW64 is a system subdirectory in the Windows directory- it has similar files as the System32 directory, but the 64 bit versions I think. (I'm not a Windows system expert though, so I could be wrong). I do know many of the files that WinAGI uses are there.

The zip file with the WinAGI source code on the wiki is very out of date. I haven't bothered updating it for years. If you want the files for the latest version, PM me your github ID and I'll send you a link to the repository.

AGI Development Tools / Re: WinAGI Version 2.3.4
« on: January 22, 2024, 04:26:39 PM »
That's not something I've ever seen or heard of before. If the installer ran correctly, all necessary files should be there, and it should work. If something was broken, I would expect it to be repeatable, not random. Makes no sense to me.

You're running W10? if so, there should be no problem. I run it (and occasionally do development of it) on a W10 system. Also on W11. It shouldn't matter, but are you running 64bit or 32bit? I've also seen it run on both of those systems.

In looking over the Install package, I can see there MIGHT be a possible problem with the text editor; WinAGI uses a custom editor control, but it relies on having the file riched20.dll installed, but my installer doesn't add it - it assumes it will be there like all other kernel files. Maybe that file is missing or corrupted? But even if that's the case, I would expect a different error instead of what you describe.

Only other thing I can possibly think of is that one of the Windows components used by WinAGI is the wrong version on your system but isn't being updated by the installer. If you are interested, I can send you a list of all windows components that WinAGI uses; if you check the versions/dates of them and send those data back to me, I can check against the list of what is working to see if there's a file that's problematic.

Pages: 1 [2] 3 4 ... 20

SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.049 seconds with 20 queries.