YellowAfterlife

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.

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.

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.

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.

Oh stop it, you.

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.

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.

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.

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.

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.

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.

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.

I haven't made any separate examples (though I may soon), but most HaxePunk examples run quite fine with no or little modifications. Other than that, bitfive is primarily intended for use with applications and frameworks that use a single (or a few) Bitmap objects to represent the game on screen. This also is the preferred way of building games for mobile, since older devices are not able to handle too much dynamic DOM objects at once. One other thing to watch out while building is that you also need to provide OGG versions of audio files for game to work correctly in browsers without direct MP3 support (such as slightly earlier versions of Firefox). CreateJS is indeed pretty good, but still problematic to use if you want to target both Flash and HTML5 from single codebase.

To some extent, yes. Game-side logic (such as entity/component management) would have to come from other sources though.

Fixed. copyPixels & draw indeed remain the preferred method of drawing though. Testing validity of implementation is hard sometimes.