Working with Azure

Recently I've begun putting all of my HTML5 experimentation together, and coalescing it towards a single product offering.

I needed a platform on which to implement them, and settled on Windows Azure as my backend .

I figured I'd share some of my experiences with the cloud as I go, after all, it's a new environment to many of us, and the more we can inform each other, the more we can make of it.

So, a handful of tips and stories, to recap the last week or so of my life:

Connecting to a SQL Azure database

Trying to connect to the database engine itself in Management Studio won't work.

What you can do is connect directly to a database, by clicking "New Query", filling in the database connection string, which you can grab from Azure's management portal, and then specifying the database itself in the Additional Connection Parameters tab, like in the picture yon:


Moving out of SQL, and into Table Storage
I've decided to remove SQL from my backend, for various reasons. The first thing I needed to do was rejigger my entities to derive from TableServiceEntity class.

 This was a fairly simple task, as I didn't have very deep object graphs to work with, but since table storage works as a list of key/value pairs, no relations between objects are stored, and you must restructure data so each thing can stand by itself.

A quick solution I came up with for storing complex object graphs was to derive a simple base class from TableServiceEntity, which exposes domain specific key, holds a property storagetext, and a reference to an object which implements an interface, IThingTranslator, where T is the type of the root object. I called this class Thing.


All my entites now derive from Thing, and an appropriate concrete instance of ITranslateTableEntry is injected by the DI framework. Every table operation works on instances or lists of Thing, and the function of the translator is to serialize the object into storagetext on a write, or deserialize and reconstitute it on a read.

    public interface IThingTranslator where T : Thing

    {

        T Translate(string s);

        string Translate(T thing);

    }

This is a pretty flexible approach, as it lets me swap out my serialization routines to use the most appropriate one. I use JSON if I want to work with an object on the client, or something more optimized if I wanted it only in server side or lower level code, and changing between them is merely a configuration tweak.

My ongoing shenanigans can be followed at http://playground.cloudapp.net, and I'll of wild adventures about developing for WebKit and Android, using Microsoft IDEs and server-side tools.  Stay tuned!

My nonsensical WebGL javascript NES Emulator

I present to you my wholly javascript NES emulator. It spins in a cube and a monkey throws barrels slowly, that's about it.

Though it started as more of a science experiment than anything else, I wanted to see just what can be done with pure JavaScript in this brave new world of 'browser apps can do it all'.

I actually ported the code a long while ago, optimized it a little, but there's still much more I could do.

I had abandoned it until typed arrays hit the street, as I figured the performance boost over regular javascript arrays for holding everything from the memory maps to the output buffers might give me a running chance again. It did, but just barely.

The next step is to run the emulator in a web worker, sending back partial frame update information to the calling thread. That may help, besides that there's still more code to flatten, and plenty of tweaks to be found.

I wanted to play with the file api, so I'll maybe write a function to load ROMs. I only have the most basic of mapper support at this point, so there aren't many that would load, but it's about the experience.

It would be nice to have it run fast enough to add sound. It might be fun to port my apu code over one night and have it just play back register dumps.

In the meanwhile I think I'm going to move on to kicking WebGls tires some more. Multiple textures were annoying me (broken?), and I want to set up a reusable post-processing chain I can play with. Then move on to loading models, skinning and animating some meshes, terrain generation. Make it so you can lock a smart bomb on the guy and blow him up with all your twitter friends.

Of course, if you just want to play some nintendo in your browser, my Silverlight version still works. It's still missing working IRQs, sadly, and who knows if and when I'll come back to it.

DynamicSoundEffectInstance is THE SHIZNITE

So, what I discovered today, is that XNA 4.0 has added support for the Microphone.  While perusing the docs, I noticed that the Microphone class has a GetData() method which returns an array of bytes.

Hmm, I thought.  You can certainly shove your Microphone up your ass, however, if XACT now has a way to GET bytes, it surely must have a way to GIVE bytes directly to the underlying audio system.  This, obviously, is exactly what one needs to be able to do to create audio proceduraly.  Henceforth, XACT was all about cueing up and playing wav files. 

A response from a MVP on a msdn forum post about procedural audio snarkily said it was a feature only useful for emulators.  Apparantly it's also useful when you have a Mic present, or are otherwise sourcing audio in real time.

The end-all is that my humble NES emulator now runs on Windows Phone 7, and (still to be tested now that I have cause to shell out for a CC license) Xbox 360.

The 360 makes me think...  Obviously a NES emulator would not be allowable.  But, as a content delivery platform, it might actually find a niche.  There's a ton of decent NES homebrew out there, and I wonder if I could bring any of it to the XBox marketplace.   Time to chat up some homebrew'ers, perhaps.  

Regardless, I have forked the project, and am now working outside of the open sourced code I stuck on googlecode.  I will still update the googlecode, but focus on the Silverlight (software rendering) side, rather than the D3D10 Silliness I was engaged in (though I'll come back to that, because there's plenty of GPU fun to be had there).

