html5 and DOM gets no love for mobile apps/games?

I think you'd run into performance problems trying to run a HTML5 game on iPhone or Android. Even on a PC it doesn't run too well.

I think you'd run into performance problems trying to run a HTML5 game on iPhone or Android. Even on a PC it doesn't run too well.

^^ this

My parents have a 1.5GHz older machine. Even running Chrome that has one of the fastest JavaScript engines it is too slow for that kind of games.

Consider that most phones range in 300MHz - 800MHz range. Even in the latest round of phones it is rare to see 1GHz or faster except in the top-tier devices.

There are a few browsers in Android land that support it. I tried running several HTML5 demos on my dual-1GHz android; I can barely manage 5 FPS on several of the simple HTML5 'official' tutorial demos.

Last time I checked my little prank game seemed to work on an android. But sadly I didn't think about mobile browsers while making the input class....

Last time I checked my little prank game seemed to work on an android. But sadly I didn't think about mobile browsers while making the input class....

Yea my game works on mobiles, even the localstorage works on my 2-3 year old android which was nice.

I just don't know enough about mobiles to know what the biggest weaknesses are with performance. Like I have 20+ unoptimized sprite sheets with extra stuff on them I'm not using, up to 4000 pixels wide, and probably 150+ other individual images(icons, inventory backgrounds, buildings, trees, objects, etc). I imagine when I resize them, crop out only the images I'm using, and put them all on an "atlas" image, or maybe a couple different atlas images based on category/level, one for background, one for buildings/objects and one for character/monster sprites, how much will that help?

The background and game area is 5,000x3750 pixels, I don't know what effect that has on performance for mobiles, I imagine it's not good, I'm thinking of generating smaller amounts of tiles around the char and not drawing an entire 5000x3750 bg image . I divided it into a grid and depending what zone of the grid you're in, different stuff is drawn over that background and different monsters are either active or not. If they're active, they start checking distance. I should probably chop up the actual image into sections and only draw sections that are visible based on where the character is.

Also i went through and set some counter properties so certain chains of code only fire every 5-20 frames, also collision detection for projectiles instead of running every frame is turned on when an attack happens and turned off when the attack is over. But I haven't messed around enough to know how much processing the mobiles can do...I wonder if there's a way to modulize the code so on level 1 you only load relevant code for that level rather than my entire game.

Android pisses me off with it's touch events only being able to detect a single touch. On iOS a first touch triggers movement, second touch fires a spell towards the point touched. On android I had to make 4 buttons, if the first touch is within the buttons, it sends the relevant movement, if the touch is outside those buttons and within the screen, it shoots a projectile that direction.

Localstorage was so simple for the amount of awesomeness it offers(minus being editable client side). I was surprised it works on my 2+ year old android's browser.

