Sunday, April 26, 2009

One step forward, two steps back

As it turns out, the Directx Application i made is too powerful for the embedded computer at my Faculty (PC/104 system). It turns out that the module containing the microprocessor has an integrated video card with no true 3D capabilities. I am confused, because the Spec Sheets tell otherwise and I quote:

Display:
Chipset: VIA VT8606 Twister chip with Integrated S3 Savage4 2D/3D/Video Accelerator
Memory Size: 8/16/32 MB frame buffer using system memory
One thing is for sure, the DirectX function CreateDevice fails when trying to create a Direct3D device, it only works with an emulated device only suitable for small tests. It doesn't even work in software mode.

Tomorrow I will talk to my attending teacher to try to find a solution.

Monday, April 20, 2009

DirectX Front-End finished

Today I finished the DirectX front end of my project. To be honest I should have thought of this in the first place.

First of all I can now display and simulate a real sphere with the artificial horizon on it, and I can rotate it pretty easily with rotation matrices from DirectX. Let me show you a picture and then comment on it:


Here you see a background PNG image file with transparency in the middle circle. Behind it is a sphere with a texture of an horizon wrapped around it.

Now, in DirectX or any other Graphics Engine API, the transformation of objects in a scene is done using Transformation matrices, for example: Translation, Scalling or Rotation. The last one is the one we are interested in, and since we normaly can move in 3-Dimensions, then it is normal that we have 3 kinds of Rotation Matrices, one for each axis. To combine the effect of any transformation matrices you just have to multiply them in the order you want them to take affect.

Therefore it is now standard arithmetics to convert the reading from the Accelerometer (3 Voltages for 3 axis of movement) to 3 Rotation Matrices which multiplyed give the relative position of the accelerometer board.

I now must add a CALIBRATE button to the scene, to remember the normal horizontal position, and implement an .ini file system for the hardware configuration. Wish me luck!

Monday, April 13, 2009

Agony and pain

During these last few days I began to write the computer frontend of my Artificial Horizon application, using MFC. It has proven to be the worst decision I made since the beginning of this project. I am using Visual Studio 2008 and MFC 8.0 and I thought that Microsoft had improved the stability of MFC applications, but I was wrong. It is incredibly buggy, and the IDE seems to work against the programmer. Every time I added a header file, I had to restart Visual Studio to update IntelliSense, if I deleted a simple editbox from the Resource View I had to manually delete all the references that were automatically added at creation and so on.

The PictureBox control of MFC only allows to display BITMAPS, and I need to be able to display PNG image files with transparency. After an extensive search on the net I learned that I could use CImage, which is an ATL template. It is capable of displaying PNG files in an MFC dialog. I easily wrote a test program, it worked fine at first glance, but after closer inspection I saw that the transparency did not extend to the picture beneath the first PNG, but only to the background color of the CImage control. Another dead end!!

Then I wrote a simple program in a Windows Forms project, which is normal Visual C++ combined with .NET. I managed to get the desired result from the use of it's PictureBox control, but the drivers for the PC/104 platform generate 240 errors at compile time...

I closed the programming session, before I exploded... After cooling of I found a possible solution, and that is to use DirectX.

I will make another post when I have some progress with DirectX.