Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
25. April 2011


So, in its relatively short lifespan Android has seen a 1.0, 1.5, 1.6, 2.0/2.1, 2.2, 2.3 and most recently 3.0 release.  As a developer, you need to decided which of these to target and which of these to ignore.  In many ways, if you are using Unity or another engine it makes the decision easier, as they set a minimum level and abstract away the details in their own code.  For the record, the minimum Android version supported by Unity is 2.0.


One of the most obvious factors in deciding what version to support is market penetration.  Luckily, Google provides such information.  This chart shows the OS version of devices that have connected to the market in the past 14 days.


Hmmm, pretty simple really when you look at it.  Support Android 2.1 and higher and you are good to go.


From a developer perspective this is pretty true too.  There were vast numbers of changes between 1.5 and 1.6, things you would think would be a no brainer like multi resolution support, but due to such small market numbers in the first place, I think we can simply ignore 1.5 and earlier.  Trust me, they aren’t worth developing for.

Android 2.0/2.1

From a game developer perspective Android 2.0 really isn’t all that different from Android 1.6 but there are a few giant gotchas, not to mention the various “undocumented” features.

First off, due to a move towards virtual buttons, HOME, MENU, BACK and SEARCH buttons now execute on key up, instead of down.  These little changes cause all kinds of nightmares moving between platform versions.

Perhaps of the most importance to game developers, MotionEvent can now report multiple simultaneous touches ( aka, multitouch ).  Also, if you are using the NDK ( C native code ), OpenGL ES 2.0 is now supported.

Really, that’s about it.  There are other changes of course, support for bluetooth 2.1 profiles, better thumbnail generation, etc… but to a game programmer, not much else of consequence changed between 1.6 and 2.0.


Android 2.2

This was the big daddy of all updates.  First of all, they enabled JIT in the Dalvik VM, resulting in 2x-5x performance increase CPUwise over Android 2.1.  Personally, I never experienced anywhere near that level of increase, but the improvement in speed is extremely noticeable.  So first and foremost, your code is going to be faster running on Android 2.2.  If CPU bound, in some cases then, your code is going to be MUCH faster on Android 2.2.

Besides enabling JIT there were a number of other changes of note to a game developer.  One exceedingly big one is the ability for Apps to install to SD card instead of into the devices memory.

Perhaps biggest of all is that OpenGL ES 2.0 support is now available to Java based apps.  The media framework also gained a few new abilities that are quite useful, like the ability to detect the completion of a sound loading in a SoundPool.

That’s about it, but then again… a massive increase in speed, the ability to load to an SD card and OpenGL 2.0 ES support…  that’s a pretty substantial upgrade.


Android 2.3

Android 2.3 is one of the first versions that actually looked at gaming as a priority.  They improved the garbage collector to minimize pauses, which are killer to immersion.  Nothing like having a 30fps shooter slow to a crawl because the garbage collector kicked in.  They also increased the performance of touch and keyboard events and used a 3rd party OpenGL ES video driver to increase 3D performance.

In the feature perhaps most called for, they implemented OpenSL ES for native audio support.  Up until 2.3, audio support has been at best weak on Android.  Now expect to see a lot of audio applications from the iPhone show up on Android because frankly until now, they were impossible to implement.

For the very few games that require it, if you want to use a front facing camera, Android 2.3 is where support was added.  Also added support for a slew of new sensors to enable Wii-esque actions, if of course the device has said sensors installed.

Really, in the end, the audio changes are the main event in the 2.3 release.

Unless of course you are doing Native Development using the NDK.  If that’s the case, this release was huge.  Until 2.3, you basically used the NDK to develop libraries that you called from a Java code.  All your UI and event management code had to be done in Java.  With 2.3, they added the NativeActivity class which pretty much allows you to work 100% in NDK/C++ code and kiss java goodbye. 

This should result in a performance improvement and make porting to Android easier.  My question is, will it fragment the market even more?


Android 3.0

And this brings us to the most current release as of writing, 3.0.  3.0 was mostly about adding tablet and tablet UI support to Android, but from a developers perspective there were a few new additions that are handy.  Lets go with the biggy first, Android 3.0 is the first OS release to support multicore processors.  So I suppose you want to target that shiny new Tegra2, 3.0 is where you are going.

