Topics

1

AGI Development Tools / AGI Player by Hugues Valois

« on: January 12, 2019, 05:31:21 PM »

Back in 2017, you might remember that I discovered that I wasn't the first person to write an AGI Interpreter in C#. Hugues Valois had already beaten me to it. I found his website with various pictures of his Interpreter and editors, but I couldn't find any links to the application.

Well this evening I thought I'd have a look again and it appears that he has put all of his code up on github 22 days ago, along with a first release build:

https://github.com/huguesv/AgiPlayer

https://github.com/huguesv/AgiPlayer/releases/tag/v1.0.0

http://www.huguesvalois.com/ProjectsAgiPlayer.aspx

I haven't tried it yet, but I probably will at some point tomorrow. Looks amazing.

2

Everything-Else / Thimbleweed Park released this week

« on: March 26, 2017, 11:24:46 AM »

Eagerly awaiting the release of Thimbleweed Park in about four days. Looks like it will be a lot of fun.

With it being the 30th anniversary of Maniac Mansion later this year, I'm hoping that the team working on Meteor Mess 3D might also target this year for release. That game looks pretty cool as well. The web site claims it is coming out this year.

I was thinking the ultimate would be if they could use those 3D models to create a VR version of the Maniac Mansion game. Imagine that, a full VR adventure game. There are a few people working on the concept, but nothing completed yet that I've seen. I was playing Whispering Eons and Alien Apartment recently on my Android phone with a VR headset and was thinking that this is truly the pinnacle of adventure games. Felt a bit dizzy playing them, but it has a lot of promise.

3

AGI Development Tools / agi.js

« on: March 07, 2017, 01:49:26 PM »

I noticed this last night. Looks quite interesting:

https://github.com/r1sc/agi.js/blob/master/README.md

I haven't given it a go yet. A quick skim of the code reveals a lot of commands not implemented. I think this might be the first actual JavaScript AGI interpreter. There's sarien.net but AFAIK that's a conversion to JavaScript rather than an interpreter.

4

AGI Syntax Help / Non-standard or obscure/undocumented AGI features

« on: February 27, 2017, 02:06:38 PM »

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.

5

The Games and other Sierra Adventure stuff / Mega Tokyo AGI forums backup

« on: December 27, 2016, 12:20:33 PM »

That is old enough for the old MegaTokyo forums. If only they were still accessible.

Stuart George has a backup from 2004 that he says he'll check the contents of before handing over. Apparently it is a dump of the whole DB.

Stuart George has sent through a backup of the old Meka Tokyo forums data, i.e. the backup referred to in the quote above. I haven't yet had a chance to look at the data, but I thought I'd get the discussion started about what we think would be the best way to make this available again on the Internet in read only form. It would be ideal if it could be included as part of this sciprogramming site, but I'm not familiar with hosting forums and forum software, so not sure what would be involved and whether that would technically work out or not. Does sciprogramming.com use the same forum software?

I'll take a look at the file now and see what the names of the DB tables are.

6

AGI Development Tools / C# AGI Interpreter

« on: December 04, 2016, 03:56:08 PM »

Well I've finished the C# tutorial app that I've been working through on my phone over the past few weeks. It hasn't just been the tutorial though. As I've mentioned, I converted the VVVV game to C#, but I've also started to put together the beginnings of a C# AGI interpreter, something that I began about a week ago while I was still working through the tutorial.

What I've done is to fork the AGI/SCI Developer code base. I've forked it for a few reasons: One is because it might be dangerous for me to start contributing to the real thing at the moment. I figure that I can prototype something on the forked repository and then if I actually get something working, Collector can pull that back in to the main project. The other reason is so that I can make use of the AGI Library that comes with the AGI/SCI Developer. It already has code for loading the game data. It's structured for the purposes of the Editor, but it isn't far off what I'd need for the Interpreter. And it makes sense that if the Interpreter is to be integrated in to the editor that it uses the same classes for holding the game data so that the editor simply says "Here's the game data...  Interpret it!!"

