• Content Count

  • Joined

  • Last visited

  1. Removing the text seems to give me around 40FPS on BlueStacks, but only around 10FPS on my phone. Odd. Maybe trying to render an 800x600 game onto a 320x240 device is the reason why. 10FPS is pretty much unplayable. I'm stuck for now.
  2. This was fixed due to yet another bug in my transitioning code. Epic fail.
  3. I tried this and it didn't work. I debugged into Phaser. It processes all events in a for-loop. Even when I change state, it's basically impossible to stop the event processing. There's something weird going on with variable values. To use your code as an example, hasExit is set to true, but both events fire and print out that it's false. I can't figure out what the cause is there. I also discovered that most of the other bugs are my fault (no surprise there). I still would like a way around this. It appears benign, though, that the transition happens twice.
  4. TLDR: overlap callbacks happen twice even when I destroy objects and change scenes, can I stop this somehow? You can see it here: Browse to all the way to the right, through the gap, and to the next screenNote the debug console says "****** Move done." twice. Longer version: I'm using group.overlap(this.player, this.transitionTiles, function(...)) to detect when the player steps on a transition tile and should move to the next screen. When the user steps on two simultaneously, the transition happens twice. (I can't just make the gap one tile high because you'll never be able to step on it). This appears very odd, because I am literally destroying all the objects, groups, and even (for illustrative purposes) changing the game state to something totally different -- you can see from the TLDR case above that you're shoved back to the titlescreen. I would think destroying the original group, and tiles, and even changing the state would abort the second event from firing. But it seems that it's queued up internally, and I can't avoid it. I'm pretty sure this is causing more bugs (try transitioning maps a few times). How can I fix this? (P.S. it's all CoffeeScript but you're welcome to look at the source, or generated Javascript, if you want)
  5. I tried: - Phaser 2.0.7 (no effect) - CANVAS mode (big performance boost) It's still super slow. I'll have to come back to this later. I still need to try: - PhoneGap + CrossWalk app - Removing text - Removing some logic Thanks all.
  6. I tried CocoonJS and I didn't like it. With PhoneGap, after waiting about 15-20 seconds, I get a "hello world" app building to ~300kb. With CocoonJS, after waiting around three minutes, I get an equivalent 18MB app.
  7. I made a very simple game where you have a dragon flying on screen and collecting balloons. You can play it here, courtesy of GitHub Pages. You can view the source on GitHub, but be aware that it's CoffeeScript. (If you want to see the raw Javascript, you can see it here.) The game runs fairly quickly on my dev boxes in Chrome (tested in Linux VMs). It doesn't have much; maybe 10-15 sprites on screen at once, one text object, and some sine waves (yeah, I know, I couldn't resist). I built it using PhoneGap's cloud build service (it's quick to set up). But it runs slow on Android. Really slow. Oozingly slow, like a few frames per second. I'm not sure why. I checked it on my phone (Samsung Galaxy Discover -- circa 2012). I also checked it on BlueStacks, which should run lightning-fast on my desktop PC. It's still slow. Any suggestions? Is it because I left the drawing mode in AUTO instead of CANVAS?
  8. You are awesome. Thanks very much!
  9. Following the usual nine-part Phaser tutorial on making a platformer, I see code like: scoreText = game.add.text(16, 16, 'score: 0', { fontSize: '32px', fill: '#000' });Changing the fontSize property doesn't do anything. I tried multiple values (8px, 72px, etc.) as well as different types ('72px', '72pt', '72', 72, etc.) -- all to no avail. Am I doing something wrong?
  10. The answer is that the variable gets bound to, which is appropriately global.
  11. If that's true, is there a different physics engine that solves this problem? Not being able to guarantee stable physics at low framerates is pretty problematic, what with the large range of available phone hardware (not to mention PC/web).
  12. I started using this excellent Phaser tutorial: I skipped to part nine. I added a method called createStar(), which I call twice when a user collects a star: function collectStar (player, star) { // Removes the star from the screen star.kill(); createStar(Math.random() * (800 - 96)) createStar(Math.random() * (800 - 96)) // Add and update the score score += 10; scoreText.text = 'Score: ' + score;}function createStar(x) { // Create a star inside of the 'stars' group var star = stars.create(x + (Math.random() * 60) - 30, 0, 'star'); // Let gravity do its thing star.body.gravity.y = 100; // This just gives each star a slightly random bounce value star.body.bounce.y = 0.4 + Math.random() * 0.2; if (starsText !== 'undefined'&& starsText != null && stars != 'undefined' && stars != null) { starsText.text = 'Stars: ' +; }}(Note: in the initial for-loop, pass in i * 70 to reproduce the original behaviour.) As you can imagine, eventually, you can get to lots and lots of stars. On my Ubuntu VM, I clock in around 800 stars before the FPS drops to 30. Some observations: - The game stutters when I move into a place where I collect a ton of stars -- looks like the collision handling - Once I reach around 10-15 FPS (first noticed at 13 FPS), I sometimes try to jump onto the bottom platform but fall through instead. Is this a bug? In other frameworks, when you control the update call, you can usually call it with a small value if a large amount of time elapses, eg. if one second passed since the last call, you advance game time by calling update(100ms) ten times. This is supposed to be the fix for high-speed (or low-FPS) physics. Full PasteBin is here:
  13. ashes999


    For those of us who are easily confused, the correct usage is: 1) game.time.advancedTiming = true (for example, in your state's create) 2) game.time.fps returns the current FPS (after the first 1s of your game). You can draw it in your state's update method.
  14. Sounds fun but I already have my own CoffeeScript project in progress, sorry. Pair programming is not really my thing.
  15. Question updated. It's not the game state, but the assignment to "game" vs. "@game". I looked at the generated JS (obviously?) and some other stuff (see initial thoughts) -- I think it has something to do with CoffeeScript putting everything in an anonymous lambda (and thus limiting scope), but I can't quite tell what the difference is and what @game belongs to.