Category Archives: General

News and Events

Testing the HyperX CloudX Gaming Headset

So, what’s the deal with the HyperX CloudX Gaming Headset? Let me put it this way: I was giving it a try with a few of my games when my kid scared the heck out of me by startling me from behind, poking my ribs. My kid laughed so hard when she looked at my face! According to her account of the events, she had come back from the mall, she had been ringing the bell and knocking on the door, the dog had been barking all this time and, after she finally found out her house keys and open the door, she had been calling me all the way to my home-office. I was so into the game I was playing that I never noticed any of the events she described – until the rib poking, that is. That’s how good this headset is.

The reason why I wanted to write about this headset is because, as a musician “wanna-be”, sound is very important to me. You see, “Indies” wear many “hats” and I’m one of the very few that create the music and sound effects for their own games. That is why I looked forward to test this headset: It’s not just that I know how it is supposed to sound, but I also have access to the tools to create those sounds.

A few months ago, I tried to apply for a job for a particular game development company and I thought I would rock the interview if I could bring my little tablet and show the games I’ve published. Following that strategy, I revisited my slalom game back then and one of the optimizations I did was to recompile the background music following the steps of this other article. As part of the accomplishments, I was quite happy to have reduced the audio file size to less than half (less bytes per second to process means faster overall performance). However, I did not notice any change in quality at the time. The rule of the house is that headsets are mandatory during code debugging, which is understandable considering that such tasks happen well after midnight and during weekdays. I was using a typical headset back then since it is standard practice that all development must be done using run-of-the-mill equipment. The idea behind this practice is that, if it sounds good using regular devices, it will sound great when using state-of-the-art equipment. Following that line of thought, when I got my hands on the HyperX headset, my slalom game was the very first game I tried – and boy did it sound amazing!

As a composer, I have an unhealthy inclination for high pitch instruments. Call it a “retro” style resembling the Nintendo era. However, to pull that off in these days, it is very important to counteract with low pitch instruments, usually playing the background arpeggio. As a result, my music scores have notes at both extremes of the audible bandwidth.

Here is what I noticed when testing the HyperX headset with the newly compiled background music of my slalom game: On one side, the high pitch instruments including a pan flute, a nylon guitar, a chorus and a harp (see the unhealthy inclination?) were crispier but not by much. However, the low pitch instruments including a clarinet and an acoustic bass were more imposing, giving a much better body to the overall music score. Even the sound effects (like braking) were striking.

I put my Xbox aside, I went straight to Microsoft’s DirectMusic Producer application and I started digging on my backup of “unfinished projects”, looking for some other midi files I had created in the past. I went this route because my other games have an unfortunate loss in quality due to a conversion from midi to wma to wav, consistent with the migration from DirectMusic Producer to XNA to DirectX. There was this particular score that focused on some dramatic percussion strikes that caught my attention. The difference was remarkable.

Thinking “outside-the-box” (no pun intended), I tried the headset with my iPod mini. It was a little bit disappointing to hear a noise in the background caused by peak cuts of the electronic signal. You see, sound devices are built assuming a particular type of speakers (in this case, the headset), measured as a “load” with a value that we call “impedance”. As a rule of thumb, we can only use speakers of the impedance defined in the technical specifications of our sound device. That said, I assume that the headset was a little bit too much for the little iPad – I guess I should have expected this, especially since it was the “mini” model.

Overall, I highly recommend this headset. It’s comfortable, it sounds incredible and it suppresses outside noise sources, immersing the player in the game at hand.

Please note that “Microsoft”, “Xbox”, “Nintendo”, “iPod mini” and “HyperX CloudX Gaming Headset” are register trademarks, and they are referred under the “fair use” clause of the Copyright law.


Using a Pixel Shader for Facial Expressions

I’ve been playing around with shaders and I thought about making a quick work-in-progress video to show the visual effects that I have been working with. In a nutshell, I have enhanced the human expression engine that I have implemented for my 3D models. The assumption here is that all characters will always be at a certain distance, and there will never be any kind of close-up. Granted, the video is a close-up itself, but that is only for the purpose of this article.

Here is the video:

The effects shown were implemented within the Pixel Shader. That’s a rather big gamble because a complex Pixel Shader may cause a catastrophic drop in performance. The advantage that I have is that my choice of design is towards a cartoon style, which makes pretty much everything much easier and cheaper than what would have been if I had chosen a realistic approach. That allows me to get away with a simplistic algorithm: The simpler the better.

In Layman’s terms, a pixel shader is a program that “paints” a tridimensional model according to a given image called “texture”. Models are made of triangles. Each triangle has three corners or “vertices”, each corner has a coordinate that points to a pixel in our texture, and all three pixels delimit a triangle in this texture. A pixel shader draws this very same triangle on the screen by extrapolating these coordinates, pixel by pixel, sampling the color to display from our texture.