Initially my plan was to port MEKA to C#, but that has evolved to some degree. What I'm now doing is looking over four sources of information as I build each component, those sources being the original AGI source code fragments, the original AGI documentation, the MEKA source code, and the AGDS documentation (i.e. the Russian project, which has quite a detailed explanation about the workings of the interpreter cycle).

I'm starting to the look at the AGI source code fragments very closely now and it looks like it has pretty much the complete animation code. There isn't anything missing in that area. I should be able to replicate the animation side of things quite well. It also includes the main top level interpreter cycle loop, but lacks the code for the execute logic routine. We can pretty  much guess what that does though, and there's quite a high percentage of the individual test and action commands represented in those original AGI source fragments as well. It's more complete than I originally thought. The C# project will be an object oriented representation of this logic.

I have yet to implement a single test or action command. I'm trying to lay the foundation first, which at the moment is working on the top level interpreter cycle and the animation code. Soon I'll be ready to dive in to the execution logic routine, but to be honest, its going to be weeks before I actually try to run it.

7

Everything-Else / Adventures in C#

« on: November 25, 2016, 05:19:03 PM »

As mentioned in another thread, I'm going to attempt to teach myself C# over the coming months, with a goal to eventually fully port my old MEKA AGI interpreter to C#, thereby hopefully making it useful to the Visual AGI project. I'm also hoping to pick up some experience that will then make me useful in contributing to other parts of the Visual AGI project.

I've got some experience with writing a few simple games in Java, JavaScript, and way back in the late 90s, in C. I've also written a few VIC 20 emulators, the first in Pascal, then in C, and then in Java (the first two also having some assembly code included).

One of the first things I start thinking about when picking up a new language is how I'd implement the game loop. The emulation loop used in the emulators is similar in many ways.

What I started looking at in the case of C# was how to get direct access to the pixels of a Bitmap as an array of ARGB values. Turns out it wasn't as difficult as I was expecting. When I ported my Java VIC 20 emulator to use the libGDX library so it could run on Android, I had to work with an abstraction of OpenGL, which when you want to update every pixel on the screen on every frame is actually not as straight forward as you might think. The GPU doesn't really want to help you when you intend sending it a whole screen full of pixels on every frame.

I don't know what's happening under the hood with this approach, but the following is what I've found through Googling on C# and direct access to Bitmap pixels:

http://stackoverflow.com/questions/24701703/c-sharp-faster-alternatives-to-setpixel-and-getpixel-for-bitmaps-for-windows-f

The first answer works fine for me. The Bits array gives me exactly what I want. I've currently got a little window running in Visual Studio with coloured pixels being placed in random positions.

8

AGI Development Tools / Java AGI Interpreter by Dr Zoltan

« on: October 24, 2016, 05:51:16 AM »

Does anyone happen to know who Dr Zoltan, the author of the following AGI Interpreter, was?

https://sourceforge.net/projects/agi/

It seems like Dr Zoltan did a lot of work on this project back in 2001, but then nothing since. I first noticed it many years ago, but hadn't really taken much of a look until yesterday evening, when I fixed it to compile with Java 8. I then loaded up KQ1 and KQ2 to try them out. There were clearly a lot of bugs still outstanding, but it seems like it wasn't too far off being usable.

I'd hate to see something like this left to gather dust. So given that Java is my language of choice these days,  I'm going to see if I can add my Apple II AGIv1 disk decoder utils/tools as a package to this project. I'm not too keen to add to sourceforge though. Would rather use github. Thus the reason I was wondering who Dr Zoltan was. I'm keen to make contact with him and see if he doesn't mind me adding the project to github. I might even see if I can fix some of the bugs. We have a lot more information these days on how AGI worked, thanks to the original documentation and interpreter source code fragments, and thanks too to scummvm's code base.

9

The Games and other Sierra Adventure stuff / What was the original King's Quest PCjr release date?

« on: October 22, 2016, 03:42:09 PM »

Does anyone happen to know what the exact release date of the original IBM PCjr version of King's Quest 1 was? Clearly it wasn't July 1983 as Wikipedia might have us believe . The best evidence for this is this magazine article:

https://books.google.co.uk/books?id=kSzKzjWHeVEC&lpg=PA61&pg=PA142&redir_esc=y#v=onepage&q&f=true

