How come that people bring CC into play? I thought the headline made the context clear: "Status quo of HTML5 gaming". The current state of HTML5 gaming. As far as I know CC has nothing to do with HTML5.

Is it the first paragraph of the original post? It is just an optional introduction to tell you a bit more about me, to let you know my relation to the Scirra products. That's all.

Ah I did miss something :P But like Captain said, if you use wrappers like node-webkit or cocoonjs you'll get the consistency that browsers lack no? Unless you need web deployment that is.

But... node-webkit is the export option of choice for C2 Windows deployment. If CC can only produce Windows executables then isn't that what you need to compare it to? Forget about inconsistency between browsers; CC could never do browsers anyway. Unless I'm missing something.

Unfortunately no. Not for fullscreen anyway.

[SPECULATION TIME]

html5 is the problem here I think. It's intended for browsers as far as I know and browsers don't need/provide access to screenmode changes. Exporters like node-webkit do a good job of camouflaging themselves as native exes but they *are* in fact just running browsers minus the browser interface. So even fullscreen is just a window stretched to fill the screen so the end-user can't tell the difference. In other words, node-webkit at least can't change screen resolution because it can't access it. C2 works around this by providing options to scale everything up to the current resolution (whatever the desktop or target device uses) and that's cool in most cases. But speed-wise not in all unfortunately. Good news is you can control resolution in window mode now at least, and maaaaybe that's just the first step in a grand solution Scirra is planning. So I'm hoping anyway :P

Depends on the game. 3D games are resolution-independent which means the game has a bunch of 3D objects with levels of detail (polygons) that stays the same regardless of screen resolution. In these cases all screen resolution does is determine the number of pixels used to draw the 3D objects on screen. 2D games, and especially 2D games with pixel art like you see in most 70's to 90's era games, rely more on specific screen resolutions to draw properly but like 3D, 2D game objects also have individual levels of details(pixel resolution) that can be scaled up or down to fit the target screen resolution.

Your gfx card has a selection of screen resolutions that it supports, usually in the range of 640x480 to 1900x1200 or something for newer cards. When you set a game to run in one of these resolutions you're telling it how many pixels to use to represent the graphics on screen. But all the rendering calculations, physics etc take an equal amount of time to process. So in terms of strain on the CPU and GPU game objects have little to do with the screen resolution itself.

Hope that helps?

Cool!

One thing that would be nice is an external script system that compiled runtime builds can run. You could allow for modding with that. Maybe this is possible already with the JS SDK?

This is a very nice concept. I like the general design and animations very much. Seems to me there's not *that* many animations or effects that C2 should croak over em. But I often got jerkiness when a projectile moved within range and the character didn't always respond to input during those times. You say things sped up when you turned off animations.. do you use a lot of collision polygons for your frames? If so, maybe try to use simple boxes instead?

EDIT:

Actually, scratch all that. I tried to lower the desktop resolution to 800x600 and the game ran so much smoother it's not even funny. So I got a lot further than before and yeah, you have a *lot* going on in some areas. The jerkiness for collisions went away but I got it in other places. When new gfx got shifted into video mem perhaps? I dunno. Hard to tell.

Been asking for this to get added. The way I understand it, sample filtering gets applied on image load so to switch it on/off would require a reload of all the gfx... Which is fine by me. As long as the option is there.

I get the same green with red lines as sqiddster in Chrome on:

Geforce GT 540 M / driver version: 295.73

Win 7 64 bit

+1

DRM-free is a major selling point for smalltime indie games. Embrace it :D Oooor... you could create an in-game serial code system that unlocks the full game after it's plopped in the first time. Lots of work to create all them individual codes tho.

Anything pre-rendered draws at the same speed as long as the image resolution is the same.

In terms of aesthetics and workload lo-poly is the better choice imo but it depends on what kind of look you want. Me, I can't stomach hi-poly pre-rendered gfx most of the time. Unless it's done with great care to shaders and lighting it tends to look very cheap and plasticy to my eyes. That Donkey Kong image is a prime example. Just look at it! If you're doing a cartoony look I think lo-poly will work better, especially if you hand-paint the textures and don't go overboard with pre-rendered lights. Workload-wise you'll be a lot better off too.