Now, the features shown in the video work by pretty much messing with these sampling coordinates. Not all the texture is always shown and, instead, the pixel shader input specifies which section of the texture should be drawn.

I. Eye movement

When the shader draws the upper half of the face, if the color of the texture sample is white then it’s drawing the eyes. Then, sample again, but this time add an offset that points to an area on our texture where the irises are located. Messing up with this offset gives the effect of eye movement. This variation is a parameter, member of the pixel shader input. Granted, the irises are not a perfect circle, but then again, they are round enough at a distance.

II. Blinking

The texture has three pairs of eye lids in it: open, half closed, and closed. A shader input field specifies which of these pairs is drawn at a given time. My animation engine computes which one should be shown (the less operations at a shader level the better), following the pattern “open – half closed – closed – half closed – open”.

A special condition applies: the animation engine half closes the eyelids when the character is looking down. That makes the overall effect a little bit more natural.

III. Smile and Frown

The tips of the mouth can be crooked up or down. Originally, on the texture, the mouth is flat. Crooking the tips of the mouth can create a smile or a frown. Only the tip of the mouth is crooked in order to give the effect of full body lips.

This one is a little bit of a gamble. DirectX experts may argue here that this effect could have a better performance if done within the vertex shader. They would be right if it were not for the fact that I’m running very close to the 39 bone limit imposed by the size of the memory buffer in the average video adapter for PC.

VI. Eyelashes

Two thirds of the eyelashes can be tilted up and down, expressing the state of emotion of the character: sad, angry, evil mischief. The secret is to know at which point the tilt starts. The fact that this is a cartoon character makes this quite easy.

A Snowy Slalom - Danika

“A Snowy Slalom”: Leading the way towards the new era of gaming technologies

In an era where technology is always evolving, he who stands still will be left behind. On the other hand, he who follows it so closely runs the risk of being led to a dead end. Yup, during my professional career, I had a good share of surprises about technologies and third-party frameworks that all of a sudden get discontinued, leaving the investment done in custom applications dead in the water. I have also gotten scolded for not having frameworks up-to-date, losing a sale due to the fact that our technology does not support this or that other requirement that other products do.

As an “indie”, I took the decision of branching out as a way of reaching a bigger audience. I have to admit, the pile of options to choose from is rather overwhelming, as each one offers features compared to none, most of them highlighted with a “wow” factor using multimedia assets widely distributed over the Internet. Crowds of followers are not shy to chant over and over the benefits that each framework has, and some of them are happy to share their knowledge by publishing detailed tutorials for free.

Regardless, the thought of venturing to an unknown landscape, using a different framework, in an unfamiliar development environment and programming for a hardware that I don’t even have, can be daunting. Therefore, it was decided that the best approach to embrace this quest was to port an existing project rather than to start anew. The champion chosen for this challenge was our game “A Snowy Slalom”.

Starting Point

The project “A Snowy Slalom” started in the winter of 2011 – 2012. It was a time when I had already published my first game in the XBLIG channel, and I believed that my 3D engine had evolved enough to take over a wide variety of projects. I still had the strong believe that game developers should be conscious about our influence, so I wanted to try and create something not violent at all, something that would be in contrast to the mass murdering shooters that were in vogue. While going through the standard brainstorm process, I remembered the time when I tried a pool of waves for the first time: It was a cute experience when dodging waves on the shallow end, and yet it was rather impacting when doing so on the deep end, where the water was literally up to the neck and where no floor can help you jump. I recalled such experience while watching a winter sport event on TV (I really need to get cable), and that is where I got the idea of creating a skiing game. Not just the average “dodge and be happy” or “jump & stunt” kind of skiing, but a project in which the overall experience changed completely once the player was right on it, an experience that would allude that the elements of nature should not be taken so lightly.

Back then, there were two main design styles for sports games: On one side, there was the “realistic” approach, in which all efforts were spent towards mimic reality at all costs. On the other side, there was the “cartoon” style featuring characters with over-sized heads and wobbly movements, aiming for a cute gaming experience. The design chosen, however, was something between these two: The style is based on a colorful environment (even the snow has a tone of blue), and yet the character rigs (or character proportions) are close to reality, allowing the execution of natural human movements. Overall, the design is heavily influenced by the masterpieces of leading American animation studios.

By June 2012 the development of the main components of “A Snowy Slalom” using XNA was complete. The game was featured in the “Dream, Build, Play 2012” contest, and it was officially released on September of that same year on the XBLIG marketplace.

The Technology to Use

