Messages

256

The Games and other Sierra Adventure stuff / Re: Mage's Initiation released (Sierra-style Adventure/RPG)

« on: January 31, 2019, 05:45:03 PM »

Congratz! I will have to try it out.

257

AGI Development Tools / Re: Need Testers for WinAGI

« on: January 24, 2019, 11:09:00 PM »

I've gotten a few comments back, but I was hoping to get more by now. If anyone who's testing has any feedback, I'd love to hear it.

In the meantime, I have a question for you all - it's been suggested that a synth instrument such as 'Lead (square)' (instrument #80) would be a better default MIDI instrument for sounds than 'Grand Acoustic Piano' (instrument #0). Does anyone have any thoughts on that?

258

AGI Development Tools / Re: Musings on Original AGI Game Source Code

« on: January 13, 2019, 07:10:01 PM »

These problems led to the cancellation of the IIx project, but later, a new project was formed to produce an updated Apple II. This project, which led to the released IIGS, was known by various codenames while the new system was being developed, including "Phoenix", "Rambo", "Gumby", and "Cortland".

https://en.wikipedia.org/wiki/Apple_IIGS#Development_and_codenames

Thx! When I searched google with the terms "cortland" and "computer", I got no hints that it was related to Apple.

Stupid Google.   

259

AGI Development Tools / Re: C# AGI Interpreter

« on: January 13, 2019, 05:13:13 PM »

Sierra's original PICTURE editor must have allowed them to draw down to 168, perhaps as a result of a bug maybe? Given this issue is in KQ4, maybe it was one of their later PICTURE editors. This issue doesn't seem to be in any other game that I've noticed so far.

I have 2 versions of Sierra's PICTURE editor: PIC.EXE (1987-02-23) and PE.EXE (1987-05-28).
I did not check them out yet, but you are welcome to do so: I just released my stash of AGI tools in this thread: http://sciprogramming.com/community/index.php?topic=1814.0

Thx Omer. Maybe I will try to decompile these to see it there is a bug that allowed a Y value of 168 to slip in.

260

AGI Development Tools / Re: C# AGI Interpreter

« on: January 13, 2019, 05:03:35 PM »

For those pictures where the 0xF7 relative draw tool is drawing down to Y = 168, I'm not 100% sure what to do. If I remove the validation check, then they load fine and render fine in my Interpreter, but then that means we're allowing an original Sierra game to violate rules that our own editors enforce. Sierra's original PICTURE editor must have allowed them to draw down to 168, perhaps as a result of a bug maybe? Given this issue is in KQ4, maybe it was one of their later PICTURE editors. This issue doesn't seem to be in any other game that I've noticed so far.

As I mentioned earlier, in the interpreter, the position is converted to a linear offset in the picture memory buffer (pos = 160*y+x). The interpreter doesn't bother checking either X or Y; so when the offset exceeds the actual buffer size, AGI just sets that byte in memory even thought it's a buffer overflow. But since the picture buffer is the very last hunk of memory that is allocated, it doesn't overwrite any AGI data. So it looks just fine in AGI.

In WinAGI, I just do a check every time a pixel is plotted. If the linear offset exceeds the buffer size, I just ignore it. That way the picture will be rendered the same as in AGI.

261

AGI Development Tools / Musings on Original AGI Game Source Code

« on: January 13, 2019, 04:57:24 PM »

I spent a lot of time going through the samples of game source code that Omer provided in this post.

Here are a few random things I gleaned from those files:

-  Their coding style and even syntax varied quite a bit from game to game; Al Lowe appears to have preferred camelCase, and also had his own set of preferred names for some of the commands. Other programmers used the dot.separator style. All of the examples were consistent in using ALL_UPPER_CASE for defined numerical constants

-  Command names used in source code were defined on a game by game basis; apparently the compiler did not use text values for game code- the preprocessor is where command names got converted to numbers.

-  In one game, 'variable' commands (for example isset.v, print.at.v) were actually defined with an 'f' (isset.f, print.at.f). I wonder why they used an 'f'?

-  increment and decrement functions used 'pre-assignment' syntax (++v1, --v1) not 'post-assignment syntax (v1++, v1--). Since you can't write complex statements in AGI script it doesn't really matter. (WinAGI handles either syntax.)

