Fishpool

To content | To menu | To search

Tag - Tech

Entries feed - Comments feed

Monday 14 November 2011

Flash is dead? What changed?

By Osma on Monday 14 November 2011, 13:10

So, Adobe finally did the inevitable, and announced that they've given up trying to make Flash relevant on mobile devices. Plenty has been written already about what lead to this situation, and the "tech" blogosphere certainly has proved their lack of insight in matters of development again, so maybe I won't go there. Flash plugin has a bad rap, and HTML5 will share that status as soon as adware crap starts to be made with it. It's not the tech, but its application.

So, lets focus on the developer angle. Richard Davey of Aardman and PhotonStorm is offering a developer-focused review into the alternatives. TL;DR; Flash is what's there now, but learn HTML5 too. Yeah, for web, I would agree.

However, that misses the big picture as well. Choosing any tech today for the purpose of building games for Web is deciding a future course by the back-view mirror. Web, as it is today, is about a 500M connected, actively used devices market. Sure, more PCs have been sold, and about that many are sold both this and next year, but the total number of devices sold doesn't matter - the number of people using them for anything resembling your product (here, games) does. So, I'll put a stake in the ground at 500M.

In comparison - iPad and other tablets reach about 100M devices this year, and projections look like about as much more next year. I would argue that most of them will be used for casual entertainment, at least some of their active time. That makes tablet-class devices (large touchscreen, no keyboard, used on a couch or other gaming-friendly situations) a significant fraction of the Web market already, and that will only be growing going forward.

Mobiles are a class of their own. Several billion devices already, maybe about a billion of them smart phones, some projections claim another billion smart phone-class devices to be sold next year. Just by limiting the market to only those devices which sport installable apps, touch screens, significant processing power (think iPhone and Android devices, possibly excluding lowest-end Android and the iPhone 1.0 and 3G), you're still looking at a potential market of 1 billion devices or so. Now, phones are not in my book very gaming-friendly - the screen is small, touch controls obscure parts of it, play sessions are very short, the device spends most time in a pocket and rarely gets focused attention, and play can be interrupted by many, many things. Still, as we've seen, great games and great commercial success can be created on the platform.

However, lets not pretend that a Web game could ever have worked on either a tablet or a phone without significant effort, both technical and conceptual. The platforms' underlying assumptions simply are too different.

So, how would you go about choosing a technology for creating a game for the future, instead of the past?

The choices are:

  • Native, writing for iOS only. Decent tools, except when they don't work, one platform, though a relatively large one with customer base proven to be happy to spend on apps.
  • Native, writing for iOS and Android. Perhaps for Windows Phone too, if that takes off. Welcome to niche markets or fragmentation hell.
  • Native, but with a cross-platform middleware that makes porting easier. Still, you're probably dealing with low-level crap on a daily basis.
  • HTML5, if you're willing to endure an unstable, changing platform, more fragmentation, dubious performance, and frankly, bad tools. Things will be different in a couple of year's time, I'm sure, but today, that's what it's really like. I would do HTML5 for apps, but not for games, because that way you'll get to leverage the best parts of web and skip on the hairiest client-side issues. In theory you'll also get Web covered, but in practice, making anything "advanced" work on even one platform is hard work.
  • AIR, if you continue to have faith that Adobe will deliver. In theory, this is great: a very cross-platform tech, you can apply some of the same stuff on Web too, get access to most features on most platforms on almost-native level, performance is not bad at all, and so on. Except in practice HW-accelerated 3D actually isn't available on mobile platforms, its cousin Flash was managed to oblivion, and perhaps most crucially, Adobe's business is serving ad/marketing/content customers, not developers. I keep hoping, but the facts aren't encouraging. For now though, you'd base your tech on a great Web platform with a reasonable conversion path to a mobile application, caveats in mind.
  • Unity, if you're happy with the 3D object-oriented platform and tools. You'll get to create installable games on all platforms, but lets face it: you will give up Web, because Unity's plugin doesn't have a useful reach. Here, the success case makes you almost entirely tables/mobile, with PC distribution (in the form of an installable app, not a Web game) less than a rounding error. This is probably what you'd be looking for in just a few years time anyway, even if today it looks like a painful drawback.
Conclusion: Working on tools? HTML5. Web game for the next 2 years? Flash 11. Mobile game? Unity, if its 3D model fits your concept. AIR if not, though you'll take a risk that Adobe further fumbles with the platform and never gets AIR 3 with Stage3D enabled on mobile devices out the door. Going native is a choice, of course, but one that exceeds my personal taste for masochism.

