Random thought on 1080+P

some random thought I had while sitting on a bench at a rainy park today....

I finally watched James Cameron's Avatar the other day on DVD. It was a good movie, but the DVD quality was not that great on my 1080p display.  It's after all 480P right? Now people are used to 1080P, so DVD quality wouldn't cut it. (even youtube video looks better than DVD, jesus!)

So then what's next? will we need anything over 1080p?  I believe the common belief was that our eyes can't process more than a few million pixels so going over 1080p would be waste.(1080P is about 2 million pixels)  But apparently we can perceive way more than that....  So we will need more than 1080P.

But one day TV resolutions will overcome our eyes' capabilities right? Then can we stop adding more pixels on the TV?  I don't think our eyes are the limit.. the manufacturing cost would be the deciding factor.. Say our eyes can only process 1,000 million pixels.  But if we are given a TV with 4,000 million pixels, our eyes will see 4 pixels as one pixel. right? So it would be same as blending those 4 pixels into 1. Oh sweet! it's a 4X super sampling antialiasing! If it's gets 16,000 million pixels it's 16x SSAA.. I can't say no to this.. :)

But as I said, it might become too expensive to add that many pixels one day... but price of LEDs are going down everyday and smart people are making LEDs use less power. so that might not be a problem.... or it might become physically impossible to add more pixels one day? just like how we coudln't make single-core CPUs faster anymore? Maybe.... but still 576 Million pixels are long way to go....

Cross-platform OpenGL Mobile Game Engine?

I made a very simple game a few years ago, and yesterday I found out this game is still making about $200 an year for me. Funny. Why didn't I think about porting it to mobile? Oh yeah I know.. because I didn't wanna write same code again and again for different platforms.... Then I remembered, I once started to write a quick demo in C++ that runs on both Android and iOS. Sure it was nothing more than displaying a couple of textures on screen, and I lost my interest very quickly that time. The reason? it was just not easy to debug on Android once you use the native sdk.

But this time I thought a bit more... maybe it's viable... Sure..... I already know I can make a mobile engine that runs both on:

1. Android
2. iOS

Android's NDK supports C/C++ with OpenGL ES 2.0, so is iOS. (iOS supports C/C++ natively as well as objective-C). So sure.. no problem...

And to make debugging easier, adding PC is probably good idea, I thought. I'm a MS whore, and I love Visual Studio too much for debugging. K then let's add....

3. PC

So I did some research to see if I can run an OpenGL ES 2.0 app natively on PC. There is OpenGL ES SDK from AMD, but it only runs on AMD graphics cards. (I tried it on my NVIDIA card, and yup it crashed :P) Also I heard there's an emulator from NVidia, which runs on NVidia cards only.... duh..... Different stuff for different vendors... yuck...... and what about Intel cards?... so yeah.. i gave up on this idea.

Instead, probably it's an okay idea to use pure OpenGL 2.0 on PC as long as I can be careful about not using those functions calls not supported by GL ES 2.0. Then the only difference will be the window management part. But is it really different from mobile versions which use something like GLSurfaceView? Also there are some GL ES functions which are not part of OpenGL 2.0. For those, I can easily supply my own implementations with matching function names on PC. Not a big deal.

Once PC is supported through OpenGL 2.0, other desktop platforms can be supported easily with only minor tweaks on the window management code. So extending this to:

4. Mac
5. Linux

Although I haven't looked into Windows Phone SDK, I heard it also supports native code too. So I guess it should be do-able:

6. Windows Phone

After all, it shouldn't be that far from Android. What about webbrowser side? There's a very natural choice for it:

7. Chrome Native Client

Chrome Native Client is also based on OpenGL ES2 and C++. Unity supports Linux through NaCl too, I believe?

Then I was thinking... 'uh... so for the people who don't use chrome, what's available..? oh.... i know... Flash..... but flash doesn't support native code... or does it now?' Then I did a quick web search... and apparently something came out last month...

http://gaming.adobe.com/technologies/flascc/

I didn't even know it exists... Apparently this can compile C/C++ into Flash. This one doesn't support OpenGL directly. Instead, it uses its own Stage3D API, which talks to either OpenGL or DirectX directly. Well, writing a warpper for this shouldn't be that hard... right? Another huddle I heard is ... it also uses its own shader language....... makes sense to support both OpenGL and DX... but... seriously... why do you have to be so hard.....? Luckly, there's already a converter for it. Not sure if it works well or not yet... Probably Flash is the most painful platform to support, but it might be possible.. might... and I often enjoy this kind of useless challenges.. lol.. So bring it on?

