One question come to mind...

Can 2 or more objects be at the exact same X and Y?

If

*yes*, that would be your last edge case to test... putting a few objects at the exact same X and Y and see if you still have that flickering issue.

GML:

`dgrid[# 1, yy] = ((y+z)*256) + (x mod 256);`

So my final question.. Is that too high a number, or should i consider another approach?

grid Cells contains double or string... without going into 52 vs 32 bits details... how about you play safe and stay bellow 32bit mark (2,147,483,647)?

If you go

@CMAllen way, i'd plan for new sprites which may be wider once you start adding new assets...

how about assuming wider sprites... like *512?

how about *1024?

Heck... why not just assume 65536 wide sprites? *65536?... 1300*65536=85,196,800. Even there you still have plenty of room... for your (y+z).

(see where i'm going yet?)

--

I'm resurrecting

@ribbyte's idea. (and yours in the first place) just in case you can have more than 1 actor at the same X and Y

you want to

*sort by Y then by <some deternimistic value>*
Any value really... as long as it help you make a distinction between two actors in a consistant way over time... Your first guess at id sounds right! That's deterministic.

*sort by Y then by id*
Without going into the optimization bit of things, you

*could* use

*Decimal* part for the y and the

*Fractional *part for id

GML:

```
dgrid[# 0, yy] = id;
dgrid[# 1, yy] = y+z;
dgrid[# 2, yy] = (y+z) + 1/id;
```

If you want to go into the optimization...

You already know y+z can't be over 65535. (we have established that through CMAllen's conversation) so 16 bits is enough.

You can expect id to be increased on every instance_create based on a seed... (100001, 100002, 100003, 100004) ...so you can expect the lower digits to be different from one to another, while the upper one to be useless for sorting.

How about we get ride of them... sorting by

*id mod 10 gives *the same result... right? 1, 2, 3, 4.

What if you have more thatn 10 instance? .. how about 65536 instances? You think that's a fair assumption?

*id mod 65536.. *
(see where i'm going yet?)

Now it's just a matter of knowing the bitwise operator, do you agree those two lines are mathematically equivalent on integers?

GML:

```
dgrid[# 2, yy] =(y+z) * 65536 + (id mod 65536);
dgrid[# 2, yy] =((y+z) << 16) + (id & 0xFFFF);
```

This is how you get a 32bit version of what

@ribbyte was talking about.... As long as your y say in range [-32768, 32767] and you have less than 65535 instances you should be fine and deterministic on most devices.

GML:

```
dgrid[# 0, yy] = id;
dgrid[# 1, yy] = y+z;
dgrid[# 2, yy] =((y+z) << 16) + (id & 0xFFFF);
```

Code:

`dgrid[# 2, yy] = ((id & 0xffffffff) | id.y << 32);`

..also works, though i am still not sure what it does. And if it might be unstable for some reason, i think i will avoid it.

I hope you understand it now and you are not afraid of it anymore.