Articles

AGI Error Code Tutorial v1.0

by Nick Sonneveld
Last updated 9th March, 2002

Page: 1 2 3 [ 4 ] 5 6

4. Unacknowledged Errors

There are errors that occur that aren't picked up by the interpreter until it's too late.  When this happens you're not guaranteed of actually getting an error message at all, the interpreter could just act strange or hang.  These errors are from my own experience, debugging NAGI to work with lots of games (Sierra and fan made), but I'm sure there are other ways of crashing.  Some of these could be considered questions for a FAQ, but they are more of the horrible bug type nature.

After you restore a game, the game is corrupted (screen, objects, anything)

This happened in the ill-fated game Hitler's Quest. The interpreter stores a list of all the resources that are accessed in the current room so it can reload them in the exact same way when a user restores a game.

The problem with Hitler's Quest was that it used a lot of resources, so the programmer decided to increase the script size.  This is fine, you're allowed to do that.  The problem was that he put the "script.size" command in a room logic, so it was called on every game loop.  The first thing "script.size" does, after it allocates a new script, is clear it.  So the list of all the resources was erased on every game loop.

So when a game was saved and later restored, the script of all the resources that were to be loaded was empty.  The moral of the story?  Make sure you only change the script size ONCE during the entire game, and make sure you do it before you load anything too.

No games work.  The display is half black, characters go missing, it's upside down.  Game worked on another system however.

Unfortunately, some modern video cards don't support EGA properly.  The only thing I can suggest is running the interpreter in CGA mode and seeing if that works:

sierra -c
sierra -r

The alternative is to try the range of free fanmade interpreters available: AGIL, NAGI and Sarien.  The quality of the new interpreters is that most games work.  They also don't use EGA, so they should work on modern systems.  You could always try replacing the graphics card or see if a bios update will fix the problem.  This is a common problem, and unfortunately it could kill the whole AGI gaming community.

In certain places of the game, the screen shakes for ages.

There's a palette patch floating around for the interpeter.  The way it works is that you specify a number over 100 to shake.screen and the number defines the palette to be displayed.  The problem occurs when you try and run the game on an interpreter that doesn't have the palette patch.  Run the game on a patched interpreter, or removed the shake.screen command.

The game just hangs, or whenever the game tries to draw an animated object it hangs.

I'm not suggesting this is the only reason why the interpreter would hang.. but this is the one way I've encountered the interpreter hanging without actually passing it corrupted data.

It's possible to corrupt the pointers inside an animated object.  The code that sets the loop of an animated object doesn't properly check the limits of the available loops.  Lets just say there's N loops.  So you have loop 0 to loop N-1 (which is N loops). The interpreter doesn't properly check and actually lets you set animated object to use loop N, which is one loop above the maximum.  I'm guessing the programmer missed an equals sign.

Anyway, this bug occurs in Kings Quest 2, early versions of Space Quest: The Lost Chapter, and other fan games.  When you set the loop to something that doesn't exist, all kinds of freaky things happen.  The interpreter tries to read a pointer from loop graphics data, and what happens then depends on the data.  In games like Kings Quest 2, nobody noticed.  But in other games, it resulted in the interpreter hanging permanently.

It's also possible to assign a view resource to an animated object and then discard the view resource.  The animated object may still work for a while until you load another resource which will overwrite the discarded one.  It's worse if you run a Windows interpreter because protected memory kicks in first and just crashes the program.

Restoring the game works unless you try it a few times, then it crashes.

I've come across this problem in games that call restore.game within another logic.  I think the interpreter was only meant to restore from logic.0.  I'll try to explain...

The way the interpreter plays around with memory is strange.. but one thing that can be sure is that logic.0 is in memory all the time.  It would have to be because it's loaded every single time the game loops.  The problem with restoring a game is that the interpreter will discard all resources that were in use except logic.0 and then RETURN back to the calling logic.  This is obviously not very bloody good at all if the logic that just called "restore.game" got discarded along with everything else.  I don't know why, but it doesn't seem to crash the original interpreter, but it does crash NAGI.. ocassionally.  It was a pain to track down.

Moral of the story?  Only call "restore.game", "restart.game" and anything else that discards the calling logic in logic.0 because logic.0 is the only guaranteed resource to be in the same place after a restore.

Page: 1 2 3 [ 4 ] 5 6