|
|
Plug-In :
An arts coucil technology residency
Introduction |
Research |
Project Stage 1 |
Project Stage 2 |
Project Stage 3 |
Results & Links
Project Stage 1
I chose to work in C++ and use the Nokia Series 60 sdk, the symbian sdk and the EPOC emulator. The Initial Target device is the Nokia 3650. Applications that are validated on the emulator can be recompiled for the ARM cpu on the symbian device. The resulting application is then packaged into an installation file (.SIS) which is then transferred via bluetooth to the target device. During the research stage I have investigated the following areas of programming that are of key importance to the project.
1. Graphics
The 7650/3650 have a resolution of 176x208 and a 12bit Display (grouped 444). It is tricky but not impossible to access the screen buffer directly and perform per pixel operations. Unfortuanately there is no floating point processor and emulation in Symbian runs very slowly. The graphics engine supports sprite masks and different source bitmap depths.
2. Sound
The chosen system supports the playback of .wav (wave) audio files. However these files can become quite large (particularly if recorded at high quality) and can bloat the size of the final appliaction. The Nokia Symbian sdk also supports playing of sine based tones however these functions do not support any level of synthesis for generating complex sounds. It seems that the use of small wave files would suit the requirements of the Operating system better. The OS does not have a timer with decent accuracy (1/64th of a second is the best you'll get), so accurate audio quantization may be difficult to acheive.
3. Control
Control is a major problem aspect when developing for mobile platforms. Primarily designed as a communication device mobile phone keypads operate digitally (as opposed to discrete analogue controllers) and respond better to repeated presses rather than keys held over time. To add to this issue different devices have different key layouts, to account for this an application must implement a simple but flexible control method. Such a method should only involve a minimum amount of keys and not require absolute precision from the user.
Conclusion
Although further research would be beneficial it is obvious from the initial findings that the Symbian platform offers a familiar programming system and (for a mobile device) a powerful graphics engine. The issue with control would be a problem when writing for any mobile device (except one specifically designed to play games GBA for example) but a simple and elegant solution should be defined (with a minimal set of keys). In terms of sound the application may have to deal with unstable timing but there is a possibility to use MIDI instruments in order to reduce filesize (only supported on the 3650). All these concerns will be taken into account when defining a technical & design document for the chosen project idea.
Setting up for compilation
This is further complicated by the fact that symbian applications often use resource files that have to be in the right path of whichever system you are using. The SDK demonstration applications come with a few batch files (.bat) which extract/copy and compile demo applications to the correct locations. There are several versions of these batch files, one for each OS (WINS,Armi and Thumb).
Unfortunately this can lead to tedious long paths such as
C:\Symbian\6.1\Series60\Epoc32\BUILD\SYMBIAN\6.1\SERIES60\SERIES60EX\HELLOWORLD\GROUP\HELLOWORLD\WINS
These hold the workspace project files ( I am assuming Visual C++ is the compiler). These project files reference source code in a seperate (higher) part of the tree
C:\Symbian\6.1\Series60\Series60Ex\HelloWorld
This can make it difficult to keep track of which files are current and makes backups difficult.
I found it easier to create a single directory to contain both the project files and the source code (including resources). Backups are easier to make and files are more readily accessible.
You can change the actual compilation directories too if you like but since you never need access them (they just contain compiler link objects etc) you can leave them as part of the symbian build subtree.
Now you should be able to compile and test on the emulator easily.
If you want to compile for the target device you must do so from the command line compiler (Visual C++ wont compile for anything other than the WINS windows platform). You can execute a 'abld build armi urel' command from the dos prompt (you may need to check the path in abld.bat is correct) or create a batch file to run this for you. This will generate your target specific application in the appropriate directory (the ARMI subset of the symbian tree for instance).
\Symbian\6.1\Series60\Epoc32\release\armi\urel\testapp.app
Now this compilation destination is the path you should use in your package file, when you want to make up an installation file for the target device (.sis)
Example pkg instruction: (copy from PC to .sis and then install to target location)
Again I found it easier to make a batch file to do this work for me. This means I do all testing and emulation development in Visual C++ without using command line tools. When I want to compile and load to the device I can just run a batch file that compiles the code to the Symbian ARMI release directory and then run a second batch file that uses those files (via a pkg file instruction) to create a resulting .sis file. Both batch files (and pkg file) reside in the same workspace directory. The final .sis file can be easily uploaded to the target device using bluetooth or infared e.t.c.
|