ZYandu

Members
  • Content Count

    39
  • Joined

  • Last visited

Everything posted by ZYandu

  1. Yes I was using ParticleContainer. Unfortunately, making them all into normal Containers still gives me the same uniform1iv error. I just fixed a bug with my audio playing code that was actually the cause for the RAF not starting. Now my game runs the RAF on IOS Cordova so at least the error isn't stopping my game. ^.^
  2. The only pixi plugin I use is pixi-particles: https://github.com/pixijs/pixi-particles. If I run my game on IOS with the actual Safari app, pixi's console log is showing me that it reverted to webgl 1 and my game does successfully start the RAF. https://imgur.com/a/wDCwmMw So it might be something to do with Cordova's webkit 2 specifically that doesn't like the pixi texture locations allowed as you were saying. ^.^
  3. The game looks like this: https://imgur.com/a/Y4B2OYT Everything looks like it got displayed fine to start, but it doesn't start the RAF due to the uniform1iv error. Everything on screen are sprites, graphics, and bitmap texts. Once the RAF starts I use some pixi-particles emitters and interpolate sprites and graphics x position values but they aren't even .visible yet. ^.^ Hope this helps! 😁
  4. Would you happen to know what type of PIXI texture uses Webgl 2.0's uniform1iv call? I would love to just be able to remove something than to completely revert back to PIXI v4 πŸ™‚
  5. It looks like it might just be that Safari doesn't support Webgl 2.0. https://caniuse.com/#feat=webgl2 Cordova uses webkit 2 which is based upon the Safari browser...
  6. I am getting this error in my game only on IOS with Cordova on PIXI 5.1.1 with Webgl 2.0 (It works on Google Chrome perfectly fine). All my sprites and graphics get loaded to the screen but when the RAF should start it gets this error and doesn't continue. https://imgur.com/a/lqVDzdA Maybe it's something my IOS with Cordova is lacking from the requirements for Webgl 2.0 Specifications? https://www.khronos.org/registry/webgl/specs/latest/2.0/#3.4 Thanks for any advice! πŸ™‚
  7. Yes good idea! I turned off all my plugins for Chrome on my Macbook Pro and I haven't gotten a profile with a RAF failure in 3 separate 60 second profiles. However, I still see it happen in my game πŸ˜› My guess is that since an RAF is supposed to sync with the browser, Chrome is saying that it's not ready to draw yet and holds the RAF up until it is ready. Or maybe my Macbook Pro isn't giving Chrome the resources it wants to be able to draw again too when the temp rises and fans start up. To test this, I did a profile on my Chromebook with the Pixi playground example and saw many slowdowns, most of them GPU related or caused by large spaces between frame executions. Also some GC. It is obvious that a Chromebook should perform much worse, but maybe it's highlighting the main problem to be with the Chrome browser itself or more of a device specific GPU + CPU available resources type of issue. https://imgur.com/a/0r7KhJ9 https://imgur.com/a/fAJpMID https://imgur.com/a/D4ItbY8
  8. I don't have any console.logs in my Pixi playground example if you look again. 😁Thanks, yes the second animation frame delay is really what gets my game the most! πŸ˜› https://www.pixiplayground.com/#/edit/pYTkTrNrzUEica9rRZhppο»Ώ
  9. Sorry I didn't really specify before @Exca, the screenshot in my first post is a part of the profile of my full game which uses the same code setup for consistently moving x values, just with more sprites. πŸ™‚ The moving parts are all the numbers and sprites in the middle section https://imgur.com/a/hhhIavE. I made the PIXI playground example and saw that it was also having some stutters for a much more simple version of my game so I figured it must've been an issue with how I was doing it. ^.^ Here's some more profile data on the pixi playground example to try and see similar issues! 😁 30 second profile #1: As Exca mentioned, I am seeing major GC happening a few times in the beginning of the example and then it stabilizes. Longest major gc: https://imgur.com/a/LDklp5o 4 main gc in beginning 25 seconds https://imgur.com/a/ODOoCL0 30 second profile #2: I got something similar to what I see in my game, where the request animation frame seems to take up a lot of time (19.62 ms) without really doing anything. https://imgur.com/a/UARFcMb I've seen both of these types of slowdowns in my game too, any advice? πŸ™‚ Thank you!
  10. Dang... are you seeing any of the visual stutters I mentioned? It still looks like it slips up on my MacBook Pro. Are you using a computer with a nice GPU?
  11. If Pixi playground still isn't showing up for you then delete all the code and put this in x) /*pixi playground consistant transform test*/ var img = document.createElement("img"); img.src = "https://i.postimg.cc/MKDkHyGN/background-Spice.jpg"; img.style.position = "absolute"; img.style.zIndex = -2; document.body.appendChild(img); var totalTimePassed = 0; //webgl renderer var renderer = new PIXI.Renderer({ width: window.innerWidth, height: window.innerHeight, transparent: true }); document.body.appendChild(renderer.view); var stage = new PIXI.Container(); var loader = PIXI.Loader.shared; loader.add('bunny', 'https://pixijs.io/examples/examples/assets/bunny.png') .load(startup); function startup(loader, resources) { var bunnyContainer = new PIXI.Container(); bunnyContainer.position.set(0,0); //make 300 bunny sprites at the edge of the pixi canvas for(let i = 0; i < 300; i++){ var bunny = new PIXI.Sprite(resources["bunny"].texture); bunny.visible = false; bunny.msUntilStartMoving = i * 1000; bunny.anchor.set(0.5); bunny.x = renderer.width; bunny.y = renderer.height / 2; bunnyContainer.addChild(bunny); } stage.addChild(bunnyContainer); animate(); } function animate(delta) { requestAnimationFrame(animate); for(let i = 0; i < stage.children[0].children.length; i++){ //Once enough time has passed kick the next sprite into moving if(stage.children[0].children[i].msUntilStartMoving < delta && stage.children[0].children[i].x >= 0) { //unhide sprites at the edge to get ready for transforms if(stage.children[0].children[i].visible == false){ stage.children[0].children[i].visible = true; } //consistantly transform x stage.children[0].children[i].x -= 3; } //once they make it to the left side of the screen, visible false for no transform overhead else{ stage.children[0].children[i].visible = false; } } renderer.render(stage); }
  12. import myBitmapTextFont from "myFontsFolder/myBitmapTextFont.fnt"; let loader = PIXI.Loader.shared; loader.add([{name: "bitmapTextFont", url: myBitmapTextFont}]) .load(setup); function setup (loader, resources){ let text = new PIXI.BitmapText("abcdefg", { font: "50px Arial", //Arial is the face attribute located inside the .fnt file align: 'center' }); } Here's my quick code example made with a custom .fnt file from bmGlyph. You really need to follow the instructions closely in the instructions link Ivan shared! πŸ™‚ https://www.adammarcwilliams.co.uk/creating-bitmap-text-pixi/ο»Ώ
  13. Fixed the pixi playground link I think.. ^.^
  14. Here's an example of what my game is doing. ^.^ https://www.pixiplayground.com/#/edit/pYTkTrNrzUEica9rRZhpp I'm even seeing some stuttering in fps in this bare bones example. Although some of it might be the mouse events interactions. πŸ˜› Any big issues you see?
  15. Yes I only have the one RAF and I have 0 setTimeouts in my code ^.^
  16. I'm getting a lot of inconsistencies in fps due to requestAnimationFrame calls randomly taking a long time where it doesn't look like there is anything being called inside of it until the tail end of the call. What it does show in the call tree only takes PIXI 1-3ms to flush or update transforms while the RAF call can last anywhere from 8-15ms. The devtools are also showing that the GPU and other threads aren't doing any irregular work when the long RAF call happens. It happens at least 10-20 times within a 30 second Chrome devtools performance recording. Has anyone else experienced this kind of thing before? https://imgur.com/a/8Uh8028
  17. Has anyone ever seen this where my RAF wants to take up the entire frame (~15ms) but the processes within don't take very long (~3ms)? My app is running iOS on Cordova with wkwebview. Long RAFs: https://imgur.com/a/2KVeKJZ Processes within one RAF: https://imgur.com/a/CnUNSfk BUT When I zoom into the canvas (by doing the two finger swipe on the iPad) and then zoom out, the RAF fixes to take up only ~5ms total. After zoom trick: https://imgur.com/a/RSzmrTI Is the PIXI canvas loosing focus, like as if I went to another tab on the web? I'm not sure what is happening here, thanks for any help! πŸ™‚
  18. I haven't used any filters on any sprites or containers. πŸ™‚I don't use any RenderTexture's are they better optimized for the GPU? Overview of my resources: I have one tiling Sprite always moving, one spritesheet with all the sprites that have their position animated, all text is made from bitmap text, and the rest of the static sprites are loaded from data urls. Yeah I originally made two renderers because one didn't have to always get updated, but it needed to be updated enough that having separate RAFs gave worse performance than just rendering them both every frame in one RAF. I have thought about merging them into one Renderer, which would get rid of the composite layers. Is it better to have one renderer at full height and width of the screen? ^.^ I don't use antialiasing or preserveDrawingBuffer on renderer options but I do use transparency for background images. πŸ™‚ const renderer = useRef( new PIXI.Renderer({ width: 1920, height: 600, preserveDrawingBuffer: false, transparent: true, antialias: false, }) );
  19. I'm looking for any tips in regards to performance with the GPU and composite layers specifically. ^.^ My performance now is pretty good on web ~55-60 fps and it also looks pretty good on mobile, but it is using ~70% iPad's GPU power and only ~20-30% CPU. The code is in PIXI 5.1.0 and I have two renderers with one main RAF that renders both of them. Before the RAF starts, I'm using the PIXI.loader.shared to load in all the images and then I use the prepare plugin on all the PIXI containers that contain sprites. Offscreen sprites are all .visible = false. My main animations are constant x position subtracting to ~15-30 individual sprites on screen at a time and tinting menu sprites that are always on screen and aren't moving. Main Question: Looking at causes of composite layer paint complexity, I'm seeing that my PIXI renderers caused two layers for each of them. Is this normal for each renderer to have two layers with one saying n/a for compositing reasons? n/a layer: https://imgur.com/a/IGjPmTs Compositing due to the element being a <canvas> element: https://imgur.com/a/o4zZ21R Chrome devtools normal performance frame: https://imgur.com/a/iW3quHn I also have a lot of overlapping containers with sprites in the actual PIXI code which could be causing a higher memory estimate on the GPU's work. Is it worse to have each of the sprites in Containers when they overlap? Overlapping sprites: https://imgur.com/a/I61nBMo Thank you so much for any advice, you guys are the best! ^.^
  20. Makes sense, that solves it for me! Thank you! 🀘
  21. I believe all that is happening is it adds the backgroundColor to the border of the sprite. Does that mean I should just not have a backgroundColor when using a background html image?
  22. Sorry, I was out of town for the weekend ^.^ Hopefully this pixi playground works for you: https://www.pixiplayground.com/#/edit/DLhN7lSrT6uHC3uZAN3eJ
  23. I'm getting a side effect from having PIXI sprites over the top of an html image background. It seems like a white border or artifacts are created when transitioning between displaying the sprite and the image background. The z-index layout in html for the image and pixi: <!-- Background Html image --> <div className={css` position: absolute; z-index: 0; width: ${window.innerWidth}px; height: ${window.innerHeight}px; overflow: hidden; `} > <img src={backgroundImg} /> </div> <!-- PIXI Stage --> <div className={css` position: absolute; z-index: 2; transform: scale(${Math.min(window.innerWidth / 1920, window.innerHeight / 400)}); transform-origin: top left; overflow: hidden; width: ${window.innerWidth}px; height: 600px; `} ref={element => { props.updatePixi(element); }} /> Renderer settings: const renderer = useRef( new PIXI.autoDetectRenderer({ width: highwayWidth.current, height: highwayHeight.current, preserveDrawingBuffer: true, transparent: true, backgroundColor: 0xffffff, antialias: false, }) ); Removing sprites from the stage reveals more of the background, but adds white border artifacts to the other sprites now too. https://imgur.com/a/wCuLlbr Removing the background added white artifacts to the next sprites transitioning to the html image: https://imgur.com/a/1xOiAyc Any advice on getting rid of this? Thanks for any help! 😁
  24. No, I wasn't using any filters on it. All the colors and design were done in Adobe Illustrator before putting it in the project 😎