They also added new animation support, but that’s not really animation support in a way that a game developer would care, that’s more for flying bouncing windows and other annoying and overly abused eye candy.

They did however add hardware acceleration for 3D graphics.  I am kind of surprised it took this long, but is definitely a welcome feature.

They also added something called Renderscript, which due to my ignorance may or may not be of use to game developers.  I really need to look into it further, but for now I will let Tim Bray @ Google explain it.

Renderscript is a new API targeted at high-performance 3D rendering and compute operations. The goal of Renderscript is to bring a lower level, higher performance API to Android developers. The target audience is the set of developers looking to maximize the performance of their applications and are comfortable working closer to the metal to achieve this. It provides the developer three primary tools: A simple 3D rendering API on top of hardware acceleration, a developer friendly compute API similar to CUDA, and a familiar language in C99.

Renderscript has been used in the creation of the new visually-rich YouTube and Books apps. It is the API used in the live wallpapers shipping with the first Honeycomb tablets.

The performance gain comes from executing native code on the device. However, unlike the existing NDK, this solution is cross-platform. The development language for Renderscript is C99 with extensions, which is compiled to a device-agnostic intermediate format during the development process and placed into the application package. When the app is run, the scripts are compiled to machine code and optimized on the device. This eliminates the problem of needing to target a specific machine architecture during the development process.

Renderscript is not intended to replace the existing high-level rendering APIs or languages on the platform. The target use is for performance-critical code segments where the needs exceed the abilities of the existing APIs.

When I get the chance I will look into this Renderscript a bit closer, but it does sound interesting.  3.0 is such a niche of installed devices however that it really isn’t a feasible minimum level to target at this point.



So in summary, 1.5 and earlier are so ancient and decrepit you are just as well as ignoring them.  1.6 is pretty much the “core” of the current API, but a large portion of the 1.6 install base will be running on old hardware where the resolutions simply may not be worth supporting ( like 320x480 ) in a game, so this generation may be skippable on that merit alone.  Multi-touch and ES2.0 native support are the big draw to 2.0/2.1, while 2.2 offered a fair number of advantages.  Simply put, 2.3 and 3.0 currently don’t have a big enough install base to bother supporting as your minimum target.

Therefore, and this is purely opinion, if I were starting a game today… which I suppose I am, I would look at 2.0 as my baseline target unless I really needed one of the new features or the performance gains that 2.2 offers.  Luckily in my case, the developers at Unity already came to the same conclusion I have.

One last word of warning.  In my brief time working with Android, I found version bugs to be a major pain in the ass, especially in code dealing with media.  I had code that wouldn’t work in the emulator, that would only work in the emulator, that would work in 1.6, and 2.2 but not in 2.1.  Put simply, Google have done a pretty terrible job at times in the forward/backward support category.  With your code, make sure you test on as many devices and as many OS versions as you can.  This single handedly is the reason I am not developing directly for Android any more.  I spent more time, by a large magnitude, dealing with crap like this than I actually did developing.  Of course, your mileage may vary!


24. April 2011

I suppose now is as good a time as any to actually talk about “the game” we are in fact going to create from scratch.  There are a few very key things to keep in mind when going through the game design process…  imagination is cheap and easy for most people, but you always have to keep in mind, at the end of the day you need to implement all these zany thoughts you have had.  So, in a nutshell, when designing a game, keep in mind your capacity and timeframe and ask yourself “can I actually do this?”.  In a nutshell I’m just saying don’t bite off more than you can chew.  So very often you hear people talking about how they want to make their first game, then go about describing some epic MMO that EA would have a hard time budgeting!

At the same time though “Pong from scratch” really isn’t all that exciting, although in all honesty it is a very good place to start.  I have created many “simple” games in the past and one of the quickest things you learn is, that simple it isn’t!  Ok… game time.

