• Content Count

  • Joined

  • Last visited

About JTronLabs

  • Rank

Recent Profile Visitors

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

  1. So I'm interested in creating a 2D game (currently partially implemented in Phaser-CE) in JS using dynamic lighting. I want directional lights to cast shadows behind P2 sprites, be customizable by blur, dropoff, intensity, and interact with 2D normal maps (created with Sprite Illuminator), and maybe more (that I don't know yet). After doing some research, I've found a variety of tutorials for implementing point lighting in JS - Game Mechanic Explorer, Red Blob Games, 3D by Mozilla, and Byron Knoll. Phaser-CE has a Filter class for accessing GPU accelerated shaders, but its seems difficult to interface between game sprites and shaders, and there seems to be no ready-made lighting solution. Phaser3 seems to be planning some sort of lighting support, but release is far away. So I don't really want to use these options as they seem fragile or overly difficult. Illuminated seems to be the most popular 2D lighting library, though I remember reading somewhere it has some perf issues (doesn't use WebGL or something, not sure). I also came across this LightingEngine project, which while small/unknown has some really cool demos and really great documentation. Neither of these appear to have SpriteIlluminator integration though. All in all, I'm new to this and want to find the easiest way to get dynamic lighting started in a Phaser-CE game. Before I go down the rabbit hole of a specific library/start re-implementing things, I was wondering if anybody has done something similar and has some guidance. Thanks!
  2. I've had this problem for awhile now, and just figured out what went wrong. Figured I'd post for the future generations. I was setting up emitters and no matter what I did, they didn't have any speed. Eventually I discovered it is because emitter.gravity is a point object (not a number), you need to use setTo. I tried to reproduce the error in sandbox, but it still works for some weird reason. Regardless, you can fix the issue by doing emitter.gravity.setTo(0, 0); Instead of emitter.gravity = 0;
  3. The error I was receiving was: And I ended up with a different issue. I am extending a Sprite and my animations are in a textureAtlas/Spritesheet. The issue is that the animation uses frames, but the animation.add() does not know which spritesheet/textureAtlas the frames are from. I solved this issue by including the below code in the constructor. this.loadTexture(spriteSheetOrTextureAtlasKey); And now when I `add` an animation the `frames` array is pointing to the correct key.
  4. Glad it helped. I think setCircle is not relative to scale, in case you run into that issue
  5. @rblopes PMd me and we were able to figure it out. I needed to add library and libraryTarget configuration to webpack.config.js's output property. Full write up in StackOverflow post - http://stackoverflow.com/a/42302282/4180797 - THANKS FOR YOUR HELP EVERYONE!
  6. K so I got it halfway working. I changed my test script to properly reinstall the package in the test dir each time: PHASER-UI's package.json "scripts": { "test": "npm run build && cd test && npm install phaser-ui && npm start", "build": "webpack" }, The test package installs phaser-ui from a local NPM directory TEST's package.json "dependencies": { "phaser-ce": "^2.7.0", "phaser-ui": "file:../" }, Then, I included the 'Phaser' variable as an external in my webpack var webpack = require('webpack'); module.exports = { entry: './src/index.js', output: { path: 'build/', filename: 'phaser-ui.js' }, externals: { Phaser: 'Phaser' } }; So now it builds successfully and seems to work. The issue is that I don't know how to consume it in my game state. Importing and logging it only shows a generic object in the console import * as lib from 'phaser-ui'; export default class Game extends Phaser.State { create() { console.log(lib) } }
  7. Looks like it has something to do with WebPack externals, though I have not hit upon a winning configuration yet - https://webpack.js.org/configuration/externals/ Edit: I discovered the reason including all of Phaser didn't work. It seems my test project was using an old version of the `phaser-ui` library - my scripts for using a local project are not configured correctly, fixing that now.
  8. Thank you for looking it over! I just added file-specific imports and pushed to GitHub. Unfortunately I am experiencing the same error. When I import Webpack finds Phaser just fine from the node_modules and includes it in the output. Also, the consumer of the library should include Phaser, so if I include it in my bundle it will be in the final game output twice. I want some way to not include Phaser in the library output but h still have it accessible when used by a consumer.
  9. Hey there, thanks for responding! That didn't seem to have any effect unfortunately, same errors and same webpack output (I think). If I instead add "import Phaser from 'phaser-ce' ", Phaser.io will be added to the webpack build, but I encounter the same errors in the test game! The test and the src projects use the same version of phaser-ce. I intend to test the components using the Phaser game in the test/ directory (which depends the "phaser-ui" NPM package via a relative, local link in its very own package.json)
  10. I am trying to create a UI library with some useful in-game components: ProgressBar, ToggleSlider, Toast, etc. so I can re-use these across projects and to save other people from having to write these components themselves. I am having some trouble testing it tho, it looks like my NPM library does not have access to the Phaser.io game engine. Does anyone know what might be going wrong? Stack overflow post with more info here Component GitHub repo here
  11. I tested your post and I think it is incorrect. I used this.add.text and this.game.add.text, then switched between a few states. When the state began on the second time, I printed out this.game.world.children and it was empty either way. I also tried setting the texts to an instance variable "this.text = this.game.add.text", "this.text2 = this.add.text". When I return to the state the second time they still existed (soley because I save these instance refs I believe), but both had been properly .destroy()'d by state.start("XXX") where clearWorld=false by default. Thus I think I'm going to revert to using this.game.add as the code is much cleaner. In case my tests are wrong (don't think so but it's certainly possible), I didn't have any noticeable improvement gains in-game by using currentState.add.
  12. Not exactly what I was looking for. Originally was wondering if clearWorld =true would allow you to essentially "pool" sprites across state changes. I'm finally done testing it, and found no noticeable improvements (and it made the code real messy). So I've removed it. However, what you're talking about is very interesting. Not being flagged for GC is kind of a big deal. I've been led to believe (from the docs - http://phaser.io/examples/v2/sprites/add-a-sprite) that game.add.XXX is the way to go. But you're saying it'll decrease perf and lead to memory leaks? If true, that is a big help and I'm going to change this ASAP. Edit: I guess not being flagged isn't a huge deal. If you keep a reference to it it'll be overwritten next time you come to the state, and original freed for GC. If not then that would be a problem.
  13. When I start my 'Play' state from the 'Menu' state, the game is laggy for a short while before smoothing out. I was thinking that maybe if I initialized my sprite pools after Preload instead of the beginning of Play it would solve the initial lagginess. I reorganized all my states to be reusable (revive components in create() instead of creating new ones, set clearWorld = false in state.start() ), but don't think I see much of a performance gain. Might it be there but just not extremely noticeable? Even when switching to my 'Statistics' State, there is a few 100s of ms lag when starting, which I assumed would go away after the change but has not. Any ideas on why this might be? Or was this a foolhardy change to make to begin with? I'm using a Samsung Galaxy S4 with Cordova Crosswalk. Edit: I take it back. By paying a bit more attention I would say Statistics screen loads about 2x as fast, just by eyeballing/guesstimating it. Not sure why the game isn't experiencing similar gains. Has anyone else done this and found similar improvements/lack thereof? Edit: By setting visible to true/false instead of killing and reviving I further chopped off loading time for my Statistics State. Sprites in pools still have to be killed though. Edit: Now I've noticed that if I've opened Statistics, or other background states, and leave them in memory while playing the game then the game is much slower. This seems to only happen if turning off the visibility on state change, instead of killing/reviving. So I'll stick with killing/reviving, which does not seem to impact game performance (as far as I can tell). Edit: Overall I'd say this approach gave me some solid (though subtle) performance improvements. It also made the code a mess. I just discovered my performance issues were due to the lack of pooling on some random text object. I fixed that and it runs MUCH smoother now. I will probably keep the states as they are though, or maybe revert it just to test how perf would stack up. Edit: I reverted back to clearing state and have not noticed any performance hits. Turns out the Stats loading time decrease was a red herring, it happens either way. My original performance issues were due to not pooling a commonly spawned text resource. Keep reading thread for more perf ideas.
  14. Ah ok yes that is what I am doing currently. It's a bit annoying when I have a long inheritance chain, as each parent & child needs to have this check at the beginning of their update loop. Works, but makes the code a bit messy. It would be nice if the update signal for sprites/groups/text/displayObjects would only ever be triggered if they were alive. That way it not have to call the function or check alive/exists conditional. I posted about this issue here for Rich to take a look at https://github.com/photonstorm/phaser/issues/2776
  15. @tips4design I lold at the zombie comment. @rgk I think destroying would be really inefficient, and make it hard to pool as it auto-removes the sprite from its Group. @darkraziel are you suggesting overriding/editing the base Phaser engine to achieve this behavior? Currently I am including `if(!this.alive) return;` at the beginning of every one of my game loops, but it's messy code and I am not a fan. Over-ridding the base engine would be a lot cleaner, but would require manual, annoying setup after downloading/pulling from an NPM package. Do you have a link to Rich's original answer?