• Content Count

  • Joined

  • Last visited

About forleafe

  • Rank
    Advanced Member

Contact Methods

  • Twitter

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Okay I have to ask, What in the world are you doing that needs 10,000 sprites? My focus is primarily 2D animation/art and I can't think of a thing that would need that many sprites. Even 10,000 raindrops would be extremely noisy and distracting I'd think. Don't get me wrong though, I find it fascinating! Thank you so much for your explanation though. I have a much better idea of how the particle container works.
  2. Yep. Spot on! That fixed it. Thank you so much. okay so this begs a few questions. 1) What exactly are particles and when is a good time to use them? 2) Why would a particle container prevent animations from running smoothly? I thought the very purpose of them was too offload rendering to the gpu or some thing like that.. so I can render more sprites on screen at once.
  3. Tried on the latest version of pixi 4.8 and it made no difference. Guess I'm gonna have to build my own time based animation code. @botmaster Going to have to look more closely at your code, because at a glance it didn't really make any sense. Value/T = total value per miliseconds. - Value? Value of what? What's this function trying to give me?
  4. So I actually wasn't previously using .update() for my animation and setting autoupdate to false in the animated sprite. I tried implementing what you've written here into my code, sadly to my disappointment, it didn't change the behavior at all. It's still skipping frames and not running smoothly at all. Let me post some relevant snippets from my code 😕 Something I thought I'd also mention. I'm running PIXI 4.3.4 Not sure if that has anything to do with it though //Frames are added first then the animated sprite and it's properties are created below. player = new PIXI.extras.AnimatedSprite(frames, false); = "player"; player.circular = true; player.anchor.set(0.5,0.5); player.position.x = 350; player.position.y = 1130; player.animationSpeed = 12/60;; //The renderer will update the player sprite so long as we're in the play state. renderer.ticker.add(function(delta){ deltaGlobal = delta; if(state==play){ player.update(delta); } state(); }); if you'd like to see the full code, you can see the attached file below, or download the current build from my github page. main.js
  5. How do you target an FPS?- Well... I guess you're using you're own custom ticker... but yeah, the above code on my original post is literally copied straight from my game. So if I was supposed to do something additional then I likely didn't. Actually, it sounds like on your custom code you've done something additional that I haven't and that I don't know to do that's letting your animations work properly. Is there an example of how to code this properly so frames are limited and animations are smooth?
  6. Yes, of course it does. 😕 It's not my machine. Like I just said, I tested my frame animation without the ticker and it immediately ran smoothly like it should. Are you positive the ticker is built to work properly with animationsprites? Because botmaster literally just said the opposite, and I can't see why smoothie.js would even exist if the ticker already had this functionality built in. I can provide some code of mine if needed so maybe we can see more easily what's going on? What would you suggest is the solution to this then? Smoothie.js As I've looked up actually isn't in a working state for pixi v4, and was written for v3. I've asked the developer if he can update his code, but they've been a bit unresponsive lately. Are there any other popular alternatives that people use for timebased animation? I mean, this has to be a pretty common problem for sure.
  7. My sprites are animated with a spritesheet loaded through the pixi loader, the frames are then added to Pixi.extras.AnimatedSprite, and then that animated sprite is added to the container, and then played using (play). It'll play but run choppily. Just to test out my animation to see if it was the issue, on a separate file that didn't use a ticker, the animation ran smoothly.
  8. I'm not really sure that my issue is being understood, let me try explaining better. If I don't control the framerate with a delta, then higher end machines will run the game way too fast, in the blink of an eye, while slightly slower machines the game will literally run at a different framerate and possibly lag. I don't think I have any other choice to control this except with a delta, right? That way everything is a constant framerate. Okay, the issue is that because my framerate is being controlled, for whatever reason, PIXI.extras.animation doesn't at all take whether or not you're using the ticker into account(or does it?). So because of this it's literally dropping animation frames and running like crap. Not being able to control my frame rate and animate sprites smoothly is... sort of a big deal. What my mind is sort of blown on is why this isn't already taken into account with pixi's framework. I mean, I think the real question here is, how am I supposed to build an app *without* using a delta and any animations? Without a delta your user's framerate is completely at the whim of whatever the device is. So if I'm using newer hardware, it'll be like playing super mario on 5x speed. Sorry for the wall, but I'm trying to be thorough to make sure I'm not misunderstanding or missing something. Having to code a way for animations to work with a delta feels like me doing something that is so basic and ubiquitously needed, that I'd be reinventing something that someone already did. Edit: I feel like I'm struggling to express myself properly. Here's a blurb from Smoothie.js 's page that is pretty much exactly what I want. To keep my frame rates smooth and not gittery. "You can also add a Boolean interpolate property that defines whether Smoothie should use interpolation (true) or not (false). interpolate: true If you set it to false, Smoothie will render the sprites and the update function logic at the same frame rate. That means jittery animation at low frame rates - if that's what you want, you've got it!"
  9. I'm making a game where the game loop's frame rate is controlled and kept consistent with: renderer.ticker.add(function(delta){ deltaGlobal = delta; state(); }); However because of this, it causes my sprite animations to skip frames and look extremely choppy and ugly. Does pixi have a built in way to handle this that I'm just not seeing? Or are we still forced to use external scripts like this: Obviously if there isn't a built in feature for animations to run smoothly while the framerate is being controlled with a delta, then that might be a pretty essential feature that should get added soon.
  10. Thanks for that. I'll take a look. Either way I appreciate all the work you do for this wonderful tool.
  11. Honestly, out of every answer posted here, this is literally the only one that has made any sense to me. As far as the sprite sheet goes, yeah I'm doing the exact same thing as you. Putting everything on a single sprite sheet just seemed like common sense. I don't really understand why a person would want to use multiple sprite sheets when one will work fine and be more efficient. Anywho, I'm going to study how Pixi's animation tools work and see if there is a way to implement what you have here into the tools Pixi has already built. But a moment a brutal honesty here, the devs for Pixi need to take a serious look at implementing some form of animation swapping on a single sprite, and include it within pixi's code. I think this falls well within the scope of common features that Pixi should be able to do right out of the box. I shouldn't have to take apart Pixi's code nor reinvent a feature that pixi already has included, just so I can achieve something so basic and so common that a great number of users need. Google is littered with people asking how to achieve this, and every answer is a convoluted amalgamation of custom code and head scratching "Do it yourself" confusion. Anyways, thanks for the help. And sorry if this is coming of confrontational. It's not meant to be. Edit:: I had a thought. Is there a way to set the loop bounds? If there was I could, theoretically, load in every frame of animation when the sprite is first loaded, and only play a specified section of the loop. "goToAndPlay()" could handle that pretty well. The only part missing that I can't find is a way to restrict the loop boundaries.
  12. Thanks. My only question is, how would I access the new textures if I used this method? "AnimatedSprite.textures = new Textures" would create a new array of animation frames under the "AnimatedSprite", right? So how would I differentiate between the different sets of frames? I hope this question is clear and that I'm not misunderstanding too badly. Thanks for your help.
  13. I mean, is It? I'm not a master programmer by any means. But it just felt a little like a cumbersome work around. I figured since there was a really good system in place to create animated sprites, there would be a system in place to swap them easily. If this is the best way then thats fine i guess.
  14. I feel like this is something that gets asked a lot, but after searching a bunch I haven't found anything definitive. I've loaded my animations into pixi via a spritesheet on the Pixi loader and I can place an animated sprite in the game easy enough. But say I have my main character perform a running animation, but then I need her to do a punching animation. Is there an easy way to achieve this on the same sprite seamlessly? The only way I can currently think of how to achieve this is to manually remove the animated sprite from the container, then manually add a new animated sprite in its place, which just seems cumbersome and inefficient at best.
  15. The rope code might be a bit above me. I'm having trouble wrapping my head around it. I think that's mainly because there's a lot of stuff in there that doesn't have much to do with what I need. The giant texture idea sounds okay. To make things clear, you're basically saying take the cardiograph line and turn the whole thing into a sprite? Then I can manipulate it's frame with this? How do I call that? sprite.frame.set(x,y) ? and then couldn't I control it's transparency with an alpha mask or something?