Bug in my ordering code?

[dmko]

I'm trying to implement a simple "move to back" / "move to front" without relying on the heavy lifting of something like https://github.com/pixijs/pixi-display

Here's my ordering code, but it doesn't seem to always work... though it does work some of the time... I think it looks like for some of the items it works but in reverse? What am I missing?

//moves an item in an array to either the front or back
export const PopTo = (isFront:boolean) => items => item => {
    const copy = items.concat();
    const ret = copy.splice(copy.indexOf(item), 1);

    return (isFront) ? ret.concat(copy) : copy.concat(ret);
}
export const PopToFront = PopTo(true);
export const PopToBack = PopTo(false);


//move item to back
this.children = PopToBack (this.children) (target)
//move item to front
this.children = PopToFront (this.children) (target)

 

[ivan.popelyshev]

First child is at the bottom, not the top

[ivan.popelyshev]

I've added your triple lambda into https://github.com/pixijs/pixi-display/wiki

[dmko]

Hehe cool! Yeah the partial application thing is a habit I'm getting into from more and more functional programming type stuff. It's soon to be the default way things are done in the Sanctuary library - https://github.com/sanctuary-js/sanctuary/issues/438

[dmko]

I'm still having some weird stuff happening where the same code run over two different objects is having the opposite effect.

In other words, for the more recent object (starting at top layer) things work correctly. For the first object (starting at bottom layer) the action is refersed ("send to back == send to front and vice-versa")

It's almost like the ordering is affected by setting children(), but it's somehow affected by the original placement too? Not sure... will revisit on Monday probably. Have a good weekend!

[alex_h]

Just curious, why do you want to replace the children array rather than adding the child back to the existing one using push or unshift?

[ivan.popelyshev]

56 minutes ago, alex_h said:

Just curious, why do you want to replace the children array rather than adding the child back to the existing one using push or unshift?

But triple lambda!!!

[dmko]

Yeah that's basically the idea, trying to get more into functional stuff and keep things pure... in this case we're mutating the "this.children" anyway so there's no point really, but still - trying to force myself into new habits

Not sure why the action isn't working for me yet, maybe I'll add a fiddle here tomm...

[alex_h]

The idea of having immutable data for games always seemed crazy to me. In games things are moving around a lot and changing their data all the time. So if you have to throw away objects and arrays each time this happens you are going to generate masses of garbage for the GC and have hopelessly bad performance.

[dmko]

It's a debatable topic, that's for sure.

On the one hand - you're of course right, GC sucks for games and creating a bunch of objects is a no-no.

On the other hand - code that's easy to reason about is a huge win for lots of reasons.

I'm working on something which I'll hopefully share in the next week or two, it's really just pong but using some functional programming and object-copying stuff. The neat thing is I'm pushing all of the game logic off to a web-worker. Theoretically, browsers are allowed to compartmentalize GC per thread, and those that do (if they do) would get the best of both worlds from that (imho).

[dmko]

Oh my problem was on my side... was pointing to the wrong target