On the upside, Unity is actively doing something to expand their market, including trying to make Unity games run on top of Flash 11 on PC/Mac, so in theory you might be getting the Web distribution as a bonus. Making code written for Mono (.NET/C#/whatever you want to call it) run on the AS3/AVM Flash runtime is not an easy task though, so consider it a bonus, not a given.

Friday 3 August 2007

Maemo Mapper and route quality

By Osma on Friday 3 August 2007, 16:42

Finally a comment about the navigation routes. This is not really about Maemo Mapper, because it simply displays routes from Google Maps, but nevertheless the suggestions have at times left something to be desired. How it directly relates to Mapper is in the way it might help make corrections to these routes require less manual effort.

Once the route instructed to leave a regional road to turn on a foot path shortcut; fortunately, this instruction was obviously impossible to follow. A second time the route changed from a steep but drivable hillside road to a dirt track a few kilometers later; perhaps it would have indeed taken us to the destination, but only with a 4WD vehicle, so we needed to backtrack and find another road, not necessarily a trivial exercise in the narrow one-way street Sintra region.

In both cases little could be done about the error at that moment, but it sure would be nice to be able to feed this information back to the route database. Surely the track information would be valuable to at least Open Street Maps if not also Google Maps. I've heard Navteq also use a similar mechanism to improve their own route databases from tracks recorded by users' navigation computers, and this collective track mapping for sure is the future for how navigation will develop.

Wednesday 1 August 2007

"Dad, are we there yet?"

By Osma on Wednesday 1 August 2007, 10:28

Maemo Mapper has a few displays in addition to the primary map information. It can overlay the map itself with routes, tracks, and points of information, and show the current speed as well as way-point directions over the map. It also has a secondary display of GPS position information, including altitude and compass.

However, it's missing a couple of critical displays; the distance to the next way-point as well as to the end of the route, and an estimated arrival time to the end of the route. The first two are simple to provide, and in fact are available through the menus, just not as a constantly displayed overlay. The third one can be tricky; the travel time may not be included in the route information, or it may be inaccurate. Estimating it from average speed is the other alternative, also vulnerable to errors when travel conditions change. However, providing some kind of estimate is still a useful service to the user.

The readability of the overlaid information is not quite ideal in the challenging in-car circumstances. The blue dot signifying current position is small on the high-resolution display, and difficult to see in sunlight. Making larger and animated (I would suggest a rotating symbol of some sort; keep in mind also the suggestion about scaling its size according to position accuracy estimate) would help. The speed indicator flickers; whether this is due to lack of double buffering or otherwise, it's distracting. Finally, the route direction dialog also changes shape about once per second, sometimes laying out the direction on one line, sometimes needing to place the last word on the next. Not surprisingly, this draws too much attention to it (hopefully not from the driver!) as well as requiring extra effort to read.

Tuesday 31 July 2007

Maemo Mapper map display and UI

By Osma on Tuesday 31 July 2007, 11:54

As a reflection of my previous description of a smarter way to download maps, I would also suggest that the display of the route would benefit from a slightly more automatic mode. The level of detail to display could well be chosen automatically based on a few parameters, such as current travel speed, distance from the next way-point, shape of the route ahead, and availability of detail maps. I realize the current design has preferred battery lifetime and has been limited by the hardware capabilities; however, these suggestions should not be greatly more demanding of the hardware.

A few such suggestions also come to mind; besides the semi-3D tilted map display I have read the author is considering, a "smooth zoom" function by map scaling would make the detail level selection a less jarring switch, especially when it was automatically chosen. In addition, at least this writer is challenged by having to read routes where the direction of travel is, for example, down-and-leftwards. Visualizing correct turn directions becomes an effort not always easy to afford while having to make quick decisions in traffic. The map doesn't need to be rotated in real time with 360 degrees of freedom to assist the user in these circumstances; simply turning it in 90 degree angles might be sufficient.

That is for how the display works; as far as how the program reacts to user input, a few small changes here and there might make also that better when considering that this is a program used while mobile and outside.

Tapping on the map currently centers the map on the point tapped, or if the tap is on a POI (or very close to it), brings up a small message box with the POI name in it. I would suggest to make tapping always perform the same actions; zoom in on the point tapped, and display POI or way-point data if available. Re-centering should be done instead by tap-dragging a point on the map; a function which currently behaves as if the screen had been tapped in the position where the drag ended and pen/finger was lifted, exactly the reverse of what such a gesture would be expected to mean (try it to understand what I mean).

Zooming out can also be supported; either by tapping on the center of the map (where instead of meaning "center and zoom in" it will mean "show more around this point") or if the tap-drag action covers a sufficiently large area of the display, zoom out to display both previously visible as well as the revealed area. This behavior has precedent in other applications, is quite predictable and easy to get used to (especially if the UI's feedback to the action is made richer by scaling up/down smoothly instead of a sudden 2x scale change. It should also be nicely forward compatible to a new mode if and when future tablets support multi-touch displays.

Downloading routes and maps in Maemo Mapper

By Osma on Tuesday 31 July 2007, 11:11

Maemo Mapper currently has three methods of downloading map data; the immediate, "show map of current area and detail level", and the two ahead-of-time modes, "download multiple detail levels of this region" and "download multiple detail levels along a route". The routes themselves are also downloaded over the Internet, from a gateway server performing a format translation.

The drawback of these methods is that along practically any route, especially one that takes the user through municipal areas as well as countryside or highways, any one fixed selection of detail levels is either going to be a big download and memory requirement, or leave the user with lack of detail in critical intersections.

I think it should be possible to improve from this accuracy while reducing the number of decisions the user is required to make. The route information contains a rich level of data about the general shape of the route. In particular, there are the way-points and the distance between them, and the route data on a turn-by-turn basis for display purposes.

Just by using the way-points, downloading detail maps on the way-points themselves, and a level of detail relative to the distance when between way-points, is this selection already made not just automatic, but also richer for the end user. By also utilizing the route shape data, detail level could also be increased when the route takes sharp turns.

Finally, if any points of interest fall close to the route chosen, it would make sense to download a more detailed map around that point.

If Mapper is used in the same area for an extensive period, it might benefit of keeping records of the tracks taken (with significantly lowered resolution), and utilize a similar logic to the above for also keeping detailed maps of the frequently visited places and nearby locations. Of course the user is already likely to be able to navigate in such an area without the help of extensive maps; perhaps this information could be augmented with data about where has she tried to access the maps.

Monday 30 July 2007

Maemo Mapper GPS position accuracy

By Osma on Monday 30 July 2007, 16:03

The first thing I noticed when enabling the GPS receiver with Maemo Mapper and walking about for a while, was that the track recording wasn't very useful if you're going in and out of buildings, subways, or similar obstructions.

When in a constrained space such as on a narrow alley or street with high buildings or when the receiver is just warming up, it's common for the position to jump around on the map quite a bit, with a messy result also in the recorded track. Since the GPS receiver can also give an indication of its positioning accuracy, Mapper should take this into account and not treat the position information on the same detail level. I would suggest that the display would show a lower accuracy position as a larger circle and move it only when the new position data falls outside the boundaries of this circle. This would also "average out" the error data in the track record.

Using Maemo Mapper

By Osma on Monday 30 July 2007, 15:31

As I mentioned previously, I bought a bluetooth GPS receiver for the trip so that traveling in Portugal wouldn't need to be a constant peering of maps. Since I feel much more comfortable with things I can tinker with, and because such an alternative to closed GPS software exists through Maemo Mapper, I chose not to purchase a commercial navigation software package at all.

For those unaware of it, Maemo Mapper is a program for the Nokia 770 and N800 Internet Tablets that interfaces with OpenStreetMaps, Google Maps and Virtual Earth to provide an Internet-connected map browsing and navigation package. It depends on (gateway-translated) Google Maps for route information, and otherwise functions by downloading maps to a memory card cache.

This is a pretty cool program, showing what might be the disruptive future for navigation and location guides in a cooperative, Internet-connected world. It's also one of the more usable applications for the Nokia platform. I wish the platform in general was as well designed for its primary purpose as Maemo Mapper is. If a way to share the track records and point of interest data with others is found, I feel this application might become a category definer. Great work by just one author, John Costigan.

We've spent the last week walking about in Lisbon, driving in the countryside hill roads, and navigating around in the Atlantic coast. While I've used Mapper on and off before to consult maps, on this trip, thanks to the GPS receiver, it's finally become a constant companion instead of a curious diversion. With this experience, I've also seen where it currently (in version 1.4) falls short of a perfect experience. As I write those findings down, I will post them here as suggestions.

Google Maps POI

I wrote a tiny Perl program to process Google Maps' new My Maps KML files to a Maemo Mapper POI database (download). This should probably be converted to Python to be easily installed to the tablet itself, but for now I simply ran it on my laptop and then transferred the database over.

one attachment

Wednesday 18 July 2007

Acer TravelMate 6292 and Fedora 7 Linux

By Osma on Wednesday 18 July 2007, 21:52

As I mentioned in my previous note, my previous laptop destroyed its fan last week. Since it had started to show its age in other respects as well and was deemed not worth repairing, I got a new one yesterday -- an Acer TravelMate 6292. This is a Core 2 Duo / Santa Rosa chipset based model, with some pretty cutting-edge technology inside. I'll write down the details later when typing is easier, but for anyone who might be considering one to use with Linux: yes, it does work, quite well in fact, but a bit of tweaking is required due to its very new components.

Update: it's been 17 months since I wrote this post, and it keeps being one of the more popular things in this blog. Time to add some up-to-date detail.

  • Fedora 7 LiveCD didn't like to boot, possibly due to a missing driver (it didn't like my previous laptop's external Firewire CD drive either). It might be possible to work around by changing BIOS settings, but I borrowed a USB CD drive instead. Update: this hasn't been a problem since F8.

  • Otherwise, the LiveCD install experience (including resizing and moving the Windows partition out of the way) was a very smooth one. I hadn't done this before, and was positively surprised. I'm certain Microsoft hasn't made their install this smooth, and I doubt Apple has, either. Much recommended, if you're even a little bit curious.

  • Network-based update post-install no problem using a wired network. All in all, the install took about 1 hour to move Windows partition, 20 minutes to install Fedora, and 30 minutes for it to load updates afterwards (this was surprisingly slow for some reason).

  • Wireless (Intel Wireless 4965 A/G/N adapter) driver (iwlwifi) was preinstalled, but the required firmware wasn't (the package only included firmware for the previous model, 3945). No problem, just install iwlwifi-4965-ucode from ATrpms. Update: Intel has an official wireless site for the firmware.

  • Things which worked without any effort at all: battery monitoring, CPU frequency control, temperature monitoring, wired Ethernet, Bluetooth, docking station, and many other things I take for granted. In fact, the machine was entirely functional save for the missing wireless adapter microcode straight off the LiveCD, and all that I did for it was to improve performance past the "functional" stage.

  • Display was a bit fuzzy, and 3D acceleration didn't work. This was because the preinstalled Xorg Intel driver v 2.0 includes only basic support for GMA X3100. Both problems disappear by installing a new kernel (for updated 3D/DRI driver) and Xorg 1.3.0/Intel 2.1.0 (for 2D etc), ie by running this command: Update: Display has worked perfectly since F8 and the Intel driver keeps improving in capabilities and performance

  • Both suspend-to-ram (S3) and hibernate-to-disk work fine, once the usb drivers are forced out of the kernel prior to suspend. Create /etc/pm/config.d/unload_modules with one line:

    SUSPEND_MODULES="ehci_hcd ohci_hcd uhci_hcd"
  • Update: The Crystal Eye webcam (USB ID 064e:a101) works using the linux-uvc driver, which needs to be installed from source (download, extract, make, make install) is included in the kernel since F9. Make sure you configure each application to use V4L2 instead of the old V4L API. For example with Ekiga, choose V4L2 instead of V4L in the configuration druid or in the Video Devices Preferences. Same goes for anything based on GStreamer.

  • Something still to do about audio, apparently common to many Santa Rosa laptops and the ALSA Intel HD Audio driver, at least ones which use a Realtek codec. Notes from Ubuntu might guide you along - me, I'll try again after my vacations. Perhaps someone else will bother to fix this one. :) Update: Sound playback as well as recording work - though the recording quality isn't quite what I would expect from a "noise cancelling" three-mic setup the hardware has. I never tested it under Windows, though, so I can't say how close this is to intended quality.

  • Haven't tried to use the fingerprint reader (USB ID 147e:2016) yet, the biometrics libraries required look a bit overwhelming to install. Update: this is still not out-of-the-box functional, but the ever-industrious Bastien Nocera has recently packaged libfprint and fprintd for inclusion in Fedora 11. I've tested those packages, and they support the hardware - not quite ready for end-users, though.

one trackback

Wednesday 27 June 2007

Good luck, MySQL!

By Osma on Wednesday 27 June 2007, 13:13

BusinessWeek reports MySQL continuing with their IPO preparations. As a long-time user (about ten years now), and almost as long-time customer (in many companies, obviously currently and most significantly Sulake and Habbo), I wish you guys the best of luck on that road. Don't lose your sight of the ballgame while doing that -- we need you to continue to do better with the product itself while the distractions of investor communications will be great.

I'm sure we can all name a few nuisances in every software product we use, and I certainly have a few of those of the MySQL database, but what I really admire the guys for is their approach to innovating in the sales and customer relationships, or in the business of software. It's so much easier to deal with an Open Source project and vendor than with proprietary, old world software vendors, that I'm always willing to overlook a few problems in the product itself. It's not like the proprietary products aren't without their share of problems, either -- and ultimately, what counts is how much you have to suffer while trying to work around that. I get to add a new note on both sides of the coin to that experience nearly every day, and it's not common for proprietary vendors to win that game.

2 comments

Monday 18 June 2007

Update on Fedora 7

By Osma on Monday 18 June 2007, 22:53

A few weeks ago I mentioned having upgraded to Fedora 7, and linked to a couple of bugs that were bothering me. No longer; as far as I can tell, my laptop is now stabler than it has ever been, plus way more functional. It's like I got a new computer all together ;) In particular, the crash when enabling an external screen was just fixed yesterday by Keith Packard. Thanks, Keith!

- page 1 of 7