49 replies to this topic

[Nocturne]

The argument business sounds good to me... any performance boost is a good thing, and if it enforces good programming habits then I´m all for it! As for the arrays, what does DIM() mean? At the moment it´s quite useful to do

array[15]=0;

and know that the whole array is initialised to 0... are you suggesting that we do this but in some way choose the initial value? Or havit so that that code throws an error and we have to use

var i;
i=0;
repeat(15)
{
array[i]=0;
i+=1;
}

to create the whole array? Sorry if I´m being dumb, but I only know how to program in GM...

Edited by Nocturne, 08 April 2011 - 03:17 PM.

[Nocturne]

Thanks for the info, Mike... seems like a sensible move and easy to adjust my coding style to!

[GameGeisha]

Dim(myarray,16);

This would create/resize an array to 16 initialised elements. meaning you don't need to manually do it. We've seen a lot of bugs where someone simply hasn't filled in a variable, then read from it and it's worked "by chance" really.

I like this. Would it be possible to expand this to initialize all the values to a user-specified value (e.g. noone), or even generate common sequences (like range() from Python). That would definitely cut down on the time spent writing FOR loops for the purpose.

Also, will this be a special syntax, or just a new function? If it really is a function, that would mean passing arrays as arguments would be permitted. This function can be really powerful and would reduce the number of arguments per script (e.g. if min() implements this, it can take just one argument).

GameGeisha

[paul23]

Well I'm always in favour of getting things done explicitelly and do as little as possible implicetelly.. So I shared your opinion that initializing elements 0-x when setting array[x+1] is bad.

That said: did you also consider the value of optional arguments? - Optional arguments allow for much more flexibility & faster programming (no longer do you have to create a seperate script for each different number of arguments).. From what I read optional arguments will be impossible in gm 8.1?

[BlueMoonProductions]

I'm not sure wether that's a good idea. For example, in my game, I use a sound system: FMOD. There's a script FMODSound_Play(sound), which calls an external function and plays it.
I edited the script from:

external_call(argument0,and,some,other,stuff)

.. to ..

if (argument1 == false)
 {
  if (global.setting_sfx == true)
   {
    external_call(argument0,and,some,other,stuff)
   }
 }else{
  if (global.setting_music == true)
   {
    external_call(argument0,and,some,other,stuff)
   }
 }

The second argument I added tells wether the played sound is music or SFX. I edited at the time I already used this script a lot, so argument1 would be set to false > it is SFX.

So I use it in 2 ways: FMODSound_Play(sound) and FMODSound_Play(sound,type).

So, I hope you'll at least consider an option to allow a "random" number of arguments? Because there are way more possibilities

Eg: script(numberofarguments, argument1[, argument2[, argument3[, ..]]]):

n = argument0
var i;
for ( i = 1; i <= n; i += 1)
 {
  do_something_with( argument[i])
 }

I think the whole thing is a bad idea, but at least consider an option for a random number of arguments.

Edited by BlueMoonProductions, 08 April 2011 - 04:21 PM.

[LSnK]

So we'll make it so that argument[x] types are not effected by calling limits. Basically we'll assume you know what your doing if you access arguments via arrays.

Does that also mean the array would be zeroed? If not I don't like the outcome: no variadic scripts, or variadic scripts with no means of determining the argument count. That would be a very painful change. Maybe something best left to a major revision than a point release.

A function to initialise arrays would be welcome, as would error-reporting for accessing [technically] uninitialised elements.

It'd also be nice to have a means of getting the size of arrays. It's simpler and less error-prone than storing it yourself.

Edited by LSnK, 08 April 2011 - 05:00 PM.

[JAk HAk]

I'd prefer it if scripts defaulted to no arguments and every one you added had to be given a name. Currently, to avoid confusion, I end up making scripts like this:

var id, amount, direction;
id = argument0;
amount = argument1;
direction = argument2;

...

That way, I can refer to variables by a human name, rather than the easily confusable argumentx.


For arrays, I tend to initialize them either sequentially or in a for loop. Considering arrays in GM are basically unparameterized Vectors, this has always worked fine, but it sounds to me like you're wanting to make them more like traditional arrays. As long as the functionality to dynamically resize the array is left in (or Vectors are introduced) I'm fine with what you do.

[GameGeisha]

GameGeisha: Its would just be a new function... nothing special other than it'll clear the array quicker since it's native.

I understand that it's a new function, but what about the syntax?