During the last couple of years, the indie market got flooded with new engines, technologies, frameworks, programming languages and assets stores. The new generation of gaming consoles had gone all of them through a promising debut, the id@xbox program was gaining popularity and everybody started talking about game development. By June of 2014, after taking a well-deserved break, I was ready to choose the technology to use for my next project. So, I started my research and weighted all available options based on my current needs, knowledge, experience and resources. While learning their benefits and restrictions, one by one I scratches these options off my list until, suddenly, my list was empty. This was an unexpected surprise, contrary to what was promised by all marketing material widely spread through electronic media. Shockingly, I found myself with a set of tools and assets that I could no longer use for the brand I wanted to work with, and that was a fact that was hard to swallow.

For starters, from all options available, back in 2014, there were only three frameworks supported by Microsoft’s new gaming console: Unity3D, DirectX11 and Unreal Engine (this last one was not free, so it got discarded by default). Of all these, none of them supported a type of file for 3D models called “X-File”. This was an important requirement since I had worked with a game engine that used this kind of 3D files and, for years, I had enhanced it and enriched it on every game I released. I had chosen to work with this file format back in 2011 because this was by far the most well-documented from the two 3D model file formats supported by XNA. The other option was Autodesk’s “FBX”, and it is not easy to create one of these files programmatically. On my defense, the X-File had been the standard used by DirectX for almost a decade, and never in my life could I have even imagined that Microsoft would drop support for its own 3D model file. About a year before, I had dropped a line in a DirectX11 forum requesting the support of this type of file, and the answer I got was not encouraging.

My situation was a little bit more complicated than an unsupported file: I had my own game engine based on an event-driven animation language of my own invention that pretty much allowed me to create any type of game I desired. I even had quite a set of tools to assist during game development. These tools created the game characters by mixing features like hair, skin color, body type, clothes (to mention a few), compiling them in an x-file ready to use. I had proven the efficiency of this engine with a third-person shooter, “Battle for Demon City” (released on April 2014), which had earned good comments (at least when it comes to the animation used) from gamers and critics around the world. To give some perspective, “Battle for Demon City” has 230 different animation sequences for 10 different models (some animations were applied to more than one model), for a grand total of over 2300 individual frames, all of them loaded, compiled and executed at run-time almost instantly. The best part was that the installer was 22Mbytes big, which was well below the 50Mbyte limit imposed by the XBLIG marketplace.

The importance of this animation engine resided in the fact that it had been the tool that allowed me to create games that were different from all others. This is paramount in a market where there are literally thousands of games available. The results I got with this algorithm had become my style’s “signature”, and I was not keen at all to the idea of discarding everything and start all over from scratch.

I was just about to give up on consoles and focus on games for PC using Monogame, when a thought crossed my mind: If I was able to create x-files programmatically then I might just as well be able to read and upload them, even in an unfamiliar framework. So, I gave it a try. From the two options remaining, Unity3D is more a “commercial game engine” rather than a development platform, so the implementation of my own animation engine was not going to be so easy to achieve. On the other hand, DirectX is a collection of APIs, thus it welcomes any kind of implementation I desire… although it was clear that I had to do it myself, without warranty that any custom development would be supported in further versions. I jumped in, and in two week’s time I had the routine to read, load and animate a 3D model from an x-file format (I think it has taken me more time to write this article). At that point I decided to give DirectX a try, hoping for the best.

I know, this document is sounding more like a charade rather than a serious article since I started talking about new technologies and the buzz around them, and I ended up with the oldest API available and the one framework that nobody seems to cheer for. To give credit to all those who disagrees with my choice, I am very well aware that the extra effort invested in this technology is the result of refusing to let go an “outdated” file format. For those familiar with IT management, in-house development of proprietary technology has a great risk of incurring in a high cost at a long term. Still, I’m willing to take that risk, just to make sure that my games are different from all others available in the market.

The Migration

Not everything went smooth. Once I had migrated all code to C++ and DirectX11 using Visual Studio 2012, I started to suffer from performance problems. The same game in C# and XNA had better performance, which was a cold reminder that the programming language is not always a decisive factor for overall performance. I was just about to throw everything out and start working from scratch with Unity3D (this time for good), when I read something about “instancing”. The more I researched about it the more excited I got. After implementing this feature in full, all performance problems were gone. I got so “hyped” about it that I extended it to all 2D graphics as well.

By early December the migration of “A Snowy Slalom” was complete. The next steps were to ensure that it complied with Microsoft’s Windows Store policies, including support for touch screen. By the end of February, the game was released in the Windows Store as a “desktop app” game.

