jcs

Members
  • Content Count

    201
  • Joined

  • Last visited

  • Days Won

    7

jcs last won the day on February 7 2014

jcs had the most liked content!

About jcs

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    http://jcd-as.github.io

Profile Information

  • Gender
    Not Telling
  • Location
    usa

Recent Profile Visitors

1094 profile views
  1. you could rotate the sprite around its own center, then translate it out from the center and then rotate it the other direction - this is how you would achieve this using linear algebra or you could follow jerome's suggestion and just do the sin/cos math the latter will be faster, in general, as you can optimize it for the fewest operations. but the former may be easier if you prefer linear algebra (vectors and matrices) solutions. personally I'd go with the latter - it's simpler and easier
  2. I imagine that they all preserve variable type immutability for the simple reason that not doing so would actually be more difficult than doing so. the minifier need to analyze the code to know that a particular variable was no longer in use and safe to re-use. closure compiler does some of this kind of analysis - and yui's minifier might as well- but simpler minifiers don't. while closure compiler does some deeper analysis, the fact that it comes out of google where they are very aware of the JITters strengths and weaknesses would indicate to me that it wouldn't do any tricks like trying to re-use variable names in the same context. plus, there would be very limited usefulness in re-using variable names like this. it isn't likely to be beneficial in any case I can think of off-hand, and if the minifier got it wrong the generated code would be completely broken...
  3. the maximum texture size that a given device can handle depends on a number of factors: the actual hardware, the hardware drivers, the OpenGL drivers, and the browser's WebGL/canvas implementation. it's *probably* true that if the hardware & driver support a given size that the WebGL implementation will support that same size (it's hard to imagine why it wouldn't, but it's not impossible). for instance, iPhone 4 and later support 2048x2048 pixel textures in their OpenGL ES 2 implementation, so that's probably a safe bet if you're targeting iPhone 4+. but early versions of the 3gs only supported 1024x1024, so if you're targeting older systems, you might want to limit it to that. I believe only the Retina iPads (not phones) support 4096x4096. android devices are a very mixed bag, but newer devices are generally at least as capable as an iPhone 4. there's not going to be a hard-and-fast rule for all devices, unfortunately. 1024x1024 is going to fit on any device you'd care about, and 2048x2048 is probably safe too - if your game is using that many images or that large of images then chances are good it won't run well on those old devices anyway . but the only way to know for sure is to try it on a given device.
  4. (you can work around this by passing javascript objects instead of simple scalar types, or by putting 'variable' inside of a javascript object. e.g. var o = { 0: variable };doSomething( o );or var a = [variable];doSomething( a );with doSomething defined like: function doSomething( o ){ o[0] = 'cat'; // or whatever}it's not the most elegant solution in the world, but it will get the job done)
  5. no worries. I think you'll find the "d'oh... woohoo... d'oh" experience never stops
  6. agreed. as long as you follow some simple 'best practices' (which you should anyway) like not mutating objects, then the code generated will be good. the problem with temporary objects is the GC - if you're allocating objects in your game loop eventually the GC will have to run. when the GC runs it takes ms away from your game, which can be enough to cause your frame-rate to 'stutter', which can look worse than just having a lower frame-rate. but temporaries that are simple, atomic types (and aren't mutated) will be optimized into (the javascript equivalent of) stack variables by modern JIT compilers and won't incur GC overhead, so there's very little reason to try to "optimize away" every last local variable - you'll just end up with un-readable code. I agree with the sentiment about the prototypical object model as well - and the JIT compilers do a great job with it too. (if you look on jsperf.com you'll find lots of examples of different tests comparing prototypes to other patterns and prototypes do very well in all the modern compilers). I've little to say about the rest of this thread - personally I feel that require.js etc are over-engineering for the size of most of the javascript projects that I work on and I just cook my own very simple module-like system - but, each to his/her own (!), and it's great to see different alternatives put out there for people to learn about!
  7. that really depends on a lot of factors - there's no good answer for everyone and every game. the most important factor is probably your target machines/devices. if you're trying to run on pre-4.0 android devices running the old android browser then you are going to be very constrained - dozens of sprites could be a problem, let alone hundreds. on the other hand, if you're only concerned about running on new desktop machines then you've got lots of room to play (I've got a particle test that runs many tens of thousands of particles/sprites before it starts to slow down too much on my laptop - it's just using Pixi, not Phaser, but Phaser 2 should be comparable). most ppl will fall somewhere in the middle. the only sure way to know is to try it and test it on as many devices as possible. obviously there are other factors besides just raw numbers. how large they are and how much texture memory is consumed are going to be big factors. if you have lots of sprites that all use the same texture then that is going to perform much better than fewer very large sprites with separate, very large textures. also, general memory consumption is going to be an issue on phones/mobile devices. I have a pretty simple game (side-scroller) game level that causes iPhone 4 to blow up consistently and I'm pretty sure it comes down to memory usage. and then there's memory allocations and the garbage collector. the more objects that are needing to be collected during your game loop, the more often the garbage collector will have to run, pausing your game for a few ms and possibly causing its frame rate to "stutter" - which can look worse than just having a slower frame rate. it's best to keep javascript object allocation out of your game loop. note that this (mostly) applies to *objects* (meaning '{}' and '[]') - temporary, local variables are handled better by the JIT compilers in browsers these days, particularly if they are simple, atomic types like numbers. anyway, the long and short of it is to test, test, test. it won't take long before you find a "sweet spot" for your game.
  8. the rendering pipeline for sprites and tilemaps is completely different. tilemaps are much simpler than sprites and they should be more performant and consume less memory than rendering individual sprites for each tile
  9. FYI, I have the exact same issue. I only realized that it was a recent Pixi issue after reading this thread (and doing some testing), as I hadn't tried 1.4 on mobile. I've had WebGL turned off on android because the performance was so bad (but I'm getting ~60fps with canvas, so I was ignoring it for the time being) I've tried it on the Nexus 4, 5 and 7 with the same results - WebGL gets a frame-rate in the low 20s, Canvas right at 60 (once the JITter has settled, anyway)
  10. not entirely sure about the behavior you're seeing, but your sprites are all being added to multiple groups, because calling the function 'game.add.sprite( x, y, key, frame, group )' adds sprites to the 'world' group if no group is specified in the 5th parameter. so playBtn = game.add.sprite(game.world.centerX, game.world.centerY+60, 'playBtn');adds 'playBtn' to the 'world' group, and then you are also adding it to another group. if you want to create a sprite without adding it to any group (including the 'world' group), just create it using 'new'. e.g.: playBtn = new Phaser.Sprite( game, x, y, key, frame );and then add it to the group you want it in. OR use 'group.create()' (which is what game.add.sprite() is calling), e.g. playBtn = someViewICreated.create( x, y, key, frame );
  11. I believe this is because your call to: map.setCollisionByExclusion([ ], "groundLayer");should be: map.setCollisionByExclusion([ ], true, "groundLayer");the second parameter is 'collides' - a boolean indicating whether to set or clear collision. the third parameter is the layer (FYI, what is actually happening when you make the call with those parameters is that Javascript converts the string to a boolean value - which is "true" - and gets "undefined" for the third parameter. when it sees that the third parameter - the layer to set collision on - is 'undefined' it assumes the current layer, which in this case is the sky layer, not the ground layer)
  12. are you using putTile()? if so this is probably issue #371
  13. possibly. it looks like the entire line is being picked up as if it is a single tile. but it's hard to say without knowing more. have you tried debugging it and seeing what tiles Phaser creates?