Non-standard or obscure/undocumented AGI features

[lance.ewing]

I'm not sure if this is the appropriate forum, but it seems to be the closest match. I'm wondering if anyone can recall seeing an AGI fan made game that made use of some sort of non-standard behaviour of the original AGI interpreter that none of the original AGI games made use of? I could go through all of the fan made games myself and see if I can spot anything (and I probably will start doing that now) but I was hoping someone might recall seeing something at some point.

A couple of "features" that I can imagine would be possible to implement would be:

• Full screen graphics. I was prototyping this last night. There is a bit of a knack/hack to it, but it seems to be possible to draw outside of where the picture/animation area is by invoking multiple configure.screen and show.pic calls. I was wondering if anyone had made use of that in a game.
• A pop-up user input window the same as in SCI. I pretty much implemented that last night in AGI Studio as well, so I know its possible. Has any fan made game made use of that?
• Anything else that anyone can think of that never appeared in any of the original AGI games?

Attached below is a picture from the original AGI interpreter running something I hacked together last night in AGI Studio. It was a bit of an exploration of how various commands behave, mainly to come up with more things that my interpreter needs to support to be truly compatible.

Before you get too excited about the full screen graphics, there are a number of caveats about its use. It relies on leaving a ghost behind on the screen from where the picture was previously drawn. It is possible to leave part of a picture and also ghosts from views that happened to be drawn up there as well. Since these are no longer part of the picture, they'll disappear as soon as you open the menu, display a window over the area, or switch to text mode (e.g. inventory screen). Lot's of gotchas there then, but if you're happy to either redraw it when appropriate (which is quite noticeable so probably not the best), or to completely avoid all those features just mentioned (i.e. no menu, no inventory screen, and place windows so they avoid that top area), then you could utilise that area for something static.

[lance.ewing]

It appears that you can switch the configure.screen multiple times during the execution of each cycle. So if you had this in the main part of your room script... :

Code: [Select]

configure.screen(0, 0, 0);
animate.obj(o2);
ignore.horizon(o2);
set.view(o2, 1);
position(o2, 20, 20);
draw(o2);
configure.screen(4, 0, 0);
erase(o2);

...then it will redraw a view up in the top non-picture part on every cycle (I'm assuming you've got your picture placed at the bottom of the screen, which is unusual but not undocumented, but doing so allows ego to walk all the way to the bottom of the screen). So if you were to use an animated object to draw graphics in that top part rather than pictures, then you could redraw it on every cycle, which would address the issue of switching to the inventory screen since it would be redrawn immediately after switching back from the inventory screen. In the case of the menu, it clears away the graphics while the menu is active but then redraws it as soon as you close the menu. The call to erase at the bottom will have the side effect of rendering what is called a "save area" to the screen, but thanks to the configure.screen call immediately above it, it ends up drawing exactly what is already on the screen in that position, so you don't end up seeing any difference.

You could even make this animated object at the top move around by explicitly changing its position on each cycle (rather than relying on the AGI engine to do it, which clearly it wouldn't be able to do). The main reason for the erase call is to stop the AGI engine itself from drawing the animated object on each cycle, since it would place it back down in the main picture area, and obviously with it being erased then the AGI engine isn't going to cycle it or move it or do any of that kind of thing. You'll need to handle everything yourself in the AGI code if you want to animate it.

[Collector]

If you want to explore the fan games for such features you can download a ZIP with nearly all of the known ones from the link at the top on this Wiki page: http://agiwiki.sierrahelp.com/index.php?title=Fan_Release_List

Note that there are a few that will not run with the original interpreter because of memory or blown stack issues.

[Kawa]

I thought the SCI-style input window was meant for certain video systems like Hercules? I think I posted this pic earlier.

So to make it appear in a more commonly-used mode would indeed be quite a hack. Unless you play in ScummVM.

[lance.ewing]

There are references in the original AGI interpreter source code fragments to an OpenDialogue function that does indeed appear in the HDIALOG.C file and usages of it do indeed occur only when the monitor type is monochrome. I don't think it is possible to make use of that when the monitor type var is not mono (and I'm assuming, although I haven't tried it, that we can't programmatically change that var).

I've achieved something similar by using a combination of the normal print command (with the leave window open flag set) followed by a get.string placed on top of the window. After the user types something in, the next command is close.window followed by parse.