auto_duel_01Way back in the land of 80s computer gaming, there was a title called Autoduelcreated by Origin of Ultima and Wing Commander fame.  It was based off the Steve Jackson Games, um, game Car Warswhich in a nutshell was essentially MadMax the roleplaying game.  It’s the future, the world has gone to hell and we put guns on our cars… go!  Pretty much that was Autoduel.  Thing is, outside of creating my character, acquiring more money and sporting up my car, the game was actually rather lame, but the first few hours…. pure epic awesome.  Especially the time spent in the Arena and then using your winnings to design your first car! This bit of character building, customization and arena combat has always been buzzing around in the back of my head as the core of a very good game.

Now also may be a good time to point out that referring to yourself as “Lord British” is not really all that indicative of sanity.  This is to say nothing of poor “Chuckles” who you know had to have been talked into this whole thing.  Now Richard “Lord British” Garriott created many of the defining games of my childhood, so I am going to give him a pass on this one, but to you budding game designers, I don’t recommend it at all!

Anyways, back to the whole game design.  In a nutshell the big things I took away from Autoduel were the character development, arena combat and vehicle customization and of course the arcade like controls when you are actually duking it out.  The kernel of a very fun game is in those simple points.

Then in 2002, what is perhaps my favorite game of all time was released, Mechwarrior 4: 300px-MwmercsboxMercenaries. In this game you control a giant Battlemech, which is essentially a giant piloted robot killing machine.  What made this game truly great, especially compared to earlier versions, was the ability to purchase and customize your mech.  A perfect blend of strategy in the mech creation aspects, then thrust you into the action just like Autoduel did years earlier.  Even more uncanny, their was a portion of the game where you character competed in arena games, and again like years earlier with Autoduel, this was hands down my favorite part of the game.  Now, as I understand it, I need to be very very very careful in my use of terms here.  Mech, Mecha, Battlemech, etc… are all trademarked terms and will summon a hoard of avenging lawyers faster than you can say “lawsuit”.  This is why over the years we have been introducted to Chromehounds, Gears, Hercs and hundreds of other words that aren’t Mechs.  So let me say it loudly and now, this is not in any way going to be a game about Mechs!  This is going to be a game about giant mechanical human piloted robots!

So, before I get into more detail later on, essentially I am looking to create a game that combines Autoduel and Mechwarrior, with an arena focus.  Let me say this as loudly and plainly as I possibly can… our giant robots are not, in any ways Mechs!  So please don’t sue me.


21. April 2011

One of the very first things you need to decide when creating a game is what your target hardware is going to be.  This affects so many things, from the engines available to you, how many polygons you can use to create your models, how large your textures can be, etc…  In many cases, like with the Unity Engine, they take care of scaling across platforms to a certain degree but you still need to be frugal when resources are tight.

This then is a general summary of the “power” available to various different platforms and devices you may choose to develop for.

First off, is the land of the PC, which was probably always the hardest to determine as there is such a wide gamut of machines out there, from people running multiple GPU Alienware machines to the Walmart special your mom plays Farmville on.  That said, there is now an extremely wonderful resource for figuring out what the “average” machine is, thanks to Steam.  Steam runs a constant survey through their client and make the results available to everyone.This shows the most popular configurations, OS, GPU, RAM, software, etc…  A virtual goldmine of information for those intending to target the PC.  Nicely, they have recently started releasing Mac statistics as well.  One thing to keep in mind though, Steam skews more heavily towards “hardcore” gamers, as you obviously need to have installed a Steam powered game to be included in the survey.  Therefore the computers that have never seen anything outside of Facebook aren’t being represented.

As of right now, the average machine as reported by Steam is:

  • Windows 7 64 Bit
  • 2 core, 2.3 – 2.7Ghz CPU
  • Nvidia GeForce 9800 GPU 1GB
  • 4GB RAM
  • 1920x1080
  • 2MB internet connection


Frankly I am actually rather shocked by a few of those stats, including the fact Win7 64 is 37% of the install base!  The very key thing to note there though is the average video card.  The GeForce 9800 was released in 2008 and is a DX10 compatible card.  Key features as given by nVidia:

  • 112 Stream Processors
  • 512-1024MB of GDDR3 memory
  • 256-bits Memory Interface Width
  • 600 MHz Graphics Clock
  • 1500 MHz Processor Clock
  • 900 MHz Memory Clock
  • Texture Fill Rate (billion/s) 33.6
  • Memory Bandwidth (GB/s) 57.6
  • DirectX 10, Shader Model 4.0, OpenGL 3.3, and PCI-Express 2.0.


