Archive for November, 2010

Eighty Five Percent

Tuesday, November 30th, 2010

Alright, time to get back in to the routine.

It’s been two weeks since the last post. Last week became an impromptu holiday for me — I am a Canadian living in Canada, but I deal mostly with US companies, so American Thanksgiving seemed safe.

The week prior was busy though. I sent off the initial version of Smiles HD for the Mac App Store. It still sits in the approval queue, but I’m there.

DesuraThat wasn’t the only build I submitted though. For the past month, I’ve been part of the private Desura beta — a steam-like store from the ModDB and IndieDB people. They’re new and have just barely launched, but the system is very slick (it even supports buying and selling mods). Definitely one to watch.

You can check out the Smiles HD page on Desura here:

Also, this is the first Windows version of Smiles HD available for sale (Smiles on AppUp is Netbook tuned) — not even my “buy direct” option is available yet (much website work to still do). The game wont be exclusive to Desura, but it is very easy for me to make and push updates with them (until I get my own system in place).

Both the Mac App Store and Desura have Smiles HD 1.1.0. Once I add a few more things, I’ll send out a 1.1.1 update.

One thing that held back the Linux build was a little discovery of mine. It seems the stock Intel GMA drivers that ship with Ubuntu 10.10 don’t support S3TC (DXT) texture compression.

Actually this isn’t a very big deal as there’s an update that should fix it, but it reminded me I may want a fallback option. So versions of Smiles HD newer than 1.1.0 will include both the full 1080p assets, and some non-texture-compressed 16bit “720p” assets. That adds about 10 MB to the game (already 40 MB). Not much really, and it guarantees compatibility. I suppose an option would be to write a software decoder for S3TC (DXT) compressed data, but for PC’s I’m okay with adding 10 MB. I’ll probably omit it from the Mac version though, since the store requires OS 10.6.6.

Tiny Window for a Tiny Netbook Screen (1024x600) -- Oh hey! I added space from the border

One thing that didn’t make 1.1.0 was a toggle button for switching between fullscreen and windowed (the game fullscreens). I put off adding the feature for a number reasons; The main reason was that I didn’t have a good idea what resolution to make the window, and I wasn’t liking the idea of adding a resolution selection screen (it’s cluttered enough already!).

When Smiles HD starts, it checks the desktop resolution and uses that as the game resolution. Every system I’ve tested it on runs nearly 60fps. Interestingly, as the resolution of the attached monitor goes up, the computers seem to have a beefier GPU (no Intel GMA 950’s attached to 1080p screens… except for my Mac, and it runs fine there).

Hello Windows 7. My my! You have such big gutters!

So what I’ve decided to do is create a window 85% of desktop resolution. I tried 80% initially, but it seemed too small, so I bumped it up. I figure that *should* be enough room. Worst case, you’ll always have the fullscreen button available to you if you can’t fit it all. I still have to make the button work, but that is the plan.

That’s all for now.

Tales of a Silent H

Sunday, November 14th, 2010

For whatever reason, I was inspired to start playing with logo designs. There’s no new decisions to be seen here in this post, just some ideas I’m playing with (and rejecting).

I actually used to make my own typography and font designs, one such example is this:

You can see more examples of prior logos here.

For the past 5 years I’ve been using this:

I don’t know if I’ve ever really liked it, but it was good enough. The thing is, it WAS good enough, not so much anymore (or in other words, I’m bored of it).

Neither that or Smiles use fonts I created, with the exception of the Smiles logo and PAUSE/UNDO text.

Smiles... it's a logo, and the only original typography design I've done in years

So seeing how the 5 year anniversary of Sykhronics Entertainment is coming up, as well as some new projects, I think it’s time to start thinking about the branding.

In the “old days” (1998-2005), Sykhronics was an all-caps logo. When it became my dayjob, it went lowercase. For the new logo, I’m thinking about going back to the caps look, and maybe making my own font design again.

Before I go there though, I wanted to play around with some general type ideas.

What is definitely not obvious, Sykhronics is pronounced “Sigh Cron Icks” (Sy Khron Ics). It’s a invented word of mine that, for whatever reason, has a silent H in it. And for whatever reason, I don’t think I’ve ever done anything to emphasize (or rather, de-emphasize) the H. I could have just axed it (I do own the H-less domains), but it’s such an absurd word anyways, I left it in.