I've also confirmed that you can draw a cel on top of this open window, which might allow for some prettier dialog windows.

[Kawa]

What'd also be interesting is doing the opposite: AGI-style realtime command input in SCI.

[lance.ewing]

There is a brief mention here of the "ghost/clone" technique:

http://helmet.kafuka.org/megatokyo/topic_6093.html

To quote Sami_Tervo:

The trick is to use position/.v-command(s), like in Brian Provinciano's AGI Mouse-template. Note: Not REposition.to/.v-command(s)! When using position-commands previous location of object is not erased from screen and a 'ghost image' is seen. There's actually no limit for this so you can create illusion of even hundreds objects! Tricky part is updating these 'ghost objects' and making sure that they won't vanish which can happen quite easily; text-box, textscreen-mode, dropmenu, another object can easily harm them. And of course ghost objects have no location- nor priority-data or other features that real objects possess. Although that can be coped by assigning variables for ghost objects. And one must remember that save-function doesn't save ghost objects and if one wants to make ghost objects appear after loading saved game, an approriate function for redrawing ghost object (e.g. based on variables) must be done. Other bad sides using this technique is possible flickering of objects. This technique is best used when other objects are not drawn upon ghost objects.

I'm not sure yet whether anyone thought to combine this with configure.screen to achieve graphics across the whole screen. Still reading through all that AGI history...

Edit: I've just been playing with the AGI Mouse demo on archive.org: https://archive.org/details/agi_mouse-demo-v1.1.  I can see that it does indeed use the ghost object technique. The bullet holes on one screen and the pixels drawn in another screen are examples of this. They clear away if you happen to open the menu or windows on top of them.

[lance.ewing]

There are a few discussions in the MT AGI forum about changing the colour of things like the status line, menus, and text windows. The standard answer seems to be to hack the AGI interpreter executable itself but that to me isn't really AGI anymore. Things like AGI Mouse and 256 colour AGI were really cool hacks but I was reluctant to use them myself. I preferred sticking to the pure interpreter.

I came across this post:  http://helmet.kafuka.org/megatokyo/topic_1293.html

It asks about the possibility of changing the appearance of the text window. It is true that this is hard coded in the interpreter. Using the ghost object technique in conjunction with the "leave window open" flag, it would be reasonably straight forward to change the colour of the border of the window.

It has probably always been possible to draw your own windows using views, e.g. place a view on screen that looks like a window then write some text on top of it then follow that up with something that waits for a keypress. What I'm thinking though is that you could still use the normal print or print.at command to open the window, leave it open, then draw your bits and pieces on top of that. Depending on what you draw, you might get a flash of the initial white background before your custom bits get rendered. The nice thing about using the window is that it would automatically restore what was behind it when you close the window. Using a view to do it would also restore the background but you'd need quite a big view, which may cause some issues with memory I'd imagine.

[Nicktatorship]

On the SCI style parser, The Lost Planet 1.0 (1999) had it - it was selectable through the menu.

[lance.ewing]

Hey, so it does. That's pretty cool. What version of the original interpreter does it use? I tried dropping in 2.936 but the SCI-like interface didn't quite work right. It opened a window (as shown in the attached picture below), but as you'll notice, the text prompt appeared down in its normal place. Also I had typed in "look". The first letter seems to be ignored.

[Nicktatorship]

I think it was by choice, but I don't remember. The get.string line is still happening at 22,0, so it might have been something I intended to change later - there's a lot of that in that version. I did find that using spacebar to open the dialogue worked around the lost character issue reasonably enough. It definitely faked the parser approach, rather than actually changing the input type like I've also seen being possible.

[lance.ewing]

It should definitely be possible to create it more like SCI and have the prompt and text input within the window. That is what I got working with that screen shot I posted earlier in this thread.

Yeah, it seems that losing the first key is an issue though, unless you were to do as you say and have a key that opens the dialogue. Var 19 does store the last key entered but get.string doesn't allow you to pass in a starting value. You could add it to the prompt parameter I guess, which would mean that the entered key is displayed but it would then be a permanent part of the entry and couldn't be deleted. The original AGI interpreter source code shows that the GetString function calls a GetLine function that does support passing in an initial value for the string but unfortunately GetString clears the string before calling the GetLine function. If only it didn't do that (would be easy to hack the AGI interpreter so it didn't clear the string but that wouldn't be AGI anymore).