Messages

There are multiple kinds of irony.

A lot of the song does certainly come under what one might call "cosmic irony" even if it's not quite rhetorical or literary irony.

The main issue is the size of the sprite cache. Large sprites take up a lot of memory and this can thrash the cache.

The other major issue that all user drawing (i.e on custom surfaces) is not hardware accelerated and is thus really slow.

Another minor issue is the lack of sub-pixel rendering so you cant move things very smoothly.

Also nitpicking but that would mean that 1px = 1m since you define gravity as 9.81px/m^2

This is an unlikely scale for any game.... except maybe gorillas.bas

linsetup obviously.

With regards to point B, AGS already has an inbuilt gui control system which is used by the aforementioned save, load and quit dialogue boxes. And the system would not need to be customizable just like the save/load dialogues arent. They can just be ignored and alternative systems implemented by the user.

Your other points are fair.

Also I agree that native widgets are better.
Another option is the Wx set which uses native widgets.

Would it not be better to leave winsetup in for legacy purposes and instead, implement an in-engine solution?

Currently the engine has in-engine solutions for save, load and quit dialogs. Why not gfx settings?

The advantage of this is that it easily allows users to override the functionality and you don't have to maintain any GUI lib.

The problem is that "engine" is not declared or not in scope.

I forget exactly how the interface gets the engine but this is a scoping issue.

agreed. while() {} do; is not correct form basically everywhere.

I was pondering the scripting language last night and I've noticed something of a problem that should be addressed.

AGS is type safe and we're getting rid of pointer notation. Without a base object class (and type coercion) we can't have any kind of generic classes, like a stack for instance.

In C you might push pointers to a general stack.
In C# you'd use a generic or a general bass class.

We can't do either of those because there's no object class and no generics/templates.

So I propose we introduce both. I think all user structs should inherit from a base "object" class and generics should be introduced.

Both of these things seem *fairly* easy to me (although I know very little about compilation).

Requiring all classes extend object is presumably just something thats implied by the compiler.
Generics are just a type substitution thats known at compiler time.. it could almost be a find/replace.

Code example for reference:

Code: ags

class Stack<T> {
    import T Pop();
    import void Push(T item);
}

Code: ags

class object {
    import String ToString();
}

Yes, you need a way to crawl the reference tree and free all child objects (and their children).

Essentially what CW is talking about is the beginnings of a form of type reflection which would be great, especially if exposed to scripts somehow :">

The point is that they don't know at runtime.

Yes, that would be best. Thats essentially what the Lua plugin does. Most of the necessary API functions are there (except for registering engine events).

I was specifically talking about CW, yes.

Reference:

The AGS compiler, AFAIK, has no optimisation and uses no advanced CPU instructions.

Unfortunately, that's true. It produces very formal sequence of instructions, mimicing how real x86 processor (IIRC) works: putting values to registers, getting them back, calculating, putting result to register, getting it back once again for other use, etc, etc., and every action is processed separately. I think it does at least about 3-5 things more than needed per each primitive operation.

This "formal sequence" makes things like loops very very slow.

I have benchmarked this and I reckon the Lua plugin, which has an extra layer of abstraction to deal with, is about 5-10 times faster depending on what you're doing (loops mainly).

Also this thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47320.0

So when talking specifically about the speed of AGS script, it is you that has no argument here, my friend.

When it comes to replacing AGS script, I am broadly for it but I understand that it's simply unlikely to happen due to the time involved.

I've seen zero evidence that AGS has speed issues.

The core engine dev team even admit there are speed issues. The compiler has absolutely no optimization at all which is especially noticeable in tight loops.

There's absolutely no good reason to replace it by some arbitrarily chosen "more popular" scripting language.

Speed and upstream support seem like the most obvious ones to me.

I agree that replacing it with another language (AngelScript would probably be best) would be the best course of action but it's a significant thing to do.

Replacing it would be better in the long term because we get all the advantages of a popular, off-the-shelf library but it would take a lot of work.

yea, hotspot names are not valid in the global script.

if you want to reference a hotspot from the global you need to use the id like this:

Code: ags

hotspot[5].Visible = false

where "5" is the ID in question.

uggnnnnhhhh no pointers.

Pointers are a low-level, direct memory referencing construct and are not suitable for a high-level scripting environment. Let's not cut corners.

Should I just put my love for love2d and lua in my signature? Probably would save time.

- new operator (done)
- keyword "builtin" to lock down any operations we don't want (creating new objects, extending, etc.)
- fix bugs (somewhat done, zero-sized structs should probably be tolerated)
- constructors (even this is iffy right now)

This looks like a good roadmap for the time being. Better not to add too much in one go. Adding user managed structs with constructors is plenty to be testing and digesting over the next few weeks.