Impossible?

The sorry state of symbian SDL

Probably noone of you care about the fact that there are four different versions of the SDL library for symbian based devices. When I was starting my S60 OpenTTD port there were only three. What has happened in between?

The first one was created by Hannu Viitala and was targetted at antique devices, had no sound support, etc... we're not that much interested in it.

The second one, maintained by Marcus Mertama, is an evolution of the previous, with support for S60 3rd edition devices (basically anything worth considering for purchase right now), sound and a lot of problems. More on that later.

The third one is, again, based on the previous one. It's used by anotherguest in his ScummVM port and focuses on wide device range support (including UIQ, touch screen, etc). Since it had the same problems as the second version, I didn't looked too deeply into it.

The fourth option is constantly fixed (or rather stripped down from features) by yours truly. There were several issues in Markus' version which really bothered me.

The first was support for S60v1 and S60v2.

• If I'm going to modify the code, I have no way to test if the code works.
• The platform is severely limited by screen resolution, processor speed, available RAM, lack of Open C and Open C++ or even by inability to use static variables.
• The platform is dead.

So, drop it. Leave only S60v3.

The next big issue was resolution support. Or rather lack of it. The game resolution was always stretched to the phone's display resolution, which resulted in something that can be seen on the images below. The left one is original, the right one is scaled one. Horrible. And barely playable, thanks to ultra slow symbian blitting procedures.





My version does it right (or rather should be doing, I didn't actually checked it) by setting the right display orientation and by not stretching the display. This is one of things where my and other authors views differ. I don't accept the scaling, Marcus and anotherguest say that users prefer when game is displayed on full screen, without borders.

Another big issue, display orientation support. All S60v3 devices can either be in portrait (normal use) or landscape (think "camera") mode. On most devices the landscape mode is hidden from user during normal usage, but there are devices, like N95 or N82, which rotate the display when user physically rotates the phone. On phones that lack this feature, orientation support can be faked in software by using small drawing hacks. So consider this: phone is in portrait orientation, user runs application and sees something like that:
"Oh, display is not distorted, I can rotate the phone and play, how nice" he thinks. And most of the time he's correct. But when he has that new and shiny N95 this happens:
The phone has switched orientation to landscape, the application didn't follow. MAJOR FAIL! My SDL version correctly handles such situations:

Marcus writes on his site that his SDL allows "S60 programming without pain of Symbian!" This is completly untrue, as Marcus promotes the use of symbian-ridden CSDL class, which more or less requires some arcane knowledge. And when we're at it, just look at the documentation. There's a plethora of bells and whistles to enable or disable, only you don't have the slightest idea which option does what and some of them are there just because they can be. Take virtual mouse cursor for example. I doubt it was used anywhere (not in C2Doom for sure) and my experiences with OpenTTD, which is a mouse-driven game, has proven that it's completly unusable.

The amount of such undocumented or useless features only makes the code harder to read (oh, you don't want to look at it; 5 different coding styles in just 20 lines of code), without giving any profits, so the most sane option for me was brutal removal. So long, virtual mouse cursor, bye, various display modes, adiós console view, пока display overlays. You won't be missed. Such Reduction Of Useless Features not only makes the code easier to read, but also reduces the number of potential bugs and makes adding new (but this time usable) features less daunting task.

Of course, the library is still not finished (will it be ever?). Despite the fixes mentioned above and all the smaller ones, like fixing palette animation, making sound play smoother, there's still a lot of work to be done before I will be able to just get some random game using SDL and compile it for my phone without much ado. But even with having that said, my SDL port is The Best* symbian SDL version currently available.

* for me.

Symbian FTP Server

Sending and receiving files from Nokia devices is a major pain in the ass. Basically you're in a lose-lose situation.

Option one: send files using USB cable and mass storage mode. It's fairly fast, but your PC only has access to the memory card and you're locked out from using anything that's not installed in the phone memory. And that's an optimistic scenario. In case of some devices, like N73 for example, you can't use the phone at all!

Option two: send files using USB cable and Nokia PC Suite. It has the speed advantage of previous option and doesn't prevent you from using your phone, but the PC Suite is so crappy I won't even talk about it.

Option three: send files using bluetooth obex file transfer (or whatever it's called). The major advantage here is the lack of that damn cable which restricts mobility when you want to use your mobile (nyah, nyah) device. And you won't be hiding under your table wanting to select some options, just because the USB cable is so short. OK, now the bad side. Firstly, your transfer rate is limited to, like, 120KB/s. In areas with lots of EM pollution you may not be able to go over 40KB/s. And that whole client problem. You have some proprietary clients under windows, some are crappy, some are rather good in some places, but still cumbersome in others. On linux it's tragic. You have some command line mumbo-jumbo requiring lenghty man-page reading, editing /etc/fstab, using commands like dfutool, rfcomm, pand (WTF?). There are some GUI clients, but, as usual, they suck badly. kdebluetooth for example. Oh, I won't work because you have wrong version of this, oh, I won't work because you want me to do that, oh, KDE4 is there for half a year, but obex file transfer is not yet supported. And even if it does work, it's a major pain in the ass to use, as it tries to establish new bluetooth connections every other second. Move file from disk folder to bluetooth folder, wait for the actions popup to appear, oh, it didn't, try again, now it did, but after selecting the copy operation the connection just timed out. So try again, go to to the sending the file part successfully only to fail yet again because for some obscure reason the file just wasn't sent. So try again, and yes, success! All this shit only because I wanted to transfer my fucking holiday photos to PC! Why can't it be simple and just work?
In case someone wonders, it's all based on my experience.

To get back on the topic: there's also possiblity of html download, sending files using Skype client, but all this requires too much constant setup effort to be actually usable.

So, enter the Dumb FTP Server, or dftpd. The first FTP server for S60v3 devices. It's in alpha state, it can crash a lot, it doesn't support that many FTP commands, some may be misimplemented and cause problems with one or two FTP clients, but here's the catch: it does work (and doesn't corrupt the files you transfer).
To be able to use it you'll need wifi capable device and (for now) a memory card. To be able to log-in after starting the server and selecting the access point you will need to either disable authentication (any user and password will do, very insecure) or generate an one-time token that is presumably only known to you and which will be invalidated after successfully using it as a password (any username is accepted).
Attainable transfer rates are:

• 700-800 KB/s for upload
• ~350 KB/s for download

I don't think that upload will get any better, but there sure is some space for download optimizations.

How to get it:

1. Download Open C library and install it, in case you don't have it already.
2. Do the same for Open C++ component.
3. Download the server and install it.

You might be also interested in source code. The license is GPLv2. Oh, and that icon is stolen from Tango Desktop Project.