Consider this example:

foo[0] = "Foo";
foo[1] = "Bar";
foo[2] = "Foobar";
show_message(bar(foo)); //show "Bar"

/* bar(array_here) */
return argument0[1];

If the example code is run in GM8.0, you will always get "Foo", not "Bar". Changing bar to "return argument0[2]" will still return "Foo", not "Foobar". Clearly passing entire arrays by reference is not permitted in GM8.0 --- will this be permitted in GM8.1 now that we have dim()?

GameGeisha

PS: In debug mode, will all the contents of an array be displayed (i.e. through "Show local variables"), or will only the first entry be visible like now? Also, having bounds for arrays now should allow for returning arrays and passing them by reference, wouldn't it?

[mcoot]

I agree that the argumentn variables shouldn't initialise to 0. As long as optional arguments are still possible with the argument[n] array, then that's fine with me.

As for the arrays, that sounds fine to me, just so long as we have this dim() function so we don't have to initialise it manually.

[Smarty]

At the moment yes. You would have to "clear" the array yourself. However, if we added a DIM command, then it could initialise an array to the size you wanted.

   Dim(myarray,16);

This would create/resize an array to 16 initialised elements. meaning you don't need to manually do it. We've seen a lot of bugs where someone simply hasn't filled in a variable, then read from it and it's worked "by chance" really.

If you're going that way, would you mind adding a parameter that specifies a value / string to initialize it with?

With regard to the arguments: I was wondering if you were going to preserve the little known fact that to scripts, arguments are actually local variables rather than constants - you can't just read them, you can store new values in them too. I use it as a shorthand for not having to initialize private variables in scripts, e.g.:

if (argument1==0) argument1=1;
return argument0/argument1;

Edit: I also wonder how you intend to make this interact with the (horrible) "Treat initialized variables as value 0" setting for a game. If arrays throw an error when not DIMmed, that basically goes against that setting. But if they do not throw an error, you're back with arrays without bounds checks.

Edited by Smarty, 08 April 2011 - 09:11 PM.

[Medusar]

Always wondered why having the "treat uninitialized variables as 0" option turned off still produced this behaviour for unset script arguments and array values... has been a slight annoyance. Not as big however as the lack of argument_count.

As for the dim() function, I suggest that it should follow GM's current syntax of variable_local/global_set/get(), that is, passing the variable by name. Not that it's the way I like to see this kind of thing, but at least it's consistent.
Unless, of course, you're going to properly allow passing arrays by reference... but I don't expect that for now.

Anyway... I don't see your current way of handling script arguments as the proper way to do it... Yes it's better than it is done currently, but at some point you're going to want to have named arguments and default values for them (instead of forcing the user to use an "unsafe" method and filling every uninitialised "thing" with 0). If you're going to adapt the script system anyway, why not do it properly straight away? I know it's probably a lot of extra work but if you're not careful you end up supporting two old versions and the "proper" version all at the same time... It's not what I'd want.
That's my opinion anyway.

[paul23]

paul23: Named arguments is definitely on the list of things we WANT to add, but it's just not possible with 8.1. Well... anything is obviously possible, but it's not worth the effort in 8.1, probably the next version.

I think I didn't make myself clear/you didn't understand my post:

I meant optional arguments, in the sense that you give them and "initial" value:

void foo(int i, bool b = true); //"b" is optional and when not given that argument is initialized at "true"

But I didn't read your post very well either, I just realize you can still keep the "old" behaviour (of considering the value 0 being an not included argument) by treating arguments as arrays.

ow and not entirelly on topic: is there any indication that the (arbitrary) limit of 16 maximum number of arguments will be lifted some day?

Edited by paul23, 08 April 2011 - 09:19 PM.

[JonathanPzone]

Yea.

_{I never realized it behaved this way anyway.}

[Maarten Baert]

I like the 'Dim' approach, I think it's far better than resizing arrays automatically. This would also mean we can finally delete huge global arrays to save some memory, instead of just forgetting them.

argc sounds good too, however I think the name is confusing. Since the arguments are called argumentN or argument[N], the number of arguments should be called argument_count or similar.

I'd also prefer 'dim' instead of 'Dim', but that's just a detail.

