Bart Read

  • Content Count

  • Joined

  • Last visited

About Bart Read

  • Rank

Contact Methods

  • Website URL
  • Twitter
  • Skype

Profile Information

  • Gender
  • Location
    Cambridge, UK

Recent Profile Visitors

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

  1. Ha! I can't say I blame you - this sort of thing is a massive headache, and it definitely doesn't help when the documentation is patchy. I may be wrong but I suspect your biggest, and least painful, gains may come from dealing with the music related issues so I'd recommend starting there.
  2. I actually have been using VS Code a lot recently, and prefer it to Sublime Text, but have had to switch back to Sublime Text due to VS's Code Helper process rinsing my CPU, which drains the battery on my laptop at an absolutely brutal rate, and even on mains power eventually leads to everything else on the machine slowing down as multiple instances of Code Helper are spawned. Sublime Text, although not as good as VS Code functionally, is still nice to use, fast, and lightweight, so switching back to it hasn't been too painful. If Microsoft fix the Code Helper process issues with VS Code I'll be going back to it though. Whichever editor I'm using I pair it with four command line windows running bash: One for git, and manually running builds (although I also have a watch process): here I use gulp; I know webpack is the new hotness but gulp has served me well the past 3 years so I don't see any value in changing just for the sake of it One for running node One for running MongoDB And the final one for sshing into my server to kick off deployments, apply updates, and suchlike
  3. Hmm, I just tried it over a 4G connection and it took 4 minutes 25 seconds to download the 45.5MB of content, which is on average about 176KBytes/second. The download speed is low enough to make me wonder if you're being dinged/limited for bandwidth on your web server (unless you have a particularly large amount of traffic at present). Real world 4G download performance often reaches 1 - 2 megabytes/second with decently strong signal. Still, even in these ideal circumstances it's going to take 23 - 46 seconds to load the game, which I suspect may be longer than many are willing to wait. Even if you don't want to go to the extent of loading data per scene you might be able to defer loading of data not required to display the start menu and the beginning of the first episode until the start menu has been display, meaning that players can immediately start the game without having to wait for all the content to download. Of the 45.5MB, roughly 37MB is music so you could improve the situation significantly by prioritising most of the music to load after the start menu has appeared. I also notice you're loading a couple of the tracks (Effects of Elevation, and Dirty Shoes Blues) twice so you could shave off 8.7MB there, which would get you down to about 28MB. I notice the game is using 882MB in Chrome Task Manager. I suspect this is a combination of both images and music, but I'll come on to the images in a bit. On the music front you can reduce the compressed size of your ogg files by reducing the encoding bitrate from 144kbps to 128kbps. This will reduce the amount of content to download and most people won't be able to tell the difference, especially not if they're using phone/tablet/laptop/low end multimedia speakers, or average headphones in anything other than a dead quiet environment. I use MP3s rather than OGGs, simple because at the time I was putting together the music MP3s were better supported amongst different browsers, but the bitrate principles remain the same. I found dropping below 128kbps had too much of an effect on quality - 96kbps sounds noticeably washy on half decent speakers, but I do use it for mobile users so I don't rinse their data. However, you can pull another trick out of your bag that will reduce the size of the decompressed audio without significantly compromising quality by decreasing the original sample rate, which will probably be 44.1KHz (i.e., same as CD) or 48KHz. I found that 32 KHz produces still good results for the games I'm working with, but they're pretty heavy on sound effects. You can use a tool such as Audacity (which is free) to resample down to 32 KHz and then export as ogg at 128kbps: On the image front, again, this might require getting down and dirty with RenJS, but if under the covers you're using WebGL to render you may find you get better results with compressed textures rather than PNGs, but that may be a bit of a long shot. I realise all of this is a giant pain in the neck. Also worth saying that most of it is only something you need to worry about if ultimately you plan to distribute your game over the web, rather than as a self-contained app.
  4. And we're done with Star Citadel/Star Castle, or at least the game is as done as it's ever going to be! I've added multi-hit mines, which start to creep in on higher levels in the "modern" game. I've uploaded a video which shows the finished game: First game I've finished in a long while. Now I just have to get it ready for app stores and licensing to embed in other websites, none of which is the fun part so motivation is a bit low, but I'll get there. In the meantime you can play at: (Star Citadel will always be available here, even when the apps and licensing work are complete.)
  5. I've pimped the power ups slightly so it's more apparent when you've successfully collected, when they've run out, etc. Still got the multi-hit mines to do though - watch this space.
  6. I'm not familiar with the Phaser 3 framework itself but if I were approaching this problem a few thoughts spring to mind: - Can you get away with just loading images for the current, next and previous scenes, even if there are multiple possible navigation tasks? - If your images are hand-drawn, how much fidelity would you lose by reducing the resolution of each image and then scaling back up at render time? - Instead of using straight images, can you load them as compressed textures? This is a PITA because you'll probably have to support multiple different formats, but you might cut your GPU memory usage by 80% or so by doing so: Note that you can reduce the download size of compressed textures still further by gzipping them, but this is something your web server should be able to handle for you, and the browser will automatically decompress them. - Can you load an image in Phaser 3 by supplying image data rather than a URL? If so then you can use XMLHttpRequest (or possibly a built-in AJAX API if Phaser has one) to load your images, store the response bodies, which will be ArrayBuffers. Then, when you want to load the image in phaser you'd make a clone of the ArrayBuffer from the response body using something like: var imageDataToPassIntoPhaser = storedResponseDataContainingCompressedImage.slice(0); // Now create your image in phaser here, however that works. (I suspect you'd run into problems if you just tried to use the ArrayBuffer directly more than once, just like you do when decoding audio with the Web Audio API - don't get me started on that because I'll descend into a multi-paragraph rant about what a terrible API it is.) Bart
  7. I may be wrong, but I don't think it's a garbage collection problem - in any case garbage collection, in the sense you're using it, only applies to JavaScript memory. I obviously don't know much about your game, but you've mentioned WebGL, and 30MB of images in TINYPNG and JPG formats. How much compression you actually get with either of these formats very much depends on the images concerned: JPG is good for some images, less good for others, and likewise TINYPNG. However, it's probably not unreasonable to talk in terms of a 9:1 compression ratio versus the uncompressed 24-bit or 32-bit RGB or ARGB equivalent. Again, not sure if you're using transparency, but this would only apply to PNGs, which have the additional alpha channel, anyway. A 9:1 ratio means that uncompressed your images are going to use 270MB, and let's say it's in 32-bit colour to make life a bit easier for ourselves, even if some of them are only 24-bit. However, this isn't the format that OpenGL - which is what WebGL is based on - will use. I suspect your images are actually being stored in the GPU process as either GL_RGB32F (no transparency) or GL_RGBA32F (with transparency), or possibly a mix of the two. Whereas in 32-bit RGBA each component - red, green, blue, and alpha - takes 8-bits (one byte) for each pixel, in the GL_ formats each component is stored as a 32-bit float. I.e., storing RGB for a pixel will take 96-bits (3 floats, 12 bytes), and storing RGBA will take 128-bits (4 floats, 16 bytes). Depending on the format then, this means WebGL will likely use somewhere between 810MB and 1080MB. These figures are obviously only a back of an envelope estimate, but they do a decent job of showing why you're seeing a massive amount of memory in the GPU process, and thus why your game is crashing on mobile devices. One caveat: that GPU process is shared between all tabs in Chrome, so it may be that some of that memory is being used by other web pages, not just your game. On the JavaScript memory front, spiking up to 190MB and 360MB seems very high. I've never seen JS memory usage this high, so I wonder if this might also be a factor in the instability you're seeing when running on mobile. Is there a way you can get this under control? The fact that it's spiking at 360MB suggests you're holding references to a lot of objects that you're later letting go as the memory drops to 14MB - do you need to hold on to these objects? Hope that's all useful. Bart
  8. Found some time to work on this. Power-ups are now in there. There are four that upgrade your firepower and then one that you really don't want to collect. Give it a try:
  9. Interesting. Can you post a screenshot of what you're seeing when you look at the memory usage, please? Also, what format was that 100MB audio file? Thanks!
  10. Of course - I even commented on decompression of audio, and made a passing remark about images, on another thread. Doh! (In my case, since the images were generated, they were uncompressed from the off.)
  11. I'm not aware of a hard limit to the number of canvases you can have on a single page. However, things to bear in mind: Each canvas will need its own WebGL context WebGL contexts cannot share resources (e.g., textures, buffers), so if you have to load everything multiple times because you're duplicating content you can use a lot of memory. (You can do tricks with gl.viewport and gl.scissor on a bigger canvas to give the impression of multiple views, but this isn't my area of expertise.) Even when thinking about Canvas 2D, memory can become an issue on mobile devices. E.g., if you have a 1000 x 1000 pixel canvas, at 32 bits per pixel (with alpha transparency) this will require 4MB of storage. Manual double-buffering with canvas isn't necessary, but I have no idea if browsers implement full double-buffering behind the scenes: if they do that's 8MB. Either way, with multiple of these canvases the memory footprint can quickly add up. So far I've only used multiple canvases with standard 2D rendering without issues: usually for background and foreground canvases. Sometimes I have a couple of extra hidden background canvases that I can fade between as required, although only in desktop browsers. Anyway, multiple canvases is very much not a bad idea. You can, for example, paint a static background once on your background canvas, and just leave it there, rather than repaint it on every frame, which would be much more expensive, even if you were just blitting a large pre-rendered image. As already suggested, I do tend to restrict myself to two canvases total when running on mobile. All my canvases tend to be 1368 x 768, and then I rely on the browser's compositing engine to handle overlay and transparency, and scale up/down as appropriate for the window size/device screen (this process is generally GPU accelerated).
  12. I can get it to load on desktop Chrome under OSX, but it takes quite a while, presumably because it's pulling down about 30MB of MP3s (nice music, btw). The tab is also using about 780MB of RAM just to display the title screen[1], so I don't rate its chances of working well or even at all on any mobile device I own (iPhone 5S, 6S, and OnePlus Two - granted none are state of the art). Are you using context.decodeAudioData on your Web Audio context for these MP3s before you need to use them? If so then I suspect that's where most of your memory is going: calling decodeAudioData on an MP3 source will decompress the audio[2]. What this means is that a 3 minute MP3 at 128kbps that normally takes about 3MB, will blow up to a good 30MB in memory (at least), meaning your 30MB of MP3s will consume around 300MB uncompressed. Those figures are theoretical, based on the sizes of compressed MP3 audio at 128 kbps, versus uncompressed 16-bit PCM audio at 44.1KHz. The reality seems like it's generally worse in my experience. One of my games was using 600-700MB of memory, and it turned out to be the MP3s which, compressed were only about 10MB in total. I ended up decoding the audio on demand, which means there's a short but incredibly annoying lag before playback starts (makes it harder to synchronise other events to the music), but this trimmed memory usage down to a fairly stable 100MB total, and significantly improved both performance and stability, particularly on mobile devices. I notice a bunch of images coming down as well. Although they're relatively small as PNGs, they might also be a factor, again due to decompression in memory. Hope this is helpful - nice looking game. Love the funky noirish feel. [1] This is coming from Chrome Task Manager, available via the same menu as Developer Tools. [2] For this, and related reasons, the Web Audio API is terrible for handling music that you're likely to want to reuse, as you often will in a game.
  13. I've certainly noticed issues with a couple of my games causing browser tabs to crash on mobile devices, particularly my version of Asteroids where I was pre-caching lots of bitmaps with rotated asteroid images at various sizes and angles (blitting performs better than drawing operations with Canvas2D). I ended up detecting the environment and fairly drastically reducing the amount of generated content to make it stable: Reduced number of rotated images at each size. Reduced number of colours/shades for which I would generate rotated images. I also do this for desktop browsers other than Chrome and Safari, where the generation phase appears to perform much more poorly. Anyway, bottom line, I'm not aware of a hard limit. Like desktop OSes I suspect with mobile OSes it depends what else the device is running: how many applications, how much memory they're using, etc. It will also depend on the spec of the device: how much RAM it has, how much space to cache content, how much memory is available to GPU, and so on. With that said, 30MB doesn't sound like that much. What device are you using? If you want an indication of how much memory your page is really using, which can easily run into hundreds of MB if you're not careful, you could try running it in desktop Chrome and opening up the Chrome Task Manager, which is available via More Tools > Task Manager on the address bar menu, just above Developer Tools. You may find your memory usage is way in excess of 30MB, at which point it's time to start investigating why.
  14. Fun - I like the fact that even sometimes your misses will just balance on the stack, or on the table. Agree with the others on the zoom effect though: a bit too much. Maybe use it when the player achieves something special? 10 or 100 books or something like that.
  15. Hard to play with a trackpad but works fine with a mouse. Imagine it's fine with touch as well. One suggestion would be to make it so you don't actually have to press when you're controlling with mouse or trackpad. It seems to work this way to start off with, but not after the first play so I'm not sure whether that's a bug or intentional. Was quite fun once I'd got the hang of it though.