So the majority of my experimenting today is with the H.

Or as text:



sykhronics . . . . . sykhronics . . . . . sykhronics

sykHronics . . . . . sykHronics . . . . . sykHronics

The circle designs, there’s no hidden message there (MOONS!), just that the logos are all very wide. Whatever I design should last me the next 5 years (at least), so one idea I’ve been toying with is styling it to suit the game. The circle is a sort-of guide, showing where the per game identity “thing” would go. If I was to style it to Smiles, it’d probably have the Mushroom character curling and peeking over.

Other things I tried above was a lower line on the H. I kinda like it, but I also realized later I kinda like the lower case h too. The lower case H version works well in actual text too. There’s also the faint gray and outline H versions, which I think give a good contrast.

And then there’s “Tiny H”. Hmmm.

Again, no decisions. I wanted to make these mockup images for me, and put them somewhere I’d see them (and no reason not to share).

Smiles in 64 bits

Saturday, November 13th, 2010

So I spent the evening getting Smiles working in 64bit Linux (Ubuntu 10.10) as well as the Mac. Here are the results:

Smiles HD, 64bit binary running on 'The Zotac' -- Ubuntu 10.10 Desktop

And the Mac again:

Smiles HD on the Mac again, this time in 64 bits

And a closeup of the processes section:

A zoom of the process, showing 64bit mode. The CPU usage is due to it being a debug build.

Getting it working on the Mac wasn’t really necessary, but I really like Xcode’s debugging tools. They made tracing the issue very straightforward. I had two VNC windows going almost constantly, as I’d make changes on the Workstation PC, commit to SVN, and sync on both the Mac and the Zotac.

I had a pretty good idea what was the cause of my crashes, but I still hunted for some resources.

MSDN 32-bit to 64bit:
20 (potential) issue of 64bit porting:
GCC Type Attributes:

The 3rd link isn’t really important, but to be sure I set the “packed” property on a potentially dangerous union type (pointer and int overlay, though I removed the pointer).

The main issue with my code was my use of size_t. I use it everywhere! That’s not a bad thing, but I also use it inside my container types. That’s also not a bad thing, but these container types are designed to be bulk-written to disk as-is, which I do in some of my file formats.

That was the main culprit right there. Many of my datafiles contain raw DataBlock data (streams of memory, 32bit size followed by data). As it turns out, size_t is 64bits on 64bit OS’s, causing all kinds of alignment issues. Hoo boy!

My response to this was to create my own size_t: st for the system version (size_t), st32 for a 32bit size holding type (unsigned int), and st64 for a 64bit size holding type (unsigned long long int).

Ahh, much better.

I’m not too concerned about the 32bit limit on the size of a DataBlock. That lets me store and allocate just under 4GB of data in one. I may some day add a DataBlock64 type, but there’s no good reason right now (maintaining code that will never be used = waste of time).

As for other bugs going 64bit: On Linux, when I enabled GLee (the OpenGL extension library, not the musical), it introduced a number of new symbols that conflicted with my code (Thanks X Windows headers!). Bool, Status, and Font. I had to rename a bunch of variables and types to fix that.

Aside from that, the 64bit Linux build is consistently detecting a double-free I’m doing on exit. That one has plagued me for a while (rarely ever caused problems), so I’m glad I now have a platform that does it every time.

That’s all for tonight.

Ubuntu on the Zotac

Friday, November 12th, 2010

Before I get to the meat of this post, last night I finished my “early” Mac App Store TODO list. I *COULD* submit it now, but there’s a bug with submissions. My iPad version is called Smiles HD, and so will be the Mac App Store version. Right now the names conflict, so I have to wait until this is fixed.

For now it’s “done”. I sent the binary to some friends to double-check compatibility. So while I wait, it’s time to get on other ports.

Notably, my Mac binary is only a 32bit Intel binary. My source does compile in 64bit mode, but runs in to issues. Smiles isn’t a game that needs 64bit addressing, but unlike Windows and OSX, 64bit Linux doesn’t support 32bit applications (not stock at least). So one of my next portability challenges is making my Smiles codebase support 64bit Intel and AMD chips.

* * *

Aside from my Workstation PC and Macs, I have a lot of Netbooks. The Netbooks are what I usually use for Linux development. Unfortunately, all the Netbooks I currently have don’t support 64bit instructions (the current generation Intel Atom CPU’s do).

