New compiler: Is it worth my time?

[Mokalus of Borg]

I've just completed my preliminary work on the new AGI compiler I proposed a while ago, and it seems there are only three potential benefits:
1. Compile-time allocation of variable/flag/room numbers.
2. Evaluation of more complex Boolean expressions.
3. while() loops.

So, here's the question: If I (or a team) go ahead and attempt this, are the benefits going to outweigh the costs (time it takes me to write it, beta-testing and debugging, adapting to some new syntax)? To help you decide if you really need this, I'll release what I've got so far: Chris Cromer's template game, translated into the new syntax. Here's the link (sorry about the Angelfire popups). It's not perfect, but it gives a good idea of what a game written in the new syntax would look like.

Mokalus of Borg

PS - I think it would help a little.
PPS - But not much more than good coding practices would.

[Brian Provinciano]

The current AGI compiler, though a high-level language compiler, it still pretty much a bytecode assembler. The code it produces is pretty much a direct representation of the code you write. Because of the way it was designed, this is really the only way you could do the lanuguage. If statements, for example, are handled totally by the interpreter. It reads opcodes for IF, ELSE, OR, AND, NOT, ENDIF, etc. The only way to make more complex if statements would be to have the compiler write your own routines with gotos.

If you're interested in making your own compiler, I think it would be a great idea, just to do it for fun. An AGI compiler would be very simple, and only take about a week to finish completely.

It pretty much just compiles.
foo(1 2 v3)
to
$xx $01 $02 $03.

It's as simple as that. Then, you add nice things, like the ability to directly use strings in functions rather than having to declare them, then use their labels.

All in all, I think it will be a fun project for you. Maybe you could play around by giving it a different language front end? It's currently based off C, maybe you could base it off Pascal or something?

There is one missing feature that would be handly to add... functions! Just use some gotos and rets to create a structured programing lanuguage!

[Joel]

As I said before, my primary interest in any new syntax would be the addition of minor things that are missing from the current syntax while leaving the current syntax more or less intact.

Switch statements would be more convenient than a series of if statements, even though the compiled code would probably look the same. And, as I suggested earlier, the object-oriented syntax as opposed to the function with call with the object as a parameter would be a little cleaner, I think, but even that's not really needed.

I agree that having the completely new syntax wouldn't help much more than having good coding practices (particularly because of all the limitations of AGI as discussed when this topic came up before).