So there you go, if you are targeting the PC with your game, the above is the current markets “average” machine.

The end results of the above stats are actually being dragged down quite a bit by the Mac.  If you look at the Mac market only, your average target becomes quite a bit weaker.  The “average” Mac as reported by Steam is:

  • OS 10.6.6
  • 2.3 Ghz – 2.7Ghz CPU
  • 4 GB RAM
  • 1280x800 resolution
  • NVidia GeForce 9400M w/ 256MB RAM


So, if you are going to target the Mac, be very aware the average machine has a much lower resolution screen ( Blame the MacBook! ) and a much worse video card.  9400 doesn’t sound that much worse than 9800 does it, how bad can it be?  Actually, honestly, quite bad.  The key is M, as in Mobile, which is a card optimized for battery life and heat more than speed.  A quick look at the specs on NVidia illustrate this clearly.  Fill rate is 3.6 (billion/s), almost 1/10th the speed of the 9800.  So, keep in mind if you are targeting the Mac, if you want maximum compatibility, you need to set the graphical target quite a bit lower than If you are targeting the PC.


Now we move on to devices, where it gets quite a bit more difficult to come up with an average, as there are so many different devices out there.  As of right now, there are only two and a half viable targets, iOS ( iPhone/iPad/iPod ), Android and Windows Phone 7.  I list Windows Phone 7 as a half because their market share is currently quite appalling, worse than I would have expected at this point.  That said, they are about to become the exclusive OS of Nokia, which should change their market share drastically.   Android has significant market penetration, but to be honest the state of their app market, especially for games, has been absolutely horrid.  Since I purchased my first Android phone well over a year ago, the same game has been at the top of the charts, that’s pretty sad.  On the upside, with so many phones and such a crappy selection of games, the market is wide open for a good game to excel. When Game Dev Story was released to the Android market, it instantly jumped to the front of the charts, so if you make a great game, sales are possible.  I have to warn you though, if you haven’t played GDS and you wan’t to get your own actual game completed, DON’T!  I lost a few days of my life when that game came out!


Anyways, now on to the actual phones.

IPhone 3G/8-16GB iPod


This is pretty much the 800lb gorilla in the mobile phone space.  Easily the best selling and thus most common phone out there worth making games for.  Now for the specs:

    • 320x480 screen
    • 8/16GB storage
    • 128MB RAM
    • ARM 11 412MHZ CPU


The phone supports multitouch ( registers multiple screen presses at the same time ), a camera, light sensor, 3 axis accelerometer and a proximity sensor mostly for detecting if the phone is pressed to your ear or not.  In practical terms, you have touch and tilt to work with for inputs.  Other than the main button, volume, orientation lock ( now mute for some unknowable reason ) and the power button, there are no physical buttons available to you as a developer.

Of key importance is the GPU, the PowerVR MBX Lite which according to the all knowing brainthat is Wikipedia, it is capable of 3.4 million triangles per second and 270 million pixels per second.  Now keep in mind, these numbers are theoretical maxes, reality will be much different.  Even working with maximum values, the restraints start to become clear.  At 30 Frames Per Second, that means a maximum of 113K polygons per frame.  Now lets keep in mind, there is no way in hell you are going to come even close to that number, especially once you start adding textures.  I have heard 7,000 polygons is a pretty reasonable number to use as a target.  That’s 7000 polygons to represent everything visible on your screen, your player, your world, enemies, GUI, etc.  It sounds tight, and compare to the PC it is, but at the same time, the Nintendo DS is around 2K, so if you look at it that way, its absolutely massive!

iPhone 3GS/iPod 32-64GB

This was mostly just a spec bump release and probably didn’t sell enough to target at the exclusive of the 3G install base. The new specs:

  • 320x480 screen
  • 8/16/32GB storage
  • 256MB RAM
  • 600MHZ ARM Cortex-A8 CPU
  • PowerVR SGX535 GPU


