Any AGI engine upgrade projects? Looking for better graphics.

[OgreVorbis]

There is a conundrum that I have regarding the Sierra engines (both AGI and SCI) and as a result, I keep using AGS (Adventure Game Studio) for all my projects even though they would be more suited to a Sierra engine. I absolutely love text parser games, but there is a problem with AGI and SCI.

The problem is that AGI's graphics are simply too low resolution to be of any value to me. Do understand that I am a retro enthusiast and love pixelated graphics, but I find the AGI engine graphics are just too low to express any sort of real artistic qualities. I think the SCI engine is perfect, graphics wise. The 320 x 200 vector graphics and the bitmap VGA graphics are both great. The problem, however, is that SCI uses that esoteric scripting engine with Lisp syntax. I honestly think it is horrible. I find that I just can not code proficiently enough in it to make a real game with it. I can tell that even if I get smoother over time, it will still hamper my development speed too much.

I would honestly pay someone to do this:
Can someone please upgrade the AGI engine (fork the code) and upgrade the graphics to be just like SCI. I'm not asking for hi-res - just 320 x 200 EGA or VGA bitmap graphics (mode 13h). Forget the vector graphics (unless it's easier) and just use bitmap (or PCX) files for the backgrounds. Maybe the graphics code from the SCI engine could be ported over to AGI? That would be perfect. We'd then have an engine that is easy to use (scripting wise) and would also allow people to express themselves artistically.

I really believe the main reason why this community is small and the AGS forums are so big is because of this exact reason. It's unfortunate when I see somebody using AGS to make a game that is exactly like an old Sierra game (like Julia Minamata's - The Crimson Diamond).

SCI = horrible scripting language
AGI = too primitive graphically

I would love to help to make something like this a reality. If anybody could point me to the region of code that does the AGI graphics, maybe I could look at it and see if I can figure something out. I do have programming experience in C, but I am not proficient in low level DOS code.

[lance.ewing]

There does already exist a hack that gives the AGI interpreter 256 colours for both the pictures and the views, where the pictures are no longer vector based but bitmap. The resolution is still 160 wide though, so I assume that that is still too low resolution?

When you say upgrade the AGI engine (fork the code), are you referring to the original AGI interpreter code? If so, unfortunately we don't have a full copy of all of the original AGI interpreter source code. We are lucky to have about 80% of it. The people that implemented the various hacks for the original AGI interpreter would have hacked in small machine language hacks into the executable. It might be possible to do something like that to provide what you want, but I think it might get a bit tricky, as it isn't as "easy" as what the 256 colour hacks did. The problem with a higher width resolution is that it changes many things across the interpreter. The LOGIC file format will have to change, for example, since setting the position of views on screen will need to represent a number bigger than 256, so will require more than one byte. That's just one example. I personally wouldn't be able to update the original AGI interpreter to do that. AGKorson understands the internals of the original AGI interpreter better than anyone, so could probably give a more authorative answer, but I'm guessing it would be a lot of work, even for him.

If you are not necessarily referring to the original AGI interpreter, but could instead live with one of the fan-made AGI interpreters (of which there are quite a few now), then the problem would become easier. The updates to the fan-made AGI interpreter wouldn't be too difficult to make, but you'd then require an AGI editor suite that supports the new formats. As I say, the LOGIC files would be different, the PICTURE and VIEW files would be different. An editor like WinAGI wouldn't understand the format, unless a special fork of that was also created.

I think that the "easiest" way to achieve what you want would be a custom build of WinAGI and AGILE. It would then be its own thing, but closer to AGI than AGS.

[AGKorson]

If you want to have something that would run in MSDOS, there is no practical way to expand the resolution. First hurdle is reformatting all resources to use words instead of bytes, then rewriting every graphics function (drawing functions and commands that manipulate graphics). It would be a complete rewrite of the AGI engine. If you're going to do that, then just create something new. (Which is what Sierra did with SCI.)

In the Power Pack mod I developed, AGI is modified to use the MSDOS graphics mode that provides 80 column text. That was relatively easy and doesn't involve any changes to resource formats. As I was working on that, I had to wonder why Sierra never did it. I think AGI games look significantly better when using 80 columns for text instead of 40. But it doesn't address screen resolution for graphics- 160x200 is all you're going to get out of AGI.

The second hurdle is memory management. AGI uses a single 64K segment of memory (allowing easy memory access with just a word value as the offset). Doubling the screen width from 160 to 320 would effectively double graphics resource sizes. It might not seem like a lot, but it is! For anything other than simple fan games, AGI is already severely memory-restricted. You want more graphics? Then you get less scripting and less detailed word dictionaries to make it all fit. Just take a look at some of the late AGI games from Sierra and see what kinds of tricks they had to perform to make everything fit.

