• Content Count

  • Joined

  • Last visited

  • Days Won


YellowAfterlife last won the day on October 8 2013

YellowAfterlife had the most liked content!

About YellowAfterlife

  • Rank
    Advanced Member

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2098 profile views
  1. Pretty much so. You can still consider the local position sent back from server, but need to interpret it accordingly (see input prediction), as it is delayed by time needed for data to travel there and back.
  2. Phaser itself has little to no impact on multiplayer part of the game. What you are seeing is also not a performance issue, it is the erroneous client-side code handling the data. Applying "returning" data to the local player directly is a pretty bad idea. What you should do by least, is add some actual interpolation algorithm to handle gradual changes of positions and velocity. At some point I've used this algorithm by @thijsmie: t2 = t * t t3 = t2 * t dx = t3 * (2 * (x0 - x1) + vx0 + vx1) + t2 * (3 * (x1 - x0) - 2 * vx0 - vx1) + t * vx0 + x0 dy = t3 * (2 * (y0 - y1) + vy0 + vy1) + t2 * (3 * (y1 - y0) - 2 * vy0 - vy1) + t * vy0 + y0Here,(t) is time factor for interpolation (0..1) (x0, y0) is initial position (vx0, vy0) is initial velocity (x1, y1) is destination position (vx1, vy1) is destination velocity (dx, dy) is interpolated position.
  3. I've made a small illustrated tutorial on how to host HTML5 games on Google Drive for free. This can be particularly useful if you need to provide playable builds but do not have a reliable method of hosting them on your own.
  4. Late response, but I meant by applying the background as actual (CSS) style, = "url(" + canvas.toDataURL() + ")";If this proves fast enough (compared to canvas background drawing), you would only have to clear the canvas with transparent color, while background would be handled by browser.
  5. Kenney has made a number of asset packs, and while those may not suit every game, the style is a great example.
  6. TypeScript stays quite close to JS syntax but adds, well, types (and classes). In a sense, it also saves you a headache or two, as long as you don't stumble upon any bugs in it. Software like Visual Studio also has excellent support for both JavaScript and TypeScript. CoffeeScript option is discouraged, since the syntax is less similar to original JS, and the resulting code may end up looking even odder than JS for certain kinds of applications. Haxe is an amusing option since it permits you to not deal with "target" languages directly - you always write the healthily typed class-based Haxe code, which then translates into binaries or sources most appropriate for purpose. It can take slightly longer to get hang of (as opposed to JS) but I would say that it's well worth it.
  7. There would be no reasonable difference between a 2D canvas and image, since canvases are raster in HTML5. As such, using toDataURL would logically be even a little bit slower, since image would have to be encoded and then decoded. Perhaps a single case where it would be appropriate would indeed be the use of background for element, but probably not as a separate DOM node, but rather a canvas element style property. That would have to be benchmarked carefully though. For small tiled backgrounds you can also make a "cache" image that would be slightly larger than canvas to permit covering the whole thing with a single draw-call. Most frameworks like Phaser or HaxePunk would already include such a thing, and for custom code you can implement it quite easily. Post is pretty old (and demo page got lost a while ago), but code is present and still works.
  8. I very much second this question. One of my projects uses node-webkit, but output executables are simply a bit too large, so I'm considering options. It would be of use to be able to sacrifice some functionality for smaller filesize.
  9. Actually, not one way: Depending on architecture, you may be able to generate JavaScript code from CPU instructions. Once parsed and formed into a function, this can grant performance quite more amusing than that of fully interpreted code. Obviously, there are also caveats, such as goto/jump instructions. Generally, while these emulators are interesting, there's still long way until these will work well enough on most devices - there's a large difference between how most older consoles and mobile browsers work.
  10. Server can be set up to send game data in small portions (e.g. 16KB each), which would be later reconstructed into files client-side, but this is normally too much of a sacrifice for a smoother loading bar.
  11. Not to be confused with iOS - Android never had an equivalent security policy [like Apple does about loading media content] - sounds can be played anytime. Though it's still not quite good without WebAudio support. I wonder what influenced the decision to exclude that from WebViews. As Rich has mentioned, lack of fullscreen API doesn't matter much, as it is common to hide browser controls on in-app WebViews anyway. At least there's going to be faster canvas and V8.
  12. You can use web fonts. With enough font files provided, most of target devices and browsers will be able to load the correct font. There's also a workaround though - use bitmap fonts. That is, all relevant glyphs are rendered into a texture sheet, and then drawn accordingly to display separate characters. Implementations of popular formats like BMFont exist for most of commonly used frameworks. Second method may require slightly more memory for larger fonts, but gives consistent results regardless of browser and device rendering specifics.
  13. Approach differs for desktop and mobile. For desktop you would need to ensure that your game fits all target screens (probably including those netbooks, unfortunately), so the maximum resolution would be 1024x600 for full-screen games, and around quoted 960x540 for windowed ones. Desktop games aren't scaled often (except downscaled, if they don't fit screen after all), since quality degradation is a lot more obvious on desktop (thanks to lower DPI ratios on screens). For mobile, game is commonly designed with a single resolution and then up or down-scaled to fit others. Commonly picked resolutions are 320x480 and 640x960, but you should keep in mind that the bottom area can be covered with browser controls, thus should not be used for important/interactive elements.
  14. It seems to be a common practice to have a subfolder per every HTML5 game. So the structure may be as following www/. . js/. . . . script.js. . css/. . . . style.css. . . . print.css. . img/. . . . logo.png. . games/. . . . game1/. . . . . . index.html. . . . . . game.js. . . . . . img/. . . . . . . . texture.png. . . . . . snd/. . . . . . . . music.mp3. . . . game2/. . . . . . index.html. . . . . . game.js. . . . . . img/. . . . . . . . background.png. . . . . . snd/. . . . . . . . music.oggThis way you would have no clashes between different games.It is also recommended to have games either open in separate tabs or iframes to avoid JS source clashing between many.