gabenix

Hey Guys, There's lots of good information on this thread! I'd like to add my two cents about the method that is working for me ;-) The method I chose fills the screen as well, but also scales/zooms the game content to keep everything purportional based on either the vertical or horizontal ratio of your initial development size (you must choose one or the other), it also keeps the coordinate system for sprites, physics, etc the same. This method works best for my needs and I feel could be helpful for others. Games that have worlds that move horizontally such as endless runners will use a scale based on the height. Games that have worlds that move vertically will use a scale based on width. Below are examples of how a horizontal scrolling game would appear on screens with different sizes and aspect ratios. And the code is below.. To keep things simple I havn't included any code for "safe zones" or device orientation. <script type="text/javascript">var gameWidth = window.innerWidth * window.devicePixelRatio;var gameHeight = window.innerHeight * window.devicePixelRatio; // HORIZONTAL SCROLLING GAMES - The base height you choose to develop the game - will be used to initialize game scalingvar devY = 500;// VERTICAL SCROLLING GAMES - The base width you choose to develop the game - will be used to initialize game scaling//var devX = 500;// Initialize scaling for horizontal scrolling gamesvar game = new Phaser.Game( (devY / gameHeight) * gameWidth, devY, Phaser.AUTO, 'game', { preload: preload, create: create, render: render, update: update });// Initialize scaling for vertical scrolling games//var game = new Phaser.Game( devX, (devX / gameWidth) * gameHeight, Phaser.AUTO, 'game', { preload: preload, create: create, render: render, update: update }); function preload() { game.scale.scaleMode = Phaser.ScaleManager.SHOW_ALL; game.height = gameHeight; // Assign the available window Height game.width = gameWidth; // Assign the available window Width game.scale.refresh(); // Scale the game to fit the screen // Your code... }function create() { // Your code...}function update() { // Your code...} </script>Basically you will choose a "base" height or width to develop your game. You can then develop the entire game around that base height or width using normal x,y coordinates for sprites, tilesheets, physics etc. A couple things to consider... The window cannot be resized by just using the above code. Also, you need to ensure that you have enough game content to fill the screen for wider or taller screens depending on which axis you based your scaling.

Thanks for the reply Ben! I suppose converting to and from emitters and groups isn't that difficult and I can test it both ways. The issue I'm trying to overcome now is access to individual particle parameters. I've started a new thread on that subject...

Hello All, Is it possible to access and change the properties of individual particles released from an emitter? (without requiring an overlap detection) Let's say I've emitted 3 particles from an emitter... Is there a way to retrieve the properties of each particle (x,y,velocity,rotation, etc) then execute code that will be applied to that single particle if it meets certain criteria? I've been using emitters to create enemies, projectiles, and scene objects. Many times there are multiple on the screen at one time and they need to be accessed and respond individually. A scenario that I've came across is the combination of particles from different emitters that must work together. For example, you have an "enemy" particle, that will shoot a a "fireball" particle from the "enemy" particles current location... then the "fireball" particle will be followed by an emitter to create a smoke trail of particles as the "fireball" particle travels. I've come up with a work around by placing a physics.body that is the full size of the screen and then checking with "game.physics.arcade.overlap". Since any particle will always be overlapping with it, I can execute code on that particle. BUT.. this still only works if there is only one particle of a certain type. It doesnt give me access to indivual particles. Are particles assigned unique identifiers, and can they be accessed so each particle can be controlled individually without requiring overlap/collision detection?

Hi All, I've just started using Phaser over the last couple of days and am liking it very much. I've never attempted any serious programming with Javascript, but seem to be catching on quickly thanks to all the available Phaser documentation. My question concerns the performance hit of using "emitters" in place of "groups". I understand that the emitter functions are basically an extension to the groups functions. What I'm doing is creating an endless scroller/runner game format. As the screen scrolls, pre-composed "scene" sections are chosen randomly, then generated off screen and scroll by from right to left. These scenes are composed of platforms, coins, enemies, and various objects. I've been using an emitter for each type of scene object (i.e coin emitter, enemy emitter, platform emitter, etc). Each emitter will generate a scene that will then scroll by, after a certain time has elapsed, another scene will be chosen at random, then generated and allowed to scroll by. I've been using emitters instead of simple groups because it requires less coding on my part to generate each scene. This has been working just fine with no lag or noticable hit in performance so far. My concern is that as the game gets more complicated with more scene objects, will I eventually start to see a hit in performance? The reason I feel this way is that it seems that emitter particles get several physics properties automatically applied to them, some of which i'm not using. Will using emitters instead of groups for this eventually create a performance disadvantage? What would you use to continually generate scrolling scene content?