• Content count

  • Joined

  • Last visited

  • Days Won


mattstyles last won the day on August 25

mattstyles had the most liked content!

About mattstyles

  • Rank
    Advanced Member

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

3,717 profile views
  1. Hey There

    Welcome, What sort of guidance are you after?
  2. Game cycle, FPS and optomisation

    This is a really interesting question, but its not to do with Phaser, but to do with how the browser works, which is potentially different for each browser. To answer requires pretty intimate knowledge of how the browser works (which I don't know and isn't common knowledge, maybe it should be?). Node, as an example of implementing a JS engine (the same one in Chrome usually), and I've read this (I think), here (somewhere there anyway), creates an event loop that keeps spinning and handles all the events (as it can) when they come in, for specifics, this includes handling an async action like initiating a file read, popping that action initiation on to a stack and handling the response (whenever it arrives sometime in the future) and linking the action of the stack with its resolution, all so that the event loop can handle other actions that occur between initialisation and resolution. I've kind of always assumed that the browser works in a similar way to try and conserve system resources, as a JS developer working in this 'browser' vacuum, should you be concerned with this? Well, perhaps, but, there's nothing you can do about it if you don't like the answers you find. It's certainly true that a well-written browser application will consume more resources (such as CPU cycles) than a well-written 'native' application, but its not really a fair comparison. As a JS developer you're working at a higher abstraction and you dont/cant get involved with all the low-level interactions. When working with your average JS application (particularly targeting browsers, as most do) you're severely hamstrung with regards to implementing some of the more complex application loops common to gaming. You're almost completely restricted by requestAnimationFramerate and you can't fight it. JS is single-threaded (threads are hard, there's lots of advantages to this), stuff like web workers could try to work in other threads and free up your UI thread (which would be your main thread in JS) as other platforms might do, so, you could try to offload your AI logic (for example) to a web worker so your main thread can push rendering at refresh rate (i.e. 60fps), but, I don't know any examples of this (some might exist as some browser games are pretty involved nowadays) and its certainly a very difficult thing to do.
  3. Hello

    Hey Carbon, I think it'll be really interesting to see how you find html5 after writing games for other platforms, there are some differences for sure. Welcome
  4. PIXI with React or Angular

    Rendering perf for ng4, React, Vue, Aurelia etc etc etc is all much of a muchness, some other stuff like JS weight (both over the wire and parsing on mobile devices) does vary but largely if you pick any of the larger web frameworks/libs the perf is comparable. No idea how these frameworks/libs performance stacks up against pixi-ui. For me there are usually significant benefits to using the DOM (via vdom or not) when creating UI stuff, but your use-case might differ where the advantages are less. Generally the UI isn't going to be a perf hit unless you've got a ton of animations etc etc but, again, depends on your particular use-case.
  5. Validate Radio Button

    I'm not going to show you the exact changes you need to make, sounds like this is for an evaluation and you need to actually dig in and learn independently if you want to make any headway as a programmer. MDN should still be your first stop for small problems like this and to check syntax etc etc, for example, if you had googled 'MDN radio button', you would have ended up Having said I'm not giving you the exact code, it is actually in that link, I'm sure you'd find ~1 million other blog posts outlining almost the exact code you need. Asking questions of a community is great, but sometimes you'll find it more rewarding to find the answers on your own and experiment to find the best way of doing things. To make your code work you just have to delete 2 little characters.
  6. Phaser-Visual Studio-TypeScript Deployment

    There are lots of ways to achieve this sort of thing, and plenty of services out there that can take care of all the heavy lifting of setting up a box to serve your stuff (for a price). One relatively simple cost-effective way (if you don't mind getting your hands dirty): * Buy yourself a virtual machine from any hosting provider (Amazon, Rackspace, Azure etc are amongst the biggest providers, cheaper solutions I've used include DigitalOcean, Linode and Vultr, but there are quite literally thousands of them, all much of a muchness) * Follow guides from the provider about basic set up for the box (each will have these guides, I found DigitalOcean docs very very high quality) * If you're hosting a JS-powered client-side only game then all you have to do is set something up to serve these files to the client for you, you do not need anything smart * Nginx, varnish or apache can handle this requirement very easily * Follow guides for setting up any of the above * If you bought a domain name then set that up to point at the ip of the box you just set up (again, follow guides by the provider if unsure, many providers will also provide a DNS service for you to buy domains if you wish) * What you'll generally end up with is a service (nginx, varnish etc) serving requests from from a specific folder on the box, scp your files in to this folder and hit the url in the browser to check it This is a very simple way of doing things and doesn't require too much effort. Note that you don't have any explicit monitoring or maintenance set up like this, nor do you have anything smart like a CI/CD solution in place, nor any kind of load-balancing etc etc so don't expect to be serving thousands of requests per minute but you might be surprised at how far you get. When you need to upscale you're presumably making some money out of it and can afford to invest in a more robust solution, you may never need to do this. If even this sounds like too much work then many services will do this for you and set up basic monitoring. This is generally a little more expensive but easier, all you'd have to do is copy your files on to the box (or they may even provide some sort of web portal for uploading your files).
  7. Can't load images by any means.

    Your call to `express.static('assets')` sets `assets` as the base folder, which means that when you request `/snakeBody.png` it looks at the root, which is (as far as the static module knows) at `assets`. `../../assets/snakeBody.png` does not work because paths don't go relative to where your JS file is, they'll go relative from wherever you serve your html file from ordinarily, there are some rules (such as the `static('assets'`) which can change how your server routes requests.
  8. Deploying games to Android.

    Check carefully on assumptions about Android devices (new ones I think are all fine), we made the assumption that the version of Chrome used in the webview would match that of the device, we were wrong, some devices use an older version of Chrome. I'm sorry I don't have exact version numbers for you, but I know it wasn't an issue with newer versions.
  9. code not understood

    var gameTitle = function(game){} gameTitle.prototype = { create: function(){} } It's a JS pattern to add class-like behaviour into a prototypal language, if you know what classes are (in Java, C++ etc for example) then its pretty akin to that. The top function call is a constructor function, the prototype bit adds methods (behaviours) to your class. You should just call this an object as JS doesn't have traditional classes (despite the new class syntax). The way you're doing it though stamps over any existing methods on the prototype, this is generally bad, sometimes very bad. Extending the checkout with additional functionality is fine but be careful stamping over it, particularly if you're setting up some sort of inheritance chain.
  10. Deploying games to Android.

    No, you can continue to use Cordova, checkout Crosswalk which replaces various bits of the browser env to give you performance boosts at a hit to package size (about 25mb I think, might be wrong). I'm not exactly sure on the specifics (a quick google will confirm) but I don't think Crosswalk is required for newer Android devices as all modern ones are various powerful and run a decent enough version of Chrome in a webview that you shouldn't have too many issues. You can conditionally (somehow, I dont know how, but I think its relatively trivial) package older devices (it'll be against Android version) with Crosswalk and leave newer ones alone.
  11. [Help] Available Screen Space

    Ah, thats good. I thought that Safari started with the toolbar visible and only scrolling down the body element (a full screen size child element wont work) dismisses it (and shrinks the top url bar stuff at the top). Chrome for iOS doesn't have this problem as whilst the app is just Safari under the hood it doesn't implement the same ui. Yeah, as the browser can not lock the orientation this happens a lot as a solution. Pretty rubbish really but the best option given the alternatives!
  12. [Help] Access function in html file

    Make sure you create a thread about it here! During dev maybe, but certainly after you've created a playable version Good luck!
  13. Phaser and larger-scale games?

    This is a fine solution and solves loading large datasets by removing 'the wire' from the equation. Your second point relates to caching, the browser does this automatically to some degree, it is also the primary use case for service workers, see here for more details. I'm assuming this is another use-case for service workers. I've used web workers to achieve this. Aside from the very real problem that tooling and debugging is a major pain (as is simply dealing with threaded environments) there is an overload for starting and stopping web workers. As a terse example, I wanted a way to generate reasonably complex heightmaps on-the-fly on the client, given that even modest tests could take 200-300ms of blocking calls (which obviously nuke any animations, or anything else, happening in the page) I figured I'd explore web workers. The result was that my animations remained silky smooth, however, my heightmap generation shot up over 3x duration, most of that excess time being spent in starting a web worker, some in finishing up and communicating back. I was surprised at this (although it was hardly an exhaustive test) but for my trivial use-case that would have been acceptable, for more real life solutions, it probably isn't worth the hit (as an alternative, I could have requested this from a remote service and anything other than 3g network delay probably would have given better performance). The key take-away is probably that threading isn't the magic bullet for performance and it increases the complexity of what you're doing by a huge amount. If only it were so simple... Not sure how this really helps. I don't know who backs the project but its unlikely they have the resources to mix it with the current big players in their project scope areas. As highlighted in this thread, most issues are web issues, and those issues exist because for the vast amount of users these things are important, you can't simply strip them out. It's like becoming a master at Chess and just assuming you'll be equally proficient at Go. If you're making a rhythm game the current web ecosystem sounds more than powerful enough to support what you need (although audio support is admittedly fairly poor on the web). Rich hit on a non-technical consideration of the web platform, namely monetisation. Take a look at the mobile app stores (particularly Apples App Store as its the most mature), its only fairly recently that some games there are really very very impressive, given the (relatively) crap hardware they run on its simply incredible, but, the point is that it has taken a long time for the demand for such games to be present. I think this is so fundamental that the technical side of whether it can even be achieved is almost moot, put darkly, whats the point? Why bankrupt yourself for it? That's a bit bleak for an ending though, I'd say that we need to think more incrementally. The web needs apps/games that continue to incrementally grow in complexity and delivery, then expectations rise, which raises demand, which raises revenue, which raises standards. So long as that growth is at a faster rate than other environments (consoles, desktop, mobile app stores) then at some point we reach a tipping point.
  14. [Help] Access function in html file

    @studdDev Are you including your game code after that script? If so, then the browser works by parsing top-to-bottom (mostly) so the inline script will parse and execute first. Oh, I just noticed you’re creating the game instance before declaring the showAds function, so, yeah, won't work as showAds hasn't been declared when you start the AppBoot() stuff and whatever that does (presumably tries to call the function and thus errors). I'm guessing your workaround works because you end up executing the showAds invocation several times and it fails first time/s around as it hasn't been created yet and the next time (this could simply be on the next tick) it works. It's often worth checking property existence of globals in any case (defensive coding) but if you just move the game code (and its invocation via new StuddGames) after you declare the global then it'll be there. Also you don't need bracket notation to reference `showAds` and you don't need to call it either, you can just invoke it in the usual way. Also also, you leak version, libs and game also to global, this might not be an issue but if some of these ads are a little dodgy they may overwrite the global version (and maybe libs, I'd think game is probably safe enough) variable. May not be an issue for you but something to consider.
  15. [Help] Available Screen Space

    Does this solve it for iPhone? Because the toolbar (the bottom one) is a floating element that is not part of the viewport i.e. the window is behind it and JS has no way of knowing about it so all window size calculations (where you usually want viewable space) are wrong.