Joe Kopena

Members
  • Content Count

    15
  • Joined

  • Last visited

About Joe Kopena

  • Rank
    Member

Contact Methods

  • Twitter
    tjkopena
  1. Thanks, I'm glad you got something out of it! I believe it's the same as for the Retina displays. The DPI on high end Androids is similar or even above Apple devices at this point, so you'd want to use hi-res images for the same visual quality reasons. Even my now aging S3 has a ridiculously good display compared to my laptop, and requires double scaling the assets to get a useful image size. My assumption is that this issue is mostly only talked about in terms of Retina because: It's more recent that there are such non-Apple devices;The capability is not as conveniently branded under a single trademark buzzword ("Retina");There's a lot more variance across Android devices so it's similarly not really meaningful to discuss as an Android thing and there are literally billions of Android devices to which it doesn't apply.But if the DPI on a device is high enough, I don't see why you wouldn't apply the same techniques. That said, I don't do this professionally or anything, so there could certainly be something I'm missing.
  2. I don't think this is an actual problem with TexturePacker. It has a quite extensive command line system. I'm not sure if there is a built-in config file format, but clearly the command line options can be captured and fed into it essentially identically. It also has a system for not rebuilding spritesheets unnecessarily, determined via hashes. in my experience it actually integrates pretty well into an automated build setup; I invoke it primarily through Makefiles and Ant projects.
  3. Isn't the OP's request actually much simpler? Don't you just want to make both of the containers children of another container and then render that root?
  4. I have a recent Pixi-oriented tutorial on scaling while preserving aspect ratio here: http://www.rocketshipgames.com/blogs/tjkopena/2015/09/basic-scaling-animation-and-parallax-in-pixi-js-v3/
  5. Thanks for pointing that out, Andreas. In previous projects I had been generating spritesheets using a workable but convoluted and very manual series of ImageMagick tools (montage, etc) and Makefiles. I'm still new to TexturePacker, but definitely sold on upgrading to the full version for my next project.
  6. In (re)acquainting myself with Pixi for some hobby projects, I put together a simple example and walkthrough of scaling to fit device dimensions, using hi-res resources, animating a sprite, doing some basic parallax scrolling with tiling sprites, and assembling spritesheets with TexturePacker: http://www.rocketshipgames.com/blogs/tjkopena/2015/09/basic-scaling-animation-and-parallax-in-pixi-js-v3/ The code is very much based around Pixi, but it's easy to understand without being familiar with that API, and I thought the article makes enough broad points to be worth crossposting to this general 2D forum in hopes that others may find it useful. Thanks!
  7. In (re)acquainting myself with Pixi for some hobby projects, I put together a simple example and walkthrough of scaling to fit device dimensions, using hi-res resources, animating a sprite, doing some basic parallax scrolling with tiling sprites, and assembling spritesheets with TexturePacker: http://www.rocketshipgames.com/blogs/tjkopena/2015/09/basic-scaling-animation-and-parallax-in-pixi-js-v3/ I hope it's of use to somebody, and would love to hear any comments about any errors or sub-optimal code. Thanks!
  8. I've started using Howler.js for audio in some simple games. It takes care of loading sounds, but doesn't seem to have any preloading mechanism to fetch files before a Howler (sound clip) is created, i.e., in-game. Does anybody have any thoughts on how best to preload for it so sounds are ready to go as soon as the action starts? At the moment I'm leaning toward having Howler figure out which codecs to use, and then downloading the appropriate files so they're at least in the browser cache. Possibly I'll rework Howler a bit to use a cache internally. Is anyone aware of such a thing already? Thx
  9. This weekend I've been playing with fullscreening, specifically SHOW_ALL, and had some challenges getting the stock examples and project template to work correctly on both my laptop and phone. After mostly nailing those down, I have a blog post up that may be useful to others: http://www.rocketshipgames.com/blogs/tjkopena/2014/10/fullscreen-scaling-in-phaser/ I've also posted that demo code and the start of a revised boilerplate project template to GitHub: https://github.com/RocketshipGames/phaser-fullscreen I'd be appreciative of any comments, suggestions, and pointers to best practices. In particular, next I'd like to figure out why it gets scaled disproportionately in Firefox. I'm also not sure the orientation prompt (in the larger project) is being handled optimally, it shows flashes of rotated screen in the transition though there may be nothing much to be done about that. The standard project template doesn't show the orientation prompt at all in fullscreen mode because of the div not being contained in the fullscreen element. Thx
  10. For me the demo scrolls nicely in some sense but has unacceptable graphical glitches. Check out the black bands along the left and top sides: http://rocketshipgames.com/tmp/bugs/20140707-tmr-bug.png These appear and disappear, causing the edges to flicker when scrolling. When you stop scrolling they stay in place, so if you catch it at the right point in the flicker cycle you just wind up with a view like this. If you scroll along the opposite axis from a band it remains blacking out the edge of that layer. If I make the screen bigger the band is on the right side. Depending on screen size the bands can be a bit bigger or smaller. This happens for me in both Chromium 34 and Firefox 28, Lenovo laptop with some kind of Intel graphics chipset.
  11. I enjoyed this more than I should have. Totally dig the art & music. Thanks.
  12. Also note that many of them have simply been cribbed from OpenGameArt.org, and presumably other sources as well.
  13. If you're just trying to attach a weapon decorator to the sprite, you probably don't want to attach physics to the weapon. The main sprite would move about, rotate, collide, etc., and the child sprites are basically just getting drawn on top of it.
  14. I haven't fully deciphered this, but for now at least seem to have worked around the problem. It seems like it's something about using a pivot setting to place the bullets out on the arms. They show up for a cycle or two near the center of the shooter, then pivot out (hence the brief flicker at the center of the robot). That allows them to penetrate the walls without being checked, and once inside the collisions fail for possibly a variety of reasons, including the faces not being interesting because there is an adjacent colliding block, etc. I switched to doing the trigonometry manually to place the bullets initially and I no longer have either the flicker or the collision problem.
  15. I've been experimenting with Phaser a bit the past few days. I've encountered a problem with sprites not overlapping with tilemaps. Two captures follow with slightly different settings in play. 1) 2) The robot near the center is a sprite, shooting other sprites. It has moved hard up into the corner of a couple walls defined by a tilemap, such that when the bullets appear they are already inside colliding tilemap tiles. I would expect the bullets to overlap and be killed by my handler. Note that they do collide otherwise, so there's no basic problem here of improper collision flags or such. The green boxes are the body debug draw, showing that they're in the right places. This is using arcade physics, Phaser 2.0.5. I can't find any "reasonable" setting of TILE_BIAS, tilePadding on the bullets, velocities, etc., that prevents this problem in all cases. At first I thought the bullets were simply moving too fast, hence their velocity is much slowed down in the second capture. In both cases though they're clearly squarely in the middle of the colliding tiles for several cycles, but still no overlap. Note in the first example that the angles work out such that the left shot is probably starting right on the edge of a tile and is properly detected after it first enters the tile (hence the slight flickering). Currently I have TILE_BIAS set to 40 and the following creation code on the bullets: this.pBullets.createMultiple(40, "player-shot"); this.pBullets.setAll('anchor.x', 0.9); this.pBullets.setAll('anchor.y', 0.5); this.pBullets.setAll('pivot.x', -30); this.pBullets.setAll('body.width', 4); this.pBullets.setAll('body.height', 4); this.pBullets.setAll('body.tilePadding.x', 16); this.pBullets.setAll('body.tilePadding.y', 16);The tilemap is created as such: this.map = this.game.add.tilemap("map", 32, 32); this.map.addTilesetImage("tiles"); this.map.setCollisionBetween(0, 10); this.map.setCollisionBetween(28, 38); this.map.setCollisionBetween(56, 67); this.ground = this.map.createLayer(0);The collision is called as such: this.physics.arcade.overlap(this.pBullets, this.ground, this.bulletHitWall, null, this);And the overlap callback is: bulletHitWall: function(bullet, wall) { bullet.kill(); },Any thoughts? Thanks