Watching video on RISC OS isn't very easy. We've run an article here on how you can download and convert YouTube videos into a format RISC OS can understand. Though it's very clever, and the tools involved are actively developed, it's not as simple as clicking 'Play' in a browser window.
 
Improving this situation has been hampered up until now for two main reasons:

• RISC OS hardware has been too slow to play back video at an acceptable rate;
• RISC OS software hasn't supported popular codecs (formats), some of which are proprietary and expensive to license.

 
The first of these is already well on the way to being fixed. The Beagleboard is modestly powered in comparison to the average desktop PC, but it's perfectly capable of playing video at a decent rate. The diminutive boards have been shown running 720p video (a high-definition format) while running a Linux distribution - have a look here to see this in action.
 
The RISC OS port can't quite match that yet. All that might be about to change, though, due to the development of something called Theorarm. This is a library of routines to enable the playing of videos in the Ogg Theora format on ARM-based machines. Ogg Theora is a relatively new format, but it has some interesting features. Perhaps most importantly, it's entirely open source, so videos encoded using the technology can be played back by any suitably-written software. Moreover, Theora is one of the contenders for the [video] tag in the new HTML5 specification. That means that it may become a significant rival to the more common MPEG and Flash videos on the web.
 
Theorarm is interesting, as it's been optimised for newer ARM chips using hand-written assembly code. This makes it very fast. The developer, Robin Watts (of Warm Silence Software fame) has done some development work on the Beagleboard, with promising results: "With post processing disabled, I can play a PAL DVD sized film (720x576x25fps, 48kHz stereo audio track) in realtime with software YUV2RGB. The limited profiling I've done, along with some back-of-an-envelope maths suggests that we should just about be able to do 720p films if the YUV2RGB process is done by hardware." That means, in English, that DVD-quality film can be played back on a Beagleboard with decent audio too. If some of the complex conversions from YUV colour format to RGB could be carried out in hardware, then higher definition films could be played.
 
This is pretty exciting stuff for Beagleboard owners. If Theorarm is ported to RISC OS (and there's no reason, other than developer time and effort, why it couldn't be), then we'd have the basis of a fast, native video playback system. Some issues would require addressing, of course, since RISC OS can't handle the Beagleboard's YUV facility - see here for Jeffrey Lee's proposals to fix this - but these are all surmountable.
 
If anyone is interested in getting involved, then the ROOL project is the place to start. In particular, the proposals for working on the GraphicsV vector need attention from developers with the right level of experience, and the draft API on the ROOL site could do with some more exposure.
 
A few years ago, RISC OS lacked fast hardware, a half-capable browser and a media player capable of showing popular streaming video formats. The first two are being actively addressed - what are the chances that the last one will be as well?
 

There's been a fair bit of effort to get RISC OS software working on ROOL's port of RISC OS to the Beagleboard and other OMAP-driven boards. The shift from software that works on the Iyonix to software that works on the OMAP family isn't as big as the shift to 32-bit of a few years ago, but there are still some issues. Most importantly, the OMAP family of processors use the 'ARMv7' specification, which means that certain instructions that work on the Iyonix's IOP processor (or earlier) fall over.
 
The ease of fixing a recalcitrant application depends on how it's been written. If the app's written in BASIC, then all should be well. If it's written in C, then a recompile with the latest version of the GCC or Norcroft tools should fix it. If you've got some hand-crafted assembler to cope with, then the process is a bit more involved. There's a full list of these technical issues here.
 
As time goes on, more and more software is having fixes applied to enable compatibility. Over the last few days, David Pilling's Ovation Pro and SparkFS have been updated to work with the new hardware. The text editor Zap has also been fixed, though there's not an official release of this yet. Apps like NetSurf, KinoAMP, ArtWorks and RDPClient already work, and there's some indication that EasiWriter and TechWriter will soon join the list.
 
More details on the applications that work on the new hardware platform can be found here. Hopefully this list will keep on growing. Meanwhile, at least one RISC OS user is happy with the experience of using the BeagleBoard...
 

