Show Posts
1
AGI Development Tools / Re: Any AGI engine upgrade projects? Looking for better graphics.
« on: December 04, 2024, 03:58:47 AM »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.