• Content Count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Like
    clark got a reaction from plicatibu in Can I Build My Game Using KIWI   
    I like how that is a thing.  How the only reason we know that is due to the transparency of Rich and due to that, kiwi has its place in the journey as a pioneer 
  2. Like
    clark reacted to mattstyles in Thinking Ahead: Need Help With Code Optimization...   
    Property keys in JS are dynamic and can be calculated at runtime i.e.
    let obj = { foo: 'bar' } let i = 10 while (--i) { foo['prop' + i] = i * 2 } console.log(foo) // { // foo: 'bar', // prop10: 20, // prop9: 18 // ... // } So, in your case, you could eliminate awkward branching logic (which is always a good thing) and do something like:
    // Warning, anti-pattern ahead const handlers = { onClickArrow1: () => {...}, onClickArrow2: () => {...} } function init () { let i = 3 while (--i) { arrow[i].on('click', handlers['onClickArrow' + i]) } } But, this is kinda rubbish as (at least in your example) all your handlers are the same. In the name of creating code that can be reused, is reliable, single source of truth etc etc I'd suggest doing something like passing in the context your handler is working with:
    function checkScale (arrow) { return arrow.scale.x < 1 && arrow.scale.y < 1 } function prepClick (arrow) { return function onClick (event) { if (checkScale(arrow)) { return } ... } } let i = 10 while (--i) { arrows[i].on('click', prepClick(arrows[i])) } There are lots of good esnext syntax to do this sort of stuff, but thats a separate issue
    Notice the `prepClick` function, this returns a function, this is sometimes called a thunk, but it uses closure to make arguments available later, in this case we trap an `arrow` object in the closure so that the actual event handler (onClick) can reference the specific instance it wants to work with when it is invoked later.
    If you're on an OOP track then this stuff becomes easier to specify but JS handles context really weirdly so you'll have to deal with `this` issues. This way is more functional, but either way will get you where you want to be without writing the same stuff over and over.
  3. Like
    clark got a reaction from 8Observer8 in Pixi.js for Typescript?   
    This is up to date.
    In the future will look at possibly including types with the official package.json so that they are automatically available when acquiring pixi from npm. 
  4. Like
    clark got a reaction from in Pixi.js for Typescript?   
    This is up to date.
    In the future will look at possibly including types with the official package.json so that they are automatically available when acquiring pixi from npm. 
  5. Like
    clark reacted to Infernal in POM - PIXI Object Model   
    Hello Guys!
    at Grey Rook we had the need to have non-code descriptions of the PIXI stage and animations, you know, like HTML.
    So we created POM - PIXI Object Model.
    It is JSON and if you know PIXI you know POM:
    { "type":"sprite", "values": { "position": { "x":100, "y":100 }, "source":"image.png" } } We built all our tooling around this, one of our clients has nearly 3k animations using it,
    with over 99% of them sharing the exact same JavaScript and are pure JSON!
    We want to share some of the internal tools and helpers we wrote with the PIXI community.
    We are starting with POM - the most central piece.
    So please let us know if there is interest!
    The documentation is a bare minimum and we are going to improve it - let us know what you are looking for!
    Our scene is composed of elements, like Containers, Sprites, Graphics, or any other custom element you come up with.
    What attributes these elements have is represented as JSON data, like the example above.
    All you have to do is pass the data representation to the manager and let it create the scene for you.
    It works like a factory, where you can register any custom Element you want, as long as it has the methods for processing the JSON data.
    We extracted POM out of our internal source tree and open sourced it.
    If there is interest more is to follow, for example our tweenJS-based AnimationManager, that takes JSON data of timelines and creates all the tweens for you,
    aswell as synchronize animations that use our custom tweens for controlling videos, and checking their buffering status.
    We hope this is useful for others too, so we can build it and make it awesome together.
    For a start we have created a minimal project page where you can find the information we have collected so far,
    we are currently mostly looking into improving our documentation, test coverage and examples.
    We built an online animation editor where users can create (and animate) scenes direcly in the browser and view them again anywhere else in a player.
    For this we mostly use PIXI (and TweenJS), the backbone of the project is our PIXI Object Model (POM) and its' manager.
    About us
    We are Grey Rook Entertainment, a software development and graphic design company from Mülheim an der Ruhr in Germany,
    designing and manufacturing interactive HTML5 expieriences, and connecting them with the real world.
  6. Like
    clark reacted to rich in Phaser 2.5 Roadmap (and request for ideas)   
    Without diminishing what they've achieved, we were clocking 1m+ sprites over a year ago too. It's very GPU specific - the demo above renders nothing on mobile (as you'd expect), and crashes Chrome on my laptop with an integrated GPU. It's an edge case test though, so this isn't exactly representative or fair to Pixi, but still don't let it create a reality distortion field either - this won't create speed where speed isn't available.
    This thread is about the best use of time spent on Phaser. Merging Pixi 4 appeals a lot, but will break a lot too. They're still not at a stable release either, which is worrying because it means if I use it, then I'm likely opening myself up for months and months of needing to stay on top of their updates, and there are only so many hours in the day sadly.
    Yet it's hard to ignore the new shiny isn't it? The grass is always greener and all that jazz.
  7. Like
    clark reacted to enriqueto in Typescript defs for Phaser Box2D plugin on GitHub   
    great job!
  8. Like
    clark reacted to Tom Atom in Typescript defs for Phaser Box2D plugin on GitHub   
    Hi, I just published short blog post on announcing my new Typescript defs for Phaser Box2D plugin. I remember, that few people asked for it here, on this forum.
    It may still contain some flaws - I already caught few of them during work on my game - but it is still very helpful.
    The blog post is here:
    And direct link to GitHub is here:
  9. Like
    clark reacted to permith in Deterministic physics engine?   
    A fixed time step can be really really important. 
    Acceleration 50 pix per sec 5 MS step 15 MS step Step Speed Position speed position 1 0 0 0 0 2 0.25 0.25 3 0.5 0.75 4 0.75 1.5 0.75 0.75 5 1 2.5 6 1.25 3.75 7 1.5 5.25 1.5 2.25 8 1.75 7 9 2 9 10 2.25 11.25 2.25 4.5 11 2.5 13.75 12 2.75 16.5 13 3 19.5 3 7.5 14 3.25 22.75 15 3.5 26.25 16 3.75 30 3.75 11.25 17 4 34 18 4.25 38.25 19 4.5 42.75 4.5 15.75 Speed = Acceleration Rate * (Step rate/1000) + previous speed Position = last position + speed This is the simplest possible physics demo, taking one of the the simplest problem(s) of acceleration, and chosen as pretty much the "worse case"/"most obnoxious" scenario.   Even a more complex engine that properly integrates and derives out, the physics engine will start to run into problems with different step times when you start to see things collide with each other(IE in the 15MS something would happen at step 10 instead of step 8 and compound out from there).
    Basically if you were to have a variable tick rate, everything might as well be semi-random instead of determined.   If you don't have a fixed tick rate you can't even count on your game running the same on every computer, since with a variable tick rate will probably be determined by the system.
    Really it comes down to taking the assumptions that you "need", and adjusting your other requirements to suit the engine.    IE:  in the 15MS example to get the same final speed you're going to choose a higher acceleration rate to account for the missed steps.    To account for inaccuracies in not having a .001MS step time you're going to have some logic to get get objects out of the inside of each other, choose some max speeds, and take actions to minimize/account for objects with race conditions(IE: 3 objects inside of each other)(which should be handled by the engine itself).
    There are in the end A LOT of things you can do if you want to race down the rabbit hole.   But to get there you're going to need to go deeper down it than most people ever need to to make something fun.    Especially when the same thing can be achieved with a little bit of understanding, kludging numbers, and focusing on a few actual requirements.  
    Even the most popular games like candy crush or solitaire don't care if they give a winnable game at the start of the game.   And people still return to those.
  10. Like
    clark reacted to Nomid in TypeScript: cannot set property of undefined   
    Yes, I read about that after finding the solution.
    Anyway, I took a look at the resulting JS, finding it interesting how it is structured.
    This is because, technically JS is not OOP, since prototypes only emulate the way we're used to instance objects.
    It was very clear, thank you
  11. Like
    clark reacted to mattstyles in TypeScript: cannot set property of undefined   
    Looks like it does support class properties. The actual spec can be found here.
    Any of the ways proposed are a solution. JS being heavily event-driven means that, in difference of most classical languages (JS is not classical, its not really a class you are defining, not in the traditional sense anyway), event handler are scoped to the element that invokes them. When JS adopted the class syntax there was a lot of discussion about whether the scope should be classical or JS-style, it was fairly unanimous that JS-style should remain. Many libraries, such as React's createClass method, goes against spec and autobinds.
    You're using a class property/field and an arrow function to get scope how you want it. If you look at the transpiled version you'll see whats happening (arrow functions are supported in most browsers but not all, I expect the standard TS transpilation will support older browsers, so it'll bind rather than rely on the arrow). A quick word of warning on using arrow functions like this, they mutate scope in a fairly unique way and it probably isnt how you think, more info here. 
    Another, very brief note on class properties, you're defining a function for each new class to get the bound scope. Mostly this doesnt matter but it is worth considering. If you create 1000 instances then thats 1000 functions, normally JS creates just the 1 and references it from the prototype.
  12. Like
    clark reacted to Tom Atom in {SOLVED} - Game Object Becoming Undefined - TypeScript and Phaser   
    In your place, I would clearly split game and state objects like this:
    // ------------------------------------------------------------------------- class Game extends Phaser.Game { // ------------------------------------------------------------------------- constructor() { // init game super(640, 400, Phaser.CANVAS, "content", State); } } // ------------------------------------------------------------------------- class State extends Phaser.State { } // ------------------------------------------------------------------------- window.onload = () => { new Game(); }; Note, that your Game clearly extends Phaser.Game and calls super constructor with your new State, that extends Phaser.State. You can then put your preload method into State class - for example like this:
    class State extends Phaser.State { // ------------------------------------------------------------------------- preload() { // background image"BG", "bg.jpg"); // load sprite images in atlas"Atlas", "atlas.png", "atlas.json"); } } Some time ago I wrote 3 part tutorial on building simple Phaser game in Typescript. It is enough to follow part 1 to build minimal working example:
  13. Like
    clark reacted to toytoytoytoytoy in {SOLVED} - Game Object Becoming Undefined - TypeScript and Phaser   
    The problem ended up being some vaguery of 'this' in context. I changed the function definition that was accessing to the format foo = () => { logic; }, which in TypeScript is the equivalent of setting "_this = this" outside of a closure, then within the closure using '_this' to maintain the correct context.
    Weird problem, weird answer, but '= () =>' solved all my problems
  14. Like
    clark got a reaction from WombatTurkey in [Removed]   
    I hear you
  15. Like
    clark reacted to staff0rd in [Removed]   
    You might be able to configure the browser to not care about that.  For example in Chrome, the following switches may help;
    chrome.exe --allow-running-insecure-content --disable-web-security  
  16. Like
    clark reacted to mattstyles in Which game engine to use for this app? (Humanitarian Disaster Relief App)   
    You dont need a game engine, its a terrible idea. Most game engines are designed to render to canvas (infact most require it), and you dont need it.
    You're creating a fairly standard app, I love the idea of the app and use of Tinder-like swipes is easily understood, sounds like a great mechanism. But use technologies for building apps, the field is mature and diverse, you will have no problem finding developers to build it and you will understand it.
    If you want true offline you have to build this native. Backend resources aside you could hire one good IOS developer (presumably an Android chap/chappette would do the same) to crack that out in a month or so, it sounds like you only have a couple of views and deliberately limited functionality (thats a good thing).
    For you info, CSS transformations are GPU accelerated on nearly every device now so UI transitions are easier and about as smooth as they can be.
    I guess the question is, would you write Tinder using Phaser, cocos, createJS etc? No, of course not, from your list in your post you have no requirement of a game engine whatsoever. Use the right tech to solve the problem (disclaimer, I've just built something fairly similar for a client but on the web rather than native). Problem with native for you I guess could be delivery, but, if someone has the internet they have the capacity to download an app so I guess that point is moot.
    And very very good luck to you, it sounds like an amazing project!
  17. Like
    clark got a reaction from hollygood in Securing HTML games is it possible?   
    My boss asked me today about my thoughts on attempting to secure games. 

    In the past we had an encryption tool built into the build process of our Flash Games. It was a great tool and made it pretty impossible to just steal the SWF. 

    Maybe a (easy to crack) domain check, or obfuscating the JS.... They seem like pretty meagre approaches but the best I have heard of. 

    Basically, if someone is going to steal your game, should you just accept it and move on or is it worth spending time looking for solutions?

  18. Like
    clark reacted to xerver in Is there any virtual dom library which could work with pixi dom?   
    If you need to create the whole object tree every change, then you should rethink your methodology. Do what you feel is better for your application. I would look into and use object pooling.
  19. Like
    clark got a reaction from tarnos12 in Visual Studio, JSON + Failed to load resource: 404   
    This one was obscure for me, I set up Visual Studio as normal, and downloaded Phaser (or PIXI btw) as normal. But when I ran it, I would always get:

    Failed to load resource: the server responded with a status of 404 (Not Found)
    With regards to the JSON file of my Sprite Sheet. 

    In Visual Studio, I need to double click on web.config and then enter these lines:
    <configuration> <system.web> <compilation debug="true" targetFramework="4.5" /> <httpRuntime targetFramework="4.5" /> </system.web> <system.webServer> <staticContent> <mimeMap fileExtension=".json" mimeType="application/json" /> </staticContent> </system.webServer></configuration> I have no idea what is happening here, but I burned 6 hours on it. Hopefully this will show up on a google result for someone else. Maybe its my browser settings or whatever but the point is, that it works!
  20. Like
    clark got a reaction from BrunoHautenfaust in Any Pause Screen Code / Examples?   
    Hey Shaun!

    You could pause the main game with 

    game.paused = true 

    The tricky thing is your UI. The problem was we had a pause button in the game, and pausing the game pauses everything....including the button inputs.  

    We are trying to move UI into the DOM....... But none the less, in either case, game.paused = true and game.paused = false is what we use.
  21. Like
    clark reacted to xerver in What is FragmentShader and how to use it?   
    Custom shaders are implemented in PIXI using Filter objects. There is nothing called FragmentShader. A fragment shader is a specific shader in the GL programmatic pipeline. It is used to decide what color a pixel on the display should be.
    You can create a Filter object that has a custom fragment shader to draw what you want. You then assign that filter to the shader or filters properties of a sprite to use it. The filters property will apply the shader as a post-processing effect, the shader property will override the normal drawing behavior of that sprite to use that shader instead.
  22. Like
    clark reacted to jmp909 in TypeScript problem accessing BitmapFont Data   
    i asked Rich in the Phaser Slack channel
    i think therefore you could add this to phaser.d.ts
    class BitmapFont {    data: HTMLImageElement;     font: any;     url: string;    base: PIXI.BaseTexture;}class Cache {    ...    ...    getBitmapFont(key: string): Phaser.BitmapFont;    ...} but actually maybe that should be something like BitmapFontData ?
    also i've noticed 2 entries for cache add in the phaser.d.ts .. i'm assuming this isn't a mistake but just means you can construct it 2 different ways?
    addBitmapFont(key: string, texture: Phaser.RetroFont): void;addBitmapFont(key: string, url: string, data: any, atlasData: any, atlasType: string, xSpacing?: number, ySpacing?: number): void; we'd need to ensure not to mess up any internal workings!
    this file is based on contributions though, so i guess you could propose something

  23. Like
    clark reacted to InsaneHero in Rough attempt at a Phaser "BunnyMark"   
    There are a great many complications with this sort of test, the most important being that browsers do all sorts of stuff behind the scenes... dynamic optimisations sometimes make code triple in speed after about 30-60 seconds of run time.
    In order to test drawing speed for Phaser 3 I've been building incredibly simple test beds, and feeding the graphics to webgl with as few pieces of code as possible.  Even then I find that sometimes I can get 250K bunnies and on other days, with no apparent change in the environment, it will cap out at 175k (a more than 25% difference).
    Unfortunately the nature of Phaser (being a complex and comprehensive API) is that you cannot do "simple" tests with it.  Even the most basic implementation of sprites-on-screen has a ton of support code related to handling all the many different graphic sources and purposes that the system might be used for.  With this amount of code the browser performance becomes somewhat random (in my experience) and optimisation of your demo code is unlikely to gain true benefits across all browser types and for all circumstances.
    If you absolutely need the fastest performance, you really have to use a very low level API... of course that means you won't get all the benefits that Phaser provides and you'll have to spend a lot more time finding solutions to the problems raised.
    However, thanks #jmp909 for making this test... I'll be sure to include it into the tests for Phaser 3 because even with such erratic behavior, I can hope that the new renderer will be significantly faster
    (Note: any speed improvement will most likely come from the tighter bonding between the new renderer and Phaser 3, PIXI is already extremely well optimised for pure drawing power)
    EDIT: I just ran the demo, I think that environment (dynamic code editing) has a fairly heavy performance impact... pretty sure Rich warned me about that just a few days ago.  Try it locally or on a clean web-page and see if there's a big difference (or at least a more consistent response).
  24. Like
    clark reacted to rich in Can you help with the ParticleStorm TypeScript defs?   
    I'm getting ready to release the new ParticleStorm plugin for Phaser. It's really quite neat and allows you to create some beautiful effects But I'd really like to offer TypeScript defs with it. I don't code in TypeScript myself, so I need some help with them.
    I have written the defs for about 80% of the plugin already, but I've not tested them. If someone has some time to help finish them and test them please send me an email ( - you'll of course receive a free copy of the plugin as a result
  25. Like
    clark got a reaction from Tom Atom in Computer Science With a Focus on Game Programming vs. Game Programming   
    Going back a good 10 years now, I started a game degree, it was not what I wanted so I switched to Multimedia Systems.  

    In hindsight, the best thing I could have done was a standard computer science degree. It does not pigeon hole you into any specific field while leaving you open to explore the subject.

    Good luck!