In the Power Pack I was also able to create a separate segment to hold text resources, which frees up a substantial amount of memory. But there's no way to easily expand that to cover other resources - most of the game's functions need to be able to address graphics and the overlay resources from within the same segment. (Which is why available memory is even less than 64K- the overlays have to be in the same segment and take up ~7K or 8K depending on version).

As far as forking the source, Lance is correct that original source is not fully known. But that's a trivial matter- The program is a very simple MSDOS EXE file. It disassembles quite easily, and source code is not difficult to create that provides 100% compatibility. The NAGI engine is exactly that. (It probably wouldn't be that difficult to fork NAGI and create a version that outputs an MSDOS program file if you really wanted to do it - time consuming I imagine, but not difficult).

Bottom line is that AGI is inherently limited in graphics due to its memory model and resource formats. To get more resolution you have to go beyond AGI. Just like Sierra did. Like you though, I really dislike their move to the LISP syntax. Frankly, it's the primary reason I never had much interest in studying SCI.

Probably not what you were hoping to hear. But if you did want to poke around in AGI internals, I have fully disassembled all AGI versions, with detailed annotations. I'd be happy to share that with you if you want. I would also suggest looking at NAGI's source. As I said, it was created from disassembled AGI.  And you could take a look at the fragments of source that are available. And I'd be happy to answer any specific questions you might have.

As far as a practical implementation of 'Hi-Res AGI', I agree with Lance that something like his AGILE engine (which is currently under active support) along with an editing suite to handle the resources (WinAGI potentially, but I'm not currently interested in adding support for custom resources) is your best option.

[OgreVorbis]

If you want to have something that would run in MSDOS, there is no practical way to expand the resolution. First hurdle is reformatting all resources to use words instead of bytes, then rewriting every graphics function (drawing functions and commands that manipulate graphics). It would be a complete rewrite of the AGI engine. If you're going to do that, then just create something new. (Which is what Sierra did with SCI.)

In the Power Pack mod I developed, AGI is modified to use the MSDOS graphics mode that provides 80 column text. That was relatively easy and doesn't involve any changes to resource formats. As I was working on that, I had to wonder why Sierra never did it. I think AGI games look significantly better when using 80 columns for text instead of 40. But it doesn't address screen resolution for graphics- 160x200 is all you're going to get out of AGI.

The second hurdle is memory management. AGI uses a single 64K segment of memory (allowing easy memory access with just a word value as the offset). Doubling the screen width from 160 to 320 would effectively double graphics resource sizes. It might not seem like a lot, but it is! For anything other than simple fan games, AGI is already severely memory-restricted. You want more graphics? Then you get less scripting and less detailed word dictionaries to make it all fit. Just take a look at some of the late AGI games from Sierra and see what kinds of tricks they had to perform to make everything fit.

In the Power Pack I was also able to create a separate segment to hold text resources, which frees up a substantial amount of memory. But there's no way to easily expand that to cover other resources - most of the game's functions need to be able to address graphics and the overlay resources from within the same segment. (Which is why available memory is even less than 64K- the overlays have to be in the same segment and take up ~7K or 8K depending on version).

As far as forking the source, Lance is correct that original source is not fully known. But that's a trivial matter- The program is a very simple MSDOS EXE file. It disassembles quite easily, and source code is not difficult to create that provides 100% compatibility. The NAGI engine is exactly that. (It probably wouldn't be that difficult to fork NAGI and create a version that outputs an MSDOS program file if you really wanted to do it - time consuming I imagine, but not difficult).

Bottom line is that AGI is inherently limited in graphics due to its memory model and resource formats. To get more resolution you have to go beyond AGI. Just like Sierra did. Like you though, I really dislike their move to the LISP syntax. Frankly, it's the primary reason I never had much interest in studying SCI.

Probably not what you were hoping to hear. But if you did want to poke around in AGI internals, I have fully disassembled all AGI versions, with detailed annotations. I'd be happy to share that with you if you want. I would also suggest looking at NAGI's source. As I said, it was created from disassembled AGI.  And you could take a look at the fragments of source that are available. And I'd be happy to answer any specific questions you might have.

