download page 5 - Dave's Blog

Wiimote wiissues

2007 Jun 7, 5:29The other day I had the best idea for my Wii remote. Clearly I should use it to control the rotation of Tetris pieces in my N-dimensional Tetris game Polytope Tetris. One of the issues I described with Polytope Tetris is user input. Given a Wii remote the user could rotate a piece through 3 dimensions in a manner that's much easier to adjust to than particular keys on the keyboard.

Anyway, I did a little research into how this might work. I knew that the Wii remote used infrared for absolute positioning and Bluetooth for everything else (LEDs, speaker, accels.) I bought a Bluetooth adapter for my PC after realizing that none of my computers had one already. I used GlovePIE to ensure that my Wii remote could connect and successfully communicate with my computer. GlovePIE is actually pretty cool -- it provides a simple script layer over the Wii remote to control things like your mouse.

Since Polytope Tetris is in Java I looked for and found a Java library for operating with the Wii remote and a long forum thread discussing its use. I then read up on Bluetooth in Java. Apparently JSR 82 is the name of the standard that describes the API a Bluetooth stack should expose in Java. That is, to get Bluetooth working in Java one needs an additional package for Java that actually implements the Bluetooth Java API. This package would depend on the system so I suppose I can't fault Sun for not including it... Where to find such a package? I found a comparison list of implementations and tried the ones that support javax.bluetooth. None of them worked for me because none can address USB devices it seems or they cost money and I couldn't get the trial version working. I also tried bluesock (not listed on the previous list) which seemed promising and could produce an address for my Wii remote as a connected device but couldn't use that address.

And I thought that after I found the Wii remote Java library it would be easy... Oh well...java bluetooth wii technical remote jsr82 tetris polytopetetris wiimote

New XSLT - IE7 XML Source View Upgrade Part 2

2007 May 11, 8:55Last time, I had written some resource tools to allow me to view and modify Windows module resources in my ultimate and noble quest to implement the XML content-type fragment in IE7. Using the resource tools I found that MSXML3.DLL isn't signed and that I can replace the XSLT embedded resource with my own, which is great news and means I could continue in my endevour. In the following I discuss how I came up with this replacement for IE7's XML source view.

At first I thought I could just modify the existing XSLT but it turns out that it isn't exactly an XSLT, rather its an IE5 XSL. I tried using the XSL to XSLT converter linked to on MSDN, however the resulting document still requires manual modification. But I didn't want to muck about in their weird language and I figured I could write my own XSLT faster than I could figure out how theirs worked.

I began work on the new XSLT and found it relatively easy to produce. First I got indenting working with all the XML nodes represented appropriately and different CSS classes attached to them to make it easy to do syntax highlighting. Next I added in some javascript to allow for closing and opening of elements. At this point my XSLT had the same features as the original XSL.

Next was the XML mimetype fragment which uses XPointer, a framework around various different schemes for naming parts of an XML document. I focused on the XPointer scheme which is an extended version of XPath. So I named my first task as getting XPaths working. Thankfully javascript running in the HTML document produced by running my XSLT on an XML document has access to the original XML document object via the document.XMLDocument property. From this this I can execute XPaths, however there's no builtin way to map from the XML nodes selected by the XPath to the HTML elements that I produced to represent them. So I created a recursive javascript function and XSLT named-template that both produce the same unique strings based on an XML node's position in the document. For instance 'a3-e2-e' is the name produced for the 3rd attribute of the second element of the root element of the XML document. When producing the HTML for an XML node, I add an 'id' attribute to the HTML with the unique string of the XML node. Then in javascript when I execute an XPath I can discover the unique string of each node in the selected set and map each of them to their corresponding positions in the HTML.

With the hard part out of the way I changed the onload to get the fragment of the URI of the current document, interpret it as an XPath and highlight and navigate to the selected nodes. I also added an interactive floating bar from which you can enter your own XPaths and do the same. On a related note, I found that when accessing XML files via the file URI scheme the fragment is stripped off and not available to the javascript.

The next steps are of course to actually implement XPointer framework parsing as well as the limited number of schemes that the XPointer framework specifies.xml xpointer msxml res xpath xslt resource ie7 technical browser ie xsl