themoonrat

Members
  • Content Count

    232
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by themoonrat

  1. themoonrat

    which format is good for memory between png and etc1

    Once graphics are loaded, they are decompressed for the device to use, so there is no difference in memory used for a .jpg or a .png, only the amount of disk space they take up. Memory taken up by an image is width * height * bitdepth, regardless of initial format. If disk space is your questions concern, I use a combination of jpgs and pngs, with some of the later pngcrushed, depending on size and visibility.
  2. themoonrat

    How do you control memory to use mp3 with IOS

    Doing a little memory profiling on the game I'm working on using Chrome Task Manager. I load a single audio sprite, which is 6 minutes 40 seconds long. I tested with both a similarly encoded ogg and m4a, and there was no difference to the results No audio loaded: 94 mb 48kbits 44100hz mono: 171 mb 64kbits 44100hz stereo: 247 mb So you can see, decreasing the bitrate WILL decrease memory usage. It's up to you to judge at what quality is acceptable. As I mentioned, I personally feel that 48kbits is fine for mobiles, and 64kbits is fine for desktops, but that's my opinion for the type of games that I make. The other option is of course to decrease the number of sounds that you load for lower end devices. Do not be scared to do this. An iPhone 4s has 512mb of RAM, an iPhone 6s has 2gb; you can't expect the older device to cope with all of the sounds and animations that newer devices can handle. If you trim well enough, for example, the user of an iPhone 4s would never know that there are actually 4 different background tunes to the game; make them happy with the 2 they get!
  3. themoonrat

    How do you control memory to use mp3 with IOS

    I also use the OGG / MP4 combo as described by b10b on SoundJS with no issues. Encoding to AAC gives you better compression and better sound looping than using MP3s In terms of compression, I went for 64kbits stereo when targetting devices with plenty of memory, such as desktops, and 48kbits mono for most mobile devices. I don't value high quality sound on mobiles; the speakers on devices are usually poor, lots of people turn off sound when playing games on their phone, and most importantly, it's hard enough just getting sound working on mobiles in the first place!
  4. themoonrat

    ticker example

    Here's an super basic example of using the shared one wrapped up using an ES6 style class. class TickManager { constructor( settings ) { PIXI.ticker.shared.add( this._onTickEvent, this ); } destroy() { PIXI.ticker.shared.remove( this._onTickEvent, this ); } _onTickEvent( deltaTime ) { console.log( deltaTime ); } } It's a replacement for requestAnimationFrame for my usage. That way if I want to pause the game, I can just stop the timer. If for debug reasons I want to speed up / slow down the game, I can do it on the timer, instead of manipulating a rAF calls. And the positives of it being based on rAF is that if you minimise the browser, the timer is essentially paused until you maximise it again.
  5. themoonrat

    Fullscreen with safari(ios)

    There is nothing PIXI itself can do. The only way to get full screen on ios if for the user to scroll down the webpage. Get this page on your iphone for example, scroll down the comments and you see the URL bar disappear. You need to simulate this. Tip on this; compare $( window ).height() to window.innerHeight. You'll see a difference on iphones if the device is 'full screen' after scrolling or not. If the device is _not_ fullscreen, show a div that's height is much taller than the game, with an image or text instructing the player to 'swipe up' the screen. They will scroll across this div; keep comparing $( window ).height() to window.innerHeight. When the values show that the user has scrolled enough, you can get rid of this div to show the player the full screen game.
  6. themoonrat

    Any way to speed up drawing lots of primitives?

    WebGL will still be just as slow because it uses the standard canvas API to draw the shape, before saving that to a texture that WebGL can use. It's similar to how non bitmap text works too. So, you are limited in speed by that API. You need to find some way of creating the polygon, saving off it's texture, which is then drawn that as it moves, so you're avoiding the constant polygon re-creation. Could you create the polygon at its largest size, then scale and move the texture created to the correct location?