Would a "higher level" AGI compiler be useful?

[Mokalus of Borg]

Nick, that format looks very similar to what I had in mind. Seems like we're on the same page.
Also, everyone, the idea here was either to add some nice new features to the existing language, which would be backwardly compatible, or to create a whole new language, which abstracts away much of the machine-level detail we have to worry about now. This would mean giving up backwards compatibility. The second path is really intended for brand-new projects, and attracting games programmers to AGI.

Mokalus of Borg

PS - Whether or not existing projects use it, it'll happen.
PPS - Yes, Nick, I do this all the time.

[Nick Sonneveld]

Joel's right though.. agi coding is time consuming and all of those projects currently in development aren't going to swap over to the new format overnight (and that's if it works properly to begin with!) so it might be more effective to add some backwards compatible additions to the original syntax (better preprocessor, control structures, varnames in Strings) and then develop a more up to date syntax.

- Nick

[Joel]

I think creating backwardly-compatible extensions first and then maybe a new syntax would be a better idea (although more work).

As for the compiler producing code where its temporaries started overwriting global data, that wouldn't happen if the linker were written well enough that it caught the error. I was just saying what could happen in a worst-case.

You're right in saying that the situation is no different from using #define -- if there's no more variables, then you're out of luck. But when you have to manually allocate all the vars, then you are very much aware of the fact that you're running out of vars well before you ever do. With the new syntax, it's entirely conceivable that somebody could start declaring away and only after a significant amount of work find out that AGI is incapable of handling the game they want to make (and, in fact, the only way to avoid this for sure is for the programmer to keep careful track of how many variables are still available, which the programmer doesn't even know because the compiler is allocating temporaries by itself).

[Nick Sonneveld]

I think that sounds like the plan...

I just thought if we were going to write a new syntax/compiler/linker to help allocate the scarce resources, we'd at least check if we had enough too. :)

The point you made about a coder not knowing they're running out of variables is a good one.  What did the old dos compilers do when the compiler discovers that you'll need a larger memory model?  I think the best way would be to have some statistics at the end of the linking:

number of variables used
number of variables in each state (global, "chapters", rooms)
number of variables shared
number left...

the same could be used for flags, views, pics, sounds, assuming none of them gets assigned a number until link time.  a warning could be displayed when the number free gets below a certain range.

If we really wanted to get speccy, we could have some sort of pre-link when the coder is writing the logic code to check the number of variables :)  I doubt this sophistication would happen though.. I'm not trying to promote vapourware here.

- Nick

[Nick Sonneveld]

btw.. was the compiler summary page useful?  if so, I'll move it to my dingoblue server at least until the agidev server is stable (easter!).  adding the one suggested syntax and other comments would be good too..  just want to know if it was useful first.

- Nick

[Nick Sonneveld]

Another thing.. (sorry about all the comments).. does anybody have any ideas on refering to variables defined in an external logic.. should we follow C's method of using headers/extern prototypes or should the linker just do it automatically by reading in all the objects at once?

it might help programmers because then they'll know they're refering to a global variable that exists, it would stop variables with the same name too.. but I just want to know if there's a better way than C's

course, we'd have to worry about scope too...

- Nick

[Joel]

I think reporting the statistics every time the program is linked would be a good idea. There is still a problem with function calls, however. With temporaries, the compiler can keep its own internal stack (a compile-time stack, more or less) and the game doesn't even need to know about it. With functions however, if they can call each other, you need a run-time stack. A run-time stack can, of course, be done, but the amount of information needed for function calls might make the ability to call functions from functions infeasible. For one thing, in order to return from a function call, you need to be able to jump back to the exact location from which the function was called, which means you need a record of the the next instruction that should execute after the function returns. If functions are not implemented as a separate logic invoked with a call() command, then going back through the call stack would be complicated at best, because goto commands take 2-byte values and all the vars are 1 byte. It may not even be possible. Also, the functions could presumably be defined to take different numbers of arguments (I won't even discuss different types, which would add even further to the complication), in which case you'd need an environment pointer variable and an environment pointer field in the activation record for a function (i.e., more variables not available for the game), so that you'd know where the previous activation record starts on the stack.

Actually, the more I think about it, the more I'd say that functions should not be able to call other functions. It would be too easy to fill up the stack, so the feature would be practically useless.

A run-time stack would also be dangerous for overwriting data(although, again, writing the compiler well would prevent it from going on unchecked). The thing is that any time a function was called, the compiler would need to make sure there was enough space available on the run-time stack (which could only be done at run-time, obviously) for the activation record. If not, the game might as well crash, because it's unlikely that the function call can just be ignored with proper results.

[Nick Sonneveld]

Considering the limitations of the variables, if you're going to spend all those resources to initialise and use a stack just to call a few functions, it might just be better off to make these functions inline or just macros...

- Nick

[Andrew_Baker]

I know that macros that could take arguments would be good enough for me...  just the ability to reuse code without having to copy and paste would make me fall to my knees and cry with joy.

[Nick Sonneveld]

I've been thinking about other shortcuts:

room postoffice
{
 var people_timer;
 pic postoffice_bg;

 NewRoom()
 {
 }

 TouchLeft()
 {
    new.room(toilet)
 }
}

defining NewRoom() and TouchLeft to be standard if(isset(newroom)) or if (touch border)

- Nick

[Joel]

Sorry, accidently submitted that last one early.

That stuff's not an issue if functions can't call other functions, so inline expansion would be fine as an alternative (it wouldn't work for functions calling other functions), although there are some issues to work out. For example, what happens in the following case:

var SomeFunction(var v)
{
   if (v > 100)
   {
       v = 100;
   }

   return v;
}

later...

if (SomeFunction(vSomeVar) < vSomeVar))
{
// do something here
}

should the parameter map to a temporary or should it alter the value of vSomeVar? Will there be a sort of pass-by-reference mechanism?

Those new room a touch left things are ok, but how about if they looked like event handlers instead. For example:

room SomeRoom
{
   OnNewRoom
   {
   }

   OnTouchLeftEdge
   {
   }
}

[Nick Sonneveld]

we'd probably have to define the parameters as "pass by reference"...

[Mokalus of Borg]

That does sound useful, Nick. Go to it. I'll keep reading up on the current format.

Mokalus of Borg

PS - I think for now, to ease production of games already started, we should look at adding to an existing compiler.
PPS - After that, we can start with a clean slate.

[Nick Sonneveld]

ok.. one more thing we could add are easy to use timers..  we could have room timers (for intros, animations) and then global timers (timed puzzles.. meeting at a certain time)

basically, you init the timer, and the compiler adds in code to count up.  Then you could have sections of a room that are only called when the timer reaches a certain number.  The compiler could use two-three variables if necessary to use counts with high numbers...

- Nick

[Nick Sonneveld]

ok, added plan of action, tools available, more comments for ideas, syntax suggestions and compile process.

Compiler Discussion Summary

if people have trouble accessing it, I'll move it to my dingoblue server.

- Nick