html5cube–The HTML5 Cube
I’ve been wanting to do a puzzle cube with video on each side for a long time as a tech showcase. Finally I got bored enough to do it.
html5cube is a 3D puzzle cube with video on each side. Make sure you’re running IE9, Opera, or at least Chrome, and go check it out at html5cube.com.
I haven’t extensively ripped it apart in many browsers, other than IE9 and Chrome. FIrefox got a real workover, and after Firefox 3 or 4 simply not able to play nice, I’ve ignored them. Their performance is crap, and I think that ends up causing all sorts of race conditions. I might look into it in the future, but this experiment isn’t for Firefox.
Lessons learnt:
- IE9 still outperforms the other browsers when juggling more than 1 thing (matrix maths + lots of drawImage calls)
- webm is much fatter than H.264 and OGG. I increased the encoded images by 4x, H.264 ended up SMALLER, OGG went up by about 20%, and webm went up about 3x. As such the worst video quality is webm since it’s the low res version.
- <video> playback varies between browser in terms of CPU priority. This means that CPU intensive JavaScript calculations can chop the video around, and other browsers the video chops the JavaScript around. Yet another metric to balance.
- Three.js is excellent.
- Canvas rendering (as per my previous post) leave visual artifacts and different approaches in each browser. Anti aliasing, and texture resizing all differ and it causes changing visuals. IE9 tends to look the best, but I think that’s half good management, half convenient accident.
- It’s on canvas, and I think every browser that has WebGL support is ignoring canvas performance completely. I still am surprised at Chrome’s poor scaling with pixel count.
- Cubes are still very very awesome.
- Cubes that have video in each side are much much harder to solve.
HTML5 Video Codec Selection in JavaScript
I was looking around for a nice video codec selection via JavaScript, and possibly writing my own if I couldn’t find one. Outside of the video players, there isn’t a library either.
It is possible to interrogate the <video> element to find out what codec support it has. The problem is that it is only reliable in Opera. All other browsers are completely unreliable.
But there is an easier solution if all you are trying to do is load the right video via JavaScript. With video selection being an option within the video tag itself, you just need to create the <video><source/><source/></video> via JavaScript. Assuming your video files are encoded correctly (and the server is sending back the right mime types) you’re set!
// Takes a file with no extension, and
// creates a video element for webm/h264/ogg
// and plays it
function createVideo(fileNoExt)
{
var newVid = document.createElement(‘video’);
// IE, Safari, IOS
var h264 = document.createElement(‘source’);
h264.setAttribute(‘src’, fileNoExt+’.mp4′);
h264.setAttribute(‘type’, ‘video/mp4′);// Firefox
var ogv = document.createElement(‘source’);
ogv.setAttribute(‘src’, fileNoExt+’.ogv’);
ogv.setAttribute(‘type’, ‘video/ogg’);// Chrome
var webm = document.createElement(‘source’);
webm.setAttribute(‘src’, fileNoExt+’.webm’);
webm.setAttribute(‘type’, ‘video/webm’);newVid.appendChild(webm);
newVid.appendChild(h264);
newVid.appendChild(ogv);document.body.appendChild(newVid);
newVid.play();
}
I’ve been using this approach for a few things, and it seems to work every time.
NOTE: The order of source elements is important. iOS 3.x has a bug where it only looks for the first element, so H.264 should always go first.
Read MoreA Standard HTML5 Standard Standard
After working on www.wayoutwars.com, and tinkering with other ideas since, my original thoughts on HTML5 increasing the gap between browsers is becoming apparent. Having the HTML standard is awesome, but until everyone has a standard approach to the standard, we’ll still be making exceptions.
Not everything in this post is HTML5, more HTML and JavaScript in general, but with HTML becoming an evolving standard it makes it more important for there to be consistency as adoption of HTML features will become increasingly staggered.
The core issue is with interpretation, and/or certification. Who certifies that a browser is HTML* compliant? Whether it’s a central body, or an individual tester, they need to ensure there is consistency, but in the scenario of the individual tester, what is the benchmark? If text is being rendered on the page, what are the metric to measure that it is rendered correctly? I’ll take a step back from HTML to explain.
Bad Jump
If I was to write a specification for a computer game, one of the aspects to be described is controls. To simplify it for discussions sake ”when a player hits ‘fire’, the character will jump. Jump duration is a maximum of 2 seconds, to a height of 10 units”. But how this occurs has many options:
- Is there in air control?
- Is there hang time at peak or is it a parabolic jump?
- Does the character slow down in the air?
- If the character hits a ceiling/wall do they fall immediately or still hang?
- …
New initiatives in games are benchmarked against all the previous successors. There is always a parallel. This is why jump times in all 2D platform games are about the same.
Coming back to HTML, the standard may be open for interpretation, but just because a new standard is being implemented doesn’t mean that the function of the standard should behave any differently that you would normally expect.
I’ll start with the basics.
Text Rendering
One of the fundamental things that every browser does and has done since the beginning, is render text. Visually, this is the primary concern of the browser. So one would expect that this is something that does not merit discussion.
As such, I’m not sure how this gets through testing, but take a look at the following in Firefox and in parallel have a look in Chrome and IE9.
Chrome just AA’s the entire thing into a blurry mess, but at least it makes sense, if undesirable. IE9 realises it’s rendering text, and does more intelligent text smoothing.
But Firefox’s behaviour be described as a bug. By default, text should be render with no anti aliasing, and if you have some smoothing it shouldn’t degrade the legibility of the text. Having to design for another browser, or cater for it in code, is bad. This just makes everyone design in to keep their designs predictable and maintainable. For those without HTML5, or Firefox, or super sonic zoom eyes, let’s have a closer look at FF’s rendering.
NOTE: You do not need 3D glasses to view the above picture.
Once your eyes stop bleeding, lets look at what is actually being rendered. Anti aliasing with shades of red, green, and blue? What is going on here isn’t in the style of Apple IIE monochrome monitors (for those that remember) but actual colours being rendered. A single vertical line has a line of blue, a line of green, and a line of red. Did anyone actually test this? It’s like no one knew how to do text smoothing, so they just put 1 of each colour around the text.
Also notice how the vertical line in IE is doing anti aliasing on the 1 pixel line, making it appear transparent, and in Firefox it decides to make a 2 pixel wide line to avoid the issue altogether. So while IE9 has good text smoothing, the anti aliasing logic in both browsers is broken and inconsistent.
It also negates the awesomeness of WOFF and the Google font API if you have to use bitmap font templates to have consistency (and even then not 100% reliably).
Media Handling
MP3 vs OGG. I’ve stated my views on this. Support OGG if you want, but don’t ignore MP3 if you want to be serious about creating a media rich web. MP3 is out there, everywhere, and creating a barrier for innovation is dumb.
I won’t start on video codecs, that’s just too much of a mess for now.
Secondly, the extremely poor memory management regarding audio. In all browsers, eventually media elements hit a limit. For most sites this isn’t an issue. But at about 50 megs of audio, IE9 stops loading new audio, even though the previous audio elements were removed. They had to be ‘delete’ed. Chrome hit this issue a few tracks later.
When deleted every browser behaves consistently and smoothly, except Chrome, which goes silent for no apparent reason at around 280 megs of audio.
You may ask why on earth would a page have 280 megs of audio? This isn’t isolated to www.wayoutwars.com but is also a problem for audio stores where you can preview sample audio, and online radio such as www.lastfm.com that could be playing gigabytes of tracks.
JavaScript
I’m not talking syntax, but being able to crash a browser in JavaScript doing a standard JavaScript call just isn’t acceptable.
The line was ‘delete a;’ where a was null. I was trying to reproduce the error, but in isolation it seems to work. Why does it crash Chrome but not consistently? I’m currently assuming it’s to do with Chrome trying to be smart around garbage collection that is not thread safe.
Never mind whether the syntax used is good form, JavaScript should not crash the browser. And since it crashes the browser, it doesn’t throw a JavaScript error, and has to be debugged from an external debugger like Visual Studio.
Final Thoughts
My biggest issue is that we’ll end up in a world supporting multiple codecs for audio and video to support different browsers, increasing cost of implementation, and reducing budget for innovation.
It’s not all doom and gloom, but for the discussed issues, and others, I feel that there is no short term win. The LCCD (lowest common common denominator) consistently will be the target platform.
Read MoreNobody Likes A Space Chicken, Everyone Should Love HTML5
Over the last few weeks at work I have been head down involved with building a fun HTML5 game for EMI titled ‘Way Out Wars’.
Way Out Wars is a fun game for casual gamers, and provides the much sought after challenge for veterans of the ‘space chicken music discovery typing shoot ‘em up’ genre. The game was built in pure HTML5, with some heavily modified impactjs as the core engine. Lots of long hours spent tuning nanoseconds off particle render times.
My best is 75 tracks back to back for around 44 million. Go play it at http://www.wayoutwars.com … preferably before reading the rest of this post to give insight.
Some things achieved in HTML5 that were pretty cool:
- Real time usable particle effects engine we had to dumb down because it was just looking too busy (yet awesome). At one stage we had smoke, jets, trails, explosions, musical notes, and swarms. Unfortunately you couldn’t see the game.
- Infinite playlist – Depending on your browser, since Chrome mysteriously dies
- Music discovery that’s fun – Songs you hate, songs you like and songs you don’t know, that you can review and purchase.
Some pleasant discoveries:
- HTML5 rocks. It’s definitely a platform for the future, however it’s not necessarily the be all and end all. But the game has no browser dependent coding. It does however have code that checks for issues that may occur in some browsers, there isn’t any code that goes ‘if IE do this, if FF do that’.
NOTE: This does happen for audio however since Firefox hates MP3. - Impactjs rocks! In the end we probably didn’t need it as much as we thought, but it did so much heavy lifting in the beginning it allowed us to experiment and play around with ideas. We simply wouldn’t have had a product as far advanced without it.
- HTML5 benchmarks don’t coincide with real world scenarios. Simply ignore them until real world tests turn up. Every benchmark I do IE9 doesn’t come out on top, but all of our experience with the game has been IE9 is way out on front, with no IE9 specific tuning in sight. Someone who is familiar with graphics pipelines who understands the concepts behind draw calls, fill rate etc. needs to give HTML5 the same treatment.
- As such, IE9 rocked, and we were pleasantly surprised.
- Opera is amazing, although I’ll probably still never use it. It came in 2nd performance and stability wise.
- Firefox and Safari were stable, however their performance lacked.
- Chrome was fast, however it’s stability lacked.
- Hardware acceleration rocks. Browsers without it will die slowly as user experience becomes encumbered by poor performance.
- The iPad did load it once, but it got too big for it. This however is promising for HTML5 moving forward when the processing power of these devices steps up.
Some discoveries that were as fun as being jettisoned into the sun by space chickens:
- Having lots of <audio> elements on a page can cause issues. Clean them up, delete them, and do everything you can to remove any trace of them. This was common for all browsers, with the impact having different results in each. But cleaning up the audio elements makes all the browsers behave. And whilst Chrome will still go silent after about 100 songs, without doing this it will crash after 57.
- Oh, and be careful deleting i.e. ‘delete obj;’ audio objects in Chrome, you can crash the browser and all open Chrome windows will stop working. I think Chrome tries to do garbage collection on audio elements no longer in use. A quick check ‘if(obj != null) delete obj;’ tends to be stable.
- Any browser that doesn’t support MP3 needs to fix that. It is a bug, not a feature. If every music site in the world has to re-encode their audio to OGG, they will ignore browsers that require it, or simply be ignorant to it. Firefox needs to wake up. Media companies are going to be staring at mobile devices, and Firefox is the last thing their IE and Safari based offices will test in.
- Firefox 3 is antique, Firefox 4 feels like a classic, that still goes well, but won’t keep up for long. A shame. This feels like a Firefox bash, but it has just been the reality we’ve been dealing with.
- Chromes instability. Chrome is fast, yet buggy. We discovered a critical error that would happen on the 57th track crashing Chrome. After writing a universal piece of code that wouldn’t crash Chrome, we found that at some point, chrome refuses to play audio, and kills audio across all chrome tabs and windows, with no error message. This came as a surprise to me, and over the coarse of 3 weeks Chrome has been superseded by IE9 now as my default.
- Safari underperformed. Of the big names it was the worst performer.
This Blog Post Best Viewed In Netscape Navigator
</2 years not posting>
HTML5 is great. I’m really looking forward to it, but with all it’s standardised extended capabilities comes a new frontier, browser performance.
I’ve been playing around with IE9’s GPU accelerated HTML5 SVG, and performance blows Chrome and Firefox out of the water. Throw in a few physics engines and play around a bit more though, and you start to notice the performance spread shifting dramatically. Because IE9 is doing all the display calculations in GPU, the choke point is the physics engine, and that choke point is the JavaScript engine, so it generally slows down proportionately to world object calculations (once the world step calculation time exceeds your physics time step delta).
With Firefox and Chrome, you start to notice massive differences early on. Chrome starts to slow down, but it flies compared to Firefox, which seems to struggle pushing everything through the physics steps and the graphics rendering at a decent frame rate. If I was to rate the performance in the ‘Eyeball HTML5 Benchmark TM’ it would be 100, 60, 20 to IE9, Chrome, Firefox.
But this isn’t a browser war rant, this is a rant about the problem this creates on the developer side.
At the moment the main considerations when doing an advanced website are limited. The questions asked by clients are generally straight forward.
Will this run on the PC’s of our users (CPU, resolution etc)? Will it render correctly in all browsers?
I’m not talking about a bleeding edge benchmark of performance, but something consumer mass market oriented. My concern is that with the new era of HTML5 RIA apps emerging, the performance gap in rendering and JavaScript, are we going to re-enter a world of ‘Best Viewed in Netscape Navigator’ ? WebGL is coming in Chrome and Firefox, but Microsoft has no public announcement it is going to come with IE9. The underlying engines when they arrive will differ drastically in performance. SVG, Canvas, WebGL, and HTML rendering performance may vary between browser, CPU, and GPU.
But even on the day that Chrome, Firefox, and IE have relatively equal performance metrics, with mobile internet usage projected to outgrow desktop internet usage by 2014, the problem gets exponentially complex when catering for mobile devices, tablets, and the rest of the crew.
The cost of development and testing goes through the roof. Creative designers have been trained to think in terms of Flash / Silverlight and the predictable performance metrics, and development houses without foresight will start pumping out amazing creations that only work under lab conditions.
And while as a geek I will write something to push the GPU in IE9, I don’t see it as a compelling reason to develop bleeding edge clock cycle pushing code until the all browsers are up to speed. I do see GPU acceleration as a reason to use IE9 so hats off to Microsoft for getting that in there. I’ve found it much snappier than any of the other browsers at the moment. But throwing something out there publicly knowing that in FIrefox it will crawl along slowly is not compelling at all.
I’ve been hearing a lot about the future of gaming and apps, and simply put, it’s a long way off for now. The technology is there, but the industry is not. While the future may hold some exciting things for HTML5, the short to mid term holds some nice standard ways of doing things that for the past 10 years have been HTML and CSS hacks. And that’s enough to get excited about for now.
PS – Any other browser I haven’t mentioned above is still relevant for this discussion, and the ‘if everyone just used X’ argument simply reinforces the issue.
PPS – IE9 GPU acceleration can be seen working best with SVG, and not to be mistaken with WebGL. 3rd party 3D libraries I’ve found just come down to JS execution speed, the rendering is the baby step in those scenarios.
Read MoreSilverlight 3DSMax Exporter – Update
The exporter is coming along nicely. I’m really happy with the results. So much so that I decided to create a Q*Bert scene. Click on the image blow for the full sized image.
In the image you have 3DSMax in the background with all it’s wireframe goodness. The render on the right, and as you can see, the Silverlight output in Firefox on the left.
Features in the short term will be more .NET features, as full scene rotation would give fantastic interactivity, and open up the door for useful Silverlight transitions. Texture mapping is another one I want to look at, mainly focusing on texture scaling and offset.
Read MoreSilverlight 3DSMax Exporter
Silverlight 3 comes with the new shiny Projection and PlaneProjection for perspective 3D effects. One issue is to create rich 3D environments, you need a good toolset, and although Blend is a great tool, it’s not a 3D authoring environment.
Enter 3DSMax. 3D Studio has an awesome scripting capability in the form of MaxScript. Writing 3DSMAX exporters is a past time of mine, and having had a conduit to John Wainwright (aka Mr MaxScript) at that time I became very fond of 3DSMax and MaxScript. But here ends the history lesson.
The main aim of the Silverlight 3D Studio Max exporter is to create a pipeline for 3D authoring, through to Silverlight in browser, and convenient stops in between. It shouldn’t ignore or outcast Visual Studio or Blend (or Photoshop etc), and should not replace them. But where as Visual Studio is a coding environment, Blend an awesome behavioural and layout authoring environment, neither are good 3D authoring environments. The Silveright 3DSMax Exporter hopefully will fill that gap.
So first up, lets take the following image.
In the screenshot below I’ve taken the above image, applied it as a textures to planes (rectangles), replicated them helix/spiral paths in various directions, textured, translucent, with a blue environment background. This process took about 2 minutes.
You can see in the image above the front perspective wireframe, the render, and an angled perspective view showing the planes along the various paths.
But with a click of a button, this 2 minutes of work gets exported to XAML in a second. Alt tab to Blend (Visual Studio doesn’t like ImageBrush for some reason) and voila, instant 3D.
Note that the background is actually blue, but Blend doesn’t stretch it to the full view by default. A quick stop over in Visual Studio and every object is named and available in Intellisense.
And the real test, taking it to the the browser. Firing up Firefox gives us…
So in 2 steps, 1) Export, 2) Build, we have a 3D Studio scene in Firefox.
Currently in v0.001 pre alpha, but I thought I’d post some information about what I’ve been working on. But it truly is 1 click, 1 build. No smoke, no mirrors.
So what features does it currently have? For the time being I’m focusing on only 1 shape, being a rectangle. Simple shape rotation can be done in Blend. Max is for full scene creation. Shapes are the easy part, and the hard part is getting coordinate transformations, texturing, and full scene rotation. These are the real features that I’m currently working on, and I’ll let you all know when it’s ready to get your dirty mitts on. Stay tuned.
Read MoreFive Second Test
Following a tweet from shanemo, I decided to check out fivesecondtest.com, and took the 5 second test. I had no idea what it was prior to turning up, but within 10 seconds the minimalistic site had me sold. From the site…
The five second test is a simple usability test that helps you measure the effectiveness of your user interfaces.
I’m a big fan of the “don’t make me think” usability principle, possibly because it’s the only one I truly understand. But after doing a few tests, you notice that some designs remain vividly in your head, and you can visualise an entire design. Other designs you can hardly remember, and possibly never knew what they were for.
Having a community of people review your designs is an obvious benefit for submitting designs, but what do you get out of doing the tests? For one, you get to see designs that work, and in turn that should be a learning experience. The stark contrast between good and bad designs during 5 seconds really hits home. Secondly, you get a warm and fuzzy feeling from helping the community of designers out there.
Read MoreAhoy! – Silverlight Virtual Earth MapControl
What does a developer do when exploring the possibilities of the new Silverlight MapControl. Create a pirate map of course!
Yarr! So how do you get the paper look and feel on the map? It’s a simple, and doesn’t require any C#, you can do it purely via the XAML.
&lt;grid x:name=&quot;LayoutRoot&quot; background=&quot;#FF000000&quot;&gt;
&lt;img x:name=&quot;Paper&quot; source=&quot;images/ye_atlas.jpg&quot; /&gt;
&lt;m:map x:name=&quot;MainMap&quot; opacity=&quot;0.5&quot; /&gt;
&lt;/grid&gt;
Yes, that’s how easy it is. The aged paper look doesn’t zoom, I played around with having the paper scroll and zoom with the map, and it gave me a headache. One of those times when you spend an hour or so finding that your cool idea wasn’t as cool as you thought. When you zoom in, what does it look like?
But what is missing from the map? Treasure of course! YARRR! Pushpin marks the spot! So add a few custom pushpins, a bezier path later, and the map shows you the way. How do you add a pushpin? The best way is to create a layer to put all your pushpins, that way you can hide/show them all together quite easily. So your XAML becomes…
&lt;Grid x:Name=&quot;LayoutRoot&quot; Background=&quot;#FF000000&quot;&gt;
&lt;Image x:Name=&quot;Paper&quot; Source=&quot;images/ye_atlas.jpg&quot; /&gt;
&lt;m:Map x:Name=&quot;MainMap&quot; Opacity=&quot;0.5&quot; &gt;
&lt;m:Map.Children&gt;
&lt;m:MapLayer x:Name=&quot;PushpinLayer&quot;/&gt;
&lt;/m:Map.Children&gt;
&lt;/m:Map&gt;
&lt;/Grid&gt;
… and by adding the following function which takes the position, the pixel size to resize your image/pushpin icon, and the title text of the pushpin …
private void AddPushpin(double latitude, double longitude, double size, string title)
{
// Grab our map layer
MapLayer ml = MainMap.FindName(&quot;PushpinLayer&quot;) as MapLayer;
// Create the title for the pushpin
TextBlock t = new TextBlock();
t.Text = title;
t.SetValue(MapLayer.MapPositionProperty,
new Location(latitude, longitude));
t.SetValue(MapLayer.MapPositionMethodProperty,
PositionMethod.Center);
// ... and the Pushpin image
Image img = new Image();
img.Width = size;
img.Height = size;
img.Source = new BitmapImage(new Uri(&quot;images/skull.png&quot;,
UriKind.Relative));
img.SetValue(MapLayer.MapPositionProperty,
new Location(latitude, longitude));
img.SetValue(MapLayer.MapPositionMethodProperty,
PositionMethod.TopCenter);
ml.AddChild(img);
ml.AddChild(t);
}
Note the use of the PositionMethod to have the bottom of the title aligned with the top center of the image. Having this makes life so easy when plotting pushpins on a map around a particular coordinate.
Call AddPushpin in your public Page() constructor, and play around with adding pushpins. Lots of fun to play around with. Then by simply adding a bezier path method (which I’m still not happy with yet) and vary the pushpins and voila, there be treasure! YARR!
If only the sailors of yesteryear had zoomable pannable treasure maps! Features to come are some pirate ships that float around in the water… and I’d love to add a little mini-canon fight, but time is of the essence.
So why is this exciting? Well, aside from our privateering friends out there, what it does open up is a great way to communicate hiking trails, cycling tracks, walks. Feed in a heap of map data and you can overlay anything! Add a custom map data source and you can really start to expand the possibilities.
Read MoreGame Review – Street Fighter IV
Street Fighter IV arrived on my coffee table last month. I can’t stop playing it. There are too many reasons why. Being addicted to Street Fighter II when it came out, I had been waiting a long time for the game to evolve significantly. Everything post Street Fighter II until now has felt like an experiment in what to do next, and with Street Fighter IV being released, it has finally stepped up.
3D is a big aspect graphically in the game, but fighting is still 2D. Ultra moves/combos when in action allow for some camera play, as it zips around giving a truly dramatic feel. In game music is excellent, and the sound FX are top notch. I would however pay for someone to mute the announcer, and the boy band that plays during the title screen.
Where SF4 really shines is in online multiplayer. Create a lobby, wait a minute, bam, you’re online kicking but with your leet skillz. The best online feature is being able to play arcade mode, and still having a lobby available online for people to join, meaning that during quiet times online you can dive straight into the game practise pulling off your 94 move combo.
The new characters are excellent, with 25 characters available (16 available initially, and 9 unlockable characters), and each character feeling just right. The stories in arcade mode are fun to watch, and the challenge modes provide some extreme combo challenges. Titles and Icons are a great way to earn some street cred, whilst giving the game more legs.
And then when you think you’re starting to get the new game, you discover focus moves. Focus moves are the first step in the master part of ‘easy to pick up, hard to master’. But when you start learning how to use them, watch your online ranking halve overnight. Moves that were hard to deal with will become trivial, and block turtles now have more to worry about than fireballs and throws.
A game that may not appeal to those who aren’t Street Fighter fans, it’s a must buy for those that were or still are, and it will have you playing online for many months, if not years.
And yes, playing it on a big HD plasma between the two Street Fighter Rubixels is awesome.
Big thumbs up. 5/5.
Flickr
|
Recent Comments