The Mac version of SimCoupe started with the 48×48 Windows XP icon scaled up to 256×256, which looked very out of place along side the 3D icons used by other applications. I wanted a decent new icon for the SimCoupe 1.0 release but didn’t have the artistic talent to draw my own. Rendering a 3D version seemed the way to go, so I downloaded the free Blender package and got started.

Creating the basic robot shape wasn’t too difficult, with simple hemispheres for the head, body and feet. The eyes and aerial were bezier curves pulled into shape and then filled. I was lucky enough to find a hand model in an animation tutorial, which saved me a lot of work creating my own.

The neck, arms and legs were created using the screw tool. However, the arm segments were straight and needed to hang out from the body and round to the hands. Getting them to curve took weeks of experimentation, but was eventually solved using armatures. Inserting bones into the arms meant I could bend them to the shape I wanted in pose mode, with inverse kinematics (IK) doing all the work. It’s not perfect, with a few kinks visible if you look closely, but it’s good enough!

To ensure the robot was symmetrical I built only the left half, with the right half created by cloning and mirroring it. The images below show the left half as wireframe and filled, and the completed robot in wireframe mode. (click for full size):

The final step was lighting, and I found another tutorial to help with that. I used standard positions to evenly light the scene, knowing they could easily be changed later to fit any user interface guidelines for icon lighting. The render took only a couple of seconds, and was saved out as a PNG image, preserving transparency where needed.

Here’s the final 256×256 image:

At this point I created the Mac icon, importing directly from the PNG render to create the .icns file. For the Vista version I needed to merge the new icon into the existing SimCoupe icon file, so the OS could choose which one to use. XP wouldn’t recognise the new format and fall back to using the original smaller versions, which was perfect.

Rather surprisingly Vista uses the PNG format to store the new icon images in the file, and for a 256×256 32-bit image that meant a huge space saving compared to the old format. This downside was that none of the existing tools would recognise the new icon format, and that included the resource compiler used to build the SimCoupe executable! A 3rd party tool (ReplaceVistaIcon) came to the rescue, allowing the new icon to be injected into the executable after the build.

Here’s how the new icon compares to the original 48×48 XP icon, using Vista’s large-icon view (click for full size):

Vista doesn’t use the new icon for everything though, falling back on the old icon in some situations (including the task list). Hopefully that’s something I can improve as I learn more.

1. Avoiding touching the primary display surface

   SimCoupe uses a video overlay surface for the SAM display by default, which gives the best performance on old video cards. For this I must determine a colour-key value where overlay pixels should show through to the display, like green-screen special effects used on TV. This meant locking the primary surface to peek a pixel value, and that’s something Vista wasn’t happy with me doing.

   In previous versions of Windows the primary display surface was what you saw on your screen, and where most objects were drawn directly. Vista’s Aero interface uses off-screen compositing for its fancy scaling and transparency effects. The visible display is managed by the compositing engine and is off-limits to direct manipulation. Any attempts to do so disables the Desktop Window Manager (DWM), returning the display to a compatibility mode. As part of this it also rather unhelpfully reports: “This program is not compatible with Windows“!

   Video card overlays don’t really fit into the new composite world anyway. They can be scaled, but they can’t be rotated or skewed, and don’t support transparency. The DWM can’t make any use of them, so there’s little point in us trying to use them – problem solved!

   SimCoupe no longer attempts to create a video overlay on Vista, and to avoid any confusion I also grey the setting in the options used to toggle it on and off.

2. Avoid querying the capabilities of the primary display surface

   This is related to the first issue, but shouldn’t have been a problem at all. I found that simply querying the capabilities of the primary surface (using GetSurfaceDesc()) was enough to disable the DWM.

   This was confirmed to be a Windows bug in beta 1, scheduled to be fixed in beta 2. In the meantime I changed my code to work around it, using the required capabilities from the back surface instead.

3. Double-checking the main window is the correct size

   The partial scanlines on the boot screen were showing a banding effect, which happens if the main window is resized to non-multiple of the natural display size. Further investigation showed the main window size (as set using AdjustWindowRect()) was slightly too small.

   This was yet another Windows bug, and not one I found documented anywhere! The size calculations didn’t seem to be including all the extra window decoration and the larger Vista borders were throwing it out. This just required a second size adjustment in SimCoupe if the first one was found to be wrong. This problem affected other programs that required an exact display size, which was mainly other emulators.

These changes were the bare minimum needed to run the program correctly under Vista. True Vista support will require additional changes, almost all related to the tightened security model. More about those in a future update.