How to perform Static Drawing, Optimization Not Needed

[NerdyElf]

I'm trying to task that's easy to handle in Canvas, but which I can't seem to make sense of in PIXI. I thought I was getting close with this ( https://github.com/pixijs/pixi.js/issues/4894 ) and ( https://github.com/pixijs/pixi.js/issues/3251 ), but some of that is now deprecated; also, I'm not convinced this is quite what I'm looking for (or at least maybe not yet the way to do it) and I'd like to see a code example for what I'm trying to do.

What I'm trying to do, and why:

I have an editor, which is on a grid of tiles. The data for that level is stored in a JSON object, which may look something like this:

{
  "room1": {
    10: {
      5: {
        "id": "Enemy/BossGuy"
      },
      6: {
        "id": "Ground/GrassH2"
      }
    }
  }
}

Now, obviously I *could* design an additional data structure on the side and an entire system that tracks every sprite, and another system that renders them, and another system that culls it based on your position, etc, etc...

I most certainly don't want to do that. The data is already there, it just needs to render it. Additionally, the editor doesn't need blazing fast speed, I just want something that won't absolutely kill the memory.

So what I want should look something like this:

// We are INSIDE of the Y-Loop at this point...
for( let x = tileXStart; x <= tileXEnd; x++ ) {
  
  const split = roomData[y][x].id; // assumes we know there's an id here
  
  const sheet = split[0]; // example: "Enemy"
  const spriteName = split[1]; // example: "BossGuy"
  
  // Uses the existing atlas textures and sprite references to render here:
  PIXI.draw( sheet, spriteName, x * 48, y * 48 );
}

What's the correct way in PIXI to do this?

 

[ivan.popelyshev]

What do you have to know to produce solution for your case: 1. Graphics beginTextureFill, 2. pixi-tilemap 3. How to work with renderTexture.

That's one of biggest threads about it, but there were countless others. Every time I tell people that they have to choose A. Algorithm B. low-level implementation. Every time the case is different and people are different, there's no magic button "just do it" in pixijs, you have to actually code something.

One of the basics is https://pixijs.io/examples/#/textures/render-texture-basic.js . Make a container with many sprites or graphics with beginTextureFIll()'s and just render it inside a texture.

I also know many things about canvas2d optimizations , I made that thing back in 2012-2013 https://github.com/ivanpopelyshev/bombermine-shuffle

[dacatchman]

If I understand correctly, you're just struggling with how PIXI works, conceptually?  So, when you do stuff yourself at a lower level (canvas, maybe), you have to specifically call "draw this here" for everything you want to appear on screen.  Consider that PIXI does this for you, this is why you're here, right? 

PIXI is a rendering library, and it renders what you tell it to, based on how you assemble your scene.  And how one assembles their scene is quite personal -- there are several ways to approach it.  Conceptually, you are loading stuff in advance, instancing it where it needs to be, and then telling it to be in the render pipeline or not.  You probably shouldn't be calling render directly on any given Sprite, unless you have a specific reason to be.  Don't quote me, but doing so would probably circumvent PIXI's vertex batching and other internal optimizations.  Containers are a big part of how PIXI works, and at the same time, they help you organize your scene logically (draw this "sprite layer" before this one, etc).

Quote

Now, obviously I *could* design an additional data structure on the side and an entire system that tracks every sprite, and another system that renders them, and another system that culls it based on your position, etc, etc...

I most certainly don't want to do that. The data is already there, it just needs to render it. Additionally, the editor doesn't need blazing fast speed, I just want something that won't absolutely kill the memory.

 

Not just that you could, but you should.  It's two birds with one stone.  You need to tell PIXI what to render, so thus, you only add stuff it needs to.  It doesn't really increase memory usage, certainly not to the degree that loading new graphics would.  It's fairly trivial stuff.  If you want that simplicity just to get things going then sure, just add everything to PIXI.Application.stage via the appendChild method.

If this is a learning project for you to figure out how to make a tile editor work, then you can't really get around this stuff.  This is the whole point.  Otherwise, why not just use Tiled or some other map maker and a full fledged game engine to do all the thinking for you (phaser, impactjs, etc) ?

Now, if you're hung up on how PIXI works and want it to be a little more familiar to something like using plain canvas, then you should avoid PIXI.Application and roll your own mainloop.  In this case, you spawn a new PIXI.Renderer, make a PIXI.Container (a scene to draw), call a bunch of new PIXI.Sprites based on textures you've loaded, and myScene.appendChild(sprite).  Then call RAF on your animate function and go to town.  Here's an example of that, if that's what you're after:

https://github.com/pixijs/pixi.js/wiki/v5-Custom-Application-GameLoop

Otherwise, based on examples, the out of box behavior of PIXI is to use PIXI.Application which has its own render loop and you bind your own update function to it's update ticker.  If that's confusing you, build it up yourself with the above link.  But keep in mind, pixi is a batch renderer for the most part.  You put stuff in a container, and then it appears on screen.  You wouldn't need to step over a tilemap in that traditional way to call draw on each sprite.  You'd instance them into memory and set their position, and then later (as they need to be seen) add them to a container that is being rendered.

Am I missing your issue...?