• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by themoonrat

  1. PIXI supports 9 sliced sprites too ( and you might have more success with filters on sprites than on Graphics. As always with WebGL, performance is best when you are making consecutive draw calls using the same base texture. Filters will always break that batching, so if you could put one filter over all of your sprite draw calls, rather than 1 filter per line, then that'd help
  2. A Container is nothing but a collection of other display objects, so cannot be visually represented itself. You need a Graphic or a Sprite (both of which inherit from Container) to even give the container dimensions in the first place
  3. It's not what you want in terms of an automation tool that works with pixi, but there is a chrome plugin that does detect internally rendered display objects that may be of use
  4. I'd take a guess that pixi, via the WebGL renderer, is uploading that texture to the GPU once (it's something the lib has control over) I'd then take a guess that the canvas renderer is uploading that texture to the GPU every frame. But just because WebGL _could_ do it, doesn't mean you should. Take a look at - 99.9% of gpus devices out there support 4096x4096 texture size, yet only 29.9% support the next size up, 8192x8192. It probably works on your pc because you have a discrete GPU in it.
  5. It ground to a crawl for me too, and I was able to get a profile on it, and the delay is all in the GPU At the bottom you have a canvas that is 10000x10000 This is way too big The maximum texture size I'd recommend is 4096x4096... but in my games I often play it safe with 2048x2048 for the canvas renderer because of the time it can take to upload large textures to the gpu
  6. Can something like that be popular? Sure! A Dark Room was a hit and modern-ish take on that... buttons instead of typing commands, but it was still a 'Text Adventure' imo But the best advice I can give is... would you enjoy making it? If you're a hobbyist, and your target is to make a popular game, I think there's more chance of ending up disappointed (or not finishing it) than if you set out to make a game you want to make and have passion for.
  7. I'd recommend loading the game up in Chrome, with dev tools open, and looking at the network tab. After the game has loaded, you'll be able to sort by type, and see what textures the game has loaded, which then gives you a fair idea of how they are used
  8. Again, for the example you showed, those 'particles' are just part of the sprite animation of the winning symbol.
  9. Even if your textures are created dynamically at runtime, when you convert them to a texture, you can scale that generated texture down. ```const texture = renderer.generateTexture( displayObject, 0, 0.5 );``` for example will create that texture at half the resolution Looking at your render tree (using pixi-inspector and PIXI.utils.BaseTextureCache in the console); because of all of this generated sprites, you're missing out on one of the tricks that makes WebGL so fast; rendering sprites from the same base texture. In WebGL, each time you change the baseTexture that the renderer has to render from, there is a slight penalty. If all images are from just a few base textures, then this penalty goes away. Each generate texture you're creating is from a different base canvas... so the optimisations that allows crazy levels of bunnies in the famous bunnymark can't occur in your game. Is there a reason you have to generate the assets in game? If you _have_ to, then generate them all into one display object, convert that to a base texture and manually creating your own Textures from that?
  10. There is no support for word wrapping for CJK languages ( - Boo In any case, for these language what is _actually_ required is word wrap but with break words enabled; there are no spaces in CJK text, and word wrap usually just finds spaces in text. Break words allows word wrap to work without waiting for spaces. - Yay However it's not quite as simple as enabling break words, as there are rules in place as to which characters are allowed to be broken and which aren't - - Boo So you'll need to code your own custom solution at around this line: - that checks the text wanting to be broken up to see if the rules allow for the breaking up of characters or not.
  11. As a basic 'is this mobile or desktop' - is a decent lib which Pixi uses internally. But a better option than just 'mobile or desktop' is to detect some device capabilities. At a base level 'do you support WebGL'. If not, set the lowest settings due to canvas fallback! But if it does support WebGL, you can query the hardware has to what is supported. Based off the official 'is webgl supported code' from .... imagine i'm inside that 'if ( gl ) {' statement if ( gl.getParameter( gl.SAMPLES ) ) { const maxSamples = gl.getParameter( gl.SAMPLES ); } Now, 'samples' can equate to 'can I do multi-sampling anti-alising, and if so, how many samples can I do. Older device hardware won't support this, so will have a value as 0... whereas modern devices do. is a great website to show the available parameters and the stats for what the typical results. So in the above example, I could say "Well, if you support less than 4 samples, that's the lowest 13% performing of devices, you're all low quality". You can do this for a number of parameters, like texture units available, max texture size supported etc. Is another useful website to get that kinda report on the hardware you are running. So if a user has a specific performance issue, send them there and see if you can lower quality according something their hardware doesn't support. As for how to degrade quality, the 2 things that really effect performance and are easy to change are build time are supply lower resolution assets to lesser quality devices, and lowering the rendering resolution for lesser quality devices. Beyond that you're looking at profiling your code on lesser quality devices to see where the bottleneck is. WebGL filters, for example, can often be a good candidate to remove on lower quality devices that still support WebGL
  12. The actual renderers are the canvas and webgl, which you are free to create directly, but autoDetectRenderer is usually preferred as it favours creating the webgl renderer (much faster) but automatically falls back to canvas if webgl isn't supported. You'd only have to write this fallback yourself anyway. The Application method is just a helper class that uses autoDetectRenderer in the background, and provides commonly required basic functionality, like access to a ticker, and getters for the renderer and view. If you don't want to use it, fine We've found it very useful at pixi for creating the examples, as it handles the common boilerplate code, leaving just the example code we want to show off
  13. The doc with a single options object is the correct way going forward
  14. 1. I don't think there is a full list of changes from latest v3 to latest v4. There's a changelog of each individual release: - You could go back from the beginning of the first v4 release onwards, but I'm afraid that's as close as exists as far as I am aware. Multi-texture sprite batching is the big potential performance gain with v4 over v3. The deprecation file will help to see any API changes: 2. Take a look at our wiki, it covers gotchas / migration guide / advice: 3. If v3 gives you everything you need, and works, then it doesn't matter what new version comes out in the future... it's always going to cause a few problems because upgrading a lib usually does! There are some v5 proposals on the wiki, and some tagged issues on github: v5.x . v4 is in pretty much maintenance mode now until v5; there won't be any big changes or breaking changes in the API. I've just shipped a game in v4 without any stability issues, but then each game uses different features, so YMMV
  15. themoonrat

    text height isue

    I think we're going to need a jsfiddle on this one, so we can debug rather than guess the common fixes for this sort of thing!
  16. It just works. If you had a pointerdown callback on your directional pad, and a pointerdown callback on your buttons, then they'll both get called even if you have the screen held down elsewhere. If you have just a pointerdown on the top level of interactionManager, then look within the object and you'll see all of the data that exists for that event, including information to distinguish between different presses
  17. It applies to the base texture
  18. Top result!
  19. When the user presses down (pointerdown), you start a timeout. If the user releases (pointerup), you clear that timeout If the timeout completes, they've held down the screen
  20. you don't need to worry about the texture cache... calling destroy(true) will handle that all for you (it'll also remove that texture from the gpu memory)
  21. Since you're doing this within a class, try adding the context as a second parameter when adding and removing with the ticker. So, this);
  22. You could create the sprite via PIXI.Sprite.fromImage(url); I'll create the sprite immediately, load the images from the url in the background, and as soon as the image has loaded, automatically update the texture to display it on screen. It does all the things you describe for you
  23. In texture packer, you can set the max texture atlas size. If it's creating an atlas for each image, then you probably have that setting at 2048x2048. Raise it to 4096x4096 and you'll get 4 images in per atlas. Ultimately, though, atlases are for putting lots of small individual images into one texture. You have _huge_ individual images, so not surprising atlassing isn't working out so well! With images that large, you don't have many alternate options. Raise the texture atlas size, or lower the size of the Blender output
  24. Take a look through for other webgl parameters you could use to distinguish device performance. I know that older hardware on mobile returns 0 for SAMPLES for example
  25. you can connect an android device to your pc via usb with developer mode and usb debugging enabled on your android device. Load up the game in chrome on your phone on your pc, go to chrome://inspect/#devices, and you can inspect & debug the browser like normal