Messages

I think interfaces would not be semantically appropriate and referencing Characters and Objects directly rather than by proxy is more user-friendly.

I think we need to remember that this keyword will not be available to the scripter so it's kind of irrelevant in that sense.

Just pick a word and throw an error if the user tries to instantiate a class with that keyword. I don't think it need be any more complicated than that.

Also, the goal would be, at some point, to drop this restriction anyway and allow the user to instantiate them.. so it's not like its a permanent thing anyway.

Given the choice, I would remove headers.

They are a complex idea for newbies. Ideally we should move the responsibility of the header to the compiler, not the user.
I think the headers are a stop gap for the lack of a two-pass compiler.

I will rephrase.

I think there should be a better way of accessing members from different scripts.

Ideally, imho, every member of a script should be scoped locally to that script (as is the case now) unless the member is prefixed by the modifier "public" or perhaps better "global".
If this is done then that member is accessible globally to all scripts.

Code: ags

//scriptA

int privateInt = 0;
global int PublicInt = 0;

//scriptB

function foo()
{
    Display("%d", privateInt); // COMPILE ERROR
    Display("%d", PublicInt); // compiles fine.
}

re: third point.

I think things would be assumed private first, like now.

What's simpler?

Code: ags

public function ThisIsGlobal() {}

or

Code: ags

//in header

import GlobalFunction;

// in script

function GlobalFunction() {}

The former is better because you can see the function is public immediately and its obvious how to make a function public.

the latter is bad because it's confusing and unclear.

My way is better for newbies i think.

I have started a standards document.

https://docs.google.com/document/d/1oW7dqB_GjbmlgPVoYzvBOyQevBPBjzc_jJPY2D5sDH8/edit?usp=sharing

Anyone can comment but if someone wants to do some writing then let me know your gmail address and i'll add you to the contributors.

I think a more formal process like this will allow us to do this quicker and more concisely.

I think discussion should essentially begin with some kind of proposed standard in the doc, followed by a discussion on that section on the forums, followed by edits, followed by consensus.

How does this sound to everyone?

I think we should also discuss the scoping of AGS script as currently its a bit archaic.

Could we feasibly add a two pass compiler and scope modifiers?

so we could have:

Code: ags

public class MyGlobalClass { };

class myPrivateClass {};

public function MyPublicFunc() { }

function myPrivateFunc() {}

So the local scope would be limited to the script but stuff can be exported with a simple modifier?

No, thats *awesome*

Can you override Say and have dialogs use it correctly?

EDIT: Speaking of overrides how difficult would overloading functions be?

EDIT EDIT: (Although we probably need to be able to provide access to the base function if overridden.

The problem with declaring the constructor internal is that it means all classes require a constructor and allowing a default, empty constructor would be cool.

I think defining the whole class as internal would be better. i.e "this class cannot be instantiated in the script domain"

EDIT AFTER GUROK: On balance defining the whole class as "builtin" is probably better.

Ive changed my mind about structs being value types. It would be confusing for newbies to pass an object and get a copy of it instead.

So what would the distinction between a struct and a class actually be?

Is a struct just an automatically instantiating class?

Code: ags

struct myStruct {
    int i;
};

class myClass {
    int i;
};

myStruct myStructInstance; // this is instantiated
myClass myClassInstance; // this is a null reference

What is the utility of this distinction? Why would someone, in practice, ever use a struct?

I think I agree with everything monkey says except maybe the factory methods.

I think the factory methods were included as a stop gap because there was no new keyword.

So where we have:

Code: ags

DynamicSprite *d = DynamicSprite.Create(320,180);

This should be replaced by

Code: ags

DynamicSprite d = new DynamicSprite(320,180);

Of course the factory method can be left in place for compatibility but it should simply be a wrapper for the new syntax.

Any class marked as internal should simply not be able to be instantiated in the script domain. These would currently be Character, Object, Hotspot, AudioClip, AudioChannel and Region. (might be more)

-----

I think structs should be value types and classes should be ref types and the pointer syntax should simply be dropped if thats possible.


Edit: Thinking about this is fun, i'll draw up some kind of doc soonish with my thoughts en masse.

Well basically a "null tint" is white. So just bring your tint colour closer to white. Pink tints less than red.

Essentially just think of it like this: "If I put a white piece of paper under this light, what colour should it be?" and use that colour as your tint colour.

A maybe tangential point, but does it make sense to have a "managed struct". Aren't structs generally considered to be value types on the stack?

Maybe renaming "managed struct" to "class" would be wise semantically?

Since we are essentially designing a language here should we have some kind of symposium or somethign and draw up a formal specification so we dont run into absurdities later?

I should note that you multiply them assuming that their ranges is 0..1.

if the range is 0..255 then you have to take out a factor of 255 to make the range sensible.

internal is a good candidate.

In C# internal members/classes are only accessible from within an assembly. If one could consider the engine and script as separate "assemblies" then to say that a character is an internal class makes sense I think even if it's not exactly inline with the C# definition.

I think we will, at some point, make it possible to instantiate characters from within the script (we're nearly there anyway) so it's not a huge issue either way but i think internal is a very good fit.

To me, an abstract class is a class that cannot have an instance of itself. There are clearly instances of characters even if the scripter cannot make one.

Abstracts are designed to be subclassed.

I dont think you should use abstract because it has a real meaning in the paradigm and appropriating that for something unrelated would be bad.

Characters are *not* abstract classes.

I strongly suggest "builtin".

Game and Mouse should probably just be declared as static if they arent already.

You're talking about multiplicative blending. You basically take the colour in question and multiply it by your tint value. This means that black is left alone and white is made the tint colour.

So you break the tint colour into r,g,b and then multiply each component of the tinted pixel by that.

BASIC on a BBC Micro which were amazing.

I distinctly remember trying to make a quiz type program and not understanding why this wouldnt work:

Code: basic

IF $ANSWERGIVEN < $ANSWER THEN

The answers were things like capital cities.

Can someone, (Crimson Wizard I imagine) please run me through the best practice for adding new engine features that conflict with old ones.

In this case I'd like to add multiplicative tinting. This will change the tint function from Tint(red,green,blue,saturation,lightness) to simply Tint(red,green,blue).

What are the steps I need to do this from a compatibility perspective and can you point me to any points in the code as good exemplars for this?