In other news, I refactored the emu itself somewhat, in a large code/namespace cleanup -- but also took care of some performance snags along the way.  Instancing it *outside* of Unity (ie; new-ing it all up) exposed how silly I'd let the object graph become.  The namespaces were always silly.  Not a hard thing to clean up, but something I've put off, for no good reason.

I knocked out a "touchpad" for the Windows Phone port.  It's hard to play mario when you have to click one gamepad button at a time with the mouse.  I need me some real hardware to play with.

Summer of code (not so much)

Hard to get focused on writing code with the nice weather, and being uber-busy.   Started with this, though, since the Windows Phone CTP is out.  So far, it seems to work full speed, though getting sound out will be a fuss.   This is XNA for Windows Phone 7, haven't played with the silverlight for the phone yet.  Exposing the emulations video and audio as a muxed stream might just be the ticket, and something I've thought about before.  (ie; the NES actually outputs an .avi which is then plugged into 'media player' of choice)

Drawing is only a bit of a chafe, I have to keep at least two textures, and swap them out (one texture is drawn, while the other is filled via SetData<>()).  You can't be manipulating the same piece of memory with both CPU and GPU at the same time, this is logical.  It's nice that XNA now hands my textures "back" after rendering, so I can call SetData again, before I was having to Dispose() of the old and create a new one each time to get them to update dynamically, which is hardly how to do it.

Controls..  The TouchPanel interface is easy to work with, just need to draw myself a control pad on screen, and map touches to it.

Audio...  Eh.. Not sure how well it will work, I'll try creating WAVs in memory, and see if I can schedule them in a tricky enough way to make it sound decent.

I should be able to get something people can use on their Phones in the fall, and maybe it'll be this Christmas' shopping seasons must have killer app?

What now?

I just got back from the BaltoMSDN meeting, Geoff Snowman put on a good presentation about the ins and outs of crypto, and the only thing I can think to add to it is that when you're dealing with symmetric key encryption, the message needs to be secret as well as the key. If you can derive the message from the encrypted message, using the key, you can derive the key from the encrypted message using the original message.

A lot of hard-drive based crypting programs were compromised when people realized if the drive was formatted in FAT, they could look for the allocation table in the usual spot, get the encrypted version, then derive the key from the (known, static) unencrypted version. So, encrypting the data isn't enough, the contents must be scrambled too. Which goes to the point I tried to make about security holes never being found in the cryptology - the math is solid - they're always in the implemenation.

You can hash your users passwords in the database all you want, but if every client app logs into the database with the same user/pass combo, then that's the vector an attacker is going to use, and all your high talk about salting your hash is really just masturbation.

But, as far as important news.. I got around to updating the mono port of my emulator, which took about 5 minutes, really, since Unity does all the hard work, it's just a matter of registering the appropriate platform specific classes. What was weird, was that the 'callback' member was missing from the SDL bindings in the Tao framework.. What's even weirder, is that the framework hasn't been updated since 2005, so where the hell did it go and how could it have got gone? It could be something to do with running in a VM, but I never really knew type members could just 'disappear' like that. Very odd.. No sound for linux (well, flakey OpenAL based sound).

I also started work on an assembler. Once I've populated my 'instruction' structure I already use in my debugger, emitting the bytes is all but automatic. All I needed is a parser, and it's pretty easy work, regex does most of the heavy lifting as far as identifying addressing modes, which is really the only 'problem' to solve.

The only work left is to add a pass to replace labels with actual addresses, and a little more focus on making sure the syntax is in line with other popular 6502 assemblers.

My goal is to host this as a server side component, and to leverage some of the 'online IDE' ajax type stuff out there to put together an easy to use online environment for the homebrew community.

But it'll probably be on hold for awhile as I plan to be busy at work, but I may get it online this weekend.

Silverlight Updates

I've spent a bunch of work bringing the Silverlight version up to speed, and have managed to clean up some code along the way..

New in Silverbulb:
Debugger support (currently just have the Machine Status view implemented)
Pattern and Name tables viewer
FPS Limiter for slow machines (sets Silverlight's max FPS only)
SRAM read/write to IsolatedStorage (automatic on poweron/poweroff)

SRAM read/write relies on the iNes header having the SRAM bit set properly. I haven't done anything to handle requesting more storage, and also should provide a way to purge out old saves, and a way to load/save them to a local file. Some sort of "cart data" management dialog is in order, though this should completely abstract the filesystem from the user.

Silverlight MediaStreamSource AudioBufferLength

Having end-users who've toyed with my emulator randomly complaining about sound pops or skips, I decided to sick a slider which would allow them ot set the AudioBufferLength of the MediaStreamSource which generates the sound..   However, it doesn't seem to affect the stream in real time.  Hmm, I don't want to have to tear down and recreate the audio in real time, if avoidable.  I wonder if there's a solution out there?  Anybody?