Hacker News Reader

Comment by svieira | Hacker News Reader

Ah, so you don't do parallel with implicit IDs right now, I'm guessing. Or you do, but it has some interesting bugs as the IDs shift around? Or the scope of the auto-incrementing number is lower than "the entire program" so parallel works?

View on HN

It sounds like you are asking, if auto-incrementing IDs are assigned in parallel at runtime, then order of execution of the threads must affect which ID gets assigned to what, and that must make some interesting bugs?

The IDs are assigned at compile time by the Easel compiler. So they don’t change in any way at runtime. Does that answer your question?

Mostly - if the IDs are assigned at compile time, how do you deal with _runtime_ locations like "the fifth iteration of a For loop"?

Actually, all iterations of the for loop have the same ID. This is the design. So the second iteration has the same ID as the first iteration, which means it replaces the sprite created by the first. The fifth iteration has the same ID as the fourth iteration, so it replaces the sprite. So all the iterations keep replacing the same sprite. And that is how you animate sprites!

If you are actually trying to make multiple sprites and not keep replacing them, what you do is you spawn a new entity to hold your extra sprite:

for i in Range(0,10) { Subspawn { TextSprite(i) } }

That code creates 10 sprites and achieves what I think you are thinking of.

Reply on news.ycombinator.com