In addition to the spec bump, the screen is now finger print resistant and the camera is quite a bit improved.  The most important details from a game development perspective are obviously the increased RAM and the improved GPU capable of a theoretical 14M polygons/sec an improvement of 4X that of the 3G.  Again sadly, this power is probably going to be of limited use to you simply by the economics of the massive 3G install base.



Next up, we have the iPad.  In essence it’s a really big iPod until you look at the guts.  Speaking of which, here they are:

  • 10 inch, 1024x768 screen
  • 16/32/64GB storage
  • 256MB RAM
  • Apple 1Ghz A4 CPU
  • ( 1 Ghz ARM Cortex-A8 + PowerVR SGX535 GPU )


So, that’s it.  On top of the functionality and buttons of the iPhone, it also added in magnetometer ( compass ) but otherwise the form factor and controls are pretty much identical, well except the whole being 2.5x bigger and heavier that is.  The most interesting change is the move to the A4 processor, which is an Apple designed and Samsung manufactured system on a chip.  In a nutshell, it is an ARM 1 GHZ Cortex-8 CPU coupled with a PowerVR SGX535 GPU.  So, pretty much this means the iPad is for all intents and purposes the same speed as the iPhone 3GS from a graphics perspective, and almost twice as fast from a CPU clock speed perspective.  The biggest difference between the 3GS and iPad from a developers perspective is the amount of screen real estate available.

iPhone/iPod 4


That brings us to the present, as of time of this writing, the iPhone 4.  Basically the iPad in phone/ipod format:

  • 960x640 3.5” screen
  • 16/32 MB storage
  • 512MB RAM
  • 800Mhz A4 CPU
  • 3 axis gyroscope


In addition, a 5 MP camera and a .3MP front facing camera were added to the iPhone4.  Again, the GPU is identical to that of the 3GS and the iPad, while the CPU is right in the middle clock-speed wise.


So, as a developer, you can essentially look at the iPhone 3GS, iPhone4 and iPad as more or less comprable devices, with the exception of slightly faster CPU speeds and substantially different resolutions and screen sizes.  All of which are capable of around 14M raw triangles per second as a theoretical max, while reality seems to suggest a polygon budget around 30K textured polygons per frame as realistic.  Will post some real world tests later on to confirm reality.

iPad 2


Now the newest kid on the Apple block, the iPad 2.  Basically a beefed up, scaled down, make me look at my existing iPad 1 in disgust version of the iPad.  Stats:

  • 10” 1024x768 screen
  • 16/32/64GB storage
  • 512MB RAM
  • 1 GHZ Dual Core Apple A5
  • Power VR SGX543MP2 GPU


So, take an iPad, make the form factor better, round off the annoying edges, smack on a camera at the front and back and you have an iPad 2.  Well… that and speed up the GPU by an order of magnitude and double the number of CPU cores!  This thing is a beast compared to the iPad/iPhone 4, scary the differences spec wise.  Theoretical max of 64M polygons/second, puts it at about 4 times faster than the GPU in the original, to say nothing of the fact you now have two cores.  In reality, you are probably looking at a polygon budget around over 100K per frame. 

So, right after the iPhone4, iPad and 3GS started to look like a great common baseline to target, the iPad2 comes along and throws a hell of a monkey wrench in the mix.  Hands down, as a gaming device, the iPad 2 is in a different league than all earlier devices.  You can choose to support all of them, but I am already seeing a number of complaints in the app store from iPad users where an app is made for iPad2.  Its interesting to watch reviews, where half are glowing 5 star reviews (iPad 2 owners) and the rest are 1 star complaints ( iPad 1 owners ).  If you really are pushing the limits, you may want to target the iPad2 exclusively.  That said, doing so shrinks your target market by a huge volume.




Phew…. that’s it for PCs, Macs and Apple portables… now on to the wonderful world of Android.






Top Selling Android Phones on

