There have been a number of people blogging about creating AS3 sorting algorithms. Most have come to the conclusion that it's not possible to create a faster sorting algorithm than the native one provided for Vectors. And who can blame them? It seems very unlikely that the Flash Player's native algorithm would be slower than any interpreted AS3 algorithm.
Well, it turns out everybody was wrong, and sorting with an AS3 algorithm is indeed almost twice as fast as it's native counterpart!
Consider the following code:
package
{
import flash.display.Sprite;
import flash.events.Event;
import flash.utils.getTimer;
public class Sorting extends Sprite {
public function Sorting() {
addEventListener(Event.ENTER_FRAME, loop);
}
private function loop(e:Event):void {
var data:Vector.<Number> = new Vector.<Number>();
for(var i:int = 0; i<10000; i++){
data.push(Math.random()*10000);
}
var data2:Vector.<Number> = data.concat();
var t:Number = getTimer();
data.sort(sf);
trace("Native sort", (getTimer()-t));
t = getTimer();
data.sort(sf);
trace("Native sort on ordered elements", (getTimer()-t));
t = getTimer();
shellSort(data2);
trace("AS3 Shell sort", (getTimer()-t));
t = getTimer();
shellSort(data2);
trace("AS3 Shell sort on ordered elements", (getTimer()-t));
}
final private function sf(a:Number, b:Number):int {
return (a==b ? 0 : (a < b) ? -1 : 1);
}
final private function shellSort(data:Vector.<Number>):void {
var n:int = data.length;
var inc:int = int(n/2);
while(inc) {
for(var i:int=inc; i<n; i++) {
var temp:Number = data[i], j:int = i;
while(j >= inc && data[int(j - inc)] > temp) {
data[j] = data[int(j - inc)];
j = int(j - inc);
}
data[j] = temp
}
inc = int(inc / 2.2);
}
}
}
}
The class will simply run two native sorts to test the performance on a totally randomly ordered Vector.
and then run two sorts on the same data with a pure AS3 implementation of shellSort.
Shell sort has a good worst case resolve speed and works quiet well even when the origin data is already sorted or almost sorted.
The results
On my iMac native sort on the Vector with 10.000 Numbers took an average of 50 milliseconds. When sorting the already sorted Vector again, it took an average of 38 milliseconds.
The AS3 algorithm took an average of 31 milliseconds to sort the random Vector and only 15 milliseconds to sort the sorted Vector. (Update: in debug mode!)
In real life where Vectors that need to be sorted are usually not totally random, you'll get a two-fold increase in sorting speed compared to the native algorithm.
Some things to consider, though: Shell sorting in this example gives you a head start over the native sorting algorithm that the data to be sorted are primitives. If you wanted to sort Objects (typed objects of course) based on one of their properties shellSort would no longer outperform Flash Player's native sort, as the speed is eaten up by those numerous object property look-ups. However even then it comes very close and in programs that often sort Vectors with objects that are already almost in the right order, you'll beat the native sorter by 10-30%.
But there's one great type of project where speeding up sorting of Numerical Vectors will increase application performance greatly and that's 3D. I started to dig into these algorithms after my profiler told me that 25% of all of my CPU time was going into sorting 3D polygons. Only the drawing operation was slower, but not by much.
P.S. If you want even better performance, don't just rely on a single sorting algorithm. QuickSort is 20 times faster than Shell Sort if the Vector is already sorted, but absolutely freaking slow if the Vector sorting order is random. In 3D scenes it might be a good idea to switch between these, using Shell sort for your initial render, the user quick sort if your model rotates only slightly and thus only a few poly's are out of place.
Update: Erik correctly pointed out that I should test the sorting algorithm in the release player instead of the debug player in debug mode, as this might affect results. And indeed it did. It made Shell sorting became much faster. A vector with 100.000 random Numbers took:
Native sort: 338 ms
Native sort on ordered Vector: 245 ms
AS3 Shell sort: 98 ms
AS3 Shell sort on ordered Vector: 49 ms
Who would have thought that interpreted code can do the job 3-5 times more quickly than a native call.
Permalink | Comments (7)
Previous posts in this series:
Straight from the start of our MMOG Platform project we knew we wanted to create a technology which is better than anything previously available (or unavailable in the case of proprietary, closed platforms). Quite big words, so we needed a big idea.
We didn't start the project with a concepting or architectural design phase. Instead we wanted to get coding straight away and try out some of our initial thughts in a working example and build out the technology stack from there. So we decided to start with a simple game which would still enable to test most of the critical aspects of our technology:
Asteroids.
Although TrunkTech (the code-name for our technology platform stack) is designed to run MMOG's, we don't want to limit what kind of games you can write with it. While most people think about online MMOG's being isometric, tile-based, slow-paced games where the emphasis is in moving to a certain tile and chatting, we did not want to make that assumption. We also wanted TrunkTech to be able to deliver realtime, multiplayer action-games as part of the virtual world, so Asteroids was a great playground. You have free-moving ships, fast-paced action, network latency to take into account, a world that has to be synronized across clients and server-side game logic.
After creating the single player game it took us about 30 minutes to get multiple players connect to the game space, have the space synchronize itself across all the clients with everyone swooping around without any noticeable problems from lag. Pretty sweet.
Eventually we didn't finish the game as we got too excited about what we had just unleashed and got on to create the rest of the technology stack.
Client synchronization and metaprogramming
We've been programming the client-server-side solution for a few months now and in retrospect must say that the most important ideas that we came up - which enable us to create multiplayer games in a fraction of the time it would usually take - were automated synchronization and metaprogramming.
Without getting into the boring details, our synchronization stack works essentially this:
When a client connects to a game instance (essentially a script written in AS3) the TrunkTech client and server start talking without imposing any work on the actually developer of the game or it's objects. The server synchronize the game state with the client using our custom-developed, AMF-based protocol to get the client up to speed on what's happening inside the game instance. For example, a number of other players might have joined earlier and shared their avatar instances (essentially the representation and behavior). The game instance itself might have spawned a number of game objects that need to be shared across all clients (e.g. the actual Asteroids in the Asteroids game), or the state of the game instance itself (time remaining, high-score, ...). All this synchronization happens without any developer intervention. You just join a game instance and automatically receive all the shared objects that are associated with the game.
Even after receiving the first representation of a shared object it's properties will of course change overtime. A spaceship might change it's course, accelerate, rotate, or a Avatar might say a phrase. But again, the developer does not need to implement anything to make this happen. TrunkTech keeps all shared object in sync by sending messages back and forth and automatically updating properties of these shared objects or calling it's methods as requested by the originating client.
Once connected to a game space, the client can choose to add some object to the game instance itself (his avatar or spaceship or whatever). From a developer perspective all that is needed to do is to create a instance from a Class that itself extends the SharedObject definition and tell the game instance to add it as a object that needs to be shared across all clients. The SharedObject base class will take care of all the hard work to keep the objects synchronized. This all happens through object introspection made possible by metaprogramming.
Whenever the programmer wants a property of an object to be synchronize he adds some metadata to the property to describe the type of synchronization necessary to keep all clients up to date an be able to simulate the behavior of the object perfectly. Synchronization might happen at certain intervals or whenever the property or state of the object changes.
In the ship class of our little Asteroids try-out, all we really needed to do is define metadata for a few properties to get that object synchronized correctly to all clients and thus convert a single-player game to multiplayer. Whenever the state of the controls change (an Vector containing the down-state of the arrow keys), these get synchronized. The metadata for the control-property states that whenever it's state is synchronized, the location and speed of the ship should be synchronized as well. That's really everything you need to know to simulate the movements of one ship across multiple clients.
The server is of course aware of all shared objects across the game instance, including all of their properties and can even intervene and change them at will, essentially taking control of a users objects. When a new client joins the game instance in the middle of the gameplay, the server has all the necessary information to send all the shared objects to the arriving client at get them up to speed.
Take away
Metaprogramming is utterly cool and provides you with the tools to create a system which magically do complex tasks on a complex set of objects but let's you preserve the speed at which AS3 operates by not using dynamic objects.For MMOG platforms, where you don't want to restrict the imagination of the developer actually building out a product it's a fantastic tool which let's the developer write cleaner and meaner code in a fraction of the time otherwise required by taking all the hard stuff of client synchronization and dealing with it "in the background".
Obviously I need to show you some code examples for all of this to make sense, but that's a topic for some future writing.
Permalink | Comments (5)
It's odd that I feel this happy for something that does only indirectly affect me. Still I feel that the whole world has become a better place as Barack takes his place as leader of - what can once again become - the free world.
Congratulations to everyone in the U.S. I have absolutely no doubt that the next years will be better than the last.
Permalink | Comments (0)
Thanks to good spam filters, I've received very little unwanted emails during the last few years. So little indeed that I didn't even remember that spam is still a huge problem. Well, our spam filter's license expired and it took a few days to get it back online. My email was almost rendered unusable with the HUGE amount of spam arriving in just 48 hours.
So to anyone behind a filter who's wondering whether spam is still a big problem... Yes, very much so.
Permalink | Comments (2)
Recently we at
Valve started work on a huge MMOG (Massively Multiplayer Online Game) project with a U.S. based games publisher. It's supposed to go live in a little less than a year from now, but we've already got a big team working on the MMOG technology and preproduction.
We're actually not only building a game, we're creating a end-to-end technology platform (code-named TrunkTech) which enables us (or anyone else for that matter) to create browser based MMOG's very rapidly. And I really have to emphasize the word "rapidly", as we've set extremely ambitious goals for our technology.
I'm currently the lead front-end developer and am closely working together with a phenomenal Java guru to specify and develop ( actually specifying through developing ;) ) out the low-level bits and pieces for our technology.
And I must say, I'm having a blast! At long last I'm able to work on stuff that I have almost no prior knowledge of, make sure that whatever code I write should still be readable in five years time and work on a game that I truly believe is going to be a big hit.
So I thought of starting to write a series about building MMOG's with Flash (yeah, it's Flash based), and share my thoughts and learnings from the experiences I gather by working on TrunkTech.
To get an a subject for my first post under this title, I'll start of easy:
Why Flash?
When we stared the project we quickly came to the conclusion that our client would be Flash based. Currently, the biggest web-based MMOG is
Habbo, from
Sulake (back in late 2000, I was supposed to become the first employee of what was later to be Sulake, but I chose to go to Razorfish Helsinki instead. But yeah, that's a different story altogether). Habbo is based on Shockwave, and frankly, I believe that Shockwave is still (barely) alive because of Habbo. Shockwave has seen it's best days and is quickly loosing penetration, developers and the will to live. It's too old and clumsy and has never been a productive development platform.
As we really wanted our games to be playable by everyone on the net without installing anything whatsoever, Flash was the obvious candidate. And as we did not intend to go full 3D (our MMOG's are not for hard core gamers), we quickly ditched Shockwave and
Unity3D as our client-side platform of choice (although we may want to revisit Unity3D at some stage as it's really gaining traction right now).
Flash, ecpecially with the second incarnation of it's virtual machine, has become great for development of even very complex technology platforms with it's modern and fast virtual machine. AS3 is strongly typed, catches quiet a many errors at compile time and let's the developers who use our API debug with strong tools. The syntax is modern and is ECMA-Script compliant... err... Well it was supposed to be, anyways, so people with Web development skills in general can quite easy hop on. Networking is robust as we now have access to binary sockets (very important, more on that later on). And most importantly Adobe is pushing the technology into the right direction, and Flex Builder 4 is going to make development even easier with better debugging, intellisense and auto-completion.
We did pause for a brief moment when deciding upon the technology, though. Why? Rendering speed.
While the VM2 is fast enough for most of the logic we're expecting our platform to be used for, the same thing can't be said about rendering. Kids expect quiet a bit of graphics crunching from todays desktop games, and online games are catching up really quickly. Even five years ago Shockwave was able to harness the power of the GPU, making it still about 10.000 times faster to render texels as Flash 10 does (mileage may vary). While this is crucial for 3D games, it would still make a lot of sense to have 2D drawn on the GPU aswell. (and no, don't even dare to write a comment about wmode=gpu, unless you're Tinic and have some ace up you're sleeve).
But in the end, we quickly decided that penetration was far more important than rendering speed. There's a lot we can do to make up for the poor rendering speed in Flash by beeing creative and applying a trick or two, but penetration is something you can't cheat yourself around.
Up next
In the next few posts I'll talk a bit about our Server (Java-baed), Bamboo (our client-server protocol), our server-side scripting language (ActionScript3 compiled into Java byte code, aha!), meta-programming to let developers "multi-playerize" applications really fast, mixing 3D with pixel bender to texturize a great number of 3D model based avatars and any other experienced I might find worth sharing (or you requesting).
Stay tuned.
Permalink | Comments (5)
Off to beautiful Milan this Saturday, with a bunch of my colleagues. It's sort of lame that all the new introductions were already made two weeks ago at the U.S. MAX, but I'm still looking forward to the great sessions.
Anyone else from Finland attending? It would be good to meet up for a late brunch on Sunday for example.
Permalink | Comments (0)
With every update to Flash I've felt a great urge to blog about one missing feature. But I've always withheld my outcries because I thought it was such a no-brainer that Adobe would just have to include it in the next minor update. With CS3 I thought they just didn't have the time to implement it, but certainly a minor update would implement it. Now with CS4 the feature is still missing, and I just have to accept the fact that it's not coming if nobody requests it.
What am I talking about? Copy-pasting from Photoshop!
There must be millions of Flash developers and designer wondering why one can't correctly copy-paste a selection from Photoshop to Flash. You'll get pixels, but no transparency (it's totally opaque), rendering it almost completely useless.
My work-flow probably is quite different from everybody else's, but I can't imagine a single developer or designer not been confronted with the problem of getting a single piece of graphic from a Photoshop document to Flash really quickly. Sure, you can copy-paste the selection to a new document, remove the documents background, crop it, save it as a PNG and then import it into Flash, but that's way too cumbersome. We've even implemented an action in Photoshop which will do much of the work for you, but it's still not as easy and quick as copy-pasting.
So please Flash/Photoshop teams, get your act together and implement this trivial but important feature.
Permalink | Comments (5)
Uh, I was on vacation in San Francisco and just got my phone bill... 800€ (780€ from roaming data). Yeah. I knew that roaming was fucking expensive, but 7.99 € per megabyte? That's so 1980's. And I even made extra effort to use public WLAN access whenever possible, preload my iPhone's Google Map app with the spots I was about to visit and not read email at all when using GPRS.
From now on I'll try to use telepathy whenever I'm in the U.S.
Permalink | Comments (4)
So I finally got my first iPhone app ready for distribution through Apple's AppStore. I've always found it odd that Apple didn't include a Feed reader app with the iPhone in the first place, so I decided to write my own. I really enjoyed writing Objective-C and using all of Apple's excellent development tools, but actually getting it to publish on the AppStore (it still hasn't) is an experience I could have lived without. I don't mind reviewing and signing all the necessary paper work and even calling to some Indian guy to get US taxation stuff sorted out, but what really bugs me sleeping restlessly each night and waking up early to check whether my app would have finally made it's way to the AppStore only to find out it hasn't.
I can live with the review process taking a week, but what bothers me is that my App has been in "Ready for sale" status for a week now, without it actually going live. And any inquiries send to Apple have simply not been answered. It would be nice get at least some kind of faint echo to my emails.
By the way, a big thanks to Junnu for designing the fantastic icon for "Feeds". It looks gorgeous on an iPhone.
Permalink | Comments (3)
Woot! Get it while it's hot. And yeah, Astro did seem to move a lot of compositioning to the GPU!
Permalink | Comments (0)
Yeah! We just received word that UPM Forest Life won the Corporate Communications category Webby Award.
Webby - check.
New York Festivals - check.
LIAA - check.
Cresta - check.
Now the only big one still missing is the CyberLion.
Permalink | Comments (1)
We've got a new opening. We're now also looking for senior web developers. Check out the requirements.
In addition to that we're still looking for Concept Designers, Game Developers, Game Designers, Flex Programmers and Project Managers.
Permalink | Comments (0)
Flash Media Server 3 includes functionality to verify that a connecting SWF has not been modified by a third party:
"If desired, you can configure the server to verify client SWF files
before allowing them to connect to an application. Verifying SWF files
prevents someone from creating their own SWF files that attempt to
stream your resources."
This feature works only in FP 9.0.115, so I guess the Player performs some kind of checksum on the running SWF when a certain AMF3 connection is opened (or the server requests for the checksum to be computed). The great thing about this is that this cannot be spoofed (if the user does not modify the Flash Player itself). This means that you can be absolutely sure that the SWF connecting to your server has not been modified in any way, making it very easy create a trusted relationship with the client.
Now, how the hell do we implement this absolutely fantastic feature in non-media server projects? It has to be in the AMF3 protocol somewhere. Anyone? Adobe?
Permalink | Comments (3)
Just wanted to post a quickie to say how much I love FireBug. It has made my day about a million times.
Big thanks to John Barton (and anyone else involved). You've made programming JavaScript 1000 times more enjoyable.
Permalink | Comments (0)
The
Adobe User Group Finland is hosting a special live event to share
exciting new information on Adobe's platform tools and technologies for
building RIAs. You'll see an exclusive user group video presentation by
Adobe Chief Software Architect, Kevin Lynch, hear some important
product news, plus get your hands on some exclusive schwag and other
giveaways.
Be part of the fun and excitement and join the rest of the Adobe
developer community by participating in this very special event.
When: Wednesday, February 27 at 18pm
Where: The place not decided yet, we will inform members, or just watch this blog
Speaker: Kai Hannonen, the manager of AUG
Subject: New information on Adobe's RIA platform (hmm, what could this be? ;))
Permalink | Comments (1)
Jup, its out, and it's gorgeous.
But what? 2GB of memory and not upgradeable?
They certainly had a lot of squeezing to do to fit all into such a tiny shell, but once I upgraded to 3GB on my MacBook Pro I made an oath never to go back to 2GB again. I would have never believed it, but adding memory really is the best thing to do if you want to increase the your productivity. The difference is like night and day, even if you're working only in a few apps (ok, thats CS3 apps I'm taking about).
So no MacBook Air for me... :(
Permalink | Comments (3)
So I got me an iPhone from the US a week ago. Unfortunately I did not visit the hackint0sh forums beforehand, otherwise I would have known that you no longer can SIM-unlock it since new models got a new boot-loader. Fortunately there are some inexpensive hardware-hacks around, so no big deal.
But reading through the forums at Hacint0sh, it struck me how much frustration and anger silently Apple's move to silently disabling existing software-hacks has caused. Don't get me wrong, Apple's move to stop hackers from SIM-unlocking their device was expected and in my mind also just. In the end they are a public company and they're doing everything to increase their cash-flow. Someone at Apple - who probably is much smarter than any of us - has calculated that locking down a device to one operator and getting a share of the operators revenue is more lucrative than selling the device to anyone who wants it. Therefore they're just acting like any sane business would.
However, I most ponder what the hell has happened that locking down a phone to a certain operator even is possible. Think about these cases for a while:
What would you say that when you buy a new car that you have to agree to use only gas-stations from BP (all other stations would be incompatible with the tank's nossle).
Or that when buying a new PC, you'd also had to subscribe to two year expensive ISP contract?
Sounds really stupid, doesn't it? But hey, binding a device to a certain Telco operator is in my mind the same thing.
Ok,ok. I live in Finland. A year ago it was illegal to bundle a phone with a subscription. And now it's only possible for 3G devices (apparently our legislators bought the idea that 3G phones need to be pre-configured by the operator to be useful. My arse!).
Living in such a free country I get a rash whenever I hear of U.S. telcos.
When we launched WidSets news started come in that Sprint restricted socket connections to "3rd party services". My initial thought was "OMG, another great internet-wall of china". The same thought came to mind when a month ago T-Mobile restricted mobile access to Twitter overnight. Next morning they explained "that Twitter was not a supported service"...
If my operator did the same thing I probably would sue them just for the principle. Since when does the free (as if) world tolerate censorship? Come on guys, revolt!
Permalink | Comments (3)
Whoa, what a busy years end. I've been working like crazy to get my projects finished before the end of the year... Still one more week to go.
Meanwhile we're closing the year with many competition successes. Fressis, a campaign we did with Hasan&Partners (unfortunately they totally "forgot" to mention us) got bronze at Eurobest and silver at Epica.
UPM Forest Life also got silver at Epica and won at the European Excellence Awards.
Kännissä olet ääliö won the campaign-category at SIME a few months ago.
Now bring on the new year!
Permalink | Comments (0)
I must again give it to the Apple designers, they've done a fantastic job in creating Leopard's GUI. Where visuals between Windows versions are plagued with the throw it away and redesign from scratch syndrome (aka not inveneted here syndrome, if the lead UI designer changed between versions), Apple designers seem to follow the mantra of changing things just enough to make the visuals appear fresh and modern.
The devil is truly in the details. Leopards visual changes are so small, but yet make a huge difference. The OS just feels much more modern compared to Tiger, and all it took was some settle changes here and there instead of throwing out all the visuals out and designing from scratch. As a user I hugely appreciate this kind of design. I feel comfortable and familiar from the first second, yet still there is a welcome freshness to the UI.
There are however a few things which I would have liked to see implemented. I don't know why Apple has made the decision to implement a slight delay when highlighting menu items. It's been there since 10.0, but in my mind it downgrades precision when navigating a large menu. When quickly moving the mouse over, say, 20 menu items, only a few items are highlighted along the way. This makes my Mac feel slow. The other thing is that UI controls still lack any rollover indication. I don't want the Windows christmas tree treatment, but a small, settle highlight when rolling over controls would again add some precision to daily UI tasks.
Permalink | Comments (5)
Jaiku, a social mobile service with emphasis on rich presence who has shared the same office space with us has been acquired by Google. Congratulation guys! I'm still mad that they recruited one of the best web developers I've known from us, but hey, seems he made the right decision.
And since I've created some Flash apps for them I can finally say that I've done some work for Google. Sort of at least;)
Permalink | Comments (1)
By now you've probably heard and seen the news from MAX. Custom filters, fills and blend modes using the Adobe Imaging Framework and coded with Hydra. Nice. But... Why not go further? AIF certainly makes use of the GPU to very quickly manipulate bitmap graphics by passing in one or two images to the graphics card and a compiled hydra-script which instructs the GPU to basically create a pixel shader and apply that to a textured rectangle.
Now it seems that the good stuff ends there. While fast image manipulation (and we're talking realtime fullscreen image manipulation as opposed to Flash 8's slow software filters) certainly is cool, why not go all the way? I wold guess that only the image manipulation is done on the GPU and that the Flash Player then retrieves the rendered texture from the GPU to pass it back to the Flash Players software rendering pipeline. I would have really loved to see all (or most) rendering taking place on the GPU.
Tinic, how about one of your great technical posts on this subject?
Permalink | Comments (0)
Rooooar!
I've been optimizing the performance of one of our larger site productions the last week and took quite good care at making page elements cache correctly using expiry dates for each element type individually and gzipping any content that would benefit from it.
Well, today was time to test the performance of the front-page on multiple browsers. The site is really very complex. Initially we load 130kb of (unzipped) JavaScript and make 2200 method or function calls before anything is rendered. I tested the overall performance with and without a primed cache and must say Safari's performance blew me away.
For instance, IE7 takes 300 milliseconds to run the initialization procedures of the JavaScript classes.
Safari: 28 milliseconds.
What? Ten times faster? Even Firefox, which I to this day thought to have the best JavaScript engine of all browsers, takes 89 milliseconds.
Initial page load times on Safari seemed to be a little better than on Firefox, although lacking extensions like Firebug, I was not able to test that scientifically.
But what most impressed me was page load times with a primed cache. The site is designed so that all static elements like CSS or images have expiration dates, so essentially all that needs to be loaded when navigating back to the front-page would be the dynamically generated HTML. And looking at the server logs I confirmed that none of the browsers actually requested or revalidated any of the static elements.
Still Firefox and IE take about one second to render the page.
Safari: Instant. Really, you have to experience it to believe it. I've never experienced anything like it on any browser before. You hit the link and boom - its there. No delay whatsoever (well, ok, maybe the 28 milliseconds which it executes the JS in).
And the best part? I'm running Safari on Windows Vista on my MacBook Pro. Yep, hell has frozen over.
Permalink | Comments (7)
Once again one of these posts... We're looking experienced Flash & Flex developers to join our team of brilliant people. I can without hesitation say that we've got the best Flash developers in Finland and we're looking for more!
So if you're are, or are looking to become one of the leading Flash and/or Flex developers in the Nordics Europe the World, drop me an email ( tuomas.artman(at)valve.fi ) with some references and a short bio. And oh, you would need to relocate to Helsinki, but the winter is not as bad as they say... Err, who am I kidding... It is.
We offer good compensation, great projects, even better colleagues and definitely great challenges and a fantastic learning experience.
Permalink | Comments (6)
The next Adobe User Group Finland gathering will take place next Friday at our brand new office café. This time the subject is ColdFusion and presented by Tero Pikala, a CF guru and Flex developer. Tero will give us an overview of ColdFusion and tell us about the integration possibilities with Flash and Flex.
Time: Friday 7th of September at 17.00
Place: Valve, Pieni Roobertinkatu 7, 00130 Helsinki
Join in on the fun!
Permalink | Comments (1)
There's a lot of hate-mail on diverse websites from people who have upgraded to iLife '08 and found that the totally revamped iMovie lacked a lot of features from earlier releases. While that's totally true (although I really didn't care for the features people are now whining about), I think what they did with the interface is again something every UI designer should take a look at.
Taking the gesture of selecting a block of text and applying that to video clips sounds weird a first, but oh boy, it works! Skimming is again a first for Apple. A really simple idea which no-one thought of but everyone is bound to imitate. I know I will.
Permalink | Comments (4)
I'm done using Cairngorm. It's just too much boilerplate code to write. Today I started to create my own micro nano-framework called GrainCorn. As the name implies it's quite close to Cairngorm. Or close at least when it comes to best practice rules. There's a huge difference in the amount of code you have to write. And that got me worried a little. Is there some deeper meaning to the Event-Controller-Command relationship that I'm just not getting?
In Cairngorm when you want to create a new Command you have to do three things: Create the Command class, register it in the Controller and create a Event class which eventually fires the command. Now, what's the reason to separate the event from the command, since the event always fires the command to which it has been registered, i.e. the event transports data (attributes) into the execute-method of the command.
After some thinking I came to the conclusion that it's easier to bend the spoon itself rather than to bend yourself around the spoon.
GrainCorn gets rid of the Event, and actually the Controller as well. That leaves us with one Command-class to create for every feature we'd our application to have. You issue a command by simply instantiating a new instance of a command, passing any parameters in the constructor:
new LoginCommand(username, password);
It's not necessary to store the command in a variable, since registering itself with the framework is handled by the command itself (every command extends GrainCornCommand). Also no controller is needed to bind Events to Commands, since we've removed Events altogether.
Any thoughts? Am I missing something?
Permalink | Comments (12)
Again shortlisted at Cannes this year, and still no Lions. UPM Forrest Life, which was one of the two finalists, is in my mind one of the best productions we've done in the past year, so I was a bit disappointed that we didn't get a Lion to bring home. But what the heck, this just leaves us even more hungry for next year. Growl.
And yeah, only two projects were shortlisted from Finland, and both were made by us. So either we're really good or then the overall quality of Finnish interactive agencies is quite bad. I would actually guess its both.
Permalink | Comments (0)
Huh, Ted revealed that Flex 3 will launch synchronously with a new minor release of the Flash Player. New features? Script caching! Visit a site that uses a specific Flex framework and the framework gets downloaded. Visit a second site that uses the same Flex framework and the framework will be loaded from cache, and only the application is downloaded.
And if you're developing Flex (and Flash) projects for a number of domains under your control, you can use the script caching to deploy a single, only once downloaded runtime shared library for all your apps.
Script caching is something we've been talking about with Lari over oh so many Gin & Tonics. Luckily in this case, the walls must have had ears.
Permalink | Comments (1)
We are organising a meeting on Wednesday 30th of May at 18pm at Valve. We're excited to have Flex Evangelist Ben Forsaith speaking at the event. Ben will give a talk about Flex and Apollo. After his presentation we will continue with free discussion about the same subject (and a few beers maybe?).
As seating is limited, please use the contact form on the AUG.fi-site to let us know if you are going to attend!
Permalink | Comments (1)
Our company is looking for a senior web developer (Helsinki, Finland). Candidates should have at least 5 years of experience using ... jada-jada-jada ... you know the drill. Seniority. Superb markup- and programming skills. Great projects to work on. Fantastic people. Drop me a mail at tuomas.artman(at)valve.fi if you're interested.
Permalink | Comments (3)
Wow, the PR department at Apple is really, really good. First they turned their problem with the EU over DRM to their advantage by having "Steve" write an open letter to the community, and now they've done it again, with Apple going green, err, Apple being green, oh wait, no that's not the way it went. Well at least Apple is the greenest of the bunch already - or are they? Nice brainwashing.
Permalink | Comments (0)
You've heard the news (in case you didn't, it's all about Flex going Open Source). Very good move from Adobe, and not only for the community, but for Adobe itself.
The Flex SDK and compiler have already been freely distributable, so Adobe's money is coming out of Flex Builder and server products. On the other side, money is spent on creating those freely distributable products. So why not kill two flies with one stroke. By open sourcing the SDK and compiler, the community gets a better product (more frequent updates, better performance, more features), which increases interest in Flex and drives sales and resources can be pulled (well, at some point) from the SDK and compiler teams because the community is doing all the heavy lifting.
Now people of course start going "c'mon, the only thing you haven't open sources in the Flash Platform is the FlashPlayer (apart from the AS3 engine), how about opening it up?". Dare not wish things you really don't want to see, say I. It's ok to let everyone contribute to the Flex SDK, and have millions of builds flying in each direction, since in the end, a flaw build only crashes one single application. But imagine a community driven FlashPlayer out there. New releases and branches every week. Some group would add 3D Hardware acceleration immediately, others would work on MOD-player support, and both would be distributed and not compatible and we would loose the most important aspect of Flash - ubiquity.
Permalink | Comments (2)
Ted has a great post on the shortcomings and mistakes of Silverlight. Some of the things he points out are obvious (Having 0% penetration is really problematic, although MS is of course going to bundle it with Windows/IE, but who uses them anyhow ;) ) , but there were a few big surprises (at least to me). For example, Silverlight does not stream. Ok, that makes sense, since it's not binary. But to me the killer was:
Silverlight does not have a scripting language built in, but uses the browsers JavaScript capabilities. Yeah, WTF? Welcome to debugging hell!
Of course, modern browsers are quite compatible, but to me it still means that I'll opt for my sanity and keep my hands of Silverlight (well, at least until it supports hardware-accelerated 3D on Mac)
Permalink | Comments (5)
I just put MillionClouds into production (it's only a soft launch, so pardon the dust, I know it's there...). It's my first public Flex application and I've enjoyed working on it every minute.
MillionClouds is a joint venture between our company and Christian Yakowlef , a renowned finnish photographer. The idea behind it is that whenever you arrange a photo shoot the only thing that you cannot control is the sky, so advertising agencies very often require replacement skies. Now you could go out and wait for the perfect weather or try your luck with any of the major image banks, but searching for just the right sky is really a drag if you have to use keywords (blueish cumulus clouds with 20% overcast on a nice day won't get you any results ;) ).
MillionClouds gives you a very nice and intuitive user interface to search for exactly the sky you need, and IMHO it's working beautifully. We've not yet tagged most of the images, but I just wanted to put this baby live. Oi, Christian, how about pulling yourself together and tagging the rest of the images, now that it's live? ;)
Try out the color sort functionality, found under the Global Filters panel. It produces some great looking results.
Permalink | Comments (12)
Check out UPM Forest Life, in by opinnion one of the best Flash sites we've been working on in the past half a year or so. Although I've not contributed to the project that much, I'm still very proud of it.
Permalink | Comments (5)
Man, technology sometimes just moves too fast.
A few days ago, the Nokia N95 went on sale world wide and I got mine. Today, I got a newsletter from Nokia Forum with an interesting topic; Widgets go mobile. Apparently it's a framework to Web driven applications for the S60 platform, much in the same way as Apple's widgets or Microsoft's gadgets. Both from a user and developer perspective it totally makes sense. Use technologies you know (html+javascript) to develop connected application rapidly and launch them like they were applications on your mobile. But! I just bought the newest, coolest and most expensive phone multimedia device and WTF! Mobile widget's wont work on it! Cause mobile widgets come with S60 3rd edition feature pack 2, and my device only has feature pack 1.
God! It only took 4 days to make my shiny new device an old fart.
Permalink | Comments (5)
Huh, don't know where the count goes, but Amazon has once again released product details a little too early, thanks a bunch;)
Their CS3 product page contains pricing, screenshots and most important features. One thing which caught my eye was the inclusion of Acrobat Connect (a.k.a. Breeze) in every package. Surely this can't be the real deal, but some sort of launcher application where you still need to purchase a separate account?
Update
Didn't notice it earlier, but the site also says that CS3 will ship
April 20th, far earlier than has been speculated.
Permalink | Comments (2)
So I bought a PS3 two days ago. I was looking forward to finally use my somewhat old HDTV to enjoy 720p action. Ok, I have had some decent action with my XBox360, but you know, that's still analog VGA.
The first thing that I thought was weird is that Sony does not ship the PS3 with any hires cables. No problem, i thought, just pay a few bucks more... As it turns out, Sony also does not sell any DVI-cables (my TV is about two years old and thus does not come with HDMI. Also the component input only allows for 576i). Luckily HDMI is just DVI+sound with a different plug, so I buy a HDMI->DVI cable. Now how do I get decent sound of my shiny PS3? With optical audio, of course. Unfortunately my amplifier does not support optical audio, so I head to a Hi-fi store and buy a new amplifier and optical wires. At last I have everything I need to enjoy superior picture quality.
I connect everything, select HDMI mode and.... nothing.
F*ck. I mess around a bit but the screen remains blank.
Googling around a bit I notice a lot of problems users are having with some HDTV's. A term that I've not heard before is in most posts: HDCP - High Bandwidth Digital Copy Protection. I've always thought of a TV being just a bloody stupid enhancement of the oscillator. A signal comes in and images are displayed. Boy have I been wrong. HDCP is a copy protection for the "last feet". The signal that comes out of your Blue-Ray or HD-DVD is still encrypted, so that swappers have no easy way of recording that data-stream, and HDCP encrypts it just before it hits the screen. Ok, this surely is something that a mere mortal does not need to know, does he?
Well, he does, if he has bought his LCD HDTV a few years ago.
As it turns out my f*cking LG RZ-32LZ50 does not support HDCP.
Err, I'm quite certain that the store that sold me the LG said that the TV is HD-Ready. HD-Ready is a strandard which basically says that the TV has at least 768p resolution and supports HDCP (since most HDTV services, be it satellite or blue ray require HDCP).
So what happened? Well, the store actually did not use the term that described HD-Ready standard, but they had a sticker on the TV which said "HD-Valmis". "Valmis" is a finnish word which translated into "Ready". So they did not user the standard HD-Ready, which would have given me something to complain about (they promised me something that was incorrect, which by Finnish consumer law would have given my complaint quite a bit of leverage). But because they just said "You know, this TV is ready for some of the future services because it has good resolution", I doubt I'll ever be able to have them refund anything.
The point of this story? If you're an early adapter of any technology, be sure that you know all the pitfalls involved, even if it's a simple consumer electronics product such as a TV, Microwave-oven or toaster.
Permalink | Comments (1)
Now that I've had a little time to play with Apollo (mostly lovin' it) I can't shake the idea of how great it would be to have proper (x)HTML support within the Flash Player.
You know, Flash is really, really bad at laying things out (as in layout ;)). Basically you have to define and code a heck of a lot to create something really simple. Flex does this a lot better, of course, but having spend the last 2 months with it I must say that I really do miss the elegance and simplicity of xHTML & CSS.
Flex does a good job at laying out and controlling UI controls, but a really lousy job at making it easy to display structural information. And that's the beauty of Apollo. It's inbuilt browser. Whenever you need to display a ton (or even less) of information, there's no better option than HTML. So in effect you get the best of both world, a very powerful application framework and a great way to display structured information.
So I wonder, what would be the size of a stripped down version of the Web-Kit be? Small enough for FP10? Forget JavaScript, XML support, AJAX. Just implement a decent subset (or all of the specification) of XHTML and CSS2 (ahh, if not 3) into the Flash Player and I will be your friend for life.
You've already done it for Apollo, all you now need to do is remove two thirds of the code you have in there ;)
Permalink | Comments (5)