What Worked

  • The migration project was a success. Overall, the game developed both in XNA and in DirectX have the same gaming experience, although this last one has a better performance as well as some camera enhancements applicable during collision detection, which was a feature that was recently added to my game engine.
  • The music I wrote for this game is, by far, the best thing I have ever done. It’s an up-beat, old-style midi file, played with childish instruments, yet the tone is quite dramatic. It really fits the overall game style.
  • DrawIndexedInstanced(): Everybody who works with DirectX should read about this function. This is the one that fixed all my performance problems.
  • Fonts have “Intellectual Property”. A project released to the public usually has to pay royalties to font creators. Depending on the package, it is a $50 to $100 expense. Still, I was having so many problems displaying text that I decided to implement my own font. I mean, I was hitting a dead end, and the thought of still having to pay for it after all that pain, was upsetting me. So, I took my stylograph pen out and created my own font. This was a struck of luck, as at the time I didn’t know that DirectX has some serious performance issues when it comes to text.
  • I had problems identifying a system that would represent the minimum hardware requirements to support my game engine. However, at the beginning of 2015, I got an HP Stream 7 tablet for only $99 USD. This is the best device I could ever find for performance testing (not to mention the useful touch screen). I highly recommend using one of these devices for QA and load-test.

What Caused Pain

  • The main problem with DirectX is content management. I had to convert all images (png, jpg, bmp) to “dds” files because that is pretty much the only format that I was able to load.
  • If the graphic part of DirectX is complex, the audio part takes the winning prize, by far. I understand that Audio2 is a low-level API, but it really took a big effort, just to play a sound. Likewise, all sounds had to be converted from “wmv” to “wav”. This increased the installer size by a 396% (from 16Mbytes for Xbox 360 to 63Mbytes for App Store).
  • I couldn’t make the C++ XML reader features to work. That was a little bit of a shocker, as all my animations are stored in this format. I mean, normally, in a standard custom application, I would have linked to the XML reader included in the .NET Framework. However, for App Store Applications, is not that easy to identify what can be used and what should be avoided. It’s nowhere documented. As a work-around, I had to create my own XML parser.
  • Managed classes in C++ can become a real pain. In most cases, it was much easier to use native structs and keep them loaded for the entire session rather than create, on every call, instances of managed classes and rely on the garbage collector to clean the mess.

What Didn’t Work

  • The Windows Store is not quite crowded. The more I announced “A Snowy Slalom” for Windows, the more sales I got at the XBLIG marketplace. I’m starting to consider going back to the Xbox 360 platform.
  • The pricing schema may not have helped at all. “A Snowy Slalom” is sold for a dollar at the Windows Store, just like in the XBLIG marketplace. However, the audience at the Windows store seems to be keener to download games for free, even if they have to deal with marketing ads or in-app content purchases.
  • I could not reach the deadline of December 2014. I published my game a couple of months after that, when winter was already half way through. This is a serious draw-back for a seasonal game. Maybe if I had focused on migrating this game from the beginning instead of first migrating my game engine and then re-applied it to the game would have been faster.
  • As an indie developer, I lost a little bit of popularity between my peers. It seems that not many people welcome the idea of creating their own game engine, and some of them are prone to defend their position a little bit too passionate. It’s really not that big of a deal, many people before me have created their own game engine as well. Also, I understand that what works for me may not work for somebody else.


It is rather late to celebrate the start of a new year. However, at this day, I do commemorate the start of a new era, a new phase that comes after accepting the fact that the good ol’ ways should be left in the past, and embrace new technologies that, even if they don’t make much sense at times, it is what everybody is following. Let’s face it: An artist that doesn’t have an audience is pretty much a human that has wasted a lot of resources in vain. I want to make it clear, though, that it is not the spotlight that I crave. In fact, following everybody for the sake of going where everybody is, is not an attractive plan at all. But I have to admit that hearing every now and then that one of my creations have raised a smile, even for a moment, is a thought that encourages me to continue doing what I do.

For four years now, I have used XNA to bring dreams to life. It’s been quite a journey, and I’ve enjoyed each and every step. I will not be one of those Nay-Sayers that yells to all four winds that XNA is death, running from stem to stern, carrying the lifeless head of the XNA framework in a morbid scene, attempting to move the masses towards my wallet’s convenience. Instead, I can attest that the projects I’ve created using this technology, continue to work. Funny stuff is that, the newer the system that runs it, the better they behave.

Still, the Xbox Live Indie Games market has shrunk so much that it has reached a point in which it is no longer sustainable. Simply put, it just doesn’t make any sense to invest more in a channel that nobody is listening anyway. Even the most loyal critics have moved on, looking for some other sources to feast on.

Don’t get me wrong, though, as for months we have been working hard to jump to the next platform, to the point that we are close to unveiling our next release. It hasn’t come easy, as every new framework requires a different set of tools, and none of them come easy, or cheap. Regardless, stay tuned for our first step in the new beginning. It will not bring riches and fame, but it will surely raise some eyebrows, and maybe some witty comments from critics and fellow peers.