C# AGI Interpreter

[lance.ewing]

Thanks, I'll take a look at that one when I move on to sound.

The menu system is now working. Still a lot of commands not implemented, but most of them aren't show stoppers for attempting to play the game. So I thought I might have a go at playing through King's Quest 1 this evening to discover some more bugs. I've already found my first two. I couldn't get in to the castle because sound hasn't been implemented yet. So I faked that by immediately setting the sound end flag when a sound is played. I then got to the throne room, bowed, and halfway through returning to an upright position, ego freezes. So I'll track that one down now, fix it, and then basically just keeping finding and fixing any bugs along the way.

[lance.ewing]

I made it up to 47 points before discovering the third bug. This one is a parsing bug. I haven't yet allowed for words that are actually multiple words, e.g. "look inside" can be (and is) defined as a single word in KQ1, in fact that are lots of cases of words with spaces in them. So looks like I'll have to take a look at my parser again...

[lance.ewing]

Fixed that one and I've now got up to 110 out of 158 points. Unfortunately I died climbing the beanstalk. At least I've now seen that the death scene with ego flattened on the ground is working fine. Starting to miss the lack of a save game feature though.   

I might leave it there for now as far as the KQ1 play through goes. I'll look at implementing a couple of new features again, perhaps the looking at inventory object feature (which I don't have yet) and maybe a few other commands I haven't yet got to.

[Collector]

Sounds like you are making good progress. This should also be good for helping flesh out the AGI library, especially the missing logic part of the library.

[lance.ewing]

I implemented the show.obj and show.obj.v commands over a week ago, so viewing inventory objects is working well now. Had to do a bit of after hours for work over the past week, which hindered things with the interpreter over that time. Not going to make that mistake this weekend.

I thought I'd have a go at adding the 0xFA (brush picture command) to the Picture resource this evening. As already noted, that command isn't implemented in the AGI Library, so I can't currently try playing SQ2, which is one of my favourite AGI games. SQ2 makes heavy use of that Picture command.

[Collector]

Are you able to play through any of the official games, yet?

[lance.ewing]

I haven't tried playing through a game again since my attempt at KQ1 the other evening. I think that one is probably achievable with luck, but I don't fancy falling off the beanstalk again until I have saved game capability built in. It's probably one of the next features I'll take a look at. Currently I'm refactoring my text window to support how SQ2 uses them in some LOGICs. For example, when Vohaul is talking to Roger, the text window is left on the screen while the animation continues. This usually doesn't happen in most games but shouldn't be difficult to support.

SQ2 has revealed a number of bugs (or missing features in some cases). I finished implementing the 0xFA brush command. The command to set the type of brush (0xF9) was already implemented, but not the brush command itself. So that's now working, and visually it appears to match the original interpreter. - The only picture I've seen so far that isn't happy in SQ2 is the title screen. The big blue letters are not filled in. So there's a fill issue, or it could be as a result of an issue in another command. It's the only picture I've seen so far that has such a fill issue. PICEDIT loads and displays it fine, so its just a matter of sifting through the code with a fine tooth comb and seeing where things differ. - I also noticed that newline characters aren't being handled in the display command. I'm surprised SQ2 was the first game to show this bug.

SQ1 hangs on the title screen, but you can get in to the game by hitting a key. My current theory about why it is hanging is that I think this LOGIC might be dependent on the sound timing. I'm setting the completion flag to true immediately for all sounds, but I suspect that this particular LOGIC relies on the sound taking a certain amount of time. I can probably fake the duration of the sound but I figure I'll just leave that until I actually have sound.

DDP has exposed some interesting bugs with regards to the synchronisation of picture placement and text. Should be easy to fix, just need to get to it.

[lance.ewing]

It would appear that I'll need to put a small delay between room changes:

Code: [Select]

    set(f15);
    print("You are whisked away to the airlock chamber.");
    v3 += 1;
    new.room(3);

Flag 15 tells the print command to leave the text window displayed on the screen. I'm not even seeing the window flash up, because the new.room is being actioned too quickly, probably because I've got all the resources loaded in to memory, so there's no slow disk access. Even in DOSBOX the message isn't shown for very long. I'm assuming that on the original 80s hardware it would have stayed up a little longer.

The window should stay up until the show.pic command is executed in the next room. My interpreter seems to be getting to it far too quickly. I suppose what I could do is detect that there is a window open on room change and add a small delay to account for the slower room change in the original games.

[Collector]

Of course you can lower cycles in DOSBox to get the speed of 80s hardware. Even so, if the original was getting it from disk it is both disk and CPU clock speed.

Is it possible to set speed in the interpreter to a fixed value rather than cycles? Would this help with such issues?

[lance.ewing]

My interpreter already has a fixed speed, by which I mean that the rate at which the interpreter cycle gets called is virtually the same as the original AGI interpreter. The interval between the start of the interpreter cycles isn't the issue but rather how fast a single interpreter cycle runs from beginning to end. This difference isn't observable most of the time, but if a particular AGI command would have taken a long time to execute in the original interpreter (let's say it might take the same time as 10 normal AGI interpreter cycles for a single command), then that's obviously a noticeable difference. My interpreter is taking no time at all for such a command.

I'd say that the text window in this particular example would need to be on screen for at least a second to give someone time to read it. So I'm assuming that whatever commands happen between that print command the the subsequent show.pic command are taking at least a second to run. This is all happening within a single interpreter cycle, because my interpretation of the original AGI specs, and of what the fragments of the original AGI interpreter source imply, is that a new.room runs LOGIC.0 again in the same cycle but for the new room. Even if I got that wrong and the new room doesn't get run until the next cycle, that would only introduce a fraction of a second delay and not enough time to even start reading it.

[lance.ewing]

I haven't been idle on this over the past two weeks, in fact any spare time I've had I've been continuing to slowly work towards furthering the interpreter. What's ahead of me though are a number of larger items. I'm currently looking at the save and restore functionality. I think what I'll end up doing is to support the save game format in use between versions 2.4XX up to 2.936. The interpreter doesn't yet load AGI v3 games, so I haven't looked at the saved games for those games. What I've noticed for AGI v2 though is that the 2.272 saved game format differs in a few places. It has less space for strings, less space for key mappings, and appears to have different fields toward the start of the first "piece", which the original interpreter calls the "savevars" piece. I might be able to support loading saved games from that version at some point, but I'll focus on versions from 2.4XX for now. The only difference I can spot at the moment between 2.4XX saved games and the the 2.9XX saved games is the addition of a field for storing the pushed script number for the push.script command.

My interpreter doesn't currently support the concept of script events, so in order to support saved games, I'm going to have to implement that as well. There's a whole section of the saved game format dedicated to script events. It's important for things such as restoring add.to.pics.

On the horizon for some point (perhaps towards the second half of March) would be sound implementation. Then maybe AGI v3 support in April.

[Collector]

It would be great to have sound support added to the library.

[lance.ewing]

In working on the AGI interpreter saved game functionality, using the original saved game format, I've noticed that it doesn't appear to have been documented yet, at least I couldn't find it anywhere, other than a few notes by David Symonds on the scummvm web site that was only scratching the surface. There is enough information in the original AGI source code fragments to piece the whole thing together. We probably should document it somewhere.

[OmerMor]

There is enough information in the original AGI source code fragments to piece the whole thing together. We probably should document it somewhere.

Good idea.
Why not the ScummVM wiki?

[lance.ewing]

Yeah, that was my thought. I've emailed David Symonds and he is quite happy for me to do that. He did have a note on there asking people to let him know if they were going to make changes to the page, but he says he's going to remove that note now. He hasn't touched AGI for 10 years.