So I ordered one of these, a Zotac MAG Nettop PC. For about $250 CAD (with a rebate), it’s a dual core Atom 330 running at 1.6 GHz, 2 GB of RAM, 160 GB Hard Drive, with an NVidia ION chipset (GeForce 9400M). I’m technically lacking an AMD and ATI test machine, but I do have one of each elsewhere I can turn to if I run in to problems (both running Windows).

The orange ring lights up when the computer is on (faint light). Black when off.

The version I ordered isn’t the most up to date (original NVidia ION, last year’s Dual Core Atom), which is on purpose. This is both a development and a test machine, and if I can buy one for $250, so will other people looking for a low cost PC… not that an NVidia 9400M is anything to shake a stick at either. This gives me a good cross section of graphics hardware I can test in Linux (Intel GMA on the Netbooks, NVidia on the Nettop).

When I purchased my first Netbook a couple years back (an Acer Aspire One), I started a secondary blog where I recorded all my setup notes, thoughts, and learnings (new word!!).

So here’s an extra little blog I created to share the super technical and super nuance details of a little project of mine. Turning a stock 8GB SSD Acer Aspire One running Linpus Linux in to an ideal lightweight coding machine.

More than anything, it was a blog about me learning to use Linux for development. I know a lot more about working inside Linux now, but posts of mine like this I found extremely helpful when I started doing things like Moblin:

So the remainder of this blog post will be me walking through the setup steps taken to set up this new machine for development, and get my 32bit makefile running and building code. In retrospect, the recorded setup details should be identical no matter the CPU architecture (32bit or 64bit, though this was me doing it 64bit style).


As expected, twas the Cache

Wednesday, November 10th, 2010

Not much to say or show, just that the performance problem was due to the textures being larger than the texture cache.

Under 10% CPU usage, much better

As it is now, on my Mac mini the game runs at under 8% CPU usage in the menus and Zen, and under 10% in Drop. The largest texture is 1024×1024, DXT5 compressed (4:1, or 1 MB). Before it was 1024×1024 uncompressed 32bit RGBA (1:1, or 4 MB). That either means the GMA 950 in these older Mac’s has 1 MB of cache, or perhaps 2 MB (I didn’t check with 16bit RGBA textures, but it’s unlikely).

Macs and Cheese

Sunday, November 7th, 2010

This week I’ve been downloading updates for all my tools. Linux distros, as well as Apple tools and OS updates. Yesterday was spent trying to get a 64bit version of Ubuntu running on my Media Center PC (i.e. my old dual core AMD workstation PC, now hooked up to the projector). My initial attempt of installing it to a USB key didn’t work, but I did eventually get it working using WUBI.

Unfortunately, my video-out setup on that PC is a bit strange (Component Video from an NVidia 7600), and the results were a little less than ideal:

Feeling Blue Ubuntu?

So I bit the bullet and put an order in for a dedicated Linux PC. So for about $250 + tax and shipping, I have one of these on the way. Once it arrives, I’ll be filling that 120GB/160GB hard drive (I forget which mine has) with many distros. 64’s, 32’s, Ubuntus, Fedoras, and I guess a Suse since that’s the other big one according to the chart.

Today was the first #ScreenshotSaturday. You can see a compilation of images here.

Here’s my contribution:

After a few hours of fighting, the Smiles builds on Mac again

So yes, the Mac version has had some progress. I had to rebuild my project file (and mess with precompiled headers for a while), but the game is now building with the latest Xcode.

Tray Icons

“The plan” as I saw it, was to quickly see if I could get a Mac App Store build of Smiles HD ready over the weekend. Since there’s so much time between now and the supposed launch date of the Mac App Store, I expect to have an update ready even before it goes live. I did run in to some issues though.

I have an older MacMini (Core2 Duo with GMA950), and recently picked up a Magic Trackpad for testing. So I gave the game a spin. The menus do well:

Ahh, a nice 6% CPU usage on my dual core

But for some reason in-game performance is a little low… not to mention the CPU usage:

ZOUNDS! 76%! Eek! That's the release build. The Debug build was 95%.

I’m fairly certain this is because my textures are just too big in VRAM, which is causing a cache miss. That leads me in to the next big item on my TODO list: improve my texture format. Exactly what that entails is somewhere between adding DXT compression support, and not loading/data-compressing the largest mipmap in the same chunk as the rest of them.