royibernthal

Members
  • Content count

    433
  • Joined

  • Last visited

  • Days Won

    1

royibernthal last won the day on September 17 2016

royibernthal had the most liked content!

About royibernthal

  • Rank
    Advanced Member
  • Birthday 11/28/1991

Profile Information

  • Gender
    Male

Recent Profile Visitors

880 profile views
  1. It adds very little more code, from experience, but since game resizing should be rare as you say I guess it doesn't really matter either way.
  2. I think you meant renderer.screen/myScreen but I got your point thanks
  3. Can you please elaborate? Is your note regarding @Jammy's answer or is it an answer in its own?
  4. @Jammy Could I resize PIXI.Application? I need to resize everything I have. I could add another container in the middle I guess, but would it be the most optimal solution? @ivan.popelyshev I'll remember that What should I use then?
  5. So it only changes when calling resize()... Listening to window resize and calling renderer.resize() solves it. Out of curiosity, is there a built in way to do it? On a slightly different subject, do the width and height I pass to PIXI.Application constructor matter if I resize the renderer afterwards or are they entirely overridden? EDIT: What I wrote actually doesn't solve what I'm trying to do, I'd like the stage to be resized along with the canvas, not the canvas to display a part of the stage at canvas size. It seems that I get the result when the canvas width and height remains the same and I change only the width and height in its style attribute, but I'm not sure it's the correct way to approach it. Original Canvas element width and height different than style width and height (desired result) Canvas element width and height same as style width and height
  6. I'd like the canvas to always be the same width and height as the viewport. renderer.resize() works, but renderer.autoResize doesn't seem to do anything. The code is taken from here: https://github.com/kittykatattack/learningPixi#renderer As you can see I'm using PIXI.Application instead of manually initializing the stage and renderer, in case that matters. var app = new PIXI.Application(800, 600, { antialias: true }); app.renderer.view.style.position = 'absolute'; app.renderer.view.style.display = 'block'; app.renderer.autoResize = true; app.renderer.resize(window.innerWidth, window.innerHeight);
  7. How about separating the creation and positioning logic? Call the positioning on creation and on resize, that way you don't have to deallocate and reallocate memory on each resize.
  8. I see, but technically destroying it is not a requirement for it to work. Another option should be to iterate over the menu's items and just modify their positions, correct? I just saw your edit, it answered my question. Thanks
  9. Looks like you did a good job there. What do you mean by destroy the GUI then redraw it? Is simply re-adjusting anchors/pivots/positions not enough? Doesn't the redraw happen automatically? Are anchors and pivots relative to their parent the way positions are?
  10. Sounds bad Can you at least nest anchoring and pivoting?
  11. I'm trying to create a new TypeScript project around Pixi. I'd like it to be as straightforward and lightweight as possible without any unnecessarily complex configurations, while meeting these requirements: -Using npm -Using TypeScript -Using import statements, e.g. import { Sprite, Texture } from 'pixi.js'; -Bundle all dependencies from node_modules that were imported using import statements into /build for production -Compile project source into a single outFile and put it in /build -Load dependencies at runtime according to imports made using import statements -Using SystemJS, since I understood it's in the process of becoming the standard module loader So far I created a new project: -Used npm - installed pixi.js and its typings for TypeScript -Compiling using tsc (tsconfig.json) via Visual Studio Code -tsconfig.json "module": "system" (SystemJS) -I can write import statements (since module is set to "system") -tsconfig.json "outFile": "../build/app.js" - compiles project source into a single outFile and puts it in "build" dir What I'm missing is: -Bundle all dependencies from node_modules that were imported using import statements into /build for production -Load dependencies at runtime according to imports made using import statements I don't have any experience with setting up and configuring module loaders. Could you please help point me in the right direction?
  12. From a little search I noticed there isn't any up-to-date layouts system for Pixi. How do you compensate for that in your projects? This issue mentioned pixi-ui: https://github.com/pixijs/pixi.js/issues/3482 but I couldn't find anything layout related in there: https://github.com/pixijs/pixi-ui
  13. What are you using on your server side and how do your client and server communicate? It sounds like you're limiting the answer to increasing the server <-> client speed, which is not really related to Phaser. Even if you optimize your server <-> client speed, as far as I know space_elevators is right, that's how it's done in multiplayer games. That's why if you have a bad connection players can seem to move around smoothly but many hits won't be taken into account, that's one of the reasons why lag is annoying in multiplayer games. The best solution, again as far as I know, is to interpolate between current position to last known position received from server, based on game-specific logic to make it look as smooth as possible. The faster the server <-> client speed, the less noticeable the interpolation will be, it'll only be noticeable when server <-> client speed is bad, at which point you have no better option but to at least move the players around smoothly to make the lag experience more playable. Naturally whenever you receive a new position from the server it overrides the previous position and the interpolation is recalculated.
  14. Depends on the scale of your games. From your question I get the impression you're talking about very small games. Try sending them to portals as jjwallace said and form a trusting relationship with them while earning some cash, you won't make a lot of money that way though, not in the beginning, but if you keep it up for a few years while improving your games quality you could start making some real money. Portals can offer you exclusive/non-exclusive sponsorship money for branding and/or performance based plans. You could wrap your games up for app stores, but unless they're something special and you've got some nice budget for marketing and/or a huge fan base they'd most likely not be a success. For bigger games, microtransactions would be a smart option, goes for both portals and app stores. Many hit games start at portals, accumulate a fan base then release in app stores.
  15. That's a very good point. Out of curiosity, how could you tell this game uses Pixi? I wasn't able to find it in their source code or any of the loaded js files. Don't Phaser's extra features come at the cost of performance? Also I think that Phaser is no longer based on pixi, is it? EDIT: After reading some more on the subject, it's pretty much become Phaser 3 vs Pixi 4 for me. How long roughly before Phaser 3 is ready for production? To create a VideoSlots game I don't really need most of Phaser's features (e.g. physics, particles, tilemaps, camera...) - although I understand it has a plugins system so I don't have to load any heavy feature that I don't need. I am very interested to see a comparison of: 1) Which one is more lightweight? 2) Which one has better performance? 3) Which one is better suited for mobile browsers? 4) Which one provides better TypeScript development? 5) On Slant people complained about Phaser having a poor code structure: https://www.slant.co/versus/1965/1966/~pixi-js_vs_phaser I really like Pixi's simplicity and the fact that it resembles ActionScript (I'm an ex ActionScript programmer), yet Phaser seems like it could take some time getting used to as it forces you to use a certain structure: https://github.com/photonstorm/phaser3-examples/blob/master/public/src/game/game.js Any thoughts on the structures of both frameworks? 6) Does either of the frameworks officially support Layouts? Otherwise - how do you solve dynamically fitting multiple resolutions in your projects? 7) TextureAtlas - I think both support TexturePacker which is a great software. How would you compare the implementations? 8) SpriteSheet Animation 9) BitmapFont 10) Anything else I might be missing if I choose Pixi over Phaser?