Updating a Web Site, important?

I do wonder quite often, just how important is it to update my main web site. Of course I offset not updating that web site by actually using this Blogging site a Lot more often.

Still, all the advice you see about getting noticed tends to revolve around keeping people informed, keeping them appraised of what exciting things are going on in your development life.

I'll be honest, I don't think it really makes much difference if your audience is not already there, OR if you are not going out and finding an audience. Like me and 99% of Indie games developers, we don't get much time to go and grow our audience. Most of those Indies that have grown their audience seem to me to be a number of people bandied together to create their games. I do not have the luxury of multiple people working on my team, or not lately anyway. Still I do wonder if I should spend more time getting people interested in what I do instead of actually doing it, sic.

Back to the point of this post...

So how often should I be updating my main web site. I last updated it about a month ago when I finally got my iOS Book Apps out. Maybe I should now litter it with my current development of HoopFighter, as it does star Shaq and that may make more visits for my site. Still, I am not sure it has any real value at present. Maybe when I have a real in game shot to show off or something.

Probably still worth a mention however,

I do wonder how important other small Indie devs think updating their web site is, maybe they have had more success at attracting an audience?

Laters,
Da Voodoochief

Super Duper Sprite Atlas

This is my current Sprite Atlas,

As you can see it is getting a lot more full, and a lot more complicated. Those frames of Kal are 256x256 original sized sprites, yet when trimmed they pack into this texture really well. In fact I would only be able to get 8 x 8 = 64 frames of Kal onto a 2048x2048 texture like this one if not trimmed. Yet trimmed I have 45 and a bunch of other stuff, and STILL nearly half the texture free for more frames.

I have also altered my sprite effects routines and they now work with the atlas as well. In fact the changes have made the effects drawing more efficient and less complicated. Which I am very happy about.

If you see the Hoops Fighter Logo in Red, that is because I am now developing on my laptop.. yes, even posting this via the laptop. So the license is not setup on this machine. Soon, but fortunately Andreas at www.codeandweb.com is very generous and allows anyone to play with the texture packer for as long as I want in this mode (random red sprites).

Loving the texture more and more,

Laters, Gotta get back to implementing some bad guys.

Da Voodoochief

Trimmed animating sprite offsets