While we're talking about varargs, could you please fix external_define? Currently it requires entering the type of all external arguments (ty_real/ty_string), even though functions with more than 4 arguments can't use strings. If I don't add ty_real for every single argument, the function will display an error message. This also means the number of arguments for external functions is limited to 11 instead of the claimed 16, since external_define uses 5 arguments already and doesn't accept more than 16 arguments either. I know it's not really a big issue since extensions are easier and faster anyway, but I use external_define/external_call all the time during development (especially for ExtremePhysics). I don't want to create a new GEX, install it, create a new EXE, and run it with the Visual Studio debugger every time I change something to the DLL.

It would be even better if you could remove the 4 argument limit for strings (without a huge number of if/else statements). Maybe with some inline assembly? Or some hackery .

For example:

double myfunction(double x, const char* y, double z) {
    printf("x = %f\n", x);
    printf("y = %s\n", y);
    printf("z = %f\n", z);
    return 0.0;
}

You can call it like this:

struct memblock {
    char mem[sizeof(double)*16];
    inline unsigned int write_real(double x, unsigned int pos) {
        *((double*)(mem+pos)) = x;
        return pos+sizeof(double);
    }
    inline unsigned int write_string(const char* x, unsigned int pos) {
        *((const char**)(mem+pos)) = x;
        return pos+sizeof(const char*);
    }
};

double (*funcptr)(memblock) = (double (*)(memblock))(&myfunction); // horrible hack but it will work (for cdecl at least)

memblock m;
unsigned int pos = 0;
double res;

// call function
pos = m.write_real(5.0, pos);
pos = m.write_string("hello world", pos);
pos = m.write_real(42.0, pos);
res = (*funcptr)(m);

It works for cdecl. For stdcall you have to add some inline assembly to fix the stack pointer:

unsigned int stack;
__asm {
    mov stack, esp;
}
res = (*funcptr)(m);
__asm {
    mov esp, stack;
}

It does result in a 'Runtime Check Failure' in Debug Mode, but it works . I'm not sure whether this is possible in Delphi though. If it's possible, you won't need the calling convention anymore.

[sabriath]

It would be even better if you could remove the 4 argument limit for strings (without a huge number of if/else statements). Maybe with some inline assembly? Or some hackery

I actually provided the code involved in the suggestion topic for the string limit ability of GM....not sure why YYG team hadn't thought of it before. The code would actually go something like this:

void external_call(void far* f, gmvar* v, short c)
{
  for(register short i = c - 1; i >= 0; i--)
  {
    switch(v[i]->type)
    {
      case ty_string:
        asm(v[i]->str){push %0}
        break;
      case ty_real:
        asm(v[i]->real){push %0}
        break;
    }
  }
  asm(f){callf %0}
}

A better way is to actually write the 'for' and 'switch' as actual assembly so that the stack is guaranteed to not be used by the compiler during the 'push' sequences. For 'cdecl' you would create a separate function that would save the stack pointer prior to pushing values and restore it after the call (similar to a frame push/pop).



Ontopic:

Dim functionality sounds good, but I would rather see it either using string naming or as an actual statement, using parenthesis makes it feel like the result is what you are dimming. For example:

var i[10]; //dims 'i' as a 10 element array set to '0'
dim i[20]; //redims 'i' as a 20 element array, set the new elements to '0'
redim("i",30); //redims 'i' as a 30 element array, set the new elements to '0'

looks a lot better than:

dim(i, 20);

because "dim" is a statement, not a function call, while 'redim' can be used as a function call so that the name can be referenced rather than evaluated. Other notes: variable_local_dim, variable_global_dim for those that are not strict-scoped in 'var' context.


Arguments:

Never understood why GM does arguments the way it does....but if it'll make it faster, go ahead, it's still wrong though (they should be stack-implemented, position reference saved, and boundary checked when 'argument' is used...keeps everything in a single reference frame for recursion purposes and maintains speed of operation, and "freeing memory" is simply popping the stack pointer out of the frame).

Edited by sabriath, 09 April 2011 - 12:08 AM.

[IceMetalPunk]

As long as we have an argc variable (or, to keep with GM's naming conventions, argument_count), that should be all we need. A double-check for unpassed parameters could also be useful for new users, but the argument_count is really all that's needed if you program correctly.

Instead of throwing errors, though, if you simply add in a NULL type, you can set the unpassed arguments to NULL and be done with it all.

-IMP

[gnysek]

I know that some begginer users write:

var i;
for (i=0; i<10; i+=1) {
    tab[i] = 1;
}

and then to access tab[0] they writing:

tab = 15;

This should also give error.