An obvious place to start is the header files. Motif header files are found in the #include <Xm/...> subdirectories, with every Motif program using <Xm/Xm.h>. Each Motif widget has its own header file, which we have to include e.g. #include <Xm/PushB.h>. The Motif libraries need to be linked against when using these headers which is done with the -lXm and -lX11 compiler flags. Quite often gcc will complain when using these flags if the libraries are not where it expects. This can usually be fixed by adding a flag something like -L/usr/X11R6/lib.

Every Motif program is based around six basic steps:

• Initialize toolkit
• Create widgets
• Manage widgets
• Setup callbacks
• Realize the widgets
• Enter event handling loop

Initializing the toolkit can be done using XtInitialize(). This connects the program to the X display, sets up resources and creates a top level window. Usually after creating the top level window a form widget is created to place other widgets on. This can be done using XmCreateForm(). Example code:

Creating other interactive widgets (buttons, text boxes etc) can also be done in different ways but I prefer using a specific function for each widget. These functions come in the form XmCreate() and take four arguments. These arguments are the parent widget, name of the created widget, widget argument list (or NULL) and the number of arguments in the list (or zero). The widget argument list is an array containing a list of Motif resource names and corresponding value. Each entry of the list is generated using XtSetArg() Example code:

To make a widget appear in the GUI you have to manage it using XtManageChild(). As you can see from my code I tend to manage each widget as I create it. The reason for this is purely a coding convienience. Similarly you can XtUnmanageChild() to remove a widget from a dialog.

The previous example also demonstrated the use of XtAddCallback() to add a callback control for a widget. The function is very self explanatory, except for the last argument which is client data which may be passed to the callback function.

Once you have created all your widgets and handling etc the program needs to realise the top level widget and enter the event handling loop. This is done with XtMainLoop(). Example code:

And thats it! Its pretty stright forward when you break it all down. Next update will show positioning of widgets, creating file dialogs and a closer look at callbacks.
My complete source for my GUI so far is shown below.

- FIN -

You will need ...

• Dual layer DVD burner and DVD+R media
• A downloaded image (and ss.bin etc if required)
• growisofs
• imgbpatch.jar

The first hurdle comes when you realise that not all images are created the same way. Most noticable is a rip that is not pre patched with the security sector (ss.bin). It should be noted however, that most images already contain the security sector and this step should be skipped. To merge ss.bin and game.iso into a file called IMAGE.000, the following command can be used:

This will create an image consisting of 265877504 blank bytes, the security sector and finally the game image. The final size of IMAGE.000 should be 7572881408 bytes.

