YellowAfterlife

Members
  • Content Count

    69
  • Joined

  • Last visited

  • Days Won

    3

YellowAfterlife last won the day on October 8 2013

YellowAfterlife had the most liked content!

About YellowAfterlife

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    http://yal.cc
  • Twitter
    yellowafterlife

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

1548 profile views
  1. OpenFL-bitfive uses custom software (2d canvas) based rendering algorithms with several purpose-specific optimizations (e.g. BitmapData.copyPixels will clip the imagery if it's only partially visible and will not call drawing subroutines at all if off-screen). Decision making should depend on goals - If you are making a web game that isn't in particular need of Flash or compiled native versions, Phaser is definitely a good idea, as it's an "all in one" library optimized for it's use cases (note that there are also Phaser bindings for Haxe). For porting existing applications from AS3 or developing new ones that may need separate HTML5, Flash (fallback) and native builds, OpenFL (+bitfive) is a valid choice. Generally OpenFL-centric game frameworks do not work as smoothly due to the need to consider not less than 3 different environments (Flash, HTML5, native), each of which has it's own strong and weak points.
  2. 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.
  3. 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.
  4. 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.
  5. I haven't specifically optimized bitfive for use with HaxeFlixel (Graphics and TileSheet classes need a rewrite to be used as often), but I did get it working as such.To say, I'm also not getting said crash with current version of Flixel and sample highlighted in that twitter image. Perhaps it's not the only thing that contributes? You could try dev branch of HaxeFlixel. Some people are working on improving HTML5 compatibility, among other things. Also, if anyone asks, most of issues listed on this forum page are fixed by now.
  6. Late response, but I meant by applying the background as actual (CSS) style, node.style.backgroundImage = "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.
  7. Kenney has made a number of asset packs, and while those may not suit every game, the style is a great example.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. What exactly happens? I don't have an iOS6 device, thus can't even guess.If game is not snapping accordingly, you could took ozdy's suggestion - try polling innerWidth/innerHeight (these can be accessed via stage.stageWidth/stage.stageHeight, by the way) and resize the canvas accordingly (default x/y/xscale/yscale should work fine, though manual style modification may work faster. This needs testing). ColorFilter is not going to work - filters were one of sacrifices to permit higher performance and simpler structure here.BitmapData.draw should work as long as your ColorTransform only modifies alpha value, e.g. var ctAlpha = new ColorTransform(1, 1, 1, 0.7);// ...bitmapData.draw(image, matrix, ctAlpha);Modifying other properties will void the effect.This happens because a alpha-only transform allows to use HTML5 RenderingContext2D' globalAlpha property for fast alpha transformations. While color manipulations via .colorTransform will still work, these are not too fast and are not recommended to be applied mid-run without a good reason. This is also a reason why draw() does not even attempt at applying these - if it were to, it would only make it simpler to cripple performance of application without knowing specifics. colorTransform also takes shortcuts where appropriate, by the way.