Window resizing and texture updating

[mobileben]

When a user resizes the window, the render area can become bigger or smaller. This potentially has a visual effect in that if the window started off small and then was increased, the textures could look bad if the render area is simply scaled to fit the canvas bounds. Going from larger to smaller is less of an issue, though one could make the argument that it's doing more work than is needed.

How are most people handling this? For example, if you get a resize event and the canvas say doubles in size, do you simple increase the canvas size but leave the renderer area the same? Or do both? If it is the latter then this would possible require newer textures.

For my setup, I have a defined game area which is currently defined as 480x640. I then support different multiples of this. The plan is to do layout at 480x640 right now (though I may use a higher res multiple later). When the game starts, it will best match which multiple fits the canvas and it will use that.

I'm trying to determine if I should just choose the size of everything at start only and if the user changes the window size, they are stuck with that or if I should add support to find the best matching supported dimensions and then use that. If I decide to support better fitting which multiple works, it also implies I would need to have a method to change textures on the fly. I would imagine something like this would use a multi-pass system where I destroy/dispose of the active textures, load the newer ones, and then apply those new textures to the existing PIXI.Sprites. Obviously any other draw element would need to be updated as well. This seems like a lot of work, so seeing what people's experience is regarding this and if it's worth the effort.

 

[ivan.popelyshev]

You can make something like proxy textures, i had that before: https://github.com/gameofbombs/pixi-heaven/blob/master/srcOld/base/atlas/TextureRegion.ts

That way you wont need to change "sprite.texture", just adjust baseTexture and frame. Actually you dont even need a class there because setting "texture.baseTexture" works in latest pixijs dev

I also use the same principle in new plugin that'll appear soon.

You are still on a front of the problem, there's no progress from our side.

If you solve it even partially, I suggest to publish your engine on github.

[mobileben]

Thanks. I'll need to experiment. BTW, is the best way to resize the renderer to use `renderer.resize()`? This is why `resizeTo` eventually uses and I assume then this actually modifies the framebuffer size in use. I'm not quite used to following JS code that use "runners" yet.

[ivan.popelyshev]

What's "resizeTo", is that application thing? I dont favor application class

yes, framebuffer and other things are modified through runner - "resize" method is called inside every system.

[mobileben]

It is indeedy an Application thing. 

https://github.com/pixijs/pixi.js/blob/2becb1e4e119d6e03c7f1fe0e65ee9d91a5fb687/packages/app/src/ResizePlugin.js#L22

It takes the HTML Element or window. It works, I tried it. I also tried using renderer.resize(w, h), which seems to work. For now I'll assume it correctly resizes the frame buffer versus scaling. 

Once I get further along I can verify if this hypothesis is correct or not.

[ivan.popelyshev]

Its strange that at the scale of problems you're trying to solve you're only now getting rid of Application class. I write it to every person here who encounters application-related problems, maybe it wrote it to you too: read https://github.com/pixijs/pixi.js/wiki/v5-Custom-Application-GameLoop and make your own. Otherwise you'll have to wait when someone from pixi team fixes particular problem or adds particular feature in an area that's very game-specific and has no critical WebGL stuff that we have expertise of.

[mobileben]

I very may well have to go this route. I generally try and deviate as little as possible when using 3rd party. I've been burned too many times doing my own things and then running into incompatibilities. Plus my relative lack of JS/TS experience has me focusing a bit more on getting up and running versus getting things cleaner. Up to now, I think my scaling handling has been smattered across different places. This one is more application based.

I'll dabble with the game loop a bit today. I'm still tying some pieces together and then will see if I can handle the resizing of assets dynamically. I don't expect the handling to be real time, since that is dependent on assets.

I also expect the ease of doing this to be dependent upon the actual number of assets involved. My initial stuff here is "toy" in size, so manageable.

 

 

[mobileben]

BTW, as a heads up https://pixijs.io/examples/?v=next-interaction#/basics/basic.js doesn't load/do anything. I've tried on Chrome and Safari.

[ivan.popelyshev]

Thanks, wrong branch  ill fix it

[mobileben]

I took a better look at the custom game loop and it makes sense. Not sure if I'll go that route just quite yet. A question I have when looking at the code. I can't seem to see where Application actual assigns properties such as Ticker. I've run a grep on the code base and it isn't obvious to me how this is done. For the most part, Application.js (in packages/app/src) look pretty "empty".

I also don't see assignment to other things such as view, etc.

Where is this all done?

[ivan.popelyshev]

oh, right, they are in app plugins now, separated. Good luck with investigating it, I dont even know where it is, I dont use them )

[mobileben]

I figured it out. It's assigned in bundles/pixi.js/src/index.js. I believe it's assembled through lerna/rollup. The rollup config I believe references that index file.