The Dink Network

I've updated the Readme, What's New, and Credits files to reflect the changes in Dink v1.08. If you find any mistakes or oversights, please let me know.

Right now the goal is to have the v1.08 beta release out within the next two weeks. The beta release will consist of a full-install (about 16 MB) and a patch (about 2 MB).

v1.08 is reliant upon the following three pillars. It requires that all three are working fully in order to release a beta. We need, say, Merlin to finish DFArc 2, because including Dink Frontend and DFArc (to launch and install D-Mods) would be a step backwards, and would not provide adequate testing of DFArc 2.

Frontend

Merlin

The frontend will be DFArc 2, which will handle the launching, installing, and packaging of D-Mods.

Roughly 90% complete. The GUI components to play and edit D-Mods need to be implemented.

Engine

redink1

The goal was to fix any errors that prevented people from playing Dink Smallwood. New features were added if they were simple to implement, and would not cause any problems with backwards compatibility (with the exception of D-Mods that tried to push the Dink engine, like isolated scripts in Initiation, Cycles of Evil, and Lyna's Story).

About 95% complete. There are a few things I want to look into (like font colors). Of course, there might be a few issues that will be discovered during beta testing that I'll have to fix.

Game

Tal

The goal was to go through and fix minor bugs in the script and map (hardness holes, hardness sticky points, and instances of one character's line of dialogue appearing over the wrong character or in the wrong color.

About 95% complete. Instead of five or ten little tweaks as expected, Tal found about a one-hundred-and-fifty errors. Most were spelling or grammatical fixes. I believe there are still a couple hardness holes and sticky points that need to be fixed.

Good one, guys!

When you install Dink v1.08, you'll need v1.07 to be already installed, or it will require only v1.06?

Shouldn't "Game" and "Engine" be switched?

Hurray, hurray!

Can't wait for 1.08

EDIT: Though I miss the fade_down(int &fade) function of reDink.exe. Say if you run reDMod.exe with v1.08... would that work?

Yes, yes they should. Thanks, they should be correct now.

It will require only v1.06 (because all of the v1.07 patches were 'beta,' some people preferred not to install them).

Magicman: Maybe. But then you'd lose out on all of the other changes (improved variable parsing, etc.)

I removed it because it was not reliable. On some systems, fade_down(500) would fade down half-way, while on others it would fade down all of the way.

And, with the way I implemented true-color fades, the game would run very slowly while darker on older machines.

With the improved palette support (where the palette is saved and loaded with the save game file), it should be really easy to implement darker palettes.

I modified the whatsnew.txt with a new engine change that I forgot to mention:

* Variables are now dynamicly scoped.

It basically allows you to reference local variables defined in previous functions, so you wouldn't have to resort to global variables like &save_x and &save_y (most of the time).

You can do something like this:

void main(void)
{
int &x = 4;
int &y = 6;
bob();
say_stop("&x, &y", 1);
}

void bob()
{
int &y = 8;
function();
}

void function(void)
{
say_stop("&x, &y", 1);
&x / 2;
}

This would result in Dink saying "4, 8" and then "2, 6".

If there were global variables &x and &y, they would be looked for if no local variables in the calling function stack's scope were found.

Global variables like &save_x and &save_y would be required in instances where the calling script was killed (i.e. when a sprite dies), in which case the scope defaults to global.

Sorry, but that sounds like... weird stuff

First we have &x, &y = 4, 6 (if you don't mind the notation), then it executes bob(), now, if I gather it correctly, &x, &y = 4, 8, which is what he says when it executes function(). Then, &x is devided by 2, leaving &x, &y = 2, 8...

Do you mean that while &x changes its value from 4 to 2 in the proc jumping, &y reverts back to its old value? How come? Has it anything to do with the separate int &y in bob()?

Sorry, here's a late suggestion, bt it has to do something with the font colours.
Just look at the example and think about it. It would be very useful...

int &green = Color(0, 255, 0);
say_stop("Hello.", &current_sprite, &green);

That'd be great... Probably not gonna happen tho.

I didn't create dynamic scoping, I just implemented it. It's available in some programming languages, but most use static scoping (like C). Previous versions of Dink use pseudo-static scoping.

Has it anything to do with the separate int &y in bob()?

Indeed.

Dynamic scoping allows you to have multiple variables with the same name, and they won't interact with each other. You can do this now in Dink if you use seperate scripts or multiple instances of the same script (well, depending on the variable scoping issues).

Here's a slightly different example, where &save_x, &x, and &y are all global variables:

void main(void)
{
int &x = 4;
int &y = 6;
bob();
say_stop("&x, &y, &save_x", 1);
}

void bob()
{
int &y = 8;
function();
}

void function(void)
{
say_stop("&x, &y, &save_x", 1);
&x / 2;
}

What exactly happens in the say_stop statement in 'function'?

It looks for variables starting with the current function ('function'), and if the variable doesn't exist, we look for the variable in the calling function, ad infintum, until we reach the global variables.

function(void)
[No variables]
--------------------
bob(void)
&y = 8 //We use this &y
--------------------
main(void)
&x = 4 //We use this &x
&y = 6
--------------------
global
&x = 9
&y = 7
&save_x = 42 //We use this &save_x

I was more thinking something like this:

set_color(int &colorindex, int &red, int &green, int &blue)

set_color(1, 0, 255, 0);
say_stop("`1I'm green!", 1);

I shy away from adding parameters to existing functions.

Ah, I think I understand now. I wasn't really used to using variables from calling functions. One more thing:

void main( void )
{
int &x = 3;
}

void hit( void )
{
say("&x",1);
}

If you hit it, would Dink then say 3, because it uses the one from the main() proc, or would he say 0, because it tries to get &x from the calling function, which is in this case nonexistant (at least, not in any .c script).

That's a funny case... he would say 3.

Any of the default procedures (hit, talk, etc.) are all part of that script instance's scope.

So let me see if I have this right:

void talk( void )
{
int &x;
int &y;
int &z;
&x = 1;
&y = 1;
&z = 1;
say("&x &y &z &n", 1);
//says "1 1 1 &n" (&n is undefined)
func();
say("&x &y &z &n", 1);
//says "1 1 1 &n" (&n is undefined)
}

void func( void )
{
int &y;
int &z;
int &n;
&y = 2;
&n = 2;
say("&x &y &z &n", 1);
//says "1 2 0 2"
}

If not, what would each line say?

BTW, looking at those sample scripts reminded me, did anyone ever add /= as a valid operator? It always irked me a little that you had to write it as / instead.

Yep, that's right.

Ok... I decided to add a few really awesome features to DinkC. I'll demonstrate it with an example:

table.c

void talk(void)
{
make_global_function("common", "say_stuff");
int &testy = 88;

local_function(1, 2, 3, 4);
say_stop("&return", 1);

sp_x(1, 50);

say_stuff(&testy, 1);
say_stop("&return", 1);
external("common", "say_stuff", &testy, 1);
}

void local_function(void)
{
say_stop("&arg1, &arg2, &arg3, &arg4", 1);
return(6);
}

common.c

void say_stuff(void)
{
say_stop("I like to say stuff: &arg1", &arg2);
return sp_x(&arg2, -1);
}

Output

1, 2, 3, 4
6
I like to say stuff: 88
50
I like to say stuff: 88

Notes

You can now define your own global DinkC functions, pass arguments to any custom function, and get the latest return value from any statement (including custom functions) by using the new built-in &return variable.

You're limited to 9 arguments (&arg1 to &arg9). Because of inherent limitations, you're only allowed 8 arguments when you use 'external' to call a function.

There is one odd thing... if you want to return a variable or integer, you have to use the syntax return(5); (i.e. with parenthesis). If you want to return the value of a statement, it is best that you don't use parenthesis: return sp_x(1, -1);

I may end up removing dynamic scoping... the goal was to eliminate the need for adding argument/return-value support, and now that I've added it, dynamic scoping introduces complexities to DinkC that aren't needed.

This is a bit of a nitpick, I suppose, but isn't this syntax highly misleading now:
void local_function(void)
The first void should be the return data type, and the second should be the arguments.

Feel free to ignore me on this because I probably wouldn't use it anyway, but is it possible to remove the void inside the argument parthenesis to acheive the same effect? So:

void talk(void)
-- is the same as --
void talk()

The second just seems cleaner.

Paul: Aye. I'll look into it... but it might be a messy fix. I believe the DinkC parser just looks for the 'void' keyword when locating a function, and adding support for an 'int' keyword (which wouldn't have any real effect) could cause conflicts with local variable declaration.

Merl: Yeah, I think so.

This all sounds very cool, especially the declaring your own functions part.

I would to ask though... how is it coming along. Is the beta just about ready yet?

I think it is great that there's finally an update again, because there are still tons of people making dmods and playing the game! Good job on keeping Dink alive, everyone!