So in January 1984, Roberta is saying in that article that she has only just finished the game for the PCjr. The IBM PCjr itself had only just started shipping when the above magazine article was published (apparently PCjr shipping was very slow at first and didn't ramp up until about March 1984). It is clear from the wording of the above article that the game wasn't yet available in January 1984. All the stories around the release of King's Quest suggest that it came out first on the PCjr, and then when this was a failure, Sierra refocussed on the other platforms, like the Apple II, standard IBM PC, and the Tandy 1000 (that apparently came out at the end of 1984). Perhaps the 1983 date has relevance to some kind of internal release to IBM, but clearly there was no public availability of the game until 1984.

In Chuck Tingley's LinkedIn profile, he says he was contracted by Sierra to work on King's Quest from January 1983 to May 1984.The February 1985 article about King's Quest says that Sierra were told about the IBM PCjr about a year before the announcement of the IBM PCjr. This announcement happened in November 1983, so a year before that would have been either the end of 1982, or the start of 1983. Chuck's arrival at Sierra would align with these dates then. So Sierra spent the whole of 1983 working on King's Quest.

The July 1983 date seems to come from Sierra themselves:

http://www.sierrahelp.com/Documents/Manuals/Kings_Quest_Collection_-_Manual.pdf

...but the year must be a typo. Surely the month must be wrong as well. I would have expected it to come out earlier in the year in 1984.

Has anyone been able to research this further and work out a month and year that King's Quest was originally released?

10

AGI Development Tools / Pre-AGI2 versions

« on: October 19, 2016, 05:49:09 PM »

How many AGI versions are we aware of prior to the introduction of AGI 2?

Recently I've seen:

v1.10: User by the Apple II version of King's Quest 2
v1.12: Used by the original booter PC versions of Black Cauldron
v1.20: Used by the Apple II version of Black Cauldron

I'm pretty sure there must be others.

What version of AGI did the original booter PC versions of King's Quest 2 use?

11

SCI Development Tools / Store with index opcodes (e.g. SAGI, SALI, etc)

« on: May 29, 2015, 08:10:14 PM »

The SCI specs say the following:

Example: "sagi 2" would Store the Accumulator in the Global variable indexed with 2 plus the current accumulator value (this rarely makes sense, obviously).

Rather than rarely making sense, I would suggest that this would never make sense, which would make the instruction useless. I don't have an issue with an instruction not being used if its useless. - There do, however, appear to be quite a few examples of these opcodes (store with index) being used in games (kq4, sq3, pq2, lsl3, and probably a lot of others). The sagi opcode is used 5 times in script 10 of PQ2, in fact we've got 2 in a row at one point:

Code: [Select]

pushi $7
ldi $1
sagi global[$d7]
pushi $7
ldi $2
sagi global[$d7]

Looks to me like it could be using the stack for the value.

The "sali" opcode seems to be far more common. There's around 44 examples in pq2 script 10 alone. I'm seeing something similar for "sali":

Code: [Select]

pushi $fe
ldi $2
sali local[$19]
push2
ldi $3
sali local[$19]
push0
ldi $4
sali local[$19]

I'm guessing that this is already known, possibly even been discussed before, but can someone confirm that this interpretation is correct? And if this is correct, then what does the "a" in "sagi" mean? And then how does "sagi" differ from "ssgi"? I haven't been able to find an example of "ssgi" yet, but given what the specs say, I would have expected the examples from PQ2 above to have been using ssgi instead of sagi. It seems like a more consistent interpretation of what the "a" and "s" mean. The "sag" opcode certainly appears to store the accumulator, but perhaps not "sagi"?

12

SCI Syntax Help / PQ SWAT source code mystery

« on: May 27, 2015, 07:18:25 AM »

I thought I'd create a separate thread specifically for discussions and theories in relation to the mystery of where the PQ SWAT source code snippet came from.

The first question I have in relation to this is that I noticed that PQ SWAT appears to have the script in a patch folder. I decompiled by hand the disassembly that SCI Viewer was showing me. Would it be showing me the patch version or the one from the main RESOURCE files?

What I might do is decompile the other one and see if that is a closer match for the original source snippet.

13

SCI Development Tools / LEA instruction

« on: April 21, 2015, 02:30:43 PM »

The following page is missing the number of bytes for the two LEA opcodes:

http://wiki.scummvm.org/index.php/SCI/Specifications/SCI_virtual_machine/The_Sierra_PMachine#The_instructions

It appears to suggest that both operands support a B and W:

op 0x5a: lea W type, W index ( bytes)
op 0x5b: lea B type, B index ( bytes)

...but that doesn't make much sense to me. The first operand would never need to be 16 bits.

I'm guessing Lars or Phil would know the answer to this?

14

The Games and other Sierra Adventure stuff / A sad state of affairs

« on: April 12, 2015, 11:48:02 AM »

Back about mid last year, I bought a book called 1001 video games that you must play. Some of you have probably seen it floating around in bookstores. I'm happy to see that text adventures and graphic adventures were not overlooked, but what I'm quite upset about is the almost complete lack of Sierra graphic adventures in this supposedly top 1001 games. The only one I could spot was Gabriel Knight 2. None of the other games that we loved to play are in there. You might think that perhaps graphic adventures were shunned by such a book, but this isn't the case. Almost all of the great Lucasfilm games are included: Maniac Mansion, Zak McKracken, all 3 of the Monkey Island games, Loom, Indiana Jones and the Fate of Atlantis, The Dig, Day of the Tentacle, Sam & Max. There is also Beneath a Steel Sky, Broken Sword: Shadow of the Templars, The Longest Journey, and Dreamfall. - No, instead it seems to be the Sierra games that have been shunned.

Surely King's Quest 1 released around 1983/1984 was a ground breaking game? It came out 3-4 years before Maniac Mansion. And what about the Space Quest and Leisure Suit Larry series? What about Quest for Glory? What about all of them for that matter. It just seems crazy that at least some of these games are not included, and yet most of the LucasArts games are.

A number of text adventures are included, such as Zork 1, The Hobbit, Planetfall, Hitch-hikers Guide to the Galaxy, Trinity, A Mind Forever Voyaging. So it isn't that the text parsing interface has been ignored; it's just that Sierra games have been ignored. It's like they've been wiped from the history books. I feel like my whole teenage life didn't happen.

15

AGI Development Tools / Visual Programming and AGI

« on: March 27, 2015, 06:35:09 PM »

This is something I've thought quite a bit about over the past couple of years. You'll all know about the Raspberry Pi I'm guessing, and the Scratch programming language that they're promoting on there for introducing kids to programming. Both my daughters have spent quite a bit of time playing around with Scratch, and I've dabbled a bit as well so that I can help them with their questions. It occurred to me how close the IDE for Scratch is to what we ideally need for AGI. It has sprites, background pictures, sounds. And it has the ability to write code by dragging and dropping blocks and joining them together like a jigsaw.

Snap is another one based on Scratch but with more powerful features. Scratch 1 is written in Squeak, Scratch 2 in Flash, and Snap is written in JavaScript. Due to it being written in JS, Snap is probably my personal favourite.

https://scratch.mit.edu/projects/editor

http://snap.berkeley.edu/snapsource/snap.html

Google Blockly is yet another one with the same concept, once again written in JS. And it supports building custom blocks.

https://developers.google.com/blockly/

Such an editor probably wouldn't work for SCI, but imagine an AGI editor where all of the commands were blocks. I really think it would work. And the bit that is exciting for me is that once such a thing was built, thousands of kids around the world would pick it up quickly, not to mention their schools and probably the Raspberry Pi foundation, and under the hood its all AGI based!  What a great way to bring AGI back to life. I think AGI has commands that are ideal for working with animated sprites. I tried making a walking man (controlled by the arrow keys) in Scratch and, although I succeeded, it was a bit of a mission. It's because the blocks and sprite editor isn't really geared around that type of animation. But with some tweaks to "retro"-fit the sprite editor with an AGI View editor, and the available blocks switched for AGI ones, ...  hey presto!

As I said in another thread, lots of ideas for projects but not enough time to work on them. I'm mentioning the idea in case someone else is inspired to fly with it.