Mezei

Members
  • Content Count

    8
  • Joined

  • Last visited

About Mezei

  • Rank
    Newbie

Recent Profile Visitors

528 profile views
  1. Thanks for the quick response rich and I very much agree with you about those! We'll surely keep v3 for our current project, I just hope other Pixi/Cocoon developers will keep an eye out aswell! I'll probably forward this topic to the guys at Cocoon.io so they can have a look at it instead of me! It really must be something that their in-house browser doesn't like about v4. I hope they'll fit eventually!
  2. In short, I've just recently updated the html5 app I'm working on to use the newest version of Pixi (v4) recently. It looked nice & all and it basically didn't break anything. (Well, except for a ColorMatrixFilter because v4 for some reason has a padding attribute set as default to 4.) Anyway, I was really happy with the new promises such as WebGL renderer mobile optimizations and I quickly compiled my project (using Cocoon.io) to an Android apk to test. Well saying that it ran slower is an understatement. Gameplay parts where the previous Pixi v3 provided an estimated 50-60 fps, this struggled to get 20-30. I made some other changes to the code so I wasn't sure if it was the update's fault at first, but I quickly reverted to v3 and regained the old and much better performance. Some info: - I'm probably not using any SpriteBatches - I'm initializing the renderer as this: renderer = new PIXI.WebGLRenderer(window.innerWidth, window.innerHeight); - I'm drawing a lot of Sprites with different sizes at the same time, maybe 100 at max - A lot of the above Sprites are visibility/alpha toggled many times during gameplay, but I do not store them outside the render area - I'm using manual scaling on a lot of Sprites individually, I just rarely scale a container Well, that's all I could think of right now. The strange thing is that v4 actually seemed to run faster on desktop (Firefox).
  3. Hello guys! We (an astonishing team of two!) have just released our little, casual, Dragon/Baron (boss) kill themed game based on the popular moba. It was built using Pixi.js 3.x, Cocoon.io (Cordova being behind the stuff) and is currently available on Android. (Although an iOS verison is in plans!) You can get it on Google Play here for Android! We also plan to release its "native" Html5 version on our site soon, for those on other platforms! Good luck to all the fellow Smiters and have fun! Here are some screenshots from the game:
  4. Allright, I've sent a mail to the address! Though you can also find a download link a few posts above. Thanks!
  5. Hi xerver and thanks for helping out! I tried the fix but it made no difference whatsoever. I have to note though that I do not modify/use the "resolution" property on any of my Sprites/Containers neither in the real or the test projects I've uploaded.
  6. Update 2: I managed to create a test case where things are clearly visible. At first I was unable to recreate the bug, but then modifying the spritesheet json (and probably setting rotated: true and rotating an image frame) made it appear. So coming from a JS dev perspective... my blind guess is that there is a minor error in the CanvasRenderer code and when it finds the rotated flag as "true" it does the actual rotation but breaks other things (maybe sets or resets some inner properties it shouldn't or someone made a typo there). Anyway, here is the test case (a zip with 2 projects as folders): http://www.filedropper.com/canvasbugtestcase (The grey "Download This File" button is the real one!)
  7. Update: After messing around with properties, reading pixi(.dev).js source and reorganizing my project I could narrow down the problem a little bit more: This "dispositioning" only happens if I am using Spritesheets. If I just simply throw around all the images as individual files, everything works fine. My spritesheets were packed with TexturePacker (as a command line batch) into .png files (with a max size of 1024*512 per image, so large number of assets go into multiple png and descriptor files). I've used .json as their descriptor and have rotation allowed in the settings. It's might worth to note that back in Pixi 2.x TexturePacker rotation wasn't supported (it was stated by some Pixi official) and that's one of the reasons I've upgraded to 3.x. Anyway, considering the game still works properly in WebGLRenderer without a pixel of error I can only think of the CanvasRenderer doing something wrong! I'll try to upload a test case (with both renderer types) to show the exact problem.
  8. Hi and hello there fellas, I'd like to request your help in solving a strange Canvas bug. First of all I'd like to state that I've already released an Android/iOS game using Pixi.js (and Cocoon.js) so I do have some experience in Pixi.js stuff and I'm at least not a complete rookie. I've just recently updated my current work-in-progress project from Pixi 2.x to 3.x, which took a few hours because like half the api was deprecated. But thankfully those guys at Pixi made a deprecation.js file which made the changes a lot easier. After updating all parts of my project I have come to a state where it works just like it used to - well, in WebGLRenderer at least. As soon as I switch to CanvasRenderer (which is a must for me because of performance reasons) all hell breaks loose and images just disposition themselves randomly without any consistency or reason. I'm attaching 2 images, one from a WebGLRenderer and one from a CanvasRenderer standpoint. (It is important to note that this project worked flawlessly in both renderers back in 2.x.) So basically, what happens is... I have no idea. What is happening? In the webgl screenshot you can see that the images are positioned correctly. But in the canvas one, Some of the images are not displayed in the correct position even though their position.x/y or scale.x/y or whatever attributes have obviously not changed at all. Which makes this even more inconsistent is that I have at least 4-5 screens in my game (each being a different DisplayObjectContainer, now Container) and each screen's container seems to render a different amount of images correctly and/or wrong. I've looked all over my assets' attributes to see what changed but considering that the WebGLRenderer works perfectly and both renderers also worked perfectly in Pixi 2.x I can only assume that there is something wrong with the new CanvasRenderer. Can anyone with some insight on this or someone famous(!) like Xerver or GoodBoyDigital help me out with this? [] I'd be really grateful!