Programming in a small software company

Monday morning I downloaded and set up the new Visual Studio on my main development system.  As a C++ developer, the new features and fixes are pushing me to migrate active projects to it. 

I’m excited to use the new C++ features.  Auto, lambda, and static_assert are my current favorites.

The What's New in Visual C++ 2010 has a list of all the new language goodies.

Qt doesn’t have a mkspec yet.  I believe that 4.7 will officially add VC 10 to the supported list, and remove VC 7.1 (sadly, since I think it was the best compiler Microsoft has released).

Last night our deployment server died.  It had been running (fairly) problem free for over 6 years.  We used it to host our internal FTP, Bug Tracking and Wiki software.

The silver lining is that we can migrate to a hosted service.  This would save us from needing to buy a new Server.  More importantly, we wouldn’t have to take care of it, manage software updates or back it up.

This would also let us move a few projects to a hosted svn server.  Our external developers would appreciate the speed boost.

I’m leaning towards using xp-dev.

Posted by mike at 08:13 AM | Permalink | Comments (0) | TrackBacks (0)

My plans for a well organized office have been thwarted by a rush project targeted at Window CE.  I’ve never written anything for CE before, and have learned quite a bit about it over the last month.

First, CE isn’t the same as Windows Mobile -- CE may be customized quite a bit for the device it is targeted at.  This makes it a little challenging to build the software; especially when the client isn’t sure what the hardware folks are doing.

Second, the “recommended” tools and SDK are extremely old (based on VC 6).  Luckily, you can use the newer tools (VC 2008) as long as you’re careful about your build settings and the System API’s you are using.

Lastly, it’s amazing how dependant I’ve become on the FPU.  This project was targeted at an ARM CPU.  These don’t typically have FPUs (though it is an option).  Most of the rendering code I write uses floating point.

It’s not that ARM processors are slow, they are rather quick and I appreciate their shifting ability – it’s that floating point is emulated with a software library.  This makes it imposable to use in time sensitive areas.

It reminds me of writing for the 80386.

So, after benchmarking the rendering code and discovering just how slow the math was, it was time to implement a fixed point library.  Years ago, when Intel was still developing their XScale, they had an optimized fixed point library for the ARM.  This seems to be long gone from the Internet – I looked for it for several hours and sent several emails to Marvell without any luck.

As it turns out, my ‘C’ fixed scale code was reasonably fast, and the VC2008 compiler did a decent job of optimizing it.  After tuning the routines to prevent over and underflows the module performed quite well.

The only magic is to use 64 bit integers to multiply and divide – if you don’t have those, it’s a lot tougher.

The result was a fast software renderer, with optional support for DirectDraw and GAPI blit’ing.  It was a lot of fun to get into “old school” software mode.

Posted by mike at 11:49 AM | Permalink | Comments (0) | TrackBacks (0)