themoonrat

The very latest version of pixi let's you dynamically create a Bitmap Font, which I think would work really well here. https://pixijs.download/dev/docs/PIXI.BitmapFont.html#.from You get the flexibility of dynamic styles, as PIXI.Text can generate, but it'll generate texture atlases for you so the rendering speed, and changing text speed, will be as fast as BitmapText Initially it could just generate the ASCII characters, but if you detect a different character you can regenerate the atlas?

Short answer. Not much. Slightly longer answer: the Ticker class uses requestAnimation to do the looping, just as would be recommended if handling calling render yourself. It just handles some edge cases with ordering and timing when adding and removing things to this rAF callback, adds a bit of useful information, like a delta, and lets you control the minfps / maxfps and speed of the ticker. There is nothing wrong with not using it at all. But what it contains are the kind of things you may start to realise are useful as you progress

fontfaceobserver is the one. PixiJS wise, either wait until the successful callback function from ffo has completed and then create text using the custom font, or do a force refresh of all the text using updateText function on the successful callback. Basically, don't try to render text with a custom font before ffo has done its thing

The 'from' function here is meant to be to generate your own bitmap font dynamically from a text style... which uses the Text class on the background. And the Text class uses the Canvas API to generate textures. You can use custom fonts via loaded woff / woff2 files, just like in html and CSS. But you cannot use a Bitmap font as a source to draw regular Text

Timing is never a browsers strong point 😕 One option is to have, say, 3 pieces of music, all the same length, all set to loop, all set to start playing at the same time. But you change the volume of them to say, bring one bit of music whilst another fades out. Think of it like layering instruments in an orchestra.

I'm sorry you don't like the solutions, but it's not something that's really come up before that people haven't been satisfied covering with the existing methods. There is nothing more we can give here.

From the comments... if you didn't want any move events in your game, then that is a reasonable way to do it. There's no simpler way either at a top level or on a per component level. It's that or digging into overriding functions, like Ivan suggests above, so that if the event is a move event, it's ignored if the component contains a flag or something

The reason the hitArea helps is because it uses that instead of searching through children to find the hittable areas. So if you require interactivity, hitAreas are the way to go. I'm not sure why this wasn't acceptable in your opening post? What issue were you having with them? They work on all events. In any case, for really complex scenes, what you could do is have an extra layer, where you put either transparent sprites, graphics or containers with their own hitarea - which are purely for hit areas for the scene below? So instead of stage --> armatureDisplay you have stage --> interactivity layer --> armatureDisplay Nothing below interactivity layer is actually interactive... just items in the layer above, which consist of very simple objects which mirror the size and shape of what is below.

If you could put a little demo on https://www.pixiplayground.com/#/edit we could take a look for you

There is a setting to enable this for all containers by default if you wish https://pixijs.download/dev/docs/PIXI.settings.html#.SORTABLE_CHILDREN

Ouch!

What you're looking for is a mask https://pixijs.io/examples/#/masks/graphics.js

I find that a video needs to be played for seeking to work in updating the video being watched. So try seeking, then a play, then a pause again.

The reality is, everywhere supports 4096x4096. But! If, during your app, a texture is required to be rendered from an atlas not yet in the GPU memory, then a 4096x4096 texture is going to take longer to upload to it, and, in my experience, cause a micro stutter in the app on older mobile devices. So I used 2048x2048. Not quite as efficient as more atlases required.. but texture swapping doesn't effect gameplay. Now, depending on your app, that may or may not be a problem for you! You might be able to guarantee all base textures are uploaded to GPU using prepare plugin before being used, or you might only be targeting desktop, or might not have many textures so no multi-texture swapping is required.

Yep, PixiJS is made for the normal browser environment... so anything outside that is out of the project scope. But there polyfills out there and a few specific pixi projects to enable it to work elsewhere