Leaderboard


Popular Content

Showing content with the highest reputation on 08/14/19 in all areas

  1. 1 point
    Hello HTML5 Game Devs users! While developing the game I used the game engine Construct 2, I used a personal licance version of it and the license was bought with legal ways from offical site. There is a addition system for the engine, but in this game I didn't use any addition. While developing the game I used Piksel for graphics and it is completly free. The graphics was made with only Piksel and the color name that used is na16.pal. I used almost all of these colors with white and black as addition colors. I used the game's music and sounds as quoted from opengameart.net and If you play the game and win or look in the codes you can see their names. Good Bye! Images Play Game: https://www.rijitsu.com/gamef/space-ship-andromeda/ Download Source: https://mega.nz/#!fcxfgqoz!8ky2ryvssunse7rbtowbmlsıhlscxhwqffwwolzmt44
  2. 1 point
    subpixel

    Best practice for using layers

    I'd like to write a bomberman-like game with lace.gg using pixi.js v5 as the rendering engine. I was wondering what the best practices are when it comes to layers. I assume it wouldn't make sense to create 1 layer per game element. Would it make sense to put everything into 1 layer? Or should I put the background (which never changes) into one layer and the rest into another one? Or should I maybe put all players (constantly moving game elements) into one layer and everything else into another layer? Or maybe every type of game object should go into one layer? Players, bombs, items, invulnarable blocks, normal blocks, explosions, background ... I'm also wondering if I should use layers as in: this.stage = new PIXI.Container(); this.backgroundLayer = new PIXI.Container(); this.mainLayer = new PIXI.Container(); this.stage.addChild(this.backgroundLayer, this.mainLayer); or if I should use the pixi.layers plugin?
  3. 1 point
    grelf

    Canvas zoom in and zoom out and panning

    I assume we are taking about the standard '2d' graphics context for the canvas. There two simple approaches. 1. Create your scene as an image larger than the canvas. When you use context.drawImage (x, y) the x and y values (the coordinates for placing the top left corner of the image) can be negative. The context has a clipping region which by default is the whole area of the canvas. When you try to draw something which lies partly outside the canvas only the part within the cipping region will really be drawn, and seen. drawImage has some optional parameters, so context.drawImage (x, y, w, h) also scales the image as it draws so that the full width of the image is scaled up or down to w and the height to h. So panning can be achieved by varying x and zooming can be achieved with w and h. I have found the process to be extremely efficient - far better than could be achieved by processing the image pixel by pixel. 2. When you construct a scene place objects relative to an origin and with a scale factor, both of which you can vary. Use context.drawImage (x, y, w, h) again for each object. You can then vary the origin and scale factor as required. You can see an example of mine which mainly uses the second technique at https://myforest.uk - switch from the initial map to the scene and you will see lots of photographic images are drawn in each scene (saved as PNG files with transparency). If you turn you will see that objects move because the observer's viewing position has changed. I set things so that an object 5 metres away from the observer is drawn full scale but at any other distance d the scale factor is f = 5 / d. Then those final parameters are w = image.width * f and h = image.height * f. There is more description of my techniques at https://www.grelf.net/forestdesign.html - I want to encourage others to use the wonderful creative medium of HTML5/JavaScript. I hope this helps.
  4. 1 point
    Yes good idea! I turned off all my plugins for Chrome on my Macbook Pro and I haven't gotten a profile with a RAF failure in 3 separate 60 second profiles. However, I still see it happen in my game 😛 My guess is that since an RAF is supposed to sync with the browser, Chrome is saying that it's not ready to draw yet and holds the RAF up until it is ready. Or maybe my Macbook Pro isn't giving Chrome the resources it wants to be able to draw again too when the temp rises and fans start up. To test this, I did a profile on my Chromebook with the Pixi playground example and saw many slowdowns, most of them GPU related or caused by large spaces between frame executions. Also some GC. It is obvious that a Chromebook should perform much worse, but maybe it's highlighting the main problem to be with the Chrome browser itself or more of a device specific GPU + CPU available resources type of issue. https://imgur.com/a/0r7KhJ9 https://imgur.com/a/fAJpMID https://imgur.com/a/D4ItbY8