As promised, April 4, new track. It's a bit more weird than the previous one this time ;) Seems like the collisions doesn't behave too well on replays tho, won't detail much on what's the problem, long story... However, on play time behaves pretty well.

Have fun!

http://www.sprintenterprise.com /burnandbrag/383080404145134

no comments

It's a bit off-topic in this blog but Rachel sent a very interesting article about Facebook to Hi-ReS! list the other day. It gives some logic to Facebook and, specially, to Zuckerberg robotic words/behaviour.

Read it on your lunch time.

http://www.guardian.co.uk/technology/2008/jan/ 14/facebook

In other news, yesterday I finally managed to understand how displacementMapFilter really works and how to use it properly, which means that in some days I will post some explanation of how you can do this, and, with a bit of luck, also this. Which, by extension, means that my refraction example is not right :(

no comments

Ok, sorry about the joke. No, unfortunately flash can't handle 1million particles at 30fps in a G4...

Anyways... here is the real explanation... There isn't much to explain really, the effect is very simple, in fact, it's about 1kbyte in size...

Basicaly, you use anything as input, copy it to a bitmapData that you're blurring and offseting verticaly, and on top of that you have to put a greyscale Perlin Noise texture, also scrolling verticaling in BlendMode.OVERLAY.



Take a loot at the Source file

no comments

Some people have asked about how the loading/fire effect was done on the Sprint Nascar Monster Burnout site.

Well, it's quite easy. Every vertical line on the loading bar is a emitter of 10,000 pixel particles that travel up in a sinusoidal pattern with a random phase each. All of them leaves a trail on the bitmapData which a colorTransform fades to black, on top of that there is a blurFilter on the bitmapData too. In total, when the loading is at 100%, there are 100 x 10,000 = 1,000,000 pixel particles moving, leaving trails, changing colours and the blur on top. Quite simple and I think it looks good, if you wonder how come the effect also runs fast on a G4, well... think a bit more ;)

UPDATE: Well, this was clearly (or maybe not) a April fools geek-joke. Click here to see real explanation of the effect.

no comments

Well well, seems like it's finally live. So, that's the site I've been doing a this little game for during the last months at Hi-ReS!. We should be activating a room next week and another room the week after. Probably improving some bits here and there in each release. Click here to see a replay from myself, otherwise click here to have the complete experience.

Used the ubercool (and free) FlashDevelop 3.0.0 Beta 6 and it features box2dflash for the car 2Dto3D physics, a modified version of Papervision3D 2.0 (Effects branch) and, believe it or not, Tweener for the replay. Oh! it also features loud and annoying sounds, you've been warned ;)

After working on it for that long I don't know if it's fun or not. Hope you like it.

3 comments

I'm following a little bit Breakpoint's TV this weekend. While I was at it I was wondering how come the stream and image quality was that good. After Charles'ing a little bit I found out that the stream was rtmpsomething... googled a bit more and found out that was nothing else than the recently anounced Flash Media Server 3 RTMP protocol.

So, somehow, Breakpoint organisers managed to get Adobe to let them test their new technology. Nice one guys! So, if you want to see the future of video streaming with Flash, take a look at that videostream, and while you're at it, take a look at the content too specially try to watch Sunday's evening demo show ;D

UPDATE: Obviously, as the event is now over, the stream is now down, if you missed it, I'm sorry.

no comments

http://evil.hackademix.net/fullscreen/applet.html

Eeewww! I wonder how long will it take to the phishing / spammer professionals to use this "trick". Thanks for the tip Andre!

no comments

So, here I am, still finishing off a project I've been doing at Hi-ReS! for almost 4 months already. Doesn't matter how many time I look at it, I can't see where I spent all that time. I guess it has been all on research, file optimisations, fighting with Papervision3D 2.0... By the way... Andy and Tim, thanks a lot for the constant help! <3!

I could explain some tricks I've learn on this project, but I'll leave it for some other post... I'm already out of focus... The snippet of the day:

FLV to BitmapData Sequence

On the project there were some textures that were FLV animations. At first I had it as a bitmap sequence on the library and it was running quite well, but obviosly, that would be intraframe compression, which means BIG. So, .FLV needed to be used instead. And as it was interframe compression the filesize was much more smaller. But the problem then was that it was making the whole app almost 10fps slower. The decoding of the FLV plus (bad) looping was being very CPU expensive.

So, somehow I had to find a way to mix both best features, small filesize and low CPU usage, the easy answer was just, somehow, creating a bitmap array with each frame in the video (the video doesn't have sound btw). Tried it using the Video methods (seek() and stuff) but there was no way I could jump frame by frame. I guess using these methods you can only jump to the next keyframe. As having a keyframe per frame was going back again to the intraframe compression it was time to google a bit.

Unfortunately (and also fortunately) the only bit I found was this Seb's post, which thanks to Tink managed to find a decent approach for the issue.

Just as Tink suggested, create a .SWF with the .FLV embeded (which, somehow, stays at the same filesize). Having that you get the MovieClip's magic methods: gotoAndStop(), nextframe()...

So, the only thing you need is the small class I put together today:

BitmapDataSequence.as

It's the first version, so don't expect more than the basic stuff. Oh, and yes, it runs MUCH faster than the .FLV and it loops nicely oh, and you could easily change the FPS too.

1 comment

I wisth they just used Bass and we had even .xm support, but... somehow, I don't think that will ever happen.

Actually, it would make sense if MOD files went back to life thanks to websites. MOD files are very small in size compared to a MP3, and produced by the right people they can sound really well.

no comments

From here...

".xap" files (pronounced "zap") use the standard .zip compression algorithm to minimize client download size. A "hello world" .NET Silverlight application (built using VB or C#) is about 4KB in size.

If a "hello world" takes 4KB already, what a real application would take? A "hello world" in AS3 seems to be 400bytes btw, a 10%.

Lots to do M$, lots to do...

no comments