8. Flash

Well.. this is probably just a nice dream.... but once this engine is well-written.. I can make an app in Visual Studio and do all the debugging on PC... Once it works fine on PC, I can simply compile for mobile platforms and run.... yeah..... it works only in theory... Desktop versions won't be any beefier than mobile platforms: they are just there for easy debugging only, so I think it's more viable than having two very different levels of platforms...... Well, still it's just a nice dream... but still kinda wanna try it :P

Anyhoo.. I spent a quick 4 hours today to make a basic framework and managed to open a PC window and clear the screen to yellow... I'm not sure when I'll do more coding on it... If I do.. I'll try to run it on Android first. Then I'd probably support platforms in this order:

1. PC
2. Android
3. iOS
4. WinPhone
5. Flash
6. Chrome Native Client
7. Mac
8. Linux


Oh yeah...... I need a name for this engine.. right? eh.. randomly thrown name here: Pump Mini


p.s. Oh wait.. can I support Win8? maybe not....?
p.s.2. I think I completely forgot about the game itselt... I'm more excited about making this simple multiplatform engine... lol
p.s.3. I know there is cocos2d-x although I've never used it. I just wanna code some random crap as I like. :P

Goodbye XNA, Hello SharpDX

I've been using XNA since the beginning. I liked this platform a lot because it allows me to write something that runs both on PC and Xbox 360.  And it is even possible to monetize your games on Xbox 360 Indie Games channel.  However, the importance of XNA games on Xbox Live turned out to be very minimal, and MS changed XNA a lot to support Windows Phone 7.0.  From that moment, (XNA 4.0 I believe), XNA became somewhat awkward.  PC and Xbox 360 became second-class citizens, i think.

Still I used XNA quite often.  It was a great tool to prototype anything. Its contents pipeline and ability to use DirectX in C# really gave me a huge advantage to make any demo in it.  For example, I even made the demo for my SIGGRAPH presentation in XNA.

Now XNA is dead because Windows Phone 8's not gonna support it. WinRT is apparently the new winner....Also Visual Studio 2012 doesn't support XNA officially. (an unofficial way exists, but whatever?) Sure, one can still stay behind with Visual Studio 2010 and XNA 4.0, but now XNA, aftert being neglected for a while, has some limits.

• no 64-bit support
• only supports DirectX 9 (no DX11 support)

So now time to find an alternative.... The reasons why I liked XNA were:

• C# support
• contents pipeline

So I just need to find an alternative which covers these two... right?

C# Support

There are two major libraries that supports DirectX in C#, or any .NET language:  SharpDX and SlimDX. Both libraries have almost identical API, thus the usage is very similar. Furthermore, both supports 64 bit. I needed 64-bit support for my recent work, so I tried both libraries, and decided to go with SharDX for following reasons:

• SharpDX is faster (less overhead on API calls)
• it's easier to install SharpDX(simple DLL file copies)

So with SharpDX, C# support issue is covered

Contents Pipeline

Honestly, I still don't see anything that's comparable to XNA's contents pipeline yet.  Texture is not a big issue since both C# and SharpDX's DX calls support textures pretty well. When it comes to other asset types, such as audio and mesh, it's still not that easy.

One good news is that Visual Studio 2012 contains an example which loads FBX files, I heard, and I believe Microsoft will enhance this side for WinRT, if they are really betting on Windows Phone 8. So maybe it's just matter of time?

I wish I had some time to make pretty solid contents pipeline for SharpDX or something.... But by looking at my schedule for this year, I don't think I'll ever get to do it.

My Conclusion - SharpDX

So I decided to live with SharpDX for now. My main reason was the 64-bit support.  My prototype's already using more memory than what 32-bit application can handle. I'm not worried too much about textures and mesh support... For other contents types, I'll solve the problems when I need them.


Update - Jan 12, 2013
Nicolas just told me his Assimp.NET can handle some asset import/export and it's actually used by SharpDX too. So if you need an asset pipeline check it out at http://code.google.com/p/assimp-net/ Apparently FBX files are not supported yet, but since there's already FBX SDK from autodesk for free, I would think it's just a matter of time.