Around once a month or so I receive an email or a message on Facebook asking me why Visit Dolgellau is written in English and not Welsh. It’s a tourist-focused website that I set up last year to promote my home town and the surrounding area.
Some seem to think that it’s an Assembly-backed website (which I take as a compliment, given the website’s humble background!) and are curious as to why it isn’t bilingual as a matter of course like the others. But others are clearly nationalists who simply hate anything that isn’t Welsh and this post is intended for them.
1) The role of Visit Dolgellau is to promote Dolgellau and the wider area as a tourist destination. In general, people who visit Wales tend not to be Welsh (because Welsh people already live here).
2) The website’s analytics data shows that the vast majority of traffic originates from outside Wales. In general, people who live outside Wales do not speak Welsh (because Welsh is only spoken in Wales, and by less than 20% of the population at that).
3) The research available on Visit Wales and Visit Britain indicates that among the list of reasons that tourists come to Wales are the castles and the outdoor activities. So that they may be forced to read websites that they do not understand does not feature on the list at all.
4) That same research indicates that the vast majority of visitors come from either England, Ireland, Scotland, Australia, the USA, France or Germany. None of these countries speak Welsh, but five of them speak English as a first language and the other two speak it as a second.
5) Given that the vast majority of people who visit Wales do not speak Welsh, forcing potential visitors to learn the language before they can find out about Dolgellau and the surrounding area is not conducive to a welcoming environment and is likely to have a detrimental impact on tourism. This is the opposite of what the site aims to achieve.
6) Automated translation is not an acceptable alternative for English-speaking visitors because, as shown in point 4, they are by far the site’s primary target audience. Instead, automated translation serves as a “better than nothing” option for those who wish to use the site in a language that is used by the minority, and bearing in mind points 1, 2 and 4, this is where Welsh sits in this instance.
7) If the site was called “Living in Dolgellau” and was aimed at locals then a bilingual website would make sense; the site however is called “Visit Dolgellau” and is aimed at visitors. The clue is in the name really.
8) I’m one guy, running and maintaining the website alongside a full-time job. I don’t have time to duplicate everything in any language, least of all one that fewer than 1% of the website’s users understand. If I did have time to duplicate everything in another language at all, then, based on point 4, French or German would make more sense.
9) If you really want to see a website promoting North Wales as a tourist destination for the people who already live here, then why not set up your own instead of writing to me to complain about mine? Alternatively, if you really want to see Welsh content on Visit Dolgellau and you have time to write content that only a fraction of the site’s users will be able to understand, you’re welcome to be a contributor – just get in touch and we’ll sort it out.
Although I live in Manchester now, originally I’m from a little town in Wales called Dolgellau. Dolgellau is a market town in Gwynedd, north-west Wales, and is set in the southern part of the Snowdonia National Park at the foot of the Cadair Idris mountain range. It’s a beautiful place – a fact that is only made all the more apparent now that I live in a city – and whenever I show anyone any photos I am always told how lucky I was to have grown up with such surroundings.
Back in 2004, a graphic designer colleague and I were asked by the Partnership – a guild of local businesses basically – to develop a website for the town. We enthusiastically accepted the challenge but soon discovered that politics and conflicting ideas within the Partnership made any kind of progress extremely difficult. The project ran out of steam, we all moved on to other things and in 2007 I moved to Manchester.
Fast forward some years and one day I decided to see if anything had ever become of the town website. The domain that had previously been secured had been taken over by someone else, but there was a new website at a new domain. The initial pleasant surprise that I felt on discovering that a website had finally been put together was quickly dampened when I saw what it looked like. The dated design could perhaps have been overlooked if everything worked, but unfortunately the site was full of broken links, empty pages and pixelated photos that were the wrong aspect ratio. I decided to get in touch so that I could offer to help fix some of these problems but the contact form didn’t work either – and there was no phone number.
So, the idea of a new website was born: I’d create an attractive, modern-looking website which provided quick and easy access to everything that a potential visitor could want – things to do, places to go and somewhere to stay. It would capitalise on the tourism-focused naming convention established by Visit Britain, Visit Wales and Visit Snowdonia and would be called Visit Dolgellau. There would be no politics getting in the way this time round.
The saying, “if you’ve got it, flaunt it” drove the initial concept: since the town is right in the middle of some of the most beautiful scenery in Britain, a photo gallery was a no-brainer – as was a large carousel on the front page. The other boxes to tick were “The Three As”: activities, attractions and accommodation, and these would be built around the gallery in order to provide potential visitors with the practical information they needed once the photographs had convinced them of their need to visit.
Despite Dolgellau being in the middle of the Welsh heartlands and despite the fact that my first language is Welsh, I made the conscious decision that the website would be developed primarily in English: after all, the aim here was to attract visitors and no-one outside of Wales speaks Welsh. A website aimed at attracting visitors that only people who lived in the area (or more accurately, around 65% of them) could understand was simply pointless, and doing everything twice was too much work for a team of one. Google would therefore provide translation duties for all other languages.
The aim of the website was to help promote the town and to boost the local economy, but I couldn’t provide it all for free because of course there are costs associated with setting up and maintaining a website. As such, I would ask each business for a nominal annual fee – just enough to cover running costs and to provide enough money to run the occasional advertising campaign – which would benefit everyone equally.
Visit Dolgellau launched last week and has so far received a very positive response! Its Facebook, Twitter and Google+ pages have all attracted likes and follows and together with the website itself, are each doing their bit for Dolgellau and the surrounding area.
For a couple of years now, JavaScript has been encroaching into territory traditionally held by Flash. At the BBC’s TVMP department, news of set top boxes making the switch to JavaScript seems to be an almost daily occurrence as manufacturers fall over themselves to jump onto the JavaScript bandwagon for alleged “faster development” and the mythical “build once, deploy everywhere” utopian ideal.
I’ve witnessed the repetition of such claims myself. “We’ll be switching this product to JavaScript in the near future because – obviously – it’s faster” a product owner once said, followed by the nodding heads and murmurs of agreement of other non-developers.
The reality for those of us who have not succumbed to the merry tune of the JavaScript Pied Piper’s flute is that “build once, deploy everywhere” is a load of nonsense as far as JavaScript is concerned, and the platform simply isn’t mature enough to competently support apps like this without extensive – and in terms of time, expensive – hacks and workarounds.
Time is being spent filling the gaps of missing libraries and frameworks by converting codebases from other languages – including Flash.
The Flash version of the Sports app that delivered the Olympics last year was released in time for the F1 season in March, while the JavaScript version missed that deadline and was instead launched for Euro 2012 a few weeks later. A few weeks is no big deal of course, except that the JavaScript version was started four months before the Flash version in the summer of 2011.
True, the JavaScript version targeted more devices: a half dozen TVs compared to the Flash version’s single target platform of TiVo. But using the number of target devices as a reason for delay is contrary to the “build once, deploy everywhere” mantra. Ironically, it’s the Flash version that lives up to the claim because although it was developed solely with the TiVo in mind, it runs perfectly without modification on a number of other devices including Western Digital and Popcorn set top boxes.
The Events app on which I was lead developer was developed from scratch in Flash in less than four months. It exceeded expectations by achieving not only the MVP (minimum viable product) but a few stretch goals as well, and even had a week to spare at the end. A JavaScript version wasn’t even attempted because in a somewhat surreal situation, the same management who tell each other that JavaScript development is faster and easier were also in agreement that there wasn’t enough time to build a JavaScript version… good luck understanding that one.
The first few converted devices have started to make their way into the office and are now running JavaScript versions of the Flash apps they once ran. Performance on the new JavaScript versions is shocking, with product owners even electing to disable animation in an attempt to maintain an acceptable level of responsiveness. All this hard work in switching platforms so that we can deliver exactly the same features but with a fraction of the performance… where is the sense in that?
I can understand the appeal on paper: in an ideal world an open platform would be my preference over a closed one as well if all other measures were equal, but in this case all other measures are not equal because developing for the closed platform takes half the time and delivers twice the performance.
Over the weekend I was at the Silverstone Classic event with my father and his close friend Anthony Humphreys. The three of us often go to events like this: we’ve attended events in Ireland, the Isle of Man and France.
For this event, Anthony had purchased a Trespass 200: a new wonder-tent that he proudly proclaimed could erect itself in seconds which would allow him to sit back with a beer while we were still putting ours up. And that’s pretty much what happened. Two days later though when it was time to go home, it was a very different story.
I had watched videos of people struggling with pop-up tents on YouTube some months before and was quietly confident that Anthony was going to experience the same difficulty. So on Sunday morning I packed away my tent and sat on my chair with my phone in-hand ready to capture the impending struggle.
Ladies and gentlemen, this is Anthony Humphreys demonstrating how (NOT) to pack a pop-up tent.
Before work on the BBC Events application could begin, a framework was required that would provide the team with a foundation on which to build a robust, memory-efficient app that could be re-skinned for future events.
I completed the majority of the work in an intensive 3 days which allowed the rest of the team to begin work on the app itself. Embellishments were applied over the remainder of the week.
The core framework is designed around the BBC’s One Service UI which is a drive to use a consistent UX across all current and future products.
It allows for efficient use of specialised components which are created and destroyed at runtime based on what the application requires to render each feed. Components are owned by sections, sections are owned by scenes and a component can both be shared across- or destroyed between- sections as required for maximum efficiency.
The components themselves are based on an MVC pattern and are encapsulated by a component class and interface through which they communicate with the main application. This design enforces a consistent approach to developing additional components – as well as application structure as a whole – and means it will be straightforward to add new components to the framework in the future.
Halo allowed us to create the Events app in record time – less than 4 months from start to finish which is approximately 30% less time than was spent on the Sports app last year.
At the end of November last year the BBC launched the Connected Red Button service on Virgin TiVo, along with updated versions of the iPlayer, News and Sport apps. This package also consisted of a fifth release: an application that is both integral and vital to each of the above apps, yet few are even aware of its existence!
Xenon is a brand new embedded media player that was developed specifically for AS2 embedded devices such as Virgin’s TiVo, to be used by applications like iPlayer, News, Sport and any other such applications that the BBC develops in future.
The development of a new player was actually driven by Connected Red Button. The CRB project was subject to some aggressive performance requirements that were going to be difficult to achieve even with an ideal setup on the modest TiVo hardware, but impossible with the existing media player which had been built years before to a different set of requirements. If we were going to stand a chance of meeting CRB’s performance requirements then we’d need to build a new player specifically for this purpose.
A new beginning
Xenon is based on an MVCS pattern with separate services performing the important tasks of reading playlists, parsing Media Selector responses, loading subtitles and streaming the media itself, while dedicated views handle the presentation to the user. It can be used both by standalone applications and those that are based on our AS2 Krypton Framework: the benefit of the latter being that the host application can then take advantage of the framework’s underlying BDD functionality for automated tests.
Inbound communications are provided by an API that the host application (i.e. iPlayer) can use to control everything from the desired media bitrate to subtitle preferences in real-time, while an events system to which the host can subscribe is used for all outbound communications. This events system provides the host application with around 70 different events, though only 20 of them are required for “normal” use: the others are either used for debugging, were included in order to support possible future requirements or are there simply to provide the host with more specific information on given scenarios.
The project is covered by around 200 unit tests which not only provide confidence in the existing code but will also provide future engineers with a means to test any additions or refactors.
So what’s new?
Viewers should notice a significant improvement in performance, some of which are covered by the following statistics:
Media load times have been halved
Video scrub times are now 3-4 times faster
Toggling between SD and HD is now 3-4 times faster
Subtitles load times are improved tenfold down from 30-40 seconds to just 3-4 seconds.
In order to achieve this kind of performance we had to employ a number of tricks!
One of the things we looked at was the process by which the old player would select and then connect to a server. We were interested in improving this because we’d noticed that there was a noticeable delay between getting the list of stream locations from Media Selector and the start of playback.
It turns out that the old player would make multiple connection requests to its chosen location using different ports – 1935, 80 and 443 – which of course are the standard FMS ports. When one connection responded favourably the other two were closed and the stream was requested from the open one.
Trying to avoid the delays associated with working through a list of ports in series by trying them all in parallel would be worthwhile if each port had a shared chance of success, and on a platform like the PC which operates on different types of networks with different routers and firewalls that’s most probably the case.
On TiVo however, unless there’s a serious problem with the chosen content delivery network (CDN) the 1935 connection will work 100% of the time and if it doesn’t work then we’re better off trying a different CDN than the same one again on a different port.
So that’s what Xenon does: if the single connection request on port 1935 to its first CDN fails to connect then it moves on to the next CDN and sends another single connection request to that on the same port. Since each CDN has a lots fail-over and redundancy, if the user is unable to connect to a single CDN then either their internet connection is down or they have bigger problems!
This approach means the box only has to allocate enough resources to create and connect a single NetConnection which means more resources are available elsewhere to help deliver a more responsive user experience.
Another thing we looked at was subtitles. The old player took 40-60 seconds to resume playback after subtitles were enabled and we really wanted to bring this figure down.
When we looked at how subtitles were being handled in the old player we discovered that typed objects with verified data were being created as soon as the file was downloaded and parsed. A 60-minute program with lots of talking might contain hundreds of lines of subtitles which would require a fair amount of work to get through. Again such an approach makes sense on a PC but not so much on a set top box.
The way we got round this in Xenon was to download and parse the XML file as before, but to create only basic reference objects at first without typing or validation and to defer such calculations until the reference object was relevant to the stream based on the current playback position. At this point the object’s data is verified and converted into a more usable format before the subtitle is displayed on-screen.
This approach means a little more work is done by the player for each individual subtitle as playback progresses, but it also means we can spread the necessary calculations over the duration of the program rather than doing them all up-front which allows us to resume playback in just 3-4 seconds.
What it means for us
Some specifications and supported features are as follows:
The project weighs in at around 6,000 lines
Both audio and video streams are supported, both live and on-demand
Akamai, Limelight and Level3 content delivery networks (CDNs) are supported
Dynamic CDN switching and ABR1 bitrate downswitching are both supported
Dynamic weighting and prioritisation is supported, with appropriate data supplied by Media Selector 5
The new player also provides a number of benefits for our development teams:
An API that allows direct control of every aspect of the player at runtime
A comprehensive and consistent events system which makes debugging quick and easy
A complimentary example application that both provides new teams with an implementation template and a convenient way for us to diagnose issues with the live service
The codebase is extensively covered by tests which provides confidence in the robustness of the code.
Although invisible to the average user, Xenon has received favourable feedback from the public with comments such as:
I have found since BBC released the Connected Red Button on TiVo, BBC iPlayer has worked perfectly. I have watched loads on there over Christmas mainly in HD and I’ve no stuttering of the picture or any exiting from the program. Also it pauses and restarts without exiting back to menu. And if you press the forward arrow slowly between each press you can jump in 1 minute segments when fast forwarding so it is pretty easy to get to a certain part of the program. Now that the resume works with SD and HD programmes you can also leave and come back to where you left off earlier. I used to have all the problems like what most others have reported but now I can use BBC iPlayer at any time (including peak time) with no problems. – spj20016, Digital Spy Forum
I managed to watch the whole of Supersized Earth in HD last night on Tivo iPlayer without a single blip, stutter or buffering. Something has improved. – m0j00, Virgin Media Support Forum
Even the pause button works without it throwing you back to the beginning. – Markynotts, Digital Spy Forum
While working on the BBC Sports app for Virgin TiVo, it would be safe to say that I encountered more problems than one would expect to on such a project. Some of them seemed to be bugs in Adobe’s StageCraft (Flash Lite 3.1), others seemed to be inconsistencies in the implementation of the Flash player on the box and still others came from unexpected content delivery network behaviour. As a result there were a number of feature-related tasks that turned out to be more difficult to implement than they perhaps should have been, and as a team we spent a number of days in total investigating causes of unexpected and/or undesirable behaviour in the app that resulted from these issues.
Still, this post isn’t about reflecting on the highs and lows of development or about detailing the inner workings of Virgin Media‘s flagship device: rather, it’s about a great little tool that I found while trying to diagnose one of the aforementioned problems: Connection Emulator by SoftPerfect.
The Euro 2012 tournament was about to begin and an updated version of the app was released to support it. During the opening match we received reports of stuttering video playback which we were able to replicate ourselves on some of the test devices in the office. What we were seeing came as quite a surprise because the first version of the app which was released for the start of the F1 season exhibited no such problems and played back its content without issue. All of the test content we had used during development had also played as intended. What was different about these new football streams that could cause such symptoms?
On the second or third day I was asked to take a look at the issue after different builds with different settings had failed to resolve it, and at the same time I was provided with some useful information including figures for the CDN (content delivery network) that was supplying the content. Some aspects of those figures were a little concerning and I wanted to run some tests on the TiVo under similar conditions to see how it responded.
I already had a tool that could simulate a limit in bandwidth, but in order to carry out the tests that I had in mind I needed something that could also simulate latency and packet loss. I develop on Windows because FlashDevelop (the greatest Flash IDE in the world) is only available for that OS, so Mac OSX’s built-in network simulation tools weren’t an option. After a few minutes on Google I discovered SoftPerfect’s Connection Emulator which claimed to offer precisely these features and so I downloaded the trial and took it for a spin.
Immediately the application instils confidence that you’re using a professional tool. The interface is well designed with separate tabs for each aspect of network simulation: transfer rate, latency, packet loss, duplication and reordering. The respective options on each tab are comprehensive and each option can be enabled and adjusted separately during or between tests. A graph at the bottom of the window gives a visual indication of the effect that your current settings are having on your machine’s throughput, with more precise statistics available in a separate pane.
Using the application I was able to test the TiVo under a variety of conditions with varying latency and packet loss, and along with throughput calculators (see here and here) was able to show conclusively why the football streams were stuttering: despite a dedicated connection of up to 10mbit on Virgin’s network, the TiVo simply wasn’t getting enough throughput from the CDNs because latency and packet loss were too high.
As one might imagine with stakeholders as large as projects like this often demand, in order to bring about a swift configuration change you need to be armed with significant evidence: vital settings will not be changed on the strength of gut feeling alone! Thanks to Connection Emulator I was able to provide that evidence in abundance which led to the necessary changes being made to deliver the content within the required parameters, and the rest of the tournament passed without any further problems.
One “gotcha” I discovered while using the tool however was that VirtualBox didn’t seem to like it one bit, blue-screening the host machine a few times before I was able to disable it. Switching over to VMware resolved the issue which would suggest that this is a problem with VirtualBox rather than with Connection Emulator itself, but I thought it worth mentioning anyway in case anyone else experiences the same issue.
VirtualBox issue aside, this is a great tool that performs its specialist tasks very well and very reliably, and it comes highly recommended to Windows-based developers who need to test their applications under varying network conditions.
Just over four months have passed now since I started contracting at the BBC – four months that have flown by like days!
Today the primary purpose of my contract was released into the wild: the BBC Sports F1 application for Virgin TiVo. The public release of this application means that I am finally allowed to talk about it which is a great relief because not being able to talk about such an exciting project was really quite difficult!
The application enables users to watch all the BBC’s interactive coverage for major sporting events such as Formula One, Wimbledon, Euro 2012 and London 2012 with live streams, on-demand video and other additional content.
Finally, if a picture is worth a thousand words then a video must be worth a thousand pictures. With that in mind, here’s the official introduction video!
Back in 1998 when I was 16, my father bought me my first Windows computer – a Toshiba Satellite 320CDT laptop from PC World in Chester. It had a 233mhz Pentium MMX CPU, 32MB of RAM and a 4GB HDD with Windows 95 installed.
Although new to Windows, it didn’t take long for me to realise that Windows 95 left a lot to be desired. I upgraded to Windows 98SE at the earliest opportunity and boosted the RAM with an additional 64MB taking it to 96MB in total. For the next few years I used that little laptop extensively and I learned a lot from it.
Tired of BSODs I eventually upgraded again to Windows 2000 which offered a much more stable environment at the notable expense of speed and responsiveness. Eventually it became time to upgrade to a desktop and the Toshiba was handed down to my younger twin sisters who, as it turns out, thoroughly abused it.
I dug out the machine while at my parents’ house a couple of weeks back. I was quite mortified to find the keyboard and screen covered with various bits of food, the modem cable was missing, the track pad nipple was missing, the little door covering the PCMCIA slot was missing and the charger socket was loose which meant the laptop would only charge if you held the cable in at a certain angle. Considering I had always kept the machine in good order I was not impressed. I decided to rescue it in the interest of nostalgia and brought it home with me.
The first thing to do was get all the food stains off it, which was quite easy with some wipes after taking out the keyboard. Next I got onto eBay and found a replacement modem cable, track pad nipple and PCMCIA door. I ordered one of each and then set about fixing the loose charger socket. I doubt I’ll ever use the modem again as I have a wireless network card that will fit this, but it’s better complete than incomplete nonetheless.
After finding a service manual for the laptop (mirrored below) I was all set. I opened it up to discover that the machine had obviously been pulled around by the cable as the solder was cracked and broken on BOTH pins! No wonder charging was so hit-and-miss! A little touch-up with a soldering iron and that too was fixed.
Over the next couple of days the various replacement parts arrived and eventually the laptop was as good as new – apart from the Windows installation which was full of all kinds of freeware/adware/spyware. I decided to reformat and re-install, which was easy as I’ve kept ISOs of all my OS disks over the years.
Interestingly Windows Update no longer works for any browser older than Explorer 6 SP1. As Windows 2000 comes with Explorer 5, I had to find an offline installation executable to manually update that before I was able to download the other 100+ updates required through Windows Update.
After hours and hours of downloading and installing updates I now once again have an as-new Toshiba 320CDT laptop, fully up-to-date (as far as Windows 2000 is concerned at least) and ready to go. It’s too slow to use every day, but as it’s where it all began for me I do feel much better having restored it to its former glory.
If anyone else is restoring a 320CDT, here’s a list of resources and software that might be of interest:
Update 17/2/2014: I’m afraid that I’ve been asked by a representative of Toshiba to remove any links to the company’s websites so you’ll need to use a search engine to find the above downloads page.
Back in the mid-late ’90s, Sega’s 32-bit Saturn was in the process of losing ground to Sony’sPlayStation, mostly due to a series of stupid decisions from Sega themselves. From hurriedly throwing together a machine that was incredibly difficult to program to asking for £400 for it on release (equivalent to between £600 and £707 today), Sega seemed pretty determined to make the Saturn an unattractive proposition for both developers and consumers alike.
As a result of being both difficult to program and the subject of a much smaller user-base, the Saturn was often the recipient of low quality, rushed games that looked (and sometimes played) terribly compared to PlayStation equivalents. Yes, there were obviously a number of greats on the Saturn that, in my opinion, eclipsed much of what the PlayStation had to offer, but I’m not talking about exceptional cases here – I’m talking about the way things were in general.
Sometimes this was down to developers porting over PlayStation code with minimal effort which meant no optimisation (for instance, Acclaim’sAlien Trilogy only used one of the Saturn’s two 32-bit CPUs) and sometimes it was simply down to developers not being skilled enough to get the most out of the hardware.
Sega’s non-existent software libraries meant that writing code in Assembly would yield speed increases of 300-500% over code written in C, but few publishers and developers were willing to spend the time – or the money – to do this. Yu Suzuki himself estimated that only 1% of the industry’s programmers would be skilled enough to get the most out of the Saturn, which compared to the high percentage of developers who could easily get things done on the PlayStation thanks to Sony’s comprehensive C libraries, just wasn’t good enough.
However, while most developers and publishers were happy to release sub-standard crap on the Saturn, there were a few who were willing – or maybe more importantly able – to achieve impressive results on the machine, sometimes even achieving things that were not possible on the PlayStation.
One such company was Lobotomy Software. I remember reading a preview of their first Saturn title, Exhumed, and being overjoyed that finally someone was putting some proper effort into a Saturn FPS. Deadalus, Doom and Alien Trilogy before it had all been horrendous, so I was really looking forward to playing what looked like the console’s first proper FPS game.
I pre-ordered the game and remember being late for school the day it arrived as I had been unable to wait ’til later to try it out. Over the next few months I completed the game several times over and unlocked every single secret, earning the in-game ability to levitate and even fly. The game was just awesome.
On the success of this game (at least technically if not commercially – this was the Saturn after all), Lobotomy Software was commissioned by Sega to also convert Quake and Duke Nukem 3D to the Saturn; both of which also turned out to be favourites of mine.
The brains behind the SlaveDriver engine that powered all three games and put every other Saturn FPS to shame was a guy called Ezra Dreisbach, and although I’d never met him or even seen his photo, I had some serious respect both for him and what he had achieved where so many others had failed.
Back when the Saturn had reached its apex in the US market, I had just obtained a used one and several games and had done some research on USENET for which games I should investigate. Among the games that seemed to be highly acclaimed were three by the company Lobotomy Software. Those titles were all first-person shooters: Quake, Powerslave, and Duke Nukem 3D. The last of these even had the functionality to play over the Sega Netlink modem network device. I bought all three and enjoyed them immensely. As it turns out, I was able to track down Ezra Dreisbach, the lead programmer on Powerslave and actually got to ask questions. Ezra now works at Snowblind Studios where he worked on Baldur’s Gate: Dark Alliance. Here’s the result of that communication.
Matt: You were the lead programmer on Powerslave for the Saturn by Lobotomy, but also on the team for the Saturn ports of Duke Nukem 3D and Quake. Did those all use the same engine?
Ezra: Yeah, they were all based on the Powerslave Saturn engine. It was on the strength of that engine that we were able to get the contract for Duke Nukem and Quake from Sega.
Matt: What were your contributions to that engine? What were your roles on the other games that used it?
Ezra: I was the only programmer on Saturn Powerslave, but after we got the Sega contracts our whole company started working exclusively on those two projects and I moved into more just doing the core game engine work to support them.
Matt: Powerslave and Duke Nukem 3D on the PC both used Ken Silverman’s BUILD engine. Was the engine you designed for the Saturn a port the BUILD engine?
Ezra: Both games were pretty much rebuilt from the ground up. There is no shared code at all.
Those games work very differently from the way that things need to work on the Saturn, so there is really no way to do a port other than to basically remake the game. Doing ports isn’t the most financially or personally rewarding work. So there is no way that we would have wanted to do these if we hadn’t already known how to make Saturn first person shooters.
Matt: What, besides data like textures and models, was carried over from the PC versions? How about porting Quake?
Ezra: For Quake, all the levels were rebuilt by hand using our in house tool “Brew”. For Duke, we had a way to import the level data into Brew, but it still required substantial reworking.
Matt: What kind of system did Brew run on? I presume a PC, but then I’m not aware that I’ve ever heard a Saturn dev kit described before.
Ezra: It ran in Windows. The original idea was that it would be a tool that Lobotomy could use to create first person shooter levels for many games. We used it for Powerslave (Saturn & PlayStation), Mortificator (PC, unreleased) and the Quake and Duke ports.
Matt: You were a member of the “Design Team” for the PlayStation version of Powerslave. Does that mean you were a programmer, or did you fill some other role?
Ezra: No, it doesn’t mean programmer. On a project with so few people, everyone who works on it does some of the design. For instance, I designed some of the boss behaviour.
Matt: How did you feel about the two platforms, Saturn and PlayStation?
Ezra: I did do some work on the PlayStation later. After Saturn Quake was done I did a quick port of it to the PlayStation. Lobotomy was really hurting for cash at that point, and I hoped that we could get some publisher to sign us up to do PlayStation Quake. But for some reason, we couldn’t get anyone to go for it. Lobotomy folded soon after.
Matt: A PlayStation port of Quake? That’s terribly interesting! I’ve wanted a version of Quake on the PlayStation so I could compare versions on all three of the consoles from that “generation”. If you’ve the inclination, I’d truly like to hear how the port turned out on the PlayStation hardware, compared to the Saturn and (if you’ve seen it) the N64 version.
Ezra: The most striking thing about the PlayStation port was how much faster the graphics hardware was than the Saturn. The initial scene after you just start the game is pretty complex. I think it ran 20 fps on the Saturn version. On the PlayStation it ran 30, but the actual rendering part could have been going 60 if the CPU calculations weren’t holding it up. I don’t know if it would have ever been possible to get it to really run 60, but at least there was the potential.
Other than that, it would have looked identical to the Saturn version. Except for some reason the PlayStation video output has better colour than the Saturn’s.
So I know something about the PlayStation. And really, if you couldn’t tell from the games, the PlayStation is way better than the Saturn. It’s way simpler and way faster. There are a lot of things about the Saturn that are totally dumb. Chief among these is that you can’t draw triangles, only quadrilaterals.
Matt: I think I’ve seen an example of this in Tomb Raider on the Saturn. Very early on, in the caves, you can find a rock with a triangular side. In the PlayStation version, a rectangular texture was cut down the diagonal and mapped onto that triangle. In the Saturn version they had mapped the entire rectangular texture into the triangle, reducing one side to a point (in the sense that a triangle is a degenerate quadrilateral with one side of length zero).
Ezra: Ha! That’s pretty weak. What you do if you’re really trying is you pre-undistort the texture so that when you pinch one side down like that you end up getting what you wanted. We had to do this for the monster models in Saturn Quake.
Matt: Do you recall some of the internal differences between the Saturn and PlayStation versions of Powerslave?
Ezra: If you find all the team dolls in the Saturn version, then you get to play Death Tank. I’m not sure what you get in the PlayStation version. Jeff [Blazier] (the programmer of the PlayStation version) was working on a DT-like multiplayer minigame based on asteroids, but I don’t think he put it in the final game.
There are laser wall shooters in the Saturn version, but not in the PlayStation. It was a long time ago. There are plenty of differences, but I don’t remember any more major ones.
You can play a more advanced version of Death Tank if you’ve got Saturn Quake and Saturn Duke. Just boot up Quake so that it makes its save game, then start up Duke and a Death Tank option appears in the main menu.
Matt: Who designed the four exclusive levels for Saturn Quake? And while we’re talking Quake levels, what happened to one of the most memorable secret levels in the original Quake, Ziggurat Vertigo? Was it just too much wide open space for the engine to handle? Or were there other reasons for leaving it out?
Ezra: Yeah, exactly. That level was way too open to run well on the Saturn. One of the main problems with both the Quake and the Duke ports was that, on the Saturn, you can’t just draw a huge flat wall as one huge flat polygon. For one thing there’s no perspective correction, and some other limitations prevent you from even trying to work around that problem by dynamically subdividing the walls. So a flat wall has to be drawn as a mesh of quads. This means that huge walls have to be a lot of polygons, so huge open areas just can’t work. One of the Duke Nukem secret levels had to be replaced for the same reason.
The exclusive secret levels were designed by the whole Quake team. They were actually built by the Quake Saturn level designer, Paul Knutzen, who I’m happy to again be working with on Snowblind’s new project.
“The next part is even more disappointing for the N64 port. Many of you may recall the three switches that light up as you descend a spiral ramp down to a pool of sludge. In the N64 version, the lighting is almost completely static in this section. Apparently adding coloured lighting to sections of the game is easy, but the addition of dramatic dynamic lighting is too hard to do. But wait… Lobotomy managed to pull it off on the Saturn. Crazy.”
I remember being really grumpy about implementing the dynamic-world lights like the three switches in this area. I’m glad someone appreciated it.
Matt: Do you generally like first person shooters? Or was the work on Saturn shooters a business decision, given the popularity of the genre?
Ezra: Yeah, I like first person shooters, Halo was my favourite game last year. But at that point, what I wanted to do didn’t really have anything to do with what Lobotomy decided to do. I was hired to work on Saturn Powerslave, so the decision to do that game was made way before I got there. And even after that I didn’t get much say it what we were going to work on. Not that we had much choice, people weren’t exactly lining up around the block to offer us work.
Matt: What others kinds of games do you play, in your spare time?
Ezra: I’ve already played a ton of games, so I like games that are not ordinary. In the past year, I liked Halo, Rez, Ico and Jet Set Radio Future.
Matt: Porting a game to a platform is said to be far less rewarding than creating a new game, tailored for a specific platform. If you could return to the days of Lobotomy, with the experience you have now, would you have done anything differently?
Ezra: As an independent game developer there’s always a big difference between what you want to do, and what a publisher is willing to fund you for. So usually you end up doing stuff that’s lamer than you’d like. Nothing you can do about it really.
Matt: Any plans for a Death Tank Drei hidden in any of your games?
Ezra: No. I would like to make a stand-alone DT game someday though.
Matt: Thanks for taking the time to share your answers with me. And, as I’ve said before, thanks for the work on Powerslave, Quake, and Duke Nukem 3D… I know I enjoyed playing all three of them.