With all the headway I have made with the exporter for the Texture Packer (http://www.codeandweb.com/). I am now setup that ALL my sprites come in from the texture atlas. This has caused some issues of course, related to animating sprites and trimming them.

I have the main hero sprites running in a 15 frame cycle. All his frames are rendered inside the middle of an area of the sprite, as you see below.

Then we have another part of the animation where Kal takes up a whole different area of the sprite, as you can see below.

When these are trimmed only the actual rectangular area containing colored pixels is placed into the new Texture Atlas image. Which means that the size of the sprites for rendering has of course changes.

However we also need to know where the new center offset is relative to the original frame. I need this as the artist has painstakingly placed each animation frame relative to its previous one. So in a flipbook style the animation looks like it should. However IF you render these trimmed sprites from center with no offset, you get a Very awkward looking run cycle. In fact what happens is poor Kal Bobs up and down and backwards and forwards, like he is stuck on a Yo-yo string.

To fix this I could have a table of X and Y offsets I can apply to the rendering position. However I hate that solution. I want the export to have all the information I require to render the sprites correctly. Now as it happens the Texture Packer can export the offsets for me. Yahoo I thought, only to find later there is an actual bug that means it is currently not outputting.

After a quick Tweet or two with Andreas (the coder of Texture Packer) he came to the same conclusion I did, that I should be able to calculate it from some other data that the exporter can export. So off I went to make it happen. In the end it was very easy.

 Here is where I calculate the top corner offset (my renderer uses the top left corner as its origin, so I compensate by using my xpos and simply minusing half the width...) 
int16 xOrigin = sprite_atlas[_sa_index]->offset[0];int centerOffsetX = (int)(((float)(sprite_atlas[_sa_index]->originalSize[0]/2) - xOrigin) * _scale);

Using this I can render my sprite, scaled or not at the correct location. Looks good too and smooth.

Next up is to sort out the offset for the X flipped sprites.. bah! Always more to do.

G'night
Da Voodoochief

Texture Packer pt 2

I got some very quick help when I posted about the Texture Packer and the changes I was making to its exporter etc. I received info from Andreas himself (the auther)..

All this addressed a couple of issues I was having.

1. EdDiGeronimo from Twitter told me about the 'Trimmed Filenames' so I could use those and it has the '.png' removed. Less manual labour is great!
2. EdDiGeronimo also told me about the rotation not being a variable rotation, it is in fact true or false and gets rotated by 90 degress. Depending on your exporter settings this could be CW, or CCW.
3. I did get a notice from Andreas (@codeandweb) saying my request for multiple sprite sheet exports is in the works and will most likely be in version 3.1. SWEET! I only have a simgle sprite sheet at the moment, So no real issue, but this should chnage in a month or so.

(side note: EdDiGeronimo told me he has been using the Texture Packer for a while, and cleverly used a Python script on the output to create binary data files to use at load time. A very nice solution, but I really want the output of the exporter to be used as is, no more steps.)

I have made great progress with the exporting template now. It produces a nice '.cpp' file and I have it placed into the game code. I had a few teething syntax errors but nothing earth shattering at all. So a few quick edits and it is done. Only...

Well I really like to reference assets by UID or Defined name (usually setup from an enum or some such). So I created a section in the exporter to create a nice enum that matches the order of the atlas information. This has worked wonderfully, only now I really need to export just that section as a header file, so all my code can use it and simply call my renderSprite function with the enumerated value they want to render.
For now I will simply cut and copy this section into a hand made header file.

I have not managed to spend any time on this since Monday, otherwise I am confident it would be done. Instead I am rebuilding my kitchen and also my new Laptop has arrived, which I am busy setting up for development purposes... So I am making no progress, gah!

I'll update when I get back to coding Hoopfighter again (hopefully on the new machine and tomorrow!)

G'night
Da Voodoochief

Texture Packer for C++

http://www.codeandweb.com/texturepacker is the place to go for an excellent texture packer. It will pack a bunch of sprites together andexport a new Texture Image alongside a nice texture Atlas.

I want to use this kind of functionality for several reasons listed here:

1. Less textures to have to load
2. Faster load times due to less texture to have to load
3. Less memory usage. Packed textures will take up less memory
4. Simplify sprite lists in memory (exporting is so much easier to manage)

Andreas has created a wonderful tool that runs on several systems. In my case I am using the PC version. The tool offers many options and my favourite has to be the Trim option. This will pack all your sprites as close as possible to each other, whether they be wide or tall or simply small. This creates a wonderful saving of memory and allows me to get more sprites into a single sprite sheet. As you will see in the next couple of example images of the texture packer itself, along with some of my Kal sprites from Hoopfighter for iPad.

In this image above you can see a number of the options available to this tool. In this case You also see Kals side on running animations all nicely laid out on this sprite sheet. Taking up a considerable amount of it as well.

Now this second image above us show what happens when I click the Trim button. It basically removes white space from the sprites, but will not overlap x or y of images. As you can clearly see, this has saved a lot of space on the sprite sheet. Leaving me with space for more haha!

As it happens this lovely tool come packed with several export options. Xml to specialized versions for various SDKs. It does Not however yet cover Marmalade, my SDK of choice. The other thing it doesn't do as yet is export the sprite atlas data to C++. Now  I would lvoe it to do marmalade natively, yet to be honest C++ is widely used and is not problem for me with Marmalade.

So what am I going to do about this? Use the Xml, well NO, I won't be doing that. Parsing something at run time is not my way when I know already what the assets are.  Something Rigid like assets for this game are not something I would want to parse every time it is run. So instead I really need something I could simply include into my code. the answer of course is to have a '.cpp' file created with all the appropriate data and structs or class built in.

To do that Andreas has created a Template style exporting system. Now I do not have any real instructions (I perused but never found them), but I am always game for playing with stuff. So I tracked down one of the otehr exporters I felt created soemthing close to what I would want to use. In the case I decided upon the BatteryTech_SDK exporter. and it exports a texture atlas that looks like this...
btx = 1.0
texture.assetname = test_bt.png
texture.width  = 2048
texture.height = 2048
image.assetname = Kal_Run_side_0000.png
image.uvs = 0.4072265625 0.6875 0.5390625 0.6875 0.5390625 0.90625 0.4072265625 0.90625
image.rotated = false
image.trimmed = true
image.origsize = 512 512
image.offset = 120 61
image.trimmedsize = 270 448
image.assetname = Kal_Run_side_0002.png
image.uvs = 0.16015625 0.6982421875 0.3095703125 0.6982421875 0.3095703125 0.921875 0.16015625 0.921875
image.rotated = false
image.trimmed = true
image.origsize = 512 512
image.offset = 91 50
image.trimmedsize = 306 458
Not exactly sterling C plus plus eh? Well if ya look again at the second image above, you will see that I am exporting the data using my new and shiny 'C Plus Plus' exporter. and what I get looks like this...
char tp_version[] = "cpp = 1.0";
char textureName[] = "test_batterytech.png";
int  textureWidth  = 2048;
int  textureHeight = 2048;
struct  sSPRITE_INFO
{
 char name[32];
 int size[2];
 float rotation;
 float texturePoints[4];
};
static const sSPRITE_INFO *test_batterytech.png[] =
{
  Kal_Run_side_0000.png,
  Kal_Run_side_0002.png,
  Kal_Run_side_0004.png,
  Kal_Run_side_0006.png,
  Kal_Run_side_0008.png,
  Kal_Run_side_0010.png,
  Kal_Run_side_0012.png,
  Kal_Run_side_0014.png,
  Kal_Run_side_0016.png,
  Kal_Run_side_0018.png,
  Kal_Run_side_0020.png,
  Kal_Run_side_0022.png,
};

sSPRITE_INFO  Kal_Run_side_0000.png = {
  "Kal_Run_side_0000.png", // name
 { 0.4072265625, 0.6875, 0.5390625, 0.90625 }, // TexturePoints
 false, // rotation
 { 270, 448 }, // size
};
sSPRITE_INFO  Kal_Run_side_0002.png = {
  "Kal_Run_side_0002.png", // name
 { 0.16015625, 0.6982421875, 0.3095703125, 0.921875 }, // TexturePoints
 false, // rotation
 { 306, 458 }, // size
};
Not yet correct, but getting along very nicely. As I see it I have a couple of real issues left.

1. get rid of those .png suffixes all over the place. I will try this tomorrow anyway with those manually removed.
2. Rotation is true or false, and yet I really need a rotation value, Degrees/Radians or whatever.
3. As this will be going into the Sprite drawing helper routine I use for rendering sprites. I do not have to have a '.hpp' file, I can simply include this one directly. Not the best coding practice, but pretty darned efficient.

So I am very excited to do this. Andreas is very responsible and responsive and I am sure these last items on my list will be resolved very soon.

With that, I am going to bed,
Gnight all,
Da Voodoochief

ahh Kal not in 3D

I have been working on a new title for the iPad called Hoopfighter. A Soon to be released game based upon the franchise of a Movie, Web comic and more (yes, more to come!) You can check it out at the address below, or the Facebook page also listed below.

http://hoopfighter.com/

https://www.facebook.com/Hoopfighter

The plan was to have a nice 3D rendered version of Kal, the main character in our story and also the main character in the iPad game (the dude you play as). However we ran into some complications as so often happens when starting working with a new team on something 3D. There is always some hurdle or other slowing progress and more. Below in this first image you can see that Kal as rendered in this viewer has a few problems. Notably he head and right arm are missing, also his left hand appears to have some very strange fingers.

 

 



I looked over the skeleton and also the geometry. It was not easy to spot anything really wrong. One of the problems is that this model has 65 bones, and sorting through 65 bones takes quite some time. It is simply too big and we needed to make a much smaller/simpler example with this kind of error. then we would be able to move forwards once that is fixed. However the original model was modelled in Max using something called Cat. This means that its rig did not use actual bones, but instead used objects. Alas the exporter from Marmalade exports Bones and although it would export these objects, it would not see any bones to export, so it simply won't export them. This means we would have to completely re-rig the Kal and other models... Something my friend Scott did for this test of Kal. Simply put.. it would be too expensive and time consuming.

Still I was playing with the model and determined to figure out what had happened to his head. As you can see in the next image, I found it!

But I have to say this is not quite as it seems. To make the head show up, I attached the head to the left ankle bone, and hey presto there it was.. in its rightful place oddly enough. I feel that maybe the transform stack was not cleared before exporting from Max, though I am no Max expert, it is a problem we have faced in the past with our own exporters.

Now though.. this is on the shelf as a 3D game and instead we will be going to pre-rendered imagery. Which will be a lot bigger and a lot more cumbersome for me as the programmer (blended animations anyone?).

It will look awesome pre-rendered though I am very excited about that.

g'night
Da Voodoochief

I have my Win 8 Phone

I received my new phone on Monday, just 9 days after I lost my last phone in the desert. My last phone was a classic clam shell phone and certainly not smart enough not to get lost (ok, maybe it was my fault).

Still I now have upgraded to a real smart phone, the T-Mobile Nokia 810 windows 8 phone. First impressions are that the OS is very VERY like the windows 7 phone my wife has had now for a number of years, and I will add is very happy with. So happy in fact she didn;t want to upgrade to Win8 phone haha.

I have been busy trying to setup the phone and get accustomed to its way of behaving etc. Now the thing is I am getting along well with the phone. Heck, once I found it ran Win 7 apps and games I went to the store and bought, or downloaded (some are free) my games I did through XNA for the win 7 phone. Yes they work great!! However I am very excited to update these games. It will mean reprogramming them from C# to C++, but I do not think that will be to bad. It wasn't when I did just that with Hot Chicks the Card game. I will of course be able to simply rebuild that distribute to a win 8 machine. Or I will when...

Marmalade get their new version to support Windows 8 Phones natively. They say they will release this version in December sometime, yet I find myself tense as I await this new version of their SDK. ( www.madewithmarmalade.com ).

I will say one thing that strangely saddened me at first was....
I did not expect win7 phone games to play on the win8 phones. I thought this would mean if I could get my games out quickly I would be a fish in a small pond. Now I realise I am the same sized fish I always was within the windows phone pond.. and oddly enough it is disappointing. Probably because I would not call my 3 win7 phone titles a success (or even close).

Laters all,
Da Voodoochief

Buying Dev Machines

How does a home Indie Games dev justify spending the bucks on hardware?

Generally today we can work cross platform (I certainly do using www.madewithmarmalade.com). This means we need as many pieces of hardware to test on that we would like to publish on. that is where the dificulty is, or it is difficult if you are not wealthy.

For example....

• iOS (4.2 and above)
• Android (2.1 and above)
• BlackBerry PlayBook OS
• bada (2.0)
• Windows desktop (7, XP3)... full-screen and windowed applications
• Mac OS X desktop... full-screen and windowed applications
• LG Smart TV (for Professional licensees and LG registered developers)

That is a list of supported platforms for Marmalade. If I wanted to test my game on enough of these machines to feel comfortable (differing screen aspect ratios and sizes matter). I would have to own a fair number of tablets/phones etc.

The cost of having a selection of the above must be well over 3000 dollars. OUCH'

Currently I own... (that I work on)

• Kindle Fire
• iPad2
• iPod3
• iPod4
• PC
• Android phone (ice cream sandwich) (gingerbread phone just broke!!)
• Windows 7 Phone
• Xbox 360

So the thought of buying a Blackberry playbook at the moment is frightening. But also Windows Phone 8 has gone Native development, which means Marmalade is going to be supporting that platform as well. ARGHH!!! Now I need a windows 8 phone (side note: I already have several games out on Win7 Phone via XNA).

Luckily for me my new phone that I hope will arrive today will be said hardware. So expect a new version of Hot Chicks the Card game and also my Book apps to appear fairly quickly. (ok, so not lucky at all, I opted for this phone simply because it is easier to justify the cost as a dev machine).

Jst maybe,being a Big fish in a small pond might pay off for a while.

Laters y'all,
Da Voodoochief

Plumbing vs Coding

I like Plumbing... I also dislike plumbing.

One thing about plumbing is you have some time to think about stuff, like why it is I like it, yet dislike it as well. What I discovered was a bit of a revelation, but also a lesson I try to adhere to when coding. It all breaks down to one word 'Granularity'

I like using my hands to fix stuff and build stuff, it is such a great break from using only my mind to solve problems (like my day job). So why would I not like plumbing? I learned to do soldering and also what compression joints were used for many years ago while helping my Dad rebuild our house. Since then I have fixed up my own houses and usually do a good job.

This particular job had 7 soldered joints in it, the first one being a T that I cut into an existing cold water pipe to fit, then I would be able to create a spur to a new tap for the refrigerator. Now 7 joints is not a lot in the grand scheme of things, only any joint that leaks will be depressing. If a joint leaks you have to clean out the water from the pipe and dry it, then sand, flux and re-solder it. Once again turn on the water to see if the leak is fixed. As you can tell there is no real granularity as you have to complete the whole pipe with all it's joints to know that it is watertight.

Now lets look at me coding.

When I write a system, say a manager class and its objects class. I will write the manager class and make sure it compiles and links. Once that is done I will run its update and draw and setup functions. Once this works at runtime I will move on to its child class of objects and do the same thing. In all about 6 steps or close to it. Yet I was able to test each one, without breaking anything, or getting anything else wet, like a water leak would.

That is why I prefer coding to plumbing.

GRANULARITY Rocks... use it, it is a tool!

Laters
Da Voodoochief