As far as a practical implementation of 'Hi-Res AGI', I agree with Lance that something like his AGILE engine (which is currently under active support) along with an editing suite to handle the resources (WinAGI potentially, but I'm not currently interested in adding support for custom resources) is your best option.

Excellent post. I really appreciate your time.

I understand. Maybe it would be easier to instead replace the script interpreter in SCI to use something more C-like? The end result of that would be almost exactly what I'm looking for also. I'm going to assume that that would also be a major project. However, I wonder if the SCI script engine runs some VM with a type of byte code? (you know, like Java or C# does). Cause if it works that way, then it might not be too challenging to write a new language that compiles into that byte code.

Anyway, I'll look at NAGI for some inspiration, however, I do want it to run on MS-DOS. That's one of my issues with AGS. DOS was the birthplace of these types of games and retro enthusiasts are often going to want to run games like this on period correct hardware. I think I may end up going the route of simply writing my own engine using the DOS version of Allegro. Given that it will be purely a text parser with graphics, I think that might be the easiest way. I think if I just write the C code elegantly, I might be able to make an include file which you could include to make an almost script engine w/o having a script engine if you know what I mean. If I just expose the right functions, it could make the compiled C code work like a sort of scripting language. It would certainly be much faster that way.

[Kawa]

There's already been an attempt to have a C-like syntax for SCI, so you're not the first to have this idea.

It didn't go anywhere.

[pmkelly]

Kawa, I was just browsing through the files in your SCI stash and in original/TOOLS.zip I found the following, which I was not aware of previously:

Code: [Select]

ATOS.EXE     - AGI to SCI source code translator
It seems to work when run against some of the original LSL1 files. Not sure if the resulting code compiles, but interesting to see that they actually had developed such a tool. I wonder what it was used for?

[lskovlun]

@pmkelly: In my experience, it doesn't work. It's hard to make it generate any output at all, and the paradigmatic differences between AGI and SCI mean that it can't do a very good job. I'm sure they tried, but if you read the history of how KQ4 came to be, there was a lot of crunch time where external programmers had to be brought in.

[cosmicr]

Part of the charm of an AGI or SCI0 game is the vector graphics... If you're gonna use bitmaps you might as well use AGS like Crimson Diamond did anyway... AGS has way bigger community, better tools, and easier to learn.

The only reason to adopt SCI with bitmap graphics is if you're going for authenticity.

FWIW, I like the Lisp/Smalltalk like language that SCI programs use. As a kid I didn't get it, but later I learned Lisp for work (CAD) and when I went back to it I found it fairly intuitive. The only parts I find difficult are the OO concepts and different terminology from today, like selectors/indices and superclasses hierarchy etc... I've attempted to write my own compiler for SCI (I wrote an AGI decompiler once), but it's not nearly as simple as the AGI logic scripts.

[lskovlun]

Ah yes, AutoLISP. And as for SCI being hard due to the different OO concepts, I remember writing the first class dumper way back in 1998 (I still have the source!). It allowed me to deduce the logic of the class hierarchy pretty quickly, and I was entranced.

It was based on Carl Muckenhoupt's SCI Decoder, and I ported his decompression routines to Pascal. The one thing that caused me trouble was that Turbo Pascal doesn't have an unsigned long type, so I had to write those parts in asm.

[Kawa]

It was based on Carl Muckenhoupt's SCI Decoder

Great, now we have a name to blame for the default palette being wrong in basically everything since.

[lskovlun]

It was based on Carl Muckenhoupt's SCI Decoder

Great, now we have a name to blame for the default palette being wrong in basically everything since.

Well, I spotted his name in a Telltale production (I forget which one). So he is/was active for a long time after that. And there were other bugs too, for example his routines choke on pics that contain the monochrome opcodes we've discussed earlier.

[Collector]

Muckenhoupt has been around for quite a while. He wrote the old "SCI Decoder" His name is included with FreeSCI, though it may be more inherited from his earlier efforts and used in FreeSCI's SCI Specifications. I guess you would know more about that. Even Lance refers his decrypt routine for SCI games in the AGI specifications. http://wiki.sierrahelp.com/index.php/AGI_Specifications:_Chapter_5_-_Resource_Formats

[bokkers]

Hey folks, got nothing constructive to add, but I'd like to quickly cut some slack to AGI graphics, for the sake of completion.

Sure, the resolution could be higher. Jusk ask the NPCs from the AGI game I'm working on,... Like the original poster I also think that SCI graphics are a much better base for getting a bit more sophisticated in 16-color pixel art. I'm taking the challenge of trying to squeeze out SCI style things from the AGI engine at the moment, because why not try.

Definitely looking forward to trying out SCI after finishing my current AGI project. That being said, thanks for the warnings and heads-ups regarding the scripting language, seems to be an adventure in itself...

Nice that we have option to switch to things like AGS and Unity nowadays, if need be. Wasn't always like that. When I first discovered the AGI scene back in the 90s, it was sensational that a fan could get his hands on a professional game engine like AGI, giving your fanmade game the instant look and feel of some classic and genre-defining games. Find it kind of nice and also funny to see that people use a full-blown 3D-engine like Unity to produce 16-color, lo-res, parser-driven, 2D games in the year 2025. And why wouldn't we? Whatever works to make a game good.

Cheers from the pixel workshop!