-  All of the examples were consistent in the naming conventions for resources; prefix of 'r' for logics representing a location, 'lgc' other logics, 'm' for sounds designated as music, 's' for sound effects, 'v' for views.

-  logics not associated with a location (not a room) were consistently referred to as 'dynamic'.

-  The file extension for logic source files was 'CG'. I tried to think what that might refer to, but I can't think of anything. Anybody have a guess as to why 'CG'?

-  All the examples had comments that identified variable and flag numbers 0-29 as 'use by compiler only', 220-239 as 'local variables and flags', used by rooms, and 240-255 as 'dynamic', used by 'dynamic logics'. Most of them had a check so that whenever the new room flag was set, these variables and flags would be reset.

-  Local and dynamic flags and variables were given relative number values. For example, a variable might be defined as '#define thisVar lv0'. They included a header file that would convert 'lv0' to 'v220'. It worked, but that seems like a bit overcomplicated; why not just define it as v220?

-  They all say that numbers 0-29 are for use by compiler only, but we know that not all of them were actually in use. Looks like they wanted to make sure they had room to grow (but then never did, eventually switching to SCI.)

-  Although the style varied, the names for reserved flags and variables was consistent. (I have updated WinAGI to use the values listed here as default names instead of the fan-created names that have been around forever.)

-  In addition to allowing testing of flags by using just the flag ('if(f10)' is compiled as 'if(isset(f10))'), their compiler would also allow testing of variables ('if(v10)' would compile as 'if(greatern(v10,0)'). I'm looking at adding support for that syntax to WinAGI.

-  None of their logics include a return() command at the end. Apparently the compiler would add that automatically. I prefer enforcing it to make sure the programmer really meant the logic was done.

-  Their room logics were all very well structured; the initialization section at the top, a section for handling input, a section for non-input things, and then checking for room exits at the end. I'm going to try and redo the template game to match this structure

-  In their source code, words in the said() command were not enclosed in quotes, and dollar signs ($) were used as spaces. So 'said( dirty$word, rol)' instead of 'said( "dirty word", "rol")'

-  Based on their coding and comments, only Tandy computers used volume controls. I didn't know that; I assumed all non-PC systems could adjust volume. And they used the names 'crescendo' and 'decrescendo' for their volume controllers - I wouldn't have figured their programmers to be so 'sophisticated'.

-  In their game defines file, they all had a name of 'error' defined as a value of '-1'. This suggests their compiler could handle negative numbers.  There's not much use for negative numbers(the reposition() command is the only command that used them), but apparently they could use them if they wanted to? BTW, WinAGI will allow use of negative numbers (converting them to the appropriate 2s complement value) to make working with the reposition command easier.

-  In their list of constants for machine type, all the examples include 'CORTLAND', assigned a value of 8, but with a question mark as a comment. In AGI Specs, the value of 8 is identified as 'Apple IIgs'. The Cortland is a variety of apple, derived from the McIntosh. So I wonder if 'CORTLAND' was a pre-release codename for the Apple IIgs (or even some other computer from Apple). I find that interesting from a historical perspective.

Here are a few comments I found in the examples that I found entertaining. It must have been fun working at Sierra back in those days.

In Black Cauldron:

Code: [Select]

