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.

Currently a new frame is handled as soon as enough time (1000 / frameRate ms) has passed since last frame. This indeed can result in slightly lower than real framerate. I'll get to improving this once things get less crowded in my current activities. First things first, you need to use OpenFL, and not NME. "haxelib install openfl". It should also be a relatively recent version since support for custom backends wasn't added as long ago. Then you add a line into project.xml as specified in Usage section. As the introduction post states in fair detail, primary differences are filesize (not that much of a deal - it primarily determines how long it takes before you see any kind of loading done game-side), garbage generation (browser may as well choke if there's too much to handle) and actual performance. There's also a slight factor of backwards compatibility (e.g. earlier Android browser implementations tended to miss the Context.clip() method, which original backend uses at a couple of areas) but I wouldn't say that it is driving here.

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.

Though actually, PyxelEdit has signs of such feature being added in soon future. Maybe you could take a look.

Tried again. Game runs pretty smoothly through entire thing, however it hanged up thrice. I didn't expect this kind of Spanish Inquisition so you only get two out of three screenshots. I think it has something to do with collisions. (PNG at IMGUR) But otherwise, game works pretty well, and I even completed it. Missed some achievement though: (PNG at IMGUR) Also I've managed to cause fairly undefined behaviour at menu, making music button trigger instead of "info" button, but it's not possible to show the glitch without capturing touch positions/fingers, so this'll wait till next time. Wouldn't say that there's any problem with difficulty - last levels were hard, but I still managed to complete these with 1 retry max. Talking of which, this is a pretty strange system of level ranking.

I was about to say that this was the smoothest CreateJS game that I've ran on my phone, but nothing goes too good: (GIF at Twitpic) HTC Wildfire S.

Having code structured like render()handle_physics()Would have ensured that physics-related code is ran -after- rendering code. Although, provided that part of code remains synchronous, this most likely would not solve your problem.Perhaps a setTimeout(handler, 0) would help at running code "just after" rendering. I heavily doubt that this is the source of problem though.

Synchronous timing functions? Why would you want those? Of course you can insert an old-fashioned "while (Date.now() < start + delay);" loop, but this is not a good strategy - since JavaScript code is ran in single thread, doing so will efficiently block either tab or whole browser for the time of waiting.

While built-in letterbox settings help the cause, it would be very nice if Construct 2 could also do several simple steps in regards of mobile device compatibility, such as scrolling the addressbar out of view (scrollTo(0, /* values above 0 */)) and preventing default touch scrolling behaviour. This would make a nice contrast to GameMaker: Studio, where users commonly have to use third-party libraries that can also cost a fortune.

You can embed images with "link" mode into Inkscape by dragging images onto the document. This permits realtime composition and creation of mockups. Personally I prefer making a main SVG, and then making a folder called "assets" that will contain images to be embed into it.

Well that is fancy. Seems to be forum-side as well. Though I've seen that Chrome already blocks any non-user-specified attempts to open chrome-URLs, which sure gives a bit of trouble with custom HTML homepage.