Rendering from blobs of state (without Sprites)?

[hannyajin]

Hello,

 

I'm gathering state blobs from the state of my entities and sending them over the wire and/or to the renderer in vanilla canvas.ctx that simply draws the graphics at their designated position based on the information in the state blob.

 

How would a similar approach work in pixijs where the rendering is decoupled with the game logic?

 

Currently, as I understand, in pixijs you create your Sprite objects and add them to the stage. Now this is fine if you have the logic and rendering together. But this doesn't work too well if they're decoupled.

 

For instance, a state blob that is passed to the renderer could be a simple list of Points ({x: n, y: m}) and the renderer would draw, say, rectangles or images at those positions. With pixijs I've come across a few adhoc ways of implementing this that all seem extremely hacky to me and would like your thoughts/solutions for this.

 

1. We could, each render, clear the stage of all Sprites, create new Sprites based on the state blob and add those sprites to the stage.

2. Somehow, perhaps with an included id (or based on order in the array) keep track of the Sprites that have already been added to the stage and move them around. Removing/Adding Sprites as new ones are absent or appear in the state blobs.

 

Now, #1 is what I've been doing in my labs but it seems and feels really out of place - does pixijs support a better way of doing something like this where the game logic and rendering are decoupled?

 

 

Thanks for your time.

 

 

[hannyajin]

How would one for instance implement the rendering of a wolfenstyle raycaster (http://ray.jin.fi) where vertical slices of a texture are drawn and scaled vertically on screen (based on distance) - whereas within canvas.getContext('2d') you'd simply call ctx.drawImage(...) with the appropriate (x,y) points?

 

Clearing the stage and building the appropriate sprites and adding them anew each rendering cycle seems very naive to me - can this really be the defacto way or am I missing something obvious?

[xerver]

You need more context to your data than a raw array of points. You need to assign IDs to the objects and reference those uuids in the data you send so you know which objects to update.

 

Also note:

 

> Currently, as I understand, in pixijs you create your Sprite objects and add them to the stage. Now this is fine if you have the logic and rendering together. But this doesn't work too well if they're decoupled.

 

That is just categorically untrue, in fact the whole point of pixi is that you can work on your logic and not even worry about rendering at all. Stop thinking in terms of "how do I draw X" and just think "how do I sync these objects across machines?". The answer is never simple, but that is how you should be approaching the problem.

[hannyajin]

No, yeah, you're right. I meant more of a stateless kind of rendering - but that's a bit of a pipedream anyway. It's a perfectly fine tradeoff than managing WebGL intricacies manually.

 

Anyway, made some experiments with some, perhaps obvious, findings.

 

1. Clearing and repopulating sprites to the stage each render:

- the Canvas Renderer worked fine (90% capacity out of vanilla canvas rendering) for a while until the app crashed due to memory issues. Something was leaking somewhere, the memory usage went up very slowly over time but a steady increase nonetheless.

 

2. Populating sprites on init and reusing them. A kind of sprite/object recycling:

- This worked well and steady, even better in some browsers than the vanilla canvas renderer. However, the webGL renderer blew it out of the water - really nice performance (with exactly same look too).

 

Took a bit of more maintenance, and different way to think about rendering, and setup the textures but that's to be expected.

 

http://ray.jin.fi/app.html (vanilla canvas)

http://ray.jin.fi/pixi.html (pixi canvas)

http://ray.jin.fi/pixiwebgl.html (pixi webgl)

 

(source https://github.com/hannyajin/raycast)

[xerver]

Clear and repopulating is definitely not the way to do this. Track them via an ID. If you see an ID you don't recognize, create a sprite for it. If the ID is gone, delete that sprite. When the ID's data gets updated, just move the sprite around.

Maintain and update state, don't clear and refresh every time.

[hannyajin]

Clear and repopulating is definitely not the way to do this. Track them via an ID. If you see an ID you don't recognize, create a sprite for it. If the ID is gone, delete that sprite. When the ID's data gets updated, just move the sprite around.

Maintain and update state, don't clear and refresh every time.

 

Yes, indeed, couldn't have put it into words better myself - and the reassurance of an experienced pixijs user is, well, reassuring. Thank you.