%define ego.is.a.dead.mother df1 [ the end
.
.
[*****
:no.input
:no.fucking.input
:also.no.mother.fucking.input
[*****
In KQ3:

Code: [Select]

current.status = sleeping; [ nightie, night sweet ego
.
.
if (ego.location == 9) [ do the "get out of bed" schtick
.
.
if (!edge.ego.hit && ego.y < 20) [ sweep up after Jeff's bugs
.
.
load.logics( lgc.PO'd.wiz); [ Bring on that little wizzer!
In PQ:

Code: [Select]

if ((said( show, belt) || said( show, gun))) [ Funny, you don't look Oriental!
Oh, in KQ3, the phrase to enter debug mode was originally 'rat shit', not 'rats ass'. Although due to synomyms 'rats ass' works, the source code clearly shows 'rat shit' is what was intended.

262

AGI Development Tools / Re: C# AGI Interpreter

« on: January 13, 2019, 12:28:50 PM »

Thanks for solving that mystery. That definitely explains it then. Looks like I will have to add specific version checks in there to make it truly compatible.

The one thing I've learned after all this time studying AGI is that Sierra was terrible at error checking and that a lot of their code (in the interpreter) was a bit sloppy in handling non-standard data. When opening Sierra games you gotta check for a whole bunch of things that can cause problems.

For example, when I loaded KQ4 yesterday, I found there are four resources (picture 150, 151 and view 198, 199) that point to non-existent VOL files. And there are five pictures (2, 10, 15, 102, 115) that have bad data for pixels (using a Y value of 168 occurs a bunch of times in all those pictures). Sierra's interpreter will happily overflow the picture buffer without complaining (the stuff that gets overwritten is whatever is beyond the picture buffer in memory, which is not even allocated to the program!). So they display with no visible effects, but if you want to draw them in a new interpreter or editor, you have to account for that.

263

AGI Development Tools / Re: C# AGI Interpreter

« on: January 13, 2019, 03:00:34 AM »

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.

I found it! It's a bug that's unique to version 3.002.086. Here's the code in v2.917 (which is identical in all versions up to 3.002.086:

Code: [Select]

   mov     [bp+newloop], 4                    ; set newloop value = 4(means no loop change)
   test    word ptr [si+flags], FIXED_LOOP    ; fixed loop?
   jnz     short setTheLoop                   ; if fixed, don't change loop
   cmp     byte ptr [si+loop_count], 2        ; loop count
   jz      short autoloop_sm                  ; if 2 loops, jump to small-loop selector
   cmp     byte ptr [si+loop_count], 3
   jnz     short autoloop_lg                  ; if three, also use small loop selector
                                              ; but if NOT three, go on to further check
autoloop_sm:
   mov     al, [si+obj_dir]                   ; use object direction
   sub     ah, ah
   mov     bx, ax                             ; to
   mov     al, loop_small[bx]                 ; convert direction to correct loop
   jmp     short changeLoopVal

autoloop_lg:
   cmp     byte ptr [si+loop_count], 4        ; if loop count != 4
   jnz     short setTheLoop                   ; don't change the loop
   mov     al, [si+obj_dir]                   ; if loop count == 4
   sub     ah, ah                             ; use object direction
   mov     bx, ax                             ; to
   mov     al, loop_large[bx]                 ; convert direction to correct loop
changeLoopVal:
   mov     [bp+newloop], al
setTheLoop:
...   ; change loop if newloop value has changed (!= 4)
In 3.002.0086, they made one very small change (marked with ***):

Code: [Select]

   mov     [bp+newloop], 4                    ; set newloop value = 4(means no loop change)
   test    word ptr [si+flags], FIXED_LOOP    ; fixed loop?
   jnz     short setTheLoop                   ; if fixed, don't change loop
   cmp     byte ptr [si+loop_count], 2        ; loop count
   jz      short autoloop_sm                  ; if 2 loops, jump to small-loop selector
   cmp     byte ptr [si+loop_count], 3
   jnz     short autoloop_lg                  ; if three, also use small loop selector
                                              ; but if NOT three, go on to further check
autoloop_sm:
   mov     al, [si+obj_dir]                   ; use object direction
   sub     ah, ah
   mov     bx, ax                             ; to
   mov     al, loop_small[bx]                 ; convert direction to correct loop
   jmp     short changeLoopVal

autoloop_lg:
   cmp     byte ptr [si+loop_count], 4        ; if loop count ***<*** 4
   ***jb***      short setTheLoop             ; don't change the loop
   mov     al, [si+obj_dir]                   ; if loop count ***>*** 4
   sub     ah, ah                             ; use object direction
   mov     bx, ax                             ; to
   mov     al, loop_large[bx]                 ; convert direction to correct loop
changeLoopVal:
   mov     [bp+newloop], al
setTheLoop:
...   ; change loop if newloop value has changed (!=4)
The change in that test from 'jnz' to 'jb' has the effect of always changing the loop no matter how many loops are in the view. In version 3.002.098 (not 3.002.102, as I previously thought), the check for flag f20 was added which fixed the problem.

The upshot of this is that for all versions up to 3.002.086, objects assigned a view with more than 4 loops will not update loop based on direction; in version 3.002.086 objects will update loop based on direction no matter how many loops there are; and in versions beyond 3.002.086 objects with more than 4 loops will only update loop if flag f20 is TRUE.

264

AGI Development Tools / Re: C# AGI Interpreter

« on: January 11, 2019, 05:17:29 PM »

Also, is your source code available for your C# interpreter? I'd be happy to take a look at any sections where you have questions/concerns; I might be able to find issues quickly based on my decompilation efforts.

265

AGI Development Tools / Re: C# AGI Interpreter

« on: January 11, 2019, 05:15:24 PM »

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!

266

AGI Development Tools / Re: C# AGI Interpreter

« on: January 10, 2019, 06:32:34 PM »

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?

267

The Games and other Sierra Adventure stuff / Re: Al Lowe reveals his Sierra source code collection—then puts all of it on eBay

« on: December 26, 2018, 06:04:57 PM »

Here are some samples from a few AGI games: https://drive.google.com/open?id=1HSI3RiZPYszjLPbZM9k-Zyuo4uHqd1id
The syntax is game specific and defined in their source.

Thank you for this! I'll probably spend weeks going over these samples in detail! I'm pleased that at first glance, all of the things I learned about variables, flags, commands, etc. by decompiling the interpreters appears to be accurate based on what I see here. And I also noticed that they used defines to refer to their resources (rooms, logics, views, sound, pics) which is emulated in WinAGI by the ResourceID property.

268

AGI Development Tools / Re: Need Testers for WinAGI

« on: December 26, 2018, 05:13:32 PM »

I've fixed the first couple things that have been pointed out so far. And I'm continuing to do my own testing (and found a few more minor issues). Things are progressing well. I hope to get more feedback from testers soon.

In the meantime, after thinking more about the snippet of original source code from Leisure Suit Larry (in another post here), I am thinking about tweaking the syntax used in WinAGI.

I am strongly considering dropping support for block comments (i.e. '/* … */'); I get the impression that block comments were not an option for original AGI source - it appears the square bracket '[' was the only comment token in use. AGI Studio included the bracket token, but also added the double slash token ('//') as well as block comments. If these were not in original AGI source, I'd like to take them out of WinAGI.

But I also have another reason to eliminate block comments - it will significantly improve performance of the rich text editor. There are no existing rich text editor controls available for VB (either as native OCX files, or other object that I can use API calls on) that have all the features found in modern code editors (most importantly syntax highlighting); I had to write a custom control. It works pretty well, but with large logics, the potential existence of block comments really kills performance (because the control has to re-highlight everything on each edit in case a block command was added or deleted - perhaps a smarter programmer could figure out how to make it work more efficiently, but I've run into a wall with this).

If I were to drop support for block comments performance would not suffer at all (because I only have to reformat lines/text as it is entered, and only the lines that are affected). How big of a deal would that be? In the few fan game source files I've seen, I have not seen much use of block comments.

As a compromise, I am looking to add a 'block comment' feature that will add comment tags at start of all lines in a selection, as well as an 'block uncomment' feature to remove them (this seems to be a common feature in the few source editors I've worked with).

Are there any major objections to dropping support for block comments?

269

AGI Development Tools / Re: Need Testers for WinAGI

« on: December 26, 2018, 12:44:50 PM »

Hi Peter,

I'd love to have you test WinAGI. If it hadn't been for AGI Studio, I doubt I ever would have written WinAGI. so THANK YOU for that!

I'll send you a link to the install file by PM.

270

AGI Development Tools / Re: Need Testers for WinAGI

« on: December 20, 2018, 01:45:02 PM »

You can get rid of those warnings by changing error detection to Low. The compiler won't complain unless it is unable to generate valid code; only a few 'critical' warnings ever get displayed.  Error detection level is set on the Logics Tab in Settings.

But I prefer using the Ignore Warning feature; you can individually ignore a particular warning that you don't want to see again. In the Warnings window, you can right-click a warning, and choose 'Ignore Warning', and the compiler will never show you that warning again. Use the 'Reset Message Box Warnings' option if you want to re-enable previously ignored warnings.  (Oh, and if you double-click an error or warning, WinAGI will automatically bring up the affected logic and highlight the line where the warning/error occurred.)