My Windows/Linux world has gotten a whole lot more complicated in the last few days, but I'm really liking how it's set up now.
As I mentioned in my blog entry on multi-target Makefiles, I am using Fedora 11's mingw cross compiler along with gcc's multilib support and am building the little C++ project I'm working on at work for both 32 and 64-bit Linux as well as Windows all in the same Makefile and all on every build of my CDT project. That is extremely handy and I've already fixed a problem early where there is a mismatch between the linux and mingw environments, no strndup on mingw, and was able to do so without switching machines.
This is awesome and I'll be able to produce executables for all three of these platforms for testing all in one shot. Kudos to the Fedora folk for providing first class support for mingw cross compilation and not ignoring the fact that us developers still need to target Windows once in a while. That makes Fedora my favorite development environment by far.
But, alas, Linux drivers suck for laptops. I have a Dell and a port replicator at work and at home. I have a 24" monitor at work running at 1900 wide and a 22" monitor at home at 1680 wide. I swap between the two every day, and often work undocked at home with no external monitor. I could never get Linux to recognize when I dock and to figure out which monitor was hooked up. That drove me nuts.
A couple of things have also happened recently. I've been testing the Windows 7 RC on a separate partition and have started to really like it. As a lot of people have mentioned already, it's what Vista should have been. It doesn't quite have the flash of the Mac, but I find it's a great balance between flash and the stability of XP.
The other thing that happened was that VirtualBox 3.0 has been released and it now has OpenGL support for both Windows and Linux guests. That was one of the reasons I moved to Linux, to experiment with OpenGL there. Now I can do that in a guest OS.
So putting all that together, I've replaces OSes yet again (been doing that regularly for years it seems). I'm now running on 64-bit Windows 7 with two major VMs, one for my fabulous Fedora dev environment, and one for the corporate XP environment I used to have there for Outlook and Netmeeting. So far so good. I get the odd glitch once in a while but nothing I can't recover from and it is a release candidate. But now I have the best of all worlds. Except maybe MacOSX, and an iPhone dev environment. So close...
Friday, July 03, 2009
Sunday, June 28, 2009
Understanding the Mobile Killer App
Clearly, with the success of iPhone and Blackberry and the buzz around Android and Pre, mobile already has its killer apps. But for someone new like me to this arena, I find it important that I try to understand what that app is and simplify the category so I can know where to focus what little time I have to play here. So this is what I've come up with, and I hope you have an opinion you can share in the comments to help guide me.
Here we go. I actually think there are two killer apps happening in the smartphone market today. (I'll leave out the *book platforms for another post as that's starting to gel in my mind as well). Start by looking at the iPhone, including the iPod Touch. It's really Entertainment apps that have made the iPhone one of the most popular mobile platforms of our time. My son has a Touch. He has his mp3's there, he watches YouTube videos there, he plays games on it. It's probably what the PSP should have been if it had downloadable content. The platform pretty much comes with good multimedia apps, so if you want to make a hit, writing a good game is the place to start. And looking at most of the other platforms, especially the ones with 3D hardware acceleration, this is true across the board. Actually, you look at the real big picture, good games are popular on all computing platforms, even Spacewar! on the PDP-1.
The other killer app is something a we talk lot about in the Eclipse community, especially my enterprise brethren. And that is thin web client apps. This is most obvious on the Blackberries that almost all business managers have today. Accessing e-mail from an exchange server on a small screen requires specialized software to ensure a good user experience. But I really think it goes beyond just e-mail. There are a lot of web services available in web browsers today. But web browsing on the small screen still sucks and likely will always suck. Writing a thin client that can present information from the web in a format suitable for the form factor is a real winner. The top Android apps I use are clients for gmail, twitter, and RSS. I'd love a good app that lets me write this blog, but I haven't found one yet. But I know the Google provides the API to do it and Twitter has a good API. Wrap those together and you got a customer. Or maybe I should be the developer ;).
Of course, now I'm torn. I've always dreamed of making games, but never had the opportunity to do it. I know it's a lot of work and probably something I couldn't do well in my spare time. I'm also pumped by the "mash-up" possibilities writing thin clients for internet apps. And that's probably something I can do more quickly. Lots of fun. And a reason why I think the industry is going through a reinvigoration. Where the killer app for the desktop has come and the shine has gone (that killer app was office apps, browsers, IDEs, and games by the way). There's an opportunity to get in on the ground floor of the new generation.
Here we go. I actually think there are two killer apps happening in the smartphone market today. (I'll leave out the *book platforms for another post as that's starting to gel in my mind as well). Start by looking at the iPhone, including the iPod Touch. It's really Entertainment apps that have made the iPhone one of the most popular mobile platforms of our time. My son has a Touch. He has his mp3's there, he watches YouTube videos there, he plays games on it. It's probably what the PSP should have been if it had downloadable content. The platform pretty much comes with good multimedia apps, so if you want to make a hit, writing a good game is the place to start. And looking at most of the other platforms, especially the ones with 3D hardware acceleration, this is true across the board. Actually, you look at the real big picture, good games are popular on all computing platforms, even Spacewar! on the PDP-1.
The other killer app is something a we talk lot about in the Eclipse community, especially my enterprise brethren. And that is thin web client apps. This is most obvious on the Blackberries that almost all business managers have today. Accessing e-mail from an exchange server on a small screen requires specialized software to ensure a good user experience. But I really think it goes beyond just e-mail. There are a lot of web services available in web browsers today. But web browsing on the small screen still sucks and likely will always suck. Writing a thin client that can present information from the web in a format suitable for the form factor is a real winner. The top Android apps I use are clients for gmail, twitter, and RSS. I'd love a good app that lets me write this blog, but I haven't found one yet. But I know the Google provides the API to do it and Twitter has a good API. Wrap those together and you got a customer. Or maybe I should be the developer ;).
Of course, now I'm torn. I've always dreamed of making games, but never had the opportunity to do it. I know it's a lot of work and probably something I couldn't do well in my spare time. I'm also pumped by the "mash-up" possibilities writing thin clients for internet apps. And that's probably something I can do more quickly. Lots of fun. And a reason why I think the industry is going through a reinvigoration. Where the killer app for the desktop has come and the shine has gone (that killer app was office apps, browsers, IDEs, and games by the way). There's an opportunity to get in on the ground floor of the new generation.
Friday, June 26, 2009
Android NDK Release 1 is Out
I got a surprise today (aside from the passing of Michael Jackson), the Android Native Development Kit (NDK) team has put out its first release. They never really hinted on their mailing list this was about to happen, nor did they actually provide a real time line. But it's a good surprise.
The purpose of the NDK is to provide the ability to write native libraries that the Dalvik Java code can call through the Java Native Interface (JNI). This is the exact same interface we're used to with desktop JNI so it's quick to use. As I've mentioned here before, writing native code allows you to take advantage of the underlying hardware that Java hides from you. In this first release, it's pretty basic, exposing only a few basic APIs such as the standard libc C run-time library, the math library, and libz for accessing compressed files. Just enough to accelerate some of your algorithms with direct execution by the CPU, which is ARM only right now.
There is still a lot missing, and they have promised there is more to come. OpenGL ES and audio are the big items on my wish list. At least I have enough information to be able to set up OpenGL ES so that it'll run on my HTC Dream phone and the emulator. But there are no guarantees it will run on any of the upcoming phones since the ABI hasn't been locked down. The GLES shared library name is the biggy (e.g. PowerVR as seen on the TI OMAP chips names their libs differently) although the header files should be the same.
The build system, though, has me very concerned. They've taken a lot of the concepts from the Android platform build system, which builds everything in one tree, and brought it to the NDK, including the restriction that everything has to be in one tree. I don't build software like that. I put my native code in the same Eclipse project directory as the Java. I'm also working on a library that I want to use in a number of different platforms as mentioned in my previous entry. Android is just one target, it's not the center of the universe.
I also noticed this when I took a look at Moblin. There is a standard way you setup a gcc cross-development environment. GCC has the facility to define a sysroot that organizes include files, and libraries in a natural way. And that allows for multi-target projects with very little change to your makefiles. Don't assume you're the only build system that wants to build my code.
One final nit, the Windows toolchain was built using Cygwin. Cygwin is a Linux emulation environment for Windows. As such it tries to hide as much of the Windows environment as it can, in particular when dealing with file paths. That messes up the CDT. We have some code that tries to deal with that, but the architecture is poor and we may loose that functionality over time. I'm a big fan of CodeSourcery and these guys are masters at building toolchains for multiple targets and run cleanly on Windows without Cygwin. Mind you, I'm pretty much solely on Linux now so that doesn't matter to me as much any more. But others in the community will care.
Anyway, besides all that, it's a great start. Native development and standard native APIs will be a key success factor for Android. We saw in the game console market how important it was for game developers to be able to target multiple platforms. That larger market allows for larger budgets which, of course, allows for better apps. The Apple guys get that and the iPhone SDK is very good, and at least for 3D Graphics and Audio, very standard. John Carmack of id (Doom and Quake) is a huge fan of theirs, but I wouldn't mind seeing Doom titles running on my Android phone.
The purpose of the NDK is to provide the ability to write native libraries that the Dalvik Java code can call through the Java Native Interface (JNI). This is the exact same interface we're used to with desktop JNI so it's quick to use. As I've mentioned here before, writing native code allows you to take advantage of the underlying hardware that Java hides from you. In this first release, it's pretty basic, exposing only a few basic APIs such as the standard libc C run-time library, the math library, and libz for accessing compressed files. Just enough to accelerate some of your algorithms with direct execution by the CPU, which is ARM only right now.
There is still a lot missing, and they have promised there is more to come. OpenGL ES and audio are the big items on my wish list. At least I have enough information to be able to set up OpenGL ES so that it'll run on my HTC Dream phone and the emulator. But there are no guarantees it will run on any of the upcoming phones since the ABI hasn't been locked down. The GLES shared library name is the biggy (e.g. PowerVR as seen on the TI OMAP chips names their libs differently) although the header files should be the same.
The build system, though, has me very concerned. They've taken a lot of the concepts from the Android platform build system, which builds everything in one tree, and brought it to the NDK, including the restriction that everything has to be in one tree. I don't build software like that. I put my native code in the same Eclipse project directory as the Java. I'm also working on a library that I want to use in a number of different platforms as mentioned in my previous entry. Android is just one target, it's not the center of the universe.
I also noticed this when I took a look at Moblin. There is a standard way you setup a gcc cross-development environment. GCC has the facility to define a sysroot that organizes include files, and libraries in a natural way. And that allows for multi-target projects with very little change to your makefiles. Don't assume you're the only build system that wants to build my code.
One final nit, the Windows toolchain was built using Cygwin. Cygwin is a Linux emulation environment for Windows. As such it tries to hide as much of the Windows environment as it can, in particular when dealing with file paths. That messes up the CDT. We have some code that tries to deal with that, but the architecture is poor and we may loose that functionality over time. I'm a big fan of CodeSourcery and these guys are masters at building toolchains for multiple targets and run cleanly on Windows without Cygwin. Mind you, I'm pretty much solely on Linux now so that doesn't matter to me as much any more. But others in the community will care.
Anyway, besides all that, it's a great start. Native development and standard native APIs will be a key success factor for Android. We saw in the game console market how important it was for game developers to be able to target multiple platforms. That larger market allows for larger budgets which, of course, allows for better apps. The Apple guys get that and the iPhone SDK is very good, and at least for 3D Graphics and Audio, very standard. John Carmack of id (Doom and Quake) is a huge fan of theirs, but I wouldn't mind seeing Doom titles running on my Android phone.
Wednesday, June 24, 2009
CDT 6.0 Leaves the Station
CDT 6.0 is out. Come and get it!
As I posted on the cdt-dev list the other day to the CDT developers, "CDT 6 has reached all expectations I've ever had for the CDT and for that I'm proud of you all." And I mean that. The biggest new feature for me is CDT 6's new ability to find header files pretty much anywhere in your workspace. With that, the CDT search and code navigation features work almost all the time, even on code that you simply import even without makefiles. I've been using it a lot on projects like that and I continue to be amazed and proud of how well it works. It's been a great group of people who've worked on indexing over the years and after 6+ years, I can finally call it a success!
There are a few other new features that are also very handy in CDT 6. The New and Noteworthy is on our wiki at: http://wiki.eclipse.org/CDT/User/NewIn60. Feel free to take a look and try them out. The quality of CDT 6 is also very good. As the pace of new feature development for CDT has slowed over the last couple of years, we've gained in robustness so I'm proud of that as well. As I did with CDT 5.0, I can recommend using the 6.0.0 release in production, something that I wouldn't have in releases before that.
As I look over the last year or so and look to the future, I see my involvement in the CDT has taken a real hit. I do not see myself working on any big features for the CDT in the forseeable future, as I haven't really in quite a while either. That's just the reality of where I am right now and I'm OK with that. The CDT is in fine shape. Yes, there are some areas that people want to fix up, scanner discovery being at the top of that list, and I will help guide them as they need my help. But I'm going to transition my role into a CDT user who wants to contribute to make the workflows I use better. And hopefully, others will find that useful as well.
It's been a great ride with the CDT and I'm not ready to jump off yet. But there are other interesting rides that could use my attention, Android development being my personal interest area. And if you can't tell from my recent blog posts and tweets, I've been totally re-energized by what's happening in the mobile space. And, trust me, that's a good thing.
As I posted on the cdt-dev list the other day to the CDT developers, "CDT 6 has reached all expectations I've ever had for the CDT and for that I'm proud of you all." And I mean that. The biggest new feature for me is CDT 6's new ability to find header files pretty much anywhere in your workspace. With that, the CDT search and code navigation features work almost all the time, even on code that you simply import even without makefiles. I've been using it a lot on projects like that and I continue to be amazed and proud of how well it works. It's been a great group of people who've worked on indexing over the years and after 6+ years, I can finally call it a success!
There are a few other new features that are also very handy in CDT 6. The New and Noteworthy is on our wiki at: http://wiki.eclipse.org/CDT/User/NewIn60. Feel free to take a look and try them out. The quality of CDT 6 is also very good. As the pace of new feature development for CDT has slowed over the last couple of years, we've gained in robustness so I'm proud of that as well. As I did with CDT 5.0, I can recommend using the 6.0.0 release in production, something that I wouldn't have in releases before that.
As I look over the last year or so and look to the future, I see my involvement in the CDT has taken a real hit. I do not see myself working on any big features for the CDT in the forseeable future, as I haven't really in quite a while either. That's just the reality of where I am right now and I'm OK with that. The CDT is in fine shape. Yes, there are some areas that people want to fix up, scanner discovery being at the top of that list, and I will help guide them as they need my help. But I'm going to transition my role into a CDT user who wants to contribute to make the workflows I use better. And hopefully, others will find that useful as well.
It's been a great ride with the CDT and I'm not ready to jump off yet. But there are other interesting rides that could use my attention, Android development being my personal interest area. And if you can't tell from my recent blog posts and tweets, I've been totally re-energized by what's happening in the mobile space. And, trust me, that's a good thing.
Tuesday, June 23, 2009
Multi-target Makefiles
I learned a really cool trick with gnu make the other day. I've started work on a little game engine based on OpenGL and OpenGL ES targetting Android (of course), the PowerVR simulator for ES 1.1 and 2.0, as well as Linux and Windows desktops. When I first set up the Makefile, I had five different target binaries and I hooked it into the CDT as a Makefile project with five different configs that called make with the right target. Worked fine.
But switching back and forth between each of the configs in order to test an idea was a pain. The CDT does have a Build All Configs menu item but it's a pain to fire that up since it's like three levels deep. I got to digging around the gnu make manual in hopes that something would jump out and bite me to make things simpler. And, it did!
Gnu make has a couple of interesting features that help. One, you can create a multi-line macros that take parameters (define ... endef) much like the C preprocessor. You can then call 'eval' on the resulting string to have that string parsed into the Makefile. That's awesome on it's own. But, the second great feature is the ability to define variables on a per target basis. That allows you, for example, to have different CFLAGS settings for different targets.
So combining these features, I've been able to set up my builds to generate my library in five subdirectories under lib and objects under obj, all from the same sources. I tried this with a native app at work and I've also figured out how to add target specific sources to the mix. What a lifesaver.
Unfortunately, there are gotchas in CDT-land. With each source file compiled by five different compiler and option combinations, it gets pretty confused about what's what. But the guesses it's making aren't so bad and it really drives you to keep the target specifics to a minimum.
To give you an idea of what it looks like, here is the relavent fragment from the makefile for my engine right now. I also just noticed the nice way it does source/header file dependencies using -MD of the gcc compiler and gnu make's include. Now if I can get the CDT to generate me a SOURCES list automatically...
But switching back and forth between each of the configs in order to test an idea was a pain. The CDT does have a Build All Configs menu item but it's a pain to fire that up since it's like three levels deep. I got to digging around the gnu make manual in hopes that something would jump out and bite me to make things simpler. And, it did!
Gnu make has a couple of interesting features that help. One, you can create a multi-line macros that take parameters (define ... endef) much like the C preprocessor. You can then call 'eval' on the resulting string to have that string parsed into the Makefile. That's awesome on it's own. But, the second great feature is the ability to define variables on a per target basis. That allows you, for example, to have different CFLAGS settings for different targets.
So combining these features, I've been able to set up my builds to generate my library in five subdirectories under lib and objects under obj, all from the same sources. I tried this with a native app at work and I've also figured out how to add target specific sources to the mix. What a lifesaver.
Unfortunately, there are gotchas in CDT-land. With each source file compiled by five different compiler and option combinations, it gets pretty confused about what's what. But the guesses it's making aren't so bad and it really drives you to keep the target specifics to a minimum.
To give you an idea of what it looks like, here is the relavent fragment from the makefile for my engine right now. I also just noticed the nice way it does source/header file dependencies using -MD of the gcc compiler and gnu make's include. Now if I can get the CDT to generate me a SOURCES list automatically...
all: android pvr11lx pvr20lx linux mingw
define PLATFORM_rules
$(1)_OBJS = $$(SOURCES:src/%.cpp=obj/$(1)/%.o)
$(1)_LIB = lib/$(1)/libdasEngine.a
$(1): $$($(1)_LIB)
$$($(1)_LIB): $$($(1)_OBJS)
@mkdir -p lib/$(1)
$$(TOOL_PREFIX)ar rc $$@ $$^
obj/$(1)/%.o: src/%.cpp
@mkdir -p obj/$(1)
$$(TOOL_PREFIX)g++ $$(CFLAGS) -DDAS_PLATFORM_$(1) -MD -o $$@ -c $$<
-include $$($(1)_OBJS:%.o=%.d)
endef
android: TOOL_PREFIX = arm-none-eabi-
android: CFLAGS += $(ANDROID_INCLUDE) -DANDROID -fno-exceptions -fno-rtti
android: $(eval $(call PLATFORM_rules,android))
pvr11lx: CFLAGS += -m32 -I$(HOME)/gl/powervr/1.1/include
pvr11lx: $(eval $(call PLATFORM_rules,pvr11lx))
pvr20lx: CFLAGS += -m32 -I$(HOME)/gl/powervr/2.0/include
pvr20lx: $(eval $(call PLATFORM_rules,pvr20lx))
linux: $(eval $(call PLATFORM_rules,linux))
mingw: TOOL_PREFIX = i686-pc-mingw32-
mingw: $(eval $(call PLATFORM_rules,mingw))
Monday, June 22, 2009
Palm, doing open source right
I found this in a roundabout way through the Beagleboard.org blog. Palm has recently started up an open source license compliance program. They have a team that oversees it and have set up a web site, http://opensource.palm.com, where they are releasing the open source packages they used and the modifications. See, is that so hard? Well it is a significant amount of work to set something like this up, but you are getting a ship load of great software for free, so it's well worth it and by sharing your modifications really shows you as a good open source citizen.
There's been so much FUD spread over GPL and LGPL, especially LGPL. Linux wouldn't exist without these licenses. And Linux-based platforms, like the Palm Pre and Android, wouldn't be possible without them either. Neither would a fully open Eclipse CDT-based IDE for MinGW Windows, which due to the anti-GPL rules of Eclipse, there isn't. But, enough griping about that.
Palm looks like it has a hit on its hands with the Pre. I'm still awaiting to see what their SDK looks like. So far, it looks like a bunch of Javascript, much like Android is with Java. I'm currently looking at these platforms with an eye on gaming. The Pre certainly has the hardware for it. Even my little Android phone draws a mean triangle. But you need access to that hardware to get good frame rates, which for me means native code, of course.
There's been so much FUD spread over GPL and LGPL, especially LGPL. Linux wouldn't exist without these licenses. And Linux-based platforms, like the Palm Pre and Android, wouldn't be possible without them either. Neither would a fully open Eclipse CDT-based IDE for MinGW Windows, which due to the anti-GPL rules of Eclipse, there isn't. But, enough griping about that.
Palm looks like it has a hit on its hands with the Pre. I'm still awaiting to see what their SDK looks like. So far, it looks like a bunch of Javascript, much like Android is with Java. I'm currently looking at these platforms with an eye on gaming. The Pre certainly has the hardware for it. Even my little Android phone draws a mean triangle. But you need access to that hardware to get good frame rates, which for me means native code, of course.
Saturday, June 20, 2009
Android at the Ottawa Demo Camp
Well, my demo at Thursday night's Ottawa Eclipse Demo Camp was a mitigated disaster. My laptop is in power hell as the batteries last only a few minutes and, of course, started to run out during the demo. The USB connection to may Android phone didn't work and we theorized that laptop shut down the USB connections due to lack of power. So I couldn't show that. I also ran out of time which I had a feeling would happen and I forgot to add a line of code that would have prevented the app from crashing.
Aside from that, I hopefully got my point across. Eclipse is a great IDE for doing Android development. The Java side is a natural and you get all the advantages of the JDT with the target management provided by the Android plug-ins. I also showed how easy it was to set up the CDT to write native methods in your Android apps. While not officially supported, there is an Android NDK (Native Development Kit) project that is under way to provide that support in an upcoming SDK release (donut I believe).
What I didn't get to show was the two implementations of Android's Kube demo, which shows a Rubik's cube spinning around apparently trying to solve itself (being purely random, I'm sure it'll solve itself just after the monkeys write that novel). It's not a complex 3d object, with only around 3000 triangles (300 drawn 10 times per frame to give it some load), but the performance gained by writing the transformation matrix math in C++ versus Java brought the framerate from 25 frames per second to 36. That's pretty significant. And on a mobile device where every CPU cycle drains a little bit of the battery, doing more with less is a key factor to a successful product.
At any rate, I had a great time that night. I got to catch up with some old buddies that I used to work at QNX with who are now doing a start-up just down the road from our Wind River offices. And there were some old buddies there from my ObjectTime days there as well. For some reason, these Eclipse events bring us all back together. It's probably because Eclipse is huge in Ottawa. If your a tools developer here, there's a pretty good chance your involved with it. And there are some pretty good tools developers here.
Aside from that, I hopefully got my point across. Eclipse is a great IDE for doing Android development. The Java side is a natural and you get all the advantages of the JDT with the target management provided by the Android plug-ins. I also showed how easy it was to set up the CDT to write native methods in your Android apps. While not officially supported, there is an Android NDK (Native Development Kit) project that is under way to provide that support in an upcoming SDK release (donut I believe).
What I didn't get to show was the two implementations of Android's Kube demo, which shows a Rubik's cube spinning around apparently trying to solve itself (being purely random, I'm sure it'll solve itself just after the monkeys write that novel). It's not a complex 3d object, with only around 3000 triangles (300 drawn 10 times per frame to give it some load), but the performance gained by writing the transformation matrix math in C++ versus Java brought the framerate from 25 frames per second to 36. That's pretty significant. And on a mobile device where every CPU cycle drains a little bit of the battery, doing more with less is a key factor to a successful product.
At any rate, I had a great time that night. I got to catch up with some old buddies that I used to work at QNX with who are now doing a start-up just down the road from our Wind River offices. And there were some old buddies there from my ObjectTime days there as well. For some reason, these Eclipse events bring us all back together. It's probably because Eclipse is huge in Ottawa. If your a tools developer here, there's a pretty good chance your involved with it. And there are some pretty good tools developers here.
Subscribe to:
Posts (Atom)
