BlockDoc - A Blockland coding wiki

[Lugnut]

I need a name for the argument that is used to read what the status of a button press is in keybound functions
blagh
example: toggleConsole(1); // toggles console
what name should we use for the argument that has a 1 in that example? it's a 1 when the key is down and a 0 when the key is up.

[Ad Bot]

[TheBlackParrot]

boolean

[Honno]

May I edit the front page? I would like to categorize everything where it isn't just a big list of links.

[Zeblote]

I need a name for the argument that is used to read what the status of a button press is in keybound functions
blagh
example: toggleConsole(1); // toggles console
what name should we use for the argument that has a 1 in that example? it's a 1 when the key is down and a 0 when the key is up.

%keyDown? It would explain what it is.

[Pecon]

May I edit the front page? I would like to categorize everything where it isn't just a big list of links.

Put what you want for it on your user page.

[Greek2me]

I need a name for the argument that is used to read what the status of a button press is in keybound functions
blagh
example: toggleConsole(1); // toggles console
what name should we use for the argument that has a 1 in that example? it's a 1 when the key is down and a 0 when the key is up.

%state

edit: I should really help out with this...

[Honno]

Put what you want for it on your user page.

http://pecon.us/wiki/BlockDoc/index.php?title=User:Honno

[Gen. Hothauser]

Thank you so much for this.  I have always wanted to get into serious blockland coding, but I have always been intimidated by the many functions and such.

[Lugnut]

%keyDown? It would explain what it is.

perfect

[GMO Ferret]

Why not always use global variables? This might be a pretty stupid question, I'm just beginning.

[Pecon]

Why not always use global variables? This might be a pretty stupid question, I'm just beginning.

Usually because you just don't want to clog the global scope full of variables that don't need to accessible everywhere.

On a related note, Port discovered that using local variables is just as taxing on the engine as using global variables.

[Val]

On a related note, Port discovered that using local variables is just as taxing on the engine as using global variables.

What? That's wrong from both a benchmark* and engine source code standpoint. Local variables are just *slightly* slower than global variables. He probably meant taxing to a point where the difference is negligible for most cases, but not all.

Both are hashed in a dictionary- simply put, there's one global variable dictionary that is quickly acquired using '$' versus having to grab the last stack frame and then searching for that variable.

Accessing global variables will get slower the more there is, but that depends on if you create enough to clog up the indices and create additional overhead with seperate chaining. If you add enough the table will automatically double in size and reduce the chances of this happening, though.

*test may vary depending on what you test and platform hardware

[Pecon]

What? That's wrong from both a benchmark and engine source code standpoint. Local variables are just *slightly* slower than global variables. He probably meant taxing to a point where the difference is negligible for most cases, but not all.

Port dissected how the torquescript parser handled local variables, and it turns out that every single reference to a local variable makes the engine iterate through a list of every local variable name ever declared.

[Ipquarx]

I did an actual test to see the difference between local and global variables. It involved over 2 billion iterations of accessing local and global variables, so there should be plenty of accuracy.

First it runs

Code: [Select]

for(%a=0;%a<32768;%a++)
for(%b=0;%b<32768;%b++)
%y=8192;To see how long it takes to set a local variable to a constant, timed of course.
Then it runs

Code: [Select]

for(%a=0;%a<32768;%a++)
for(%b=0;%b<32768;%b++)
%y=%x;where %x is set to the same constant, again, timed.
Then it subtracts the first result from the second to get rid of the time it takes to do the for loop and to set the variable to the constant.
Then it does the same thing where the only difference is %x is set to $x.

The result should be, with great accuracy, how long it takes to access a local/global variable and nothing else.

The results were:

Local Variables:
457.636 nanoseconds per access
Global Variables:
449.523 nanoseconds per access

so there's a 1.8% difference.

[Val]

Port dissected how the torquescript parser handled local variables, and it turns out that every single reference to a local variable makes the engine iterate through a list of every local variable name ever declared.

This isn't true, though. First of all it's not a linear search, it's actually a hash table lookup that uses a hash function plus separate chaining with linked lists*.

Local variables are stored in "frames" that are created when you enter functions, so it's not a table of "every local variable ever declared", it's actually the ones inside the same function scope. Also, when the function exits the frame is deleted and the interpreter doesn't have to bother with it anymore.

*Theoretically you could get a "bad" index in this table and have 1-2 entries for the same index for global variables, but this additional access is still faster than the time it takes to access the last stack frame and then lookup on the table for local variables. The chances of having a bad index is relatively low though, so it shouldn't matter.