$12256 / $11500
Yeah, maybe slightly the wrong forum, but then again, those code platforms have no idea about game design, imho. Except maybe some js famework modders.
Personally I like to code. I was using Blitz3D in windows for a very long time. Besides an old direct3D library, it has also the basic 2D and sound command set you would expect. So it is perfect to quickly develop prototypes, which I then port to the rather picky javascript. This works well.
Initially there was a hype about the html5 canvas, but I quickly realized how slow it is. So I am currently going an other route, instead of drawing images to a canvas context, I am drawing them directly to the page body, by using css positioning. This of course requires each umage rendered to be a seperate image in Memory. Yet, it's not that much of a problem to keep 100 or something images in memory. By setting their. src I can give each one the data of any of the separately loaded reference tiles.
This way I can have at least ten times more sprites onscreen, with the same framerate, compared to canvas.
Additionally, using css, these sprites can be scaled, faded in/out (.opacity), rotated and even 3D transformed.
This is pretty fast, since most browsers use code that was optimized for decades for the basic page layout.
For me it's also an interesting aspect to write something that runs ok even on older browsers, like those with partial html5 support.
If it wasn't for atlas loading by using a cancas to copy the sprites etc. from the atlas to the single images, I wouldn't have any canvas in my little test engine.
I know, webgl may be even faster, but there are still too many users without proper support I think. But there may be other tricks? How to speed up graphics in html5 js coding?
This website's content is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Fun hack, I wouldn't have thought using CSS would be that much faster. I guess though that if all your moving parts are like this:
.sprite { position: absolute; top: (x)px, left: (y)px, z-index: (z); }
then the document layout isn't really changing and it should be super fast. Something like that? Have a demo somewhere we can look at?
I've been using html5 canvas for all my game prototypes for a few years now. But I like making tiny low spec games so I'm not really having canvas performance issues.
I think canvas optimization will catch up at some point (if it continues to be an html standard). Same thing that happened to the technique you're using. Those "DHTML" techniques were new and awesome circa 2000 but game performance was always too poor compared to Flash.
Your technique may be a good fallback plan for maintaining web games. That vanilla CSS is going to be supported long after any other game tech for browsers.
I have not made any games with HTML5 but have utilized some of the latest features in web browsers including the canvas to make an HTML5 audio visualizer video maker. You pick an audio file, customize how the visualizer should react to the audio, and it is recorded in real time right in the web browser and saved as a webm video file. Before I started the project I knew nothing about the canvas. By the time I was done I figured out some of the tricks needed to make the performance be optimized. With that being said there are valid points for using the DOM + CSS vs the canvas.
"Additionally, using css, these sprites can be scaled, faded in/out (.opacity), rotated and even 3D transformed."
The canvas can also can do scaling, opacity, and rotations. I'm not sure about 3D transformations. I haven't worked with anything 3D.
I would personally read up on canvas optimizations and see if there is anything that you have missed on how you could squeeze out more performance. Things like using multiple canvases as layers, using smaller hidden canvases for certain operations and drawing those to the main canvas(es) instead of always drawing the image directly, and avoiding costly operations such as context save and restore and instead keep track of changes made reset them yourself or figure out a better way to avoid needing to use it at all.
With that being said if your game is pretty simple and you are getting the performance you want in the DOM then there is nothing wrong with using it. You might run into some consistenty problems though that make it diffucult to support a wide range of web browsers. As mentioned above you could use absolute positioning to avoid the DOM having to reflow the entire document which would give a performance gain. I don't have much else to offer for DOM performance boost tricks.
Thanks, yes indeed, canvas has some very interesting features. As of now, when I am working with sprites and tiles, css does a pretty good Job. Canvas allows 3D transforms by using Matrices, btw. Also, a canvas supports eighter "2d" or "webGL", which is cool, although WebGL is in fact just a hardware accellerated 2D transformator, in which one needs to use Matrix transformations as well to get real 3D, although one can put this into neat functions. I keep on experimenting with this css approach, also because it's a bit of a niche. BTW do you know any doublebuffer flipping or vsync possibilities for canvas?
Hi, here's how I do it in javascript:
id = document.getElementById("mypic");
id.style.zIndex = ""+(i+5);
id.style.position = "absolute";
id.style.top = my_y + "px";
id.style.left = my_x + "px";
id.style.width = my_width + "px";
id.style.height = my_height + "px";
opa=(ybuf[i]-240)/50; // just using some data for fade in frome distance
if(opa<0){opa=0;}// opacity range 0.0 to 1.0
if(opa>1){opa=1;}
id.style.opacity = ""+opa;
// id.style.mixBlendMode = "screen"; // unfort. not working in opera and webkit
where mypic is the id on the html tag <img src="someurl" id="mypic">. There is also style.display="none" and ="block" to actually hide and show individual images. They can also be positioned offscreen, but that is most likely slower. You may be able to position and hide anything that way, not just images. Just use the id of the html element.
I'm not sure about the double buffering but requestAnimationFrame is closest thing to vsync. You could read up on it more to get all the technical details. Basically it's requesting that the frame be drawn when the screen is refreshing.
Thanks, that may be the one.