So, myself (vocals) and one ancient verger (w1cca, on drums) performed live for Child's Play last night at Umloud.



Donate to Child's Play to prove to the world that gamers are wonderful people who care about other people! Namely sick children!

More verge-centric news to come soon. Honest.

The machine that verge-rpg.com is hosted on has had some rough days recently. Many thanks to zeromus for his multiple 3-hour trips to Houston to get things worked out in the short term, and his continued efforts to find a long-term solution!

Hey guys, I thought I'd mention another planned feature for Verge some day.
Might take a long time to get around to completing, but I think it's pretty much important in liberating Verge from a few of its current restrictions.

We need to allow fully-free function pointers for both VC and Lua, in a way that's backwards compatible with current Verge code! And, it should be doable, given a little bit of grudge work by people.

To accomplish this, a bunch of stuff needs to change. We need to add a new variable type in Verge's script engine signatures, which will allow for all-purpose function pointers in VC code, and first-class function pointers in Lua.

Effectively, all builtin functions will take a "callback" instead of strictly a string.

As a result, in Lua, you get to pass anonymous functions to stuff like HookRetrace.

In VC, you would be able to get optionally compile-time error reporting if a function does not exist, through new VC syntax features. The syntax is backwards compatible with old code, so all hooks/calls using string names will still work.

VergeC

Modifying VC is annoying. It always is. The compiler and interpreter have made things really frustrating, mainly because it wasn't designed with certain flexibilities in mind when it was first created. That said, I think it can be done, with a bit of planning. And plan I did!

Here is how the VergeC would work!

Introduces Reserved Keyword

callback

Variable Declaration Syntax

callback <return type>(<signature>) <name><array size (optional)>;

Notes about Callback Signatures

Signatures for callback declarations may give their parameters names, but aren't required to (unlike real functions). In other words, they can just give the expected types, if they want to. This makes it a little bit cleaner when dealing with a lot of callbacks

Notes about Scoping:

These variables would be allowed to be declared anywhere ints and strings are allowed.
This means local callbacks, and callbacks as arguments.
The no-struct/no-array limitations on local callbacks would apply.

Er... maybe they won't be passable to varargs functions. We'll see. If they are though, tons more flexibility.

Examples

// No args-void return type.

callback void() f;



// With an string return type.

callback string() f;



// As an array, each returning ints, and taking a string argument

callback int(string) crap[60];



struct Item

{

    string name;



    // Inside of a struct, multiple arguments

    callback void(int itemIndex, int user, int target) useItem;

}

Item itemCollection[50];





// As an argument

void CallSomething(callback void() f)

{

    f();

}



// As a return value.

callback int(string) GetCrap(int i)

{

    return crap[x];

}

Callback Expressions

These expressions are used when resolving the value for an assignment or argument pass regarding callbacks. Only these types of expressions can be assigned to callback variables. Anything else should cause an error.

mycallback = 0;

The null-function expression. Does not "exist" if passed to FunctionExists(callback void). If called, this function will do nothing. Note that, an int variable with value 0 will not work instead, but this is for a reason since any other int index won't be meaningful.

mycallback = MyFunction;

Resolve a function reference at compile time. Function must exist in VC (ie. not library code, but this might change), and must match the exact signature to compile. Map-VC function references can occur, but only in the file the function is declared.

mycallback = "My" + "Function";



string somestring = "MyFunctio";

mycallback = somestring + "n";

Resolve a function reference from a string at runtime using a name-table lookup. Required for map-VC functions to be made in system-VC code. If the lookup fails, the actual value given will be the null-function.

There's no == operator defined on callbacks, and there won't be much need for equality-testing functions, I figure. (and if you need to, just use strings as before).

On the other hand, existance checking will be there, to allow callbacks to tell when they're holding a null-function instead of something that will actually do something when called. To do this though, we pretty much have to promote the FunctionExists(f) builtin function into an operator, which will work on any callback expression, instead of just strings as it is right now.

Oh, and of course, you need to be allowed to call the callbacks:

callback void() talk = HelloWorld;

talk();

Notice how everything is backwards compatible with current VC, but introduces new features. That in mind, everyone can keep legacy code around, but adapt new VC to use function pointers. Function pointers can be faster than current string lookups (if resolved at compile-time), because the function index can be known in advance.

The Script Library

Now, with that out of the way, to allow the flexibility to be introduced into the rest of the engine, the script library needs modifications!

All of the existing callback function stuff uses strings, which are names to void functions that take no arguments. So we can pretty much introduce one extra signature type for void builtin callbacks.

Pretty much have something like this:

callback void() trigger.onStep;

callback void() trigger.beforeEntityScript;



void CallFunction(callback void f(), ... args);

void HookRetrace(callback void() render_routine);

void HookEntityRender(int ent, callback void() render_routine);

And so on. Also, remove FunctionExists(string funcname) from VC, since we'll be introducing a FunctionExists that works on any callback.

Lua

Okay, but what about Lua?

Well, we'd be able to use the new signatures that we introduced for VC.
Add a few simple cases to the argument validator and execute function stuff.
We'd need to update the current hooks to be a class with an int reference to the Lua registry. Simple enough, I think.
These are the simplest things to add, since it doesn't involve any compiler modifications.
So I might be able to FIRST add anonymous function support for Lua, and from there, chisel in VC stuff.


Afterwards, in Lua, we'd get to do weird funky things like:

v3.HookRetrace(function()

    vx.screen:RectFill(0, 0, vx.screen.width, vx.screen.height, 0)

end)

or having a function inside a table pointed to directly:

v3.HookRetrace(clouds.Render)

or having a function call a function on a table, so you can have pointers to object methods:

local world = NewWorld();

v3.HookTimer(function()

    world:Update()

end)

Will take a fair deal of thinking and grunt to get there though. But, I dunno, after all this stuff is done, we get some sexy results!

Hey everyone. As I kept hinting in various places around the net, we've got a new release of the engine all ready and put together for you!




Get Verge 3.2 for Windows!
Get Verge 3.2 for Mac!

---

In addition, we took GREAT (read: minor) pains to update Sully to the new engine. Play through it all again!




Get the Windows Sully Chronicles!
Get the Mac Sully Chronicles!

---

I'll follow this post up with a post of the release notes. If anyone has any question about new features, etc, let us know!

Now, get out there and make some games!

Want to learn Lua?

Our own Overkill has written a reference over at:
http://www.bananattack.com/vx/Learn_Lua. This page is more geared towards verge, but isn't a beginners tutorial.

For more detailed informations, try hitting up the lua-users docs over at http://lua-users.org/wiki/TutorialDirectory