To actually burn the image, the iso must be made compatable with growisofs. This is something that CloneCD users do not need to do and is a cause of great confusion for those using other software. Again, many images are already pre prepared and do not require patching but unlike the merge doing so with a pre patched image will not break it. This is carried out using a neat little java app called imgbpatch.jar (catchy, isn't it?). To use it the following command can be used:

Now you have a workable image, the next step is the burn which is carried out using growisofs. There are a lot of threads around that claim only a Pioneer 111D with Verbatim +R media will work, which I have found to be complete hocus pocus. I use both LiteOn and Samsung drives with Memorex and Mr. DVD media and not had any problems.
The burn command is a very neat one and carries out everything you need. The important things are the speed (slow, to increase the chances of a solid burn), the line break (1913760 for 360 games) and the DVD compatability flag (burns DVD+R data as DVD-ROM to increase the media's compatability with non PC hardware). To do all this the following command is used:

Of course /dev/dvd can be replaced with any DVD DL drive and IMAGE.000 with any image filename. Not all DVD burners will support the speed setting but it should still slow things down e.g. on my LiteOn drive, a setting of 2 results is 4x speed!?! The burn process can take anywhere up to about 40mins.

Another handy ability is being able to verify the burn. An MD5SUM of the DVD can be calculated using the following command:

- FIN -

This is nothing unusual. Most manufactures seem to change there interpretation of the MMAPI regularly and is a constant source of irritation for developers. However a crash bug related to audio is very serious and required some investigation.

The application used a typical sound implementation that uses a single Player and a byte array of sound data. When a sound is required, the Player instance releases any previously loaded sound, loads the required sound and finally plays it.

QA reported that the crash would occur most frequently immediately before a sound was played and in particular if sounds were played very close together. Because the bug did not occur on every played sound, this immediately points the finger at either the prefetch phase or a failed deallocation, most likely due to time constraints.

I tested this theory by placing a minimum time gap between each time the player is called, with a delay longer than that of the sound being played. This seemed to work for a while but ended up only delaying how long it would take for the crash to appear, rather than remove it. Besides, this would hardly be a suitable fix!

After some investigation, it was found that the problem lay in the Player.stop() function. It seemed that calling Player.stop() immediately after Player.start() caused the crash, and the closer the two were the more likely the bug was to arise.

The fix is equally simple. By simply calling Player.setMediaTime(0) before Player.stop(), the Player is left in a suitable state to be deallocated and closed.

A simple example is shown below:

Since writing, it has been found that the following devices are also affected
Nokia 5300

- FIN -

The observed issue is that the method will incorrectly parse a sprite sheet and return an unexpected image. In the case of this application the sprite sheet was an image containing three rows of three ball, all equispaced. When any ball other than that from the top row is required, the function returns the ball from the top row directly above it. This would suggest that the y value either defaults to zero or to the value that was used when the function was first called. Either way, it doesn't work and shouldn't be used to increase portability.

A more portable method is to use a typical clipping implementation. This would involve loading a sprite sheet at initialization time and when one of the sprites is required, set the clip area at the correct size and render the entire image at an offset that positions the required sprite to be drawn in the clipping area.

- FIN -

dan le sac vs scroobius pip

When the console arrived it was immediately identified as having an Hitachi DVD drive with the 78FK bios and I couldn't resist putting to practice the recent work by Maximus. Unfortunately I later found that the 360 suffered from stability issues and tended to crash approximately every half hour (an issue unrelated to the flash). My first suspicion was that heat was the problem (it is also known that the power supply or even live updates have been causing some people issues) and with my warranty still warm and lying in tatters on the floor, I set about looking for third party solutions.

An obvious start is to remove the poor quality thermal compound that Microsoft use and replace it with a high quality counterpart e.g. Arctic Silver. Secondly a simple drop in replacement for the (in my opinion) under powered fans is an easy upgrade to perform. I choose the Talismoon Whisper Fan (in green).

These simple modifications did show a small improvement in both noise and airflow, however provided only a 2-3 degree drop in CPU and GPU temperature when under heavy load.

Next I decided to modify the stock fans to run at their designed 12v instead of the 6v supplied by the 360. This is done by removing the two positive pins in the fan's plastic power block then connecting the wires together and to a 12v supply. There are plenty of good 12v spots on the 360 motherboard to use but be careful when choosing one to make sure the supply is cut when the 360 is turned off - not all of them do.

This modification had two extreme effects. Firstly the noise from the fans is unbelievably loud. And I don`t mean 'the 360 is so loud in comparison to the PS3' loud, I mean Harrier Jump jet loud. And secondly, the temperature drop is equally unbelievable. At idle both CPU and GPU temperatures were way below room temperature and under load there was not much change. more accurate numbers to follow

Unfortunately even this impressive temperature drop in both core and case temperatures had no affect on the stability of my 360. And even more unfortunate for me, it was about this time that my original 360 finally buckled and I got my first taste of the 3 lights of death. I think the modified 360 will be going to GT electronics in Dundee to get fixed, however I`m tempted to try and bring the RoL 360 back using the heat gun technique ... updates to follow.

- FIN -

What was observed on the application was a failure to display any special characters typically seen in French and Spanish text. Instead these (and often the next) characters were missed out.

The application used an InputStream to create an instance of InputStreamReader and parsed the text into a StringBuffer.

This already is a little unusual as there is no need to create an instance of InputStreamReader as InputStream provides all the functionality needed. InputStreamReader is only required when a stream of bytes are required to be translated into characters according to a specified character encoding.

Unsurprisingly this is the cause of the issue and by simply removing the InputStreamReader instance the bug is fixed. Another method to add to the list that should not be used for portability!

Since writing, it has been found that the following devices are also affected
LG KU950

- FIN -

After much sole searching I found I just couldn't use Visual Studio Express. Despite being free I just found it counter productive to install a second (and in my opinion, inferior) IDE to fulfill a single task. So I set about looking for a way to tie Eclipse and GLUT together in a way that would suit me (i'm not going to get into alternatives to GLUT just now - suffice to say this is the OpenGL toolkit I prefer).

The following is a guide to demonstrate how simply Eclipse can be configured for OpenGL development.

1. Install Eclipse
I have assumed that if you are reading this tutorial, then you are already an Eclipse user. If not you can download the latest build on the Eclipse download page. At time of writing I am using Eclipse SDK 3.2.2.

2. Install Eclipse C/C++ Development Tooling (CDT)
This plugin is accepted by most as the best C/C++ solution for Eclipse, and I agree whole heartedly. Installing the CDT plugin is the same as most other Eclipse plugins and does not need to get covered here. A plugin installation guide can be found in the Eclipse Documentation.

3. Install W32 gcc Compiler and Tools (MinGW and MINSYS)

• Download the current WinGW and MSYS distribution from the MinGW download page.
• Run MinGW-x.x.x.exe. I recommend using the current packages and installing at least 'MinGW base tools', 'g++ compiler' and 'MinGW Make'. Be careful not to install to a path containing spaces.
• Run MINSYS-x.x.x.exe. When asked, be careful to fill in the path to MinGW correctly using forward slashes (/).
• Add the bin directory of both MinGW and MINSYS to the PATH environment variable. e.g:
  ';C:\msys\1.0\bin;C:\mingw\bin'.
• Open a command prompt and test the installation with the following commands:
  make --version
g++ --version

4. Install GLUT for MinGW

• Download and unzip glutming.zip
• Copy glut32.dll to '\Windows\System32' folder. This is the glut library and allows glut built openGL applications to run.
• Copy glut.h to '\MinGW\include\GL' folder.
• Copy libglut32.a to '\MinGW\lib' folder.

FIN

Creating a project

1. Start Eclipse and create a new project of type 'Managed Make C++ Project'
2. Add the GLUT libraries to the project in the Project Properties page (Project -> Properties)
• Select 'C/C++ Build'
• Select 'Libraries' under 'GCC c++ Linker'
• Click the add entry icon and add the following entries
  glut32
glu32
opengl32
• Accept the changes and return to the project
3. Create a new source file (File -> New -> Other... -> C++ -> Source File) with the extension '.cpp'
4. Copy and paste the following source code:
   
   #include <windows.h>
   #include <gl/glut.h>

   void render(void)   
   {
       glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
       glLoadIdentity();      
       glTranslatef(-1.5f,0.0f,-6.0f);
       glBegin(GL_TRIANGLES);
           glVertex3f( 0.0f, 1.0f, 0.0f);
           glVertex3f(-1.0f,-1.0f, 0.0f);
           glVertex3f( 1.0f,-1.0f, 0.0f);
       glEnd();   

       glutSwapBuffers ( );
   }

   void reshape(int w, int h)
   {
       glViewport(0, 0, w, h);
       glMatrixMode(GL_PROJECTION);
       glLoadIdentity();
       gluPerspective(80, (float)w/(float)h, 1.0, 5000.0);
       glMatrixMode(GL_MODELVIEW);
       glLoadIdentity();
   }

   int main(int argc, char** argv)
   {
       glutInit(&argc, argv);
       glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE);

       glutInitWindowSize(500, 500);
       glutCreateWindow("GLUT Test");

       glutDisplayFunc(render);
       glutReshapeFunc(reshape);

       glutMainLoop();
       return 0;
   }

