Thank you curl, Thurl.

Today was a bit of engine work. (Not a bank holiday as some other people here in the UK seem think, too wet!)
For Embiggen we will need to fetch some data from the web. Namely, from a database which stores all our matches (and user profiles). A simple PHP script can convert the required match database row into some XML and pump it out - specifically into our asset XML format - and we can download it, convert it to binary asset data and load it in-game. Shimples!
Anyway, the UIKit in the iPhone SDK provides us with some functionality to do this for us (NSURLConnection) so we need a solution in windows to replicate this for easier testing. (and maybe for us on the Wii or Mac or whatever else we might port to)

I looked through a few open source projects, libs etc before settling on LibCurl which seems to do everything we require in a nice simple, supported, threadsafe, documented, active open source package. After some initial linking trouble with unresolved externals all starting with __imp__ I had a look through the example .vcproj for some pre-processor defines which sure enough I missed out on. Got it all going, setup a simple asynchronous base connection class (TLNetwork::TConnection), setup a new TestApp example which shows one texture asset on the left and another on the right. I uploaded a compiled .asset file to the web (Which is freely availible to download if you're curious, although it's binary data rather than XML representation, I'll show an example of that when it's ready)
Everything seemed to be setup nicely but when the internal thread was cleaned up I kept getting some corruption in the heap. I started looking into CRT issues and conflicts and found a full rebuild of an all debug build of the app didn't corrupt the heap. I setup all our projects to use Debug MT CRT but was still getting an occasional crash. I overloaded all the LibCurl memory allocation functions to use our own memory allocation functions which I can track much more easily. The remaining crash seemed more consistent (Instead of random crashes), looking further into it an asset kept being overwritten and corrupted... I stepped through the code and it turned out I was corrupting one of my assets myself, turning a c-pointer into a smart pointer and then releasing it, Oops.
Now I'm a little unsure if the change in the memory allocations, or the CRT changes were neccessary. Nevermind, it works!

The image is the file download test app. The image on the left is local, the image on the right is downloaded, converted and then set. Not the most exciting screenshot :)

I've put together an IPod/IPhone version, but untested. Now that this is stable I can see if it works on the iPhone and get back to game stuff :)

Embiggen day three

I'm half way through day three now and I can concentrate a bit further as I have all day to myself (bar cat-feeding).

I've added a rack to place tiles on now. The tiles on the rack come from the board's pool of letters (currently just 3 of every character). Tiles can be moved to the board and back and rearranged in the rack itself, all very nice and stable, and again, data driven. The rack places are datums inside my main GUI SVG. As are my buttons, these are extremley simple code wise, I have a datum specifying where the click should be detected and in the code I create a TWidgetButton assigned to that datum which just sends an command back to the game when it's clicked, thanks to the fantastic engine I don't need to worry about interface stuff much at all :)

The text on the buttons required a tiny bit more work, the GUI's scheme specifies text nodes which use smaller datums on the button to dictate the position of the "play"/"back"/"undo" text. Again, out of code and just means when we come to translate there are no texture or code changes.

My next task is a jump out of the Embiggen code for a while as I setup the all important (and important for Rocket) code to fetch and send files across http.

On first inspection libCurl seems like an adequate, stable, popular and open source library for me to use on win32 (and later the wii...) which mimicks apple's NSConnection classes which I'll be using on the iPod. Should be quite simple to write some platform indepedent interfaces to get/put files across HTTP which means I can send the current Match state asset as XML up to the server for PHP to process and stick in a database and reverse of that to download the current Match XML and turn back into an asset :)

All going well and nice and quick development so far! :)

Embiggen day 2

Day two was about an hour of work while I had lunch on saturday :)


Just finished the tile-drag code which dropped the tiles onto the board and worked out a local position which translates to an integer grid x/y position. If the new grid xy is empty, the dragged tile is delete and the grid entry is reset and render node is recreated. Once a tile is dragged (from wherever) it becomes detatched and a bit disposable so we are relying on the widget code to get a Mouse-Up style message to drop the node somewhere.