I also just bought some books on node.js and javascript patterns which have peaked my interest. Even though html5 is new, and very rough, I think there are some really smart people working on bringing it up to par (since it's open source), and the idea of working client/server side in 1 language seems amazing. Like what java was supposed to be. There's already amazing projects for overcoming javascript's weaknesses (like cluster.js for extensible multi-core server management for node.js)

edit:: this looks promising: not on mobile, but html5 canvas with node [media]http://vimeo.com/24149718[/media]

I just a beginner programmer myself so I am not sure what to say to you pros

i hear what you're saying about the simplicity of DOM, but my gut feeling would be to go with canvas. MS and google are putting a lot of weight behind it, it is already widely GPU accelerated across devices/browsers and that will only improve - plus you won't have the same cross browser issues and hacks as with DOM elements.

Android 2.3 and earlier is pretty much a showstopper for html5 games, but Android 4 has HW accelerated canvas and most new mobiles will be at least dual core with decent GPUs.

Check out Rob Hawkes' Rawkets which uses canvas and node.js

I'm also looking at creating a test html5 game using node.js - would be interested in seeing what you've got so far and maybe a collab? I code a bit, have node.js running on my server but my main thing is graphics and sound

PM if interested!

I'm not ignoring you dharmaone I just am pretty newb at the moment and am reading books/documentation and busy irl.

I've been messing around with a tile engine for generating tiled maps in html5 and have discovered a few things. Firstly, Google's V8 engine converts javascript to machine code at run-time, and boosts performance of javascript significantly.

V8 compiles JavaScript source code directly into machine code when it is first executed. There are no intermediate byte codes, no interpreter. Property access is handled by inline cache code that may be patched with other machine instructions as V8 executes. http://code.google.c.../v8/design.html[/quote]

V8 can run standalone, or can be embedded into any C++ application. http://code.google.com/p/v8/[/quote]

Google Chrome Frame seamlessly enhances your browsing experience in Internet Explorer. It displays Google Chrome Frame enabled sites using Google Chrome’s rendering technology, giving you access to the latest HTML5 features as well as Google Chrome’s performance and security features without in any way interrupting your usual browser usage.

The Google Chrome Frame plug-in works in Internet Explorer versions 6, 7, 8 and 9.[/quote]

The plug-in launched one week before Google's extended preview of Google Wave, which leverages HTML5. [color=darkgreen][size=1]Microsoft protested the technology, arguing that it breaks IE 8's privacy features and poses a security threat.

Mitchell Baker, former Mozilla CEO and current chairperson of the Mozilla Foundation, and Mike Shaver, Mozilla's vice president of engineering, both lamented Google's release of Chrome Frame in blog posts. The browser experts, who helped Mozilla's Firefox browser reach 23.8 percent market share largely at the expense of IE, are concerned Chrome Frame will further muddy the already cloudy waters of a fragmented browser market.
[/quote]

The pressure is on browser makers to improve javascript and html5 performance across browsers....or Google will do it for them via plugin.


This version loaded on my htc android phone but only 4 fps, firefox, IE, Safari, Opera, and of course, Chrome(best performance by far). http://simplehotkey....tiles/main.html It's generating a 500x300 tile (150,000 64px square tiles) and measures 32,000 x 19,200 pixels. You can pan it with the mouse or click inside the canvas and use an arrow key to control the character.

The map is based off a 150,000 entry array to draw each tile. It uses a second 150,000 entry array to distinguish which tiles are impassable, and a 3rd corresponding array to add objects/items onto a tile for the player to pick up/interact with....

JS/clientside solutions have definitely peaked my interest lately. In fact, when I first learned about the current run of javascript MVC solutions, I started making a RPG. JMVC is my choice currently only because it has all the pieces.

Now, in terms of making a web browser games, the bar has risen, but it still is not equal to true client-compiled gaming. Just with basic CSS3 transitions/transformations you can accomplish a ton. NodeJS should be first thought in terms of a socket handler to web browsers, so you can get db update monitoring with client notifications. Simply, that means all the basics of multiplayer is handled.

I personally do not recommend canvas (yet) because I still have a belief that if you are going to make a browser game/app, then it should be accomplished through HTML/CSS manipulated via JS. I say 'yet' because I am still ignorant at what canvas is after, and that I have accomplished a lot without it.

My final comment on this thread is that I am happy that Flash is not mentioned as a solution. I was always against Flash, and I am reveling in the fact that Adobe and Google are not supporting it.

I personally do not recommend canvas (yet) because I still have a belief that if you are going to make a browser game/app, then it should be accomplished through HTML/CSS manipulated via JS. I say 'yet' because I am still ignorant at what canvas is after, and that I have accomplished a lot without it.

Pretty much anything that requires complex rendering. Scaling, rotation, etc. Also it's much faster at showing many sprites and such. Basically it's a framebuffer and it was made specifically for games (there are other uses, but games were one of the main reasons if I recall correctly). It may be overkill for an UI you could easily express in HTML, but for complex 2D games it's pretty much the only reasonable solution if you want decent performance. DOM is just too slow at rendering and also you'll be messing up with the HTML semantics, which can carry an even worse accessibility issue than not implementing accessibility at all if not handled properly (since you could end up feeding wrong information).

Also one thing I noticed is that a lot of people use setTimeout or setInterval for timing... which is a bad idea. You're guaranteed at least the specified amount of delay, but they don't make a stable timer by any means. I found a lot of games slowing down because they assume the timers are perfect, and they aren't. You're probably better off using getTime to make your own timer (and beware of the clock changing, e.g. user adjusts the clock, DST, etc.) and use that timer to keep track of the game logic (limiting setTimeout/setInterval to just having your main loop be called periodically).

I was just looking to get inspired and checked out a couple browser mmo's only to find one using html5 in a way far simpler than I ever expected players to tolerate, yet it seems populated.

For example, the game "Lord of Ultima" from EA, uses a canvas game window with what appears to be a DOM interface, which is just a front end "vew" to some database tables updated constantly with ajax.

When a player performs an action, the server starts a timer incrementing table entries for that item. The client simply refreshes it's elements display of table records via ajax every second.

It's basically battling database "records" vs "records". No npcs, no players to synchronize.

Very basic chat, it's like the absolute minimum required to call it an mmo....very interesting as it seems extremely simplistic. Also decent application of canvas in a browser game by a large company. Gave me several ideas to incorporate.

Edit:: Also I'll have to check out the setTimer instead of setInterval. I found when I cut down on globals and wrapped properties/methods within an object it seems to perform very well.

Also looking at custom webkit or standalone V8 framework to run canvas games, I think V8 is on the money converting javascript to machine-code at runtime...now if only they can do the same for mobile devices...

Edit:: Also I'll have to check out the setTimer instead of setInterval. I found when I cut down on globals and wrapped properties/methods within an object it seems to perform very well.

The main difference between setTimeout and setInterval is that the former just calls the callback once while the later keeps calling it constantly (until explicitly removed). Both have exactly the same timing accuracy issues I mentioned before, which is why I suggest against using them for timing purposes and suggest getTime for the job instead (leaving setTimeout/Interval for just keeping the main loop going on regularly).