• Content count

  • Joined

  • Last visited

  • Days Won


alex_h last won the day on November 13 2014

alex_h had the most liked content!

About alex_h

  • Rank
    Advanced Member

Contact Methods

  • Website URL

Profile Information

  • Gender
    Not Telling
  • Location
    Plettenberg Bay

Recent Profile Visitors

1,499 profile views
  1. That doesn't seem like a realistically achievable requirement to me. To some extent this will depend on what your baseline device requirements are but you can probably only safely load about 10 or so large images at once. Navigating sets of 100 will definitely mean some loading and unloading. Unless there is some way you can anticipate in advance which ones are going to be required and preload them, while also unloading some others, then unfortunately lag is going to be unavoidable.
  2. Here's some reference material: Also the vram section of this:
  3. Also once webGL makes textures from the images their width and height will get rounded up to the nearest power of 2, requiring even more memory
  4. What are the dimensions of the images you are loading? When you say 126KB I guess thats the size on disk? It's the uncompressed size in memory that matters once you load them.
  5. you should be able to achieve this by including a viewport meta tag in your html header. Something along these lines: <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no" />
  6. Switching texture as you suggested is the best/simplest way. Or if you wanted a 'glow' effect you could do this by showing another sprite with the glow texture either in front or behind of the main sprite. If you try to do something clever with filters etc firstly you would probably want to be using webgl not canvas, and secondly it would be less efficient than simply swapping texture.
  7. pixi.text

    Nice work! One thing that might be nice is if you could exclude any parameters from the source panel that are left on their default values. That way you keep the amount of config to a bare minimum.
  8. Try changing it to uglify: { options: { mangle: true }, my_target: { files: { 'build/game.min.js' : ['build/game.js'] } } }
  9. pixi.text

    Sounds like a good idea, I think you should make one
  10. Uglify JS takes various parameters that determine in what ways it will modify your code: You should find most of these are accessible via the options you can set in your grunt config
  11. I've been listening to back to back Hong-Kong-Ping-Pong mixes while working for the past few months
  13. With bmglyph when I last used it (ages ago) I had to do a lot of trial and error to get it to output the png in the correct format, ie white characters on transparent background.
  14. There's an online bitmap font tool made in flash that is a bit easier to use you could give that a try?
  15. The big restriction on web based games in general is asset size, both on disk and in RAM. Flash worked around the download size issue by using vector graphics which are tiny. With HTML5 whether its canvas or WebGL you are general using pngs and jpegs which very quickly hit the limit of both what your users patience can handle while downloading and also device memory at run time if targeting mobile. [Edit] To be fair, apps also have the same memory limits, so its really just the downloading issue.