The ROOL team recently announced that they're no longer registered for VAT, which means the Norcroft C compiler and associated tools are a bit cheaper at GBP50 (plus P&P). ROOL took over the distribution of the suite from Castle last year, who took them over in turn from Acorn.
 
The Norcroft compiler has long been the default option for C programmers on RISC OS. It's only relatively recently that the GNU Compiler Collection (GCC) has provided a genuine alternative. The latter has many advantages, including development drawn from a wider pool of developers and the ability to compile RISC OS programs on fast PC-based hardware. However, at the time of writing, the RISC OS sources are only compilable using Norcroft. It's possible this may change in the future, but for the time being, if you fancy getting involved in the porting efforts, obtaining a copy of the necessary tools just got a bit easier.
 
The ROOL announcement is here. The announcement was publicised on RISC OS Info a couple of days ago.
 

For several years now, the need to get RISC OS running on faster hardware has been pressing. It may not be the platform's worst headache (lack of developers is surely the biggest problem), but the Iyonix and A9 hardware are now well past their prime. Even on release they weren't blisteringly quick, and cheap PCs have now left them far, far behind. Things that are taken for granted on a Windows or Mac OS machine, such as watching video, are simply impossible on current generation RISC OS hardware.
 
 

As most of you probably know by now, a few months ago I started work on porting RISC OS Open's RISC OS kernel to TI's OMAP3 platform - a group of SoC's (Systems on a Chip) which use ARM Cortex-A8 cores. To date, OMAP3 SoC's have been confirmed as being used in various products, including the Pandora handheld gaming console, the Touch Book convertible netbook/tablet, and the BeagleBoard development board. For years RISC OS users have been asking for a new portable RISC OS machine, and soon they may find that they have several available.
 
 

A while ago you may remember that I wrote an article about video conversion for RISC OS, and near the end raised the topic of video conversion on RISC OS using a port of ffmpeg. Although the version of ffmpeg I originally tried on RISC OS was old and broken, Christopher Martin obviously thinks there's some merit to this approach, as he has recently produced !FFmpeg, a working port of ffmpeg for RISC OS.
 
Once more in the interests of SCIENCE, I threw a few test videos at !FFmpeg and measured its performance against that of a similar version of ffmpeg running on my Windows PC.

 

As stated in the last article, this time I'll be looking at what went into the MK I map generator for my eternally work-in-progress game, DeathDawn.
 
Specifically, I'll be looking at the implementation and evolution of the following components of the generator:

• City block placement. This is arguably the most important stage as it defines the overall layout of the city.
• Edge and node linking. A housekeeping stage that prepares the data structures for the road weighting stage.
• Road weighting. A city with roads which all have the same number of lanes isn't very realistic, so this stage uses an algorithm to determine the number of lanes each road should have.
• Road and building painting. With the city structure generated, all that's left is to translate it into the format used by the engine during actual gameplay.

 

After writing my first article about random map generators, I said I was going to write a city generator. Well now I have, and I'm here to tell you about it over the course of the next few Building the Dream articles.

Blow your own trumpet much?

Although this article could just be dismissed as me blowing my own trumpet, I'm hoping that it will serve a somewhat more useful purpose. Before, during, and after working on the map generator I've searched the Internet for examples of similar generators and failed to find any. Sure, there are odd bits and pieces - descriptions of simpler generators that have given me ideas on some techniques to use, or screenshots of sexy work-in-progress realtime generators, but no actual algorithms or code samples from generators that come close to the required complexity of my generator.
 
So hopefully this article will become a useful reference point for anyone else wanting to undertake the task of writing a city generator, whether they're targeting a grid-based world representation like mine or a vector-based one.
 
Apart from discussing the algorithms used in the generator (and why they're used) I'll also talk about the data structures that are used - so even if you're not interested in random map generators you should be able to find plenty of examples of uses for the data structures covered in the first Building the Dream article, as requested quite some time ago.