I thought the plan was to implement the slightly modified syntax first and then do the completely new one. I understand that's an additional time investment, but as I said I'm not likely to switch languages in the middle (so the new compiler wouldn't have much value to me). But if this new compiler had a compatible language with the current language and implemented whatever communication interface we come up with for utilities to talk to AGI Studio so that I wouldn't have to go to great additional effort to use the thing, then I might use it for my current projects.

Obviously, if you're just interested in appealing to the newer AGI programmers and not worried about people who already have projects underway, then it's not all that important to go the compatible route first.

[Brian Provinciano]

I agree that the syntax should be the same.

Functions and switch statements would be handy, but I really don't think it's a good idea of making an OO AGI compiler. AGI is really not versatile enough to be efficient and object oriented at the same time.

The fact is, SCI is unbelievebly verstile. It uses a virtual machine with a stack, opcodes, heap, hunk, and everything else a computer has. It's designed to be 100% object oriented and can't be used any other way. It's so versatile, that it could be used to make pretty much any kind of game. If you want an object oriented Sierra style game, I really think you should use SCI.

It's here! I've finished coding the entire template, all 26 scripts (plus the game scripts such as the title screen, first room, etc.). All I need to do it fix some errors, clean it up, and document it.

SCI is so much like a real computer, one could write a compiler for it that uses virtually any language out there.

Starting from the templates, SCI games really aren't that much more complicated to make than AGI games.

[Joel]

What I mean by object-oriented syntax is things like

ego.draw();
ego.position(50, 120);

instead of

draw(ego);
position(ego, 50, 120);

I don't mean having any actual class hierarchy or anything like that.

Although I'm certain I could handle programming an SCI game if I spent a little time learning the syntax, and from what I have seen SCI does seem to be a great deal more powerful than AGI, what I probably wouldn't be able to do is draw decent graphics at that resolution. AGI also seems a little more stable in terms of continuing to work just fine even as computers get faster and faster and hardware changes. SCI seems to have lots of problems on modern computers.

[Chris Cromer]

I don't think SCI0 had those timer problems on faster computers(that I know of.) All of the problems with SCI and new computers seems to be with SC1.

[Brian Provinciano]

The problems I know of are really only in SCI11/SCI2/SCI32 games.

The only problems with SCI0 and SCI1 on newer computers are certain sound drivers not working under WindowsNT(XP). Of course, you can download the excellent drivers made by Ravi such as his General Midi one, which works perfectly under WindowsNT.

You can also use FreeSCI.

[Mokalus of Borg]

I thought the plan was to implement the slightly modified syntax first and then do the completely new one.

I started trying to modify AGIC into what I called "AGIC++", by adding loop constructs, but it turned out to be much more difficult to modify than I'd anticipated. That's why I started translating the template game into a new syntax. The main problem I see with AGI is keeping track of which variables are available and which are free, and that was one of the problems I wanted to address with a new compiler. Maybe I still will, but I think, for now, this will remain a second-priority project for me.

Mokalus of Borg

PS - I'll get back to work on AGI2SCI, I guess.
PPS - Thanks for the comments, guys.

[Chris Cromer]

What we really need is the logic2script part of the AGI2SCI project. I think that is the most important thing that needs to be done.

[Brian Provinciano]

Logic2script wouldn't really work. They are too different. If some kind of converter was made, it would be pointless since you'd only get the capabilities of an AGI game in the SCI game. In that case, you may as well stay with AGI or start new in SCI. Sierra didn't convert anything. All their remakes were done from scratch.

I remember when I did my old AGI2SCI picture converter. The output was essentially a 160x168 image. The lines were doubled and the bottom was cut off.

Recoding an AGI game into an SCI game would be a lot easier than creating some kind of converter.

Like I say though, whether it's possible or not (anything's possible), why would you want to play an SCI game with AGI logics, AGI pictures, AGI views, etc.? A nonstructured, nonobject oriented, 160x168 SCI game?

The logics couldn't be converted by any simple means. You'd need to decompile the AGI logics into source files which are then modified to fit into an object oriented interface and be recompiled into an SCI script. Converting AGI logics to SCI would be like converting SCUMM scripts, AGS scripts, or any other scripts of that sort. They are all completely different.

If you want to improve your AGI experience, try out Sarien with the advanced picture drawing capabilities and mouse driven motif UI.

[Mokalus of Borg]

My plan for the logic2script part of AGI2SCI (bizarre and unnecessary though the whole project is) was to write an AGI-like environment for the SCI engine, and output uncompiled SCI scripts (no sense in duplicating Brian's compiler work). I don't know if it would work too well, though.

Mokalus of Borg

PS - I started AGI2SCI because I prefer the way SCI works as opposed to the AGI system.
PPS - And I thought it might be cool.

[Brian Provinciano]

Yeah, that's the same reason I did the AGI2SCI picture converter, for the heck of it

However, my main concern is that:
a) It would be much beter just to convert it to SCI by recoding it (it wouldn't be that much work).
b) If there's a working AGI2SCI converter, we'll get a load of poor quality SCI games.

[Mokalus of Borg]

Hmm. I hadn't thought of the possibility that it would degrade the general quality or perception of the SCI engine. Maybe I should just write a guide on recoding AGI games for SCI.

Mokalus of Borg

PS - Of course, that means I'll have to learn how to do it myself...
PPS - Yah, it can't be that hard.

[Chris Cromer]

Well maybe a sound converter then Mokalus? There aren't any sound tools(that I could get to work for SCI) so maybe and AGI to SCI sound tool would be usefull.

[Mokalus of Borg]

A sound converter is part of the plan, and I'll get to it sometime soonish.

Mokalus of Borg

PS - Oh, what the heck, I'll start now.
PPS - But it could take me a while, 'coz I tend to work slowly.