In addition to the driver diaries work our car simulator is taking more rapid shape. Although a large part of it has been running since last year there is always more to be done or improvements to be made.
A very early screenshot from 2012 of our driving simulator. The image shows the early images of the Kirchberg area in Luxembourg without textures.
The platform is designed to be modular and has at it’s core a component known as the despatcher. This essentially allows us to use a range of 3D environments, right now we are using Speed Dreams which is an open source car gaming engine but will shortly support another platform as well. In addition we plan to support networked driving simulations. Also you can add in a range of devices including tablets and eye trackers. As with all such projects you constantly discover small bottlenecks and problems, usually related to some underlying development issue such as threading (neither Python nor LiveCode really support this properly). We use Python for example to build the underlying server (despatcher) while LiveCode is used to develop the front-end that is used by the person controlling the simulation (also known as the evaluator).Python can fake threading to a point, but you end up with programmes running on one core. Which given the high volume of data we are dealing with is not a good idea, so we moved to a multi-process approach which again also introduced some problems. LiveCode on the other hand while making implementing sockets and GUIs easy has some rather odd quirks including no real or even fake support for threads built-in which can cause a lot of problems, anyway more on these issues in a more extended post.
Overtime the platform will add a realistic car cockpit, multiple drivers (in a networked simulation) and a range of devices. Also the graphics will be significantly improved for example by adding textures to buildings, other cars and additional details.
I have used LiveCode on and off for about 12 years, it’s a rather nice tool for creating apps and prototypes quickly across platforms from Windows to Android. It is a commercial developer tool which includes a nice GUI builder and English-like programming language. The latter makes it ideal for use in education or when you just want to make something quickly. However, like most small indie platforms it lacks widespread use or indeed the bundles of cash needed to add new features or go open source, until now that is. They are going to offer an open source version which I think is an excellent way to proceed. They do however need your support and you can offer help from as little as $1 via Kickstarter.
Right now we use LiveCode for one of our projects and if it went open source it would help to save the tax payer some cash!
Info: I have a small stake in this company, although even if you back this the material benefit to me is probably less than the cost of a cup of coffee and what I have pledged probably cancels out the financial benefit of anyone else doing so!
Having received a Raspberry PI sometime ago I have to confess I had some issues with deciding on what to actually do with it or indeed how to go about doing stuff with it. Anyway for those in the same situation here are some handy links:
Raspbian OS, a customised version of Debian Linux for you PI.
Over at Modmypi.com they offer lots of addons including cases.
If you fancy an alternative to Linux then check out how to install RISC OS on your PI. It will be officially available and hence easier to install soon. A background to RISC OS can be found here. We used RISC OS back in my school days it was in general (for the time) a very nice platform: fast, resource light and quite user friendly.
PyGame should be easy to install on whatever version of Linux you are using and is a very easy way to make homebrew games using Python. It is also available on other platforms too making your next space invaders game potentially cross platform!
If you are wanting to do some serious coding then compiling software on the PI itself is likely to be a painful experience. Once option to avoid this is the use of a cross-compiler on your PC or Mac check out this post by Chris Boot.
If you fancy better support for video formats e.g. MPEG 2 then check out the good news from the RP foundation itself.
Anyway these are just the tips I can think of just now, there will no doubt be more in future. Happy PI eating!
Update: As of October 2012 this is now priced at $12.99.
TI has made it’s $5 alternative to the Raspberry PI available, however to get the special price you need to order soon! Their alternative, the Stellaris board looks interesting enough that I even ordered two as post is included in the price.
The board comes with an ARM Cortex M4F (ARMv7E-M e) architecture along with USB support, the particular chip comes with a built-in floating point processor and DSP instructions. TI also promise that adding peripherals and undertaking a bit if software development will be easy. From what I can see though the board and chipset does not include a graphics processor which in theory could make it less interesting than the PI to many people. That said if you read the TI website they do imply that the chipset is intended more for industrial control applications. TI also offer a number of booster packs that let you add among other things add a capacitive touch sensor, which could be fun for basic sensor applications. The final price will no doubt be a bit higher but for now it is a good deal.
I have to confess I started in the area of computer science, so I really was into stuff like assembler (6502/68k – hmm I’m old), C and more quirky languages such as Prolog and Lisp. However, as much as I like and often quite enjoy these various languages (for different things) when I put on my usability had I often find them somewhat arcane. For example, the fanatical devotion to brackets and semi-colons in C/C++ is something which I can understand but frankly find a bit annoying in terms of usability. While there is no doubt that C etc often offer excellent performance when compared to higher level languages there are often times when lower level languages simply are not suitable for the task. Take for example rapid GUI prototyping, a sane person would never do that in a lower level language, even manually editing Python code for wxWindows (a GUI toolikt) is frankly a pain in the …… So it is with that I thought I’d start a semi regular thread on the experiences of using higher level languages such as Python or LiveCode for daily programming tasks in a usability context. I should say first up in the spirit of openness that I used to work for the publisher of LiveCode until 2005, and as a result have a small stake in the company. However, this stake is so small that it means nothing to me if you decide to buy the product or not. Indeed if you bought me a coffee it would probably be worth several hundred times more to me than if you bought a copy of LiveCode.
Anyway to kick off this thread, I thought it would be good to do a very quick and dirty look at both platforms based on current experiences. We are using both of these tools where I work to do a number of things, firstly to develop a driving simulator (in combination with other software tools), develop supporting tools for our experiements and also to develop mobile applications. It’s important to note that when I talk about these two tools I do so with the following issues in mind:
We are interested primarily in user focused services, as long as they are not slow, unresponsive or crash regularly it matters not what they are written in.
We require a process that allow rapid prototyping of graphical user interfaces, we need to be able to move those buttons and sliders around with ease. Often we also require more than that, but for now those are the important aspects.
Our team consists of more than computer science graduates, for example psychologists and even a political scientist. They must be able to write their own code as it is unfair to rely on a few “computer people” to do that all the time.
Research teams often change quite a bit over the years, hence the code we create now has to be understandable and maintainable by others in years to come.
We want to leverage existing solutions where possible, in particular open source platforms.
We need skills that are usable across many platforms from mobile to Linux.
While the set of articles which follow would appear to be a direct comparison between both platforms, that is not the full intention. At times the comparisons are I think fair, e.g. when looking at the language syntax and available features. While other times they are not, for example one is free and consequently has a larger user base and more libraries than the other. Also Python on it’s own is really just a language, where as LiveCode is a full developer platform. Hence, what I will write about is how these tools played different roles in our work and when they were or were not useful.
What is LiveCode?
A video explaining LiveCode from Runrev (slightly biased I guess )
Cost: from €99-€1,500 (depending on the type of licence)
Livecode is published the Scottish software outfit Runtime Revolution (Runrev), they even eat their own cake and publish another product called Ten Thumbs Typing Tutor which uses LiveCode. LiveCode itself is built on the Metacard programming platform which Runrev bought some years ago. It owes much of its underlying heritage to the now defunct Apple Hypercard, which was an English-like scripting language that let people back in the 80s and 90s quickly and easily create Mac sofware. However, unlike it’s grandfather LiveCode supports all major platforms such as: Windows, Linux, Mac OS X, IOS and Android. You literally build the code once and it should run on all platforms, although you will get issues with screen sizes and GUI standards especially on mobile platforms. Also the mobile development experience is lacking in some respects as you do need to buy MOBGUI as an extra in order to obtain nice native looking Android or IOS apps. Also many features on the underlying desktop platforms are not always available on the mobile platforms, for example sockets or XMLRPC. Although they will argue that sockets are available via externals under IOS. That said it remains very easy to build applications for all platforms, as you have a nice GUI editor coupled with an English-like scripting language. The language is LiveCode’s biggest asset as well as perhaps for some a weakness. It does allow you to almost think it out then type it, the downside is that it can seem a little more verbose than say Python and can take a bit of getting used to. Also, the language is object-based not object oriented. That said creating applications is very easy so you can perhaps overlook the latter. The IDE lets you drag and drop interface components around with ease and add appropriate code under the relevant interface event.
What is Python?
A tutoral from derekbanas on Youtube about Python 3.0
Cost: Free
Python is a scripting language, that is it. Unlike LiveCode if you want to do much more than programme command line based applications you will probably need to add additional libraries to support GUI building e.g. wxPython. Although that said it does come with it’s own basic GUI toolkit. However, Python and many of it’s libraries are totally free, that means you can almost achieve what you would like to do in LiveCode at zero or near zero cost. The only downside is that GUI builder tools (especially the free ones) are nowhere near as friendly as under LiveCode and even the expensive ones make the rapid prototyping experience far more cumbersome than under LiveCode. You will for example still have to write some code just to develop a GUI and the editors are nowhere near as “drag and drop” as LiveCode. The other major limitation is the build process, while on LiveCode you can click and create what you want (well most of the time) under Python creating a free standing executable is a messier process although still possible.
Python syntax is closer to more standard programming languages and is fully object oriented. It is also quite readable most of the time but not quite as easily as say LiveCode. It also neatly avoids the problems of other more traditional languages by relying on the code indentation as a way to specify structure rather than semi-colons. However, if you forget to indent or do it incorrectly then error messages start appearing. In that sense Python is somewhere between LiveCode and say C.
Now comes the real pain. While it is possible to run Python (or rather variants) of it on Android and even IOS I am told that writing code for both platforms at the same time is a mess. Even my minimal experience of Python on Android (so far I have not run it under IOS) was not always pleasant. Although I did have some limited fun installing the Kivy multi-touch system on an old tablet. Right now Python in my view is little more than some fun under both platforms and nothing that could be taken too seriously by any programmer – although my view may change as these articles progress.
Summary
If you want to build GUI centric apps quickly and easily and share them across platforms then LiveCode is probably the best option. It includes all the tools that you are likely to need. The language is also streets ahead if you are looking for a gentle introduction to programming. If on the other hand you are looking at more back-end programming tasks which require proper object orientation and are keen to avoid the verbosity of LiveCode then Python is a true winner. Also Python has many more third party libraries that support anything from statistical analysis through to games much more easily – they are often also free!
For mobile apps, LiveCode is still better than Python but in my view has a little way to go until I’d say that its either comprehensive or feels professional. However, the one major advantage is that you use the same programming language and tools on ALL platforms. This makes it for now at least a better choice for development when GUIs are required.
Parting thought, this is literally a live or rather as we go along set of articles. As my experience of both programming platforms grows my views may also change!
)