Name Chipset RAM Screen Other
NVidia Tegra2 1Ghz Dual Core 1GB 960x540
4 inch
16GB internal storage
HDMI out
5MP Camera
Android 2.3
HTC Inspire 4G 1 Ghz Snapdragon 768MB 800x480
4.3 inch
4GB internal storage
8MP Camera
Android 2.2
HTC Thunderbolt 4G 1 Ghz Snapdragon 768MB 800x480
4.3 inch
8GB internal storage
8MP Camera
Android 2.2
Motorola DROID X 1 Ghz TI OMAP 3630 512MB 854x480 8GB internal storage
8MP Camera
Android 2.1
T-Mobile (LG) G2x NVidia Tegra2 1Ghz Dual Core 512MB 800x480
4 inch
8GB internal storage
8MP Camera
Android 2.2
HTC Evo Shift 4G 800 Mhz Qualcomm MSM7630 512MB 800x480
3.6 inch
2GB internal storage
5MP Camera
Android 2.2
Slide out keyboard
Samsung Galaxy S 4G 1 Ghz Samsung Hummingbird 512MB 800x480
4 inch
1GB internal storage
5MP Camera
Android 2.2
HTC Droid Incredible 1 Ghz Snapdragon 512MB 800x480
3.7 inch
8GB internal storage
8MP Camera
Android 2.2
Samsung Epic 1 Ghz Samsung Hummingbird 512MB 800x480
4 inch
0 internal storage
5MP Camera
Android 2.2
Slide out keyboard
TMobile (Google) G2 800 Mhz Qualcomm MSM 7230 512MB 800x480
3.7 inch
4GB Internal storage
5MP Camera
Android 2.2
Slide out keyboard


Other Android Devices of Note

Name Chipset RAM Screen Other
Sony Xperia X10 1Ghz Snapdragon 384MB 854x480
4 inch
0 internal storage
Android 2.1 (1.6 shipped)
8MP Camera
I own this phone and Sony Ericsson should burn in hell
Motorola Xoom NVidia Tegra2 1Ghz Dual Core 1GB 1280x800
10 inch
32GB internal storage
Android 3.0
TMobile Hero ( G1 )
528Mhz Qualcomm MSM7200A 288MB 480x320
3.2 inch
0 internal storage
5MP Camera
Android 1.5
Slide out keyboard
Motorola Droid 600Mhz TI OMAP3430 256MB 854x480
3.7 inch
0 internal storage
5MP Camera
Android 2.1
Google Nexus S 1 Ghz Hummingbird 512MB 800x480
4 inch
16GB internal storage
5MP Camera
Android 2.3


As you can see, there are a great many phones, but in the end the hardware is pretty standardized.  If you are creating a phone of any technical complexity you can probably forget the first generation of Android phones like the G1, frankly they are pretty terrible. 

Of the installed phones, most of the phones shipped in 2009 and much of 2010 have a 600Mhz to 1 Ghz, with 256-512MB of RAM.  OMAP, Snapdragon and Hummingbird are easily the most common CPUs.  Of the install base, the majority of phones in peoples hands these days fall into this group.

As to phones being sold these days, 512MB of RAM and the 1Ghz CPU’s seem to be the norm, with dual core Tegra’s being more and more common on high end phones and in the tablet space. 

Now time to dive into each chipset with a bit more detail. 

Lets start with the monster in the group, the newish NVidia Tegra 2.  It is a dual core ARM Cortex-A9 running at 1 Ghz.  Integrated is a NVidia ULV GPU with 4 pixel shader and 4 vertex shader cores  ( by comparison, a Radeon 9800 had 4 vertex cores ) running at 330mhz.


Anandtech summarize things nicely with this benchmark.

When it comes to raw rendering, the Tegra2 is really top of the class.  I do find the iPhone4’s performance extremely confusing however.  That the 3GS is almost 3x superior to the iPhone and iPad seems extremely wrong.

As you can see though, in the Android world, most Android phones regardless to chipset, preform fairly consistently by generation.

In the end, I am targeting the iPad/iPhone/3GS/mid-upper range Android phones with my game.  Why?  Because they are capable enough, sold well enough and frankly… those are the phones/devices I own! Winking smile


1. April 2011

Once, many years ago there was a company called Symbolics. This company, though now defunct, goes down in history as the very first .com address ever registered. Even more impactful, Symbolics’ actions lead directly to Richard Stallman creating GNU! At the time, Symbolics created a series of LISP based workstations, very powerful workstations by the standards of the day. For these workstations, they created one of the very first graphics suites.

