LoginLogin

Undocumented syntax for SPCOL function, with many parameters

Root / Programming Questions / [.]

SquareFingersCreated:
While examining some syntax, I found that (after SPSET 1,0)
?SPCOL(1)
does not produce a syntax error. Neither does
?SPCOL(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21)
I haven't checked the semantics.

While examining some syntax, I found that (after SPSET 1,0)
?SPCOL(1)
does not produce a syntax error. Neither does
?SPCOL(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21)
I haven't checked the semantics.
But what does it do?

Does SPCOL() with other amounts of arguments work?

Does SPCOL() with other amounts of arguments work?
I checked one parameter, two,... all the way up to 21, when I stopped. None of them gave an error. I don't know what the upper limit is.

We need to do some testing to determine what SPCOL() returns. I would assume that for SPCOL(x), x represents the sprite management number, but I'm not sure how multiple arguments would return a single value.

It seems, if the first parameter has not been SPSET, the function gives Illegal function call. None of the other parameters need to be 'set' sprite numbers, though. So far, I have only seen the value 0 returned by this function. I haven't really been testing it, though.

It seems, if the first parameter has not been SPSET, the function gives Illegal function call. None of the other parameters need to be 'set' sprite numbers, though. So far, I have only seen the value 0 returned by this function. I haven't really been testing it, though.
Try:
SPSET 0,0
SPCOL 0
?SPCOL(0)
I'm guessing that it's only meant to allow 1 paramater, and SPCOL(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21) being allowed is a bug. Does (1,2,3) evaluate to anything? if it does, then this might be caused by the same issue as USE(1)

Try:
SPSET 0,0
SPCOL 0
?SPCOL(0)
I get 0.
Does (1,2,3) evaluate to anything? if it does, then this might be caused by the same issue as USE(1)
PRINT (1,2,3) gives a Syntax error, strongly suggesting that (1,2,3) is not a value.

Try:
SPSET 0,0
SPCOL 0
?SPCOL(0)
I get 0.
Does (1,2,3) evaluate to anything? if it does, then this might be caused by the same issue as USE(1)
PRINT (1,2,3) gives a Syntax error, strongly suggesting that (1,2,3) is not a value.
SPCOL() might be something that was partially removed or unfinished, but left in by mistake.

The built-in might be using an args array (I wonder if it's not C...) It could be you're just calling SPCOL with a very long args, and its defaulting to one of the forms with OUT and grabbing the scaling value first. Try changing the collision definition of the first arg's sprite? It could also be the weird stack behavior that IAmAPersson thought he had, where the function will just take the right number of args off the stack, so this is implicitly calling form 4.

I wonder if something like this could be used to easily fill arrays...

I wonder if something like this could be used to easily fill arrays...
I doubt it, the native array the native code MIGHT get isn't anywhere near us. I'm thinking like in JavaScript how your argument list can be any length. If it's too short you get undefined variables. If it's too long, they're ignored. (even less likely now) Code that does the same thing:
function SPCOL() {
  VAR mgmt = arguments[0];
...
  IF (arguments.length>2) {
    Var scale = arguments[1]
...
    Return things,things,things
  } Elseif (arguments.length>1) {
...
  }
...
}

The built-in might be using an args array (I wonder if it's not C...)
Unless SmileBasic is running in an interpreter, the form of the arguments to a SmileBasic function is entirely unrelated to the form of the arguments used in the implementation language. I don't think it is running in a C interpreter.
It could also be the weird stack behavior that IAmAPersson thought he had, where the function will just take the right number of args off the stack, so this is implicitly calling form 4.
More details please? EDIT: I see some of your details. But, that's not consistent with Syntax errors being thrown by program statements that don't even get executed.
I wonder if something like this could be used to easily fill arrays...
Easier than FILL?

The built-in might be using an args array (I wonder if it's not C...)
Unless SmileBasic is running in an interpreter, the form of the arguments to a SmileBasic function is entirely unrelated to the form of the arguments used in the implementation language.
The way I see it, when you pass an argument list, you check for safety in the interpreter. I would build a list to check the length against the defined DEF's. That list can then be evaluated and pushed to the interpreter stack, or could be passed directly to a builtin function. I doubt SmileBasic just starts pushing the stack without some pre-checking, but hey it might.
It could also be the weird stack behavior that IAmAPersson thought he had, where the function will just take the right number of args off the stack, so this is implicitly calling form 4.
More details please? EDIT: I see some of your details. But, that's not consistent with Syntax errors being thrown by program statements that don't even get executed.
If it is just throwing the arguments onto the stack, I imagine it counts and function calls have a precondition that throws an error when the counter is higher than the number expected. It could be something as simple as a programmer putting * for that limit (weird because its probably compiled) or a bug in how it counts. Edit: clarity because I'm just spitballing

I heard from a nintendo game maker (not working at nintendo, just making games) that they use C++