C# AGILE

[Collector]

If you are talking about view.000 being the main view, then yes version 2 only has four loops. It has been some time since I have last looked at Visual AGI, but my memory is that it could not open any AGI3 resources. I am assuming that you added support for decoding these too, not just AGI3 logic support. I need to go through the project again to refamiliarize myself with it.

[lance.ewing]

Yes, it does say version 2, but the strange thing is that I've checked the timestamps of the vol files and they're all still 1988, which suggests they haven't been modified.

I have found another issue with KQ4. It only seems to affect KQ4. There are a few pictures that the AGI Library does not load, complaining that in the 0xF7 "relative draw" command that Y hits a value of 168, which it says is invalid. That sounds fair enough, but if I comment out that check, these pictures load fine and are drawn fine by my Interpreter. Not sure at this point whether this is somehow "bad" data that the original AGI Interpreter (and my Interpreter) is handling without issue, or whether there is something wrong in the AGI Library's Picture drawing code. I'm tempted to leave this validation check commented out since the Pictures are working fine like that.

Since my last update, I discovered an omission in my SOUND resource decoding that I have fixed. It wasn't catering for early termination of a voice with two consecutive 0xFF bytes.

And hold.key and release.key have been implemented, so the MH games are feeling like the real thing now.

I've been looking back over games that I thought I had working fine, and noticed that MUMG has a number of rendering issues. I recall discovering this back in early 2017. I thought I had fixed it, but perhaps I was partway through trying to resolve this when I was distracting by other things. It is to do with when animated objects are drawn. What MUMG does is to draw some animated objects to screen (e.g. speech bubble), and then immediately sets them to stop updating. The main Interpreter cycle doesn't redraw "stopped" animated objects; it only redraws those that are updating. So what MUMG does is to then position text on top of the "stopped" animated object, which it expects to stay on the screen. Currently my Interpreter is redrawing the stopped animated objects, which it shouldn't be in order to be compatible. So I'll need to take a look at that now. The way the original AGI Interpreter manages and redraws its "stopped" and "updating" objects though is like a ball of spaghetti, so its a matter of extracting the key parts in a cleaner design. I've got it all written out in a notebook, so hopefully I can get this solved soon.

Edit: Oh, forgot to mention that yes, I added AGIV3 support for loading of all resources. Mainly its just the LZW compression, and the Picture compression.

[lskovlun]

The way the original AGI Interpreter manages and redraws its "stopped" and "updating" objects though is like a ball of spaghetti, so its a matter of extracting the key parts in a cleaner design.

Oh yes, oh yes. That was one of the major sticking points in SCI as well. I suspect much of it was brought over unchanged.

[lance.ewing]

If you are talking about view.000 being the main view, then yes version 2 only has four loops. It has been some time since I have last looked at Visual AGI, but my memory is that it could not open any AGI3 resources. I am assuming that you added support for decoding these too, not just AGI3 logic support. I need to go through the project again to refamiliarize myself with it.

