Parsing text and inserting images

[GodsVictory]

Is it possible to insert images into text entities? Example:

text="I invented Pixi.js Kappa"

should end up inserting the well known "Kappa" emote in place of the text "Kappa"

 

My current idea is to use a container and parse each word of the text individually, creating PIXI.Text for each and adding them to the container. Is there an easier approach? This get's difficult when word wrapping is needed.

[ivan.popelyshev]

Ask @bqvle , he has some impressive demos for https://github.com/pixijs/pixi-ui , he added emotes into pixi, somehow

[bQvle]

Hello

This is a planned feature for dynamic text in Pixi-ui. however it's not there yet.
Its impossible to do with regular PIXI.Text. maybe you can use a BitmapText with a "custom" spritesheet.

@ivan.popelyshev the emojis it shows now is just default emojis from the system font (www.getemoji.com)

 

[GodsVictory]

Ok, so I figured it out doing the method I explained above (it's not pretty, but it works).

I've got a new problem though. I have ~175 different images I need to load. I'm currently using PIXI.Sprite.fromImage(), but I'm quickly using up memory since the textures aren't released from memory. So I added in a sprite.destroy(true) into my ticker once certain criteria is met and started getting this error:

pixi.min.js:14 Uncaught TypeError: Cannot read property 'width' of null
    at e.calculateVertices (pixi.min.js:14)
    at e._renderWebGL (pixi.min.js:14)
    at e.renderWebGL (pixi.min.js:10)
    at e.renderWebGL (pixi.min.js:10)
    at e.renderWebGL (pixi.min.js:10)
    at e.renderWebGL (pixi.min.js:10)
    at e.render (pixi.min.js:13)
    at t.render (pixi.min.js:10)
    at t.emit (pixi.min.js:16)
    at t.update (pixi.min.js:16)

I assume this is because pixi is trying to access a destroyed sprite, but I'm unsure of how to correct the issue.

 

Link to code: https://github.com/GodsVictory/BlabrBox

Link to error: https://godsvictory.github.io/BlabrBox/?c=simulateChat

[ivan.popelyshev]

There can be different sprite that uses same texture, that is still somewhere in the stage. According to authors of pixi, making it release at the right time is the problem of developer  Its a common problem and there's no clear solution except thinking better on your algorithms.

My personal opinion is that current system is unclear and pain, but there's no good alternative so far. Cocos2d and other flash-like engines have different approaches, they use refcounting, but it has its own unclear places. I'm trying to solve that in my spare time for a year already )

Also I recommend to use "pixi.js" without minification on the development stage. 

 

[xerver]

Quote

I assume this is because pixi is trying to access a destroyed sprite, but I'm unsure of how to correct the issue.

Looks like you are trying to access a destroyed texture. sprite.destroy(true) destroys the underlying texture. If you are sharing textures between sprites you will get this error. Be more explicit about managing the lifetime of the objects you are using, and make use of the destroy options that can be passed in to sprite.destroy (passing true sets all options to true).

[GodsVictory]

4 hours ago, xerver said:

Looks like you are trying to access a destroyed texture. sprite.destroy(true) destroys the underlying texture. If you are sharing textures between sprites you will get this error. Be more explicit about managing the lifetime of the objects you are using, and make use of the destroy options that can be passed in to sprite.destroy (passing true sets all options to true).

I'd like to destroy the texture completely. I was hoping that loading a Sprite from an image (in this case a URL) would create a new instance of the same texture. Does destroying a texture with the true option cause all other sprites using the texture to be destroyed, even if it was loaded using .fromImage (I'm not using a loader to load images, I'm simply using PIXI.Sprite.fromImage for every Sprite, even if it's the same image)?

[xerver]

.fromImage caches textures. When you do Texture.fromImage (or Sprite.fromImage) it returns to you the texture it created last time.

See the source:

1. Sprite.fromImage(): https://github.com/pixijs/pixi.js/blob/bf3415101797da1fa856affcdc7713e9edb4a24b/src/core/sprites/Sprite.js#L481
2. Texture.fromImage(): https://github.com/pixijs/pixi.js/blob/bf3415101797da1fa856affcdc7713e9edb4a24b/src/core/textures/Texture.js#L296

If you do Sprite.fromImage() multiple times with the same URL, you have multiple sprites all using the same texture object. If you then destroy a sprite, and pass `true` to the destroy method, it will destroy the underlying texture which is also being used on other sprites.

This is among the many reasons why I recommend that you create your objects explicitly, rather than relying on the static quicky methods. Everyone expects them to operate differently, and they do much more than their names imply. It is hard to manage your own object's lifetimes if you weren't the one who created them.

[ivan.popelyshev]

@Jinz pixi GC is very stupid, it just looks for textures that weren't used for huge amount of time and removes them from videomemory, its not related to cache.

[tywang2006]

5 hours ago, ivan.popelyshev said:

@Jinz pixi GC is very stupid, it just looks for textures that weren't used for huge amount of time and removes them from videomemory, its not related to cache.

100% agree with you. I hate it so I disable it. annoy

[Taz]

After I reread xerver's answer I got his point about explicitly creating and managing lifetime, but thanks for info about GC and cache. BTW if diligently calling destroy() then there no reason to have Pixi GC enabled right? I was afraid to turn it off in case more complicated...

[xerver]

On 7/7/2017 at 10:20 AM, Jinz said:

After I reread xerver's answer I got his point about explicitly creating and managing lifetime, but thanks for info about GC and cache. BTW if diligently calling destroy() then there no reason to have Pixi GC enabled right? I was afraid to turn it off in case more complicated...

Correct, GC is generally only useful if you are not managing the lifetime of your objects. It will come by and clean up things it thinks are left behind. if you are going to correctly destroying your objects, you want it to be off.