Also changed the colour scheme a little. These are hard-coded colours at the moment and the tile is a simple transparent + white PNG. All ready for themes!

A game in a week? ish?

I've been playing far too much Words With Friends lately (add me - SoylentGraham - if you want a challenge) and have come across various limitations and changes, additional rule options etc that I and others want, as well as additional games to play. Minesweeper, boggle, erm, more will come to me I'm sure.

After the first few hours, I have a dynamically sized grid, tile render nodes which I can drag around and the board and tile data is serialisable into a TBinaryTree, all ready for saving to an asset or upload/download. The Tiles themselves are an SVG, which is texture mapped to a tile PNG which is a simple white tile with transparent rounded edges. The tiles with letters are coloured green and 2 text render nodes are rendered on top; one for the letter, one for the number. A little OTT but it does mean I can use any font, align & scale the letter and point number by datums in the SVG too. All the visual stuff is nice and out of the code :) This will also make animating the letters, tiles, colours etc all much easier too.

Next step will be to make the dragging of the nodes a bit more functional and actually change the board's data.

Followup: Broken inherited rotations

Problem fixed, nothing terrible in the engine design thankfully, nor was there any errors in the math, the quaternion code was just overwriting itself as it calculated the new components.

I quickly expanded the thumbstick demo in our test app to add a child arrow and a second thumbstick, THEN I actually looked into the quaternion code (rather than just the Transform code as I did before) and noticed the mistake. Hindsight is great, getting half my Sunday back would be better :P

The next part of the game to finish off is the trigger linking in the editor and then maybe implement some proper particle system effects as a reward to myself :)

Broken inherited rotations

Progress on RocketMan is going swimmingly, a much more organised editor is in place; The engine-side scheme/graph editor has been split into modes (it's a state machine) and the overloaded game editor now instigates a menu for handling the different modes.

Once that and the in-game menu had been all converted to asset-based systems I wanted to cut out a part of redundant code on the player. Previously we only had 1 shape per physics node so the collision sensor on the hoover nozzle -which determined when to suck up a node- was a seperate physics object. Now this can be placed directly on the player and remove the superfolous physics node on the player.
Setup was simple, although requires an extra transform [let's assume... everyframe] now to convert the datum representing the nozzle on the hoover render node [this is a child as it requires a different rotation] up the tree to be in the same space as the main player, this was easy enough... but it appears there is a problem with the world transform on our child node, argh!
I've confirmed this by rendering ALL nodes with their calculated world transform instead of local offsets and it definately rotates incorrectly in this case...
Root -> Rotated Object -> Rotated Child
The child's rotation seems to be magnified by the rotation on the parent object, when the parent is at 0-degree's everything is fine. The more it is rotated the more we quickly end up with "quaternion wrap" (I made this term up) where the radians wrap past 2PI and we just get wrong angles.

I would just revert the code back to the old state, but I think the issue is in the engine's transform system and just not noticed before.

 

In the image, the magenta circle (Physics node's shape) is the nozzle datum which I have manually calculated (to put it in the correct local space). The hoover itself, and the datums (white outline spheres) are rotated incorrectly and the one at the furthest extent should be in the same place as the magenta 

Setting up a test case in the test app :(

Introduction

I enjoy coding, I do it a lot. Although I document my work internally (comments) I don't actually document what I am producing, techniques I use, issues I come across etc, so I rarely review anything outside of an IDE, offline if you will.

A lot of what I do could be useful to others, amaetuer and expert alike so in the interest of creating discussion, documenting my days and ego worship I am going to write here on blogger. Although I might not publish much literal code all the theory shouild be explained and source code is only really useful for copy+paste situations anyway and none of this should be language restrictive.

Really I should have done this 14 months ago when I quit full time work, but never mind :)