5. Save the file. This automagically triggers the compile process. No errors should be reported and an exe file produced. When run a windows with a white triangle should be seen confirming the installation was a success.

- FIN -

During compatibility testing an issue was occasionally reported among a variety of applications regarding the left soft key becoming unresponsive. This is normally a very rare bug to find as all key groups (numerical, directional and softkeys) are treated the same in most application and each group either all work, or all don`t. After some investigation by QA a finger was very quickly pointed in the direction of the SMS reader application.

It did not take long to realize that the issue lay in the calling of keyPressed and keyReleased. A small test application later and it became apparent that the underlying OS was hogging the LSK looking for an extended key press so it could start the SMS reader. The result in the JVM was that keyPressed and keyReleased were being called on the same tick, so in the application nothing happened.

The fix is to detect if keyPressed and keyReleased are called on the same tick when the LSK is pressed. If this condition occurs, keyReleased returns to allow the application to detect and handle the key press. A tick counter is something that many applications have and is handy to fix such bugs. An example is shown:

- FIN -

Internet Explorer              filter: alpha(opacity=50);
Mozilla                        -moz-opacity: 50%;
CSS3                           opacity: 0.5;

For compatibility it is recommended to use all three.

The problem with this is consistency. If a div is created with it's opacity set to 50% using the mentioned methods, different browsers produce different results. Mozilla browsers (rather annoyingly, correctly) apply this opacity to all child elements within the div. So any text, images or even scroll bars are also set to 50% opacity. This is true even if you try to apply an opacity of 100% to these child elements. This is because the 100% you apply to them is 100% of the 50% they currently have. Internet Explorer does not suffer from this and although more desirable, is not consistent with the CSS definition. A new solution needed to be found with the following requirements:

• Works on both browsers (IE and Mozilla being the most common browsers visiting the site)
• Does not suffer from the 'child inheritance' problem
• Has no noticeable negative performance impact

The solution I came up with lay in the PNG image format. I wanted to use a 1x1px image of opacity 30% and tile it across the div as its background. This would give the same result at setting the opacity of the div but without using the CSS properties and having the child inheritance problem. However PNG has it's own issues with support in Internet Explorer which requires a work around supplied by Microsoft. So to set the background image of a div to a PNG file, the following can be used:

Mozilla            background-image: url(box_bg.png);
Internet Explorer  filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled=true, sizingMethod=scale src='box_bg.png');

A final problem with the Microsoft fix in Internet Explorer is that if the standard (Mozilla) method is also included in a div, then the incorrectly rendered PNG image covers the fixed one. To get past this you can exploit Explorers lack of support for attribute selectors. This allows you to place the Explorer fix in the div (which Mozilla will ignore as it is an Explorer filter: attribute) and the Mozilla method in an attribute selector for it (which Explorer doesn't support).
The final div CSS is shown below:

Unfortunately this is still far from a prefect solution. Should Internet Explorer support attribute selectors in the future, then we are back to the background cover up problem. We can only hope that Microsoft sorts out its PNG problems before this ... or, perhaps all browsers will finally unite in their interpretation of opacity in CSS3 and allow the designer to decide if child elements inherit their parents transparency. We can only hope.

- FIN -