Eventually Symbolics sold their graphics division to a multi-billion dollar Japanese company called Nichimen, who released it at first as n-Worlds, then after a period of time as Mirai. Eventually a group of employees from the original team purchased the IP and incorporated as Winged Edge software, then later as Izware, where in addition to Mirai they released the much cheaper pure modeler Nendo. Their software was used most famously to create art for the game Mario 64 and for the movie Lord of the Rings and now, sadly, they are defunct.

So, if they are now out of business, why the hell did I waste your time with the above history lesson??? Two reasons; first, I love geek history and trivia. Second, Mirai and Nendo live on in the superb ( AND FREE!) Wings 3D.

Why is it called Wings? Remember earlier I mentioned that the Nichimen crew renamed themselves Winged Edge Software? Well that part is key, the underlying technology behind Mirai/Nendo ( and now Wings 3D ) is the Winged-Edge Mesh. In the time worn act of being lazy, I will let Wikipedia explain that one to you.

Introduced by Baumgart 1975, winged-edge meshes explicitly represent the vertices, faces, and edges of a mesh. This representation is widely used in modeling programs to provide the greatest flexibility in dynamically changing the mesh geometry, because split and merge operations can be done quickly. Their primary drawback is large storage requirements and increased complexity due to maintaining many indices. A good discussion of implementation issues of Winged-edge meshes may be found in the book Graphics Gems II.

Winged-edge meshes address the issue of traversing from edge to edge, and providing an ordered set of faces around an edge. For any given edge, the number of outgoing edges may be arbitrary. To simplify this, winged-edge meshes provide only four, the nearest clockwise and counter-clockwise edges at each end. The other edges may be traversed incrementally. The information for each edge therefore resembles a butterfly, hence "winged-edge" meshes. Figure 4 shows the "box-cylinder" as a winged-edge mesh. The total data for an edge consists of 2 vertices (endpoints), 2 faces (on each side), and 4 edges (winged-edge).

Rendering of winged-edge meshes for graphics hardware requires generating a Face index list. This is usually done only when the geometry changes. winged-edge meshes are ideally suited for dynamic geometry, such as subdivision surfaces and interactive modeling, since changes to the mesh can occur locally. Traversal across the mesh, as might be needed for collision detection, can be accomplished efficiently.

In a nutshell, it allows for very sub-division friendly polygonal modeling, exactly what we want. If you have worked in any other major polygon based modeler, Wings is going to feel very similar and very alien at the same time.

Hold with me though, as I will show you Wings is an extremely capable 3D modeler, easily the peer to most commercial packages. Oh, and did I mention, it’s free?

Stay tuned for more actual instructions and much less history of this great program.


1. April 2011


The following is a list of keyboard and mouse shortcuts for using Blender.  It is mostly for my own reference and exists because many of the existing shortcut lists out there a) are out dated and largely irrelevant now b) are too comprehensive.  I really only care to record the keys that are most useful to me in my work on GFS.  Hopefully they prove useful to you as well.

This is very much a live document, so as I find new shortcuts I use, I add them here.

In Object Mode:

T Show/Hide Object Tools
N Show/Hide Transform Window
CTRL + T With Camera selected, then object, tracks (points) to object
G Grab mode, like a freehand move
R Rotate
S Scale
G then x/y/z
R then x/y/z
S then x/y/z
Limited Move/Rotate/Scale to giving axis.  For example, hitting the G key, then the X key will limit your movement to the X axis
Shift – Space Toggles visibility all but active window ( ie, will hide/show Outliner and Timeline if using 3D View )
X Delete
C circle Select
B Rectangle select
In Edit Mode:  
A Select All
T Show/Hide Edit Tools
(Num Pad)   . Zoom selected
B Rectangle Select
CTRL + E Edge menu
CTRL + F Face menu
CTRL + V Vertices menu
TAB Switch between EDIT and Object
CTRL + TAB Switch between Vertex/Face/Edge menu


GFS On YouTube

See More Tutorials on!

Month List