4 replies to this topic

[tabc3dd]

Simply put, unticking that box means that i need to set some variables in the create event of some objects, variables which i sometimes don't use. I'm scared that setting these variables in the create event would have a computational cost and therefore slow down the game.
Also, unticking that box means i get an error everytime i try to access a destroyed object's variables, how can i check in the most effective manner if a variable pointing to an id has the target still existing ?

Thanks

[GameGeisha]

Simply put, unticking that box means that i need to set some variables in the create event of some objects, variables which i sometimes don't use. I'm scared that setting these variables in the create event would have a computational cost and therefore slow down the game.

The computational cost of declaring a variable is negligible. And since it is a one-time procedure, it is even more negligible. Besides, with that option on, the variable will still be declared anyways when the variable is first referenced or assigned.

But when you do have that option checked on, you can get into trouble with some very elusive bugs. Mistype a variable name and you could soon be incrementing the wrong variable without knowing it. This is why most GM experts find this option abhorrent.

Also, unticking that box means i get an error everytime i try to access a destroyed object's variables, how can i check in the most effective manner if a variable pointing to an id has the target still existing ?

Use instance_exists().

GameGeisha

[tabc3dd]

Thanks

I knew about instance exist, but some testing i've done seemed to imply it's slower then checking if the object's x position is equal to 0, so i'm not sure if i should change or not

[GameGeisha]

I knew about instance exist, but some testing i've done seemed to imply it's slower then checking if the object's x position is equal to 0, so i'm not sure if i should change or not

The problem is that 0 is a valid coordinate value. If you have that option checked and you get 0 from inst.x, there is no telling whether the instance is actually at 0 or just doesn't exist. This is why the way you're doing it is a bad idea.

The correctness of the code is more important than small performance hits that sanity checks incur.

GameGeisha

[tabc3dd]

I knew about instance exist, but some testing i've done seemed to imply it's slower then checking if the object's x position is equal to 0, so i'm not sure if i should change or not

The problem is that 0 is a valid coordinate value. If you have that option checked and you get 0 from inst.x, there is no telling whether the instance is actually at 0 or just doesn't exist. This is why the way you're doing it is a bad idea.

The correctness of the code is more important than small performance hits that sanity checks incur.

GameGeisha

Nah, i'm sure that the objects i'm checking never go there ^^. However, you are right, thank you very much, i'll change my scripts