Once you go GPU, you can't go back. +1 for this approach rather than relying on the mobile browsers implementations to deliver GPU accelleration.

I think both views are valid in different situations.

I think it just depends on the situation.

Still, this has been an excellent debate. Everyone was able to give their opinions without getting flamed, and that says a lot about this community.

Agreed <img src="smileys/smiley1.gif" border="0" align="middle" />

> I do have to add UIDs were added specifically for remembering object instances in combination with the 'pick by UID' condition - I would say they are best suited for that, instance indexes won't really cut it since they change and UIDs never change.

Yeah, but picking by uid is useless with out using a variable, and you can skip the uid part, then just use a variable.

Plus you can set the variable in the editor.

Seriously you would be better off setting a variable to the sprite index, rather than its uid.

Yes I know you can't do that. <img src="smileys/smiley17.gif" border="0" align="middle" />

I'm with Ashley on this one, and in my own words: much safer and more robust. Why set a variable to remember an index that you potentially have to keep updating in case any changes are made, when you can set it once and have it as a unique identifier for the entire duration of the runtime. If you've ever been stung by it you want to avoid relying on index ordering for references if you can, in most cases.

Also the UID is automatically assigned, so it would makes sense to use it rather than replicating the same thing by creating your own ID numbering system. You have to think of UIDs as what they literally are, reliably unique ways to reference items.

I guess the reason I am hammering on is that your original statement was emphatic about avoiding the use of UID and I feared it might be teaching what I consider to be bad habits to the others on the forum. I know since I am personally new to Construct I thought there must have been some reasons behind the scenes that I wasn't aware of but it seems not to be the case. So I'd emplore the opposite, please use UIDs.

Good debate though, willing to be shown any merits or limitations of either option to determinine if they are worthwhile influencing the way you'd approach certain situations. For me the bottom line is usually robustness and reliability.

The index is based on how many instances exist, or how many are picked, so yes that number will change if you create or destroy instances.

Like if you destroy sprite(0), sprite(1), will then be able to be referenced as the old sprite(0).

Hmm, OK, so the index is as I originally thought, and thus very unreliable to use as a reference because it has the potential to change during runtime.

The UID however will never change during runtime so acts as the most reliable reference. I still don't understand what the perceived negative is?

I use randomly asigned IDs a lot in my other work so I'm sort of defending them here, also, database convention such as in SQL uses randomly (or more likely incrementally) assigned IDs for identification because they are persistant, and by definintion, unique. Feels to me like a UID is one of the most robost identifiers to use, and also made even more attractive by the fact that there is a function built into Construct to select items by this identifier. Of course you need to keep reference but that's part and parcel of making larger scale dynamic games and applications.

PS - Persistance in this case means runtime persistance.

It doesn't change during runtime, but you cannot count on what it will be until after the object has been created at runtime. Each time you run the game the UID will likely be different.

So the index doesn't change during runtme at all, no matter how many instances are added and removed around it? If so it's a different beast to what I understood.

I guess sometimes you want to rely on ids that are essentially hard coded, but equally there are times where you need to use dynamic references that are created at run time. This is unavoidable when you are spawning items such as bullets or enemies that aren't manually placed but generated by code.

So what were the perceived negatives of using UID besides the fact that they will likely be different for each execution of the game?

2. Please, please, please stop using uid. It was not designed for this purpose.

Instead use the object index, as in sprite(index). Each time you add an instance(even in the editor) it is assigned an index based on how many instances already exist. That's far more practical than trying to guess what the uid is.

This seems counter logical to me. If a UID is a uniquely assigned ID that will never change during runtime, and the object index merely lists the current index of the instance, which (am I right in thinking) will change if more instances are added or removed around it, then it makes for much better practice to use the UID when referencing any specific instance. The only argument against it that I can think is some sort of speed hit due to the way the look up is implemented.

That's brilliant R0J0hound.

It makes a lot of sense just to maintain the hero position. I was rebuilding my approach from Flash which was object oriented so made sense for each character to keep it's own lists. Even in Flash this would have had benefits though in that there would only be a single data source.

Cheers, I was going to put Construct to the side for a while and see what developed but with the slow down issue solved for now I'll keep going with the port.

Hi Ashley, I do that quite a bit now, but that technique still doesn't allow you to set instance_1.my_variable to instance_2.my_variable directly without the use of a middle man event/action/local variable.

This came up in another post, but I thought I'd make an individual thread.

Would be very powerful and extemely handy if we could store types other than Number and Text as local or global variables. For instance storing a Sprite would allow you to have references to more than one instance of the same Sprite at any one time and cut down on a lot of work arounds.

Also, am I right in thinking you can't currently store a local boolean? (besides using the 1/0 work around).

Thanks for your exampleR0J0hound, I see what you mean.

I'm guessing it's not possible to select directly by UID with this method without using a loop firstly to map instance indexes to their UIDs and then using local variables to store the relevant indexes of the instances you are insterested in.

Look forward to families, or a way to store types other than Number, Boolean and Text in a local variable (if we could store an object/sprite instance in a variable this would be very powerful and cut down on a lot of event/action/loop work arounds.)

Thanks for the reply Ashley - I totally understand!

Hi R0J0hound, I'm not sure that would work.

Just say your sprite type was called Cat, as I understand it you could pick a first instance by it's index (though probably seleting by UID is going to be more use) but once you picked a second instance the reference to Cat in your actions section would be to the last selected instance.

So you could never have an action that said something like:

Cat(2).my_instance_variable = Cat(1).my_instance_variable.

Instead all you can do is:

Cat.my_instance_variable = Cat.my_instance_variable

where Cat refers to the last referenced instance. As far as I can tell actions only allow you to reference a single, currently selected instance of any particular type at a time.

Not sure if I have a correct understanding or maybe didn't comprehend exactly what you were saying, but to me it seems impossible without a middle man event/action to store values in a proxy variable. And the native Pin functionality seems impossible to implement at all between two instances of the same type.

Will be interested to see families... can you explain the concept at all?