There is definitely something weird going on with VIEW.0 in KQ4. My first workaround for this broke MUMG. Since the original AGI interpreter handles playing KQ4 fine, then it is coping with this extra Loop, even though the fragments of original AGI interpreter source indicate that AGI V2 would not have handled it. So I started wondering how scummvm handles this (since I've already ruled out the extra Loop having been introduced by an editor, due to timestamps on the KQ4 files still being 1988). Turns out that it has a specific workaround coded for KQ4:

https://github.com/scummvm/scummvm/blob/master/engines/agi/view.cpp

Code: [Select]

if (!(screenObj->flags & fFixLoop)) {
switch (screenObj->loopCount) {
case 2:
case 3:
loopNr = loopTable2[screenObj->direction];
break;
case 4:
loopNr = loopTable4[screenObj->direction];
break;
default:
// for KQ4
if (getVersion() == 0x3086 || getGameID() == GID_KQ4)
loopNr = loopTable4[screenObj->direction];
break;
}
}

My workaround was almost the same but without the AGI interpreter version and game ID check. This breaks MUMG though, which is why it seems that it is necessary to have a game specific check.

[Collector]

ScummVM does use an abbreviated MD5 check (from the first 5000 bytes), usually on the logdir file for AGI games to determine not just the game, but the game version as well. I used this for my Sierra game version detector tool. Wouldn't such an approach cause a problem with using it on the fly to run a new game, especially one still under development where the target file for the check would be constantly changing.

[OmerMor]

So I started wondering how scummvm handles this (since I've already ruled out the extra Loop having been introduced by an editor, due to timestamps on the KQ4 files still being 1988). Turns out that it has a specific workaround coded for KQ4:

https://github.com/scummvm/scummvm/blob/master/engines/agi/view.cpp

Turns out this fix goes all the way back to Sarien (which was imported to ScummVm), some 18 years ago:
https://github.com/cmatsuoka/sarien/commit/2e38cdc

[lance.ewing]

So I started wondering how scummvm handles this (since I've already ruled out the extra Loop having been introduced by an editor, due to timestamps on the KQ4 files still being 1988). Turns out that it has a specific workaround coded for KQ4:

https://github.com/scummvm/scummvm/blob/master/engines/agi/view.cpp

Turns out this fix goes all the way back to Sarien (which was imported to ScummVm), some 18 years ago:
https://github.com/cmatsuoka/sarien/commit/2e38cdc

I suspected as much. It wouldn't have taken long to see the issue in KQ4, in fact its right there in the first room.  I like the commit comment.   

[lance.ewing]

ScummVM does use an abbreviated MD5 check (from the first 5000 bytes), usually on the logdir file for AGI games to determine not just the game, but the game version as well. I used this for my Sierra game version detector tool. Wouldn't such an approach cause a problem with using it on the fly to run a new game, especially one still under development where the target file for the check would be constantly changing.

I've decided to go with simply the Game ID check for now, i.e. "KQ4" in this case. Its the same string they use when building saved game filenames. It seems that there is no need to check the specific AGI version because KQ4 was only released with the one version of Interpreter as far as I know.

[AGKorson]

Which interpreter version does your KQ4 game use? If it's 3.002.102, that version included a new reserved flag, f20, which if set would allow views with more than 4 loops to automatically choose loops without problem. Could that be the problem you've encountered?

[lance.ewing]

Yeah, that would definitely explain it. Let me check the version...  its 3.002.086 apparently, but it certainly behaves differently with regards to the automatic loop choosing than what AGI V2 does. Is it possible that f20 feature is there for all of AGI V3? I haven't checked yet whether f20 is set at this point in the version I have, but will do soon.

[lance.ewing]

I've checked this now, and flag 20 is not set. So I guess that agrees with the fact that only 3.002.102 and above use flag 20 for controlling this.

Version 3.002.086 must be doing something similar but not controlled by flag 20.

[Collector]

For PC I am aware of only three versions of the game; 2.0, 2.2, and 2.3, but all use 3.002.086. The demo uses 3.002.102.

Do the Easter eggs in 2.0 work OK in your interpreter?

[lance.ewing]

I assume they would. I've tried a couple of the easy to get to ones, and they work. I haven't played through much of KQ4 yet though.

I'm looking at my list of known issues at the moment. For some reason saved games don't work at all in Gold Rush. It completely ignores it when I select Save game in the menu. Really weird. I guess as soon as I start debugging that, all will become obvious.  That's probably the main one at the moment, but I haven't played through much of any game other than KQ1 so far.

[Collector]

Gold Rush seems to be another one that has multiple versions, but all use the same interpreter, 3.002.149.

[AGKorson]

I've checked this now, and flag 20 is not set. So I guess that agrees with the fact that only 3.002.102 and above use flag 20 for controlling this.

Version 3.002.086 must be doing something similar but not controlled by flag 20.

If you have verified that it works correctly with the original DOS interpreter, I would love to get a copy of that interpreter file; I've decompiled all AGI versions that I have, including all v3 versions. I can confirm that only 3.002.102 and above use flag 20. I've examined the code in the 3.002.086 version I have, and there is nothing there that I can see that would change loops (without specific code in the logic), so I would love to know if the interpreter file I have is authentic (the date/time stamp is 8/31/1988 12:38PM). Would you mind sharing your file?

Also, I don't have access to my original disks (I'm on temporary assignment for work away from home for several months). Could I ask for a copy of the game files for your KQ4 version as well?  Thx!