Search Results for 'reflection'

A number of people have written me over the past few months to mention that they’ve had trouble getting the Reflection component to work in various cases. I haven’t had time to look at each of the problems, but I do have an updated version of that may work better. If you’ve been having trouble with the original Reflector code, try this one out and let me know if it fixes your problem.

Digg!digg this | | 12 Comments

Jason Langdon took my reflection component and made a new version that adds blur, which actually makes it look a good deal more realistic (higher levels of blur make it look like it’s on a less polished “table”). Very cool.

Digg!digg this | | 1 Comment

UPDATE 2/21/2008: See this post for the latest version of I’ll reintegrate it into the source code linked to from this post eventually, but for now you’ll need to download the code from this post, then replace with the version from the newer post.

Okay, enough highfalutin’ chatter. This entry actually has (arguably) useful code in it.

The reflection effect is destined to become one of those gratuitous UI clichés, like brushed metal and gleaming highlights. But hey, the kids seem to like it, so I figured I’d try to make a similar component in Flex.

Before jumping into the explanation, here’s the demo:

You can drag the panel around to watch the reflection follow it, and play with the sliders to tweak the look of the reflection.

I’m not the first to attempt this: Trey Long created a reflection effect in an early beta of Flex 2 (the demo pointed to from that link no longer works with the shipping version of Flash Player 9). However, his version created static reflections—so, for example, you could see the reflection of a Button, but if you moused over or clicked on it, the reflection wouldn’t update to reflect (no pun intended) the visual changes to the Button.

I decided to make the reflection “live”—as you interact with the components being reflected, the reflection actually updates in (near) real-time. I also componentized the reflector itself, so you can just target it at a component and it automatically positions itself appropriately. I used code very similar to Trey’s reflection filter to render the reflection bitmap, though the way I actually draw it to the screen is a little different.

Read on for an explanation of the code: (more…)

Digg!digg this | | 48 Comments

Another year, another new project. Flex Mobile is well underway, and I’ve transitioned over to a group within Adobe working on gaming technologies. Of course, Adobe products, and Flash in particular, are heavily used in game development, and we’ve started to increase our focus on gaming over the past year. One of the first key technologies we’re delivering is a GPU-accelerated 3D API in the Flash Player codenamed “Molehill”, which enables incredibly beautiful and incredibly performant 3D content to be built using Flash. And just last weekend, we’ve put up our first public pre-release of Molehill as part of the Flash Player Incubator program on Adobe Labs.

Now, if you’re a hardcore 3D programmer, you’ll know exactly what to do with Molehill, and Thibault Imbert has a great introduction to the API for you. But if you’re anything like me, and your development experience has been in the world of 2D graphics or UI, you might find even this introductory material pretty head-scratching. Vertex and fragment shaders? Index buffers? Assembly language? LOLWUT?

I’ve just recently been learning more about GPU-based 3D programming myself, so I thought I’d try to make a molehill out of the 3D development mountain, and write an introduction to what this stuff is all about for those of us who are coming from the 2D world. In this first post, I’ll generally describe how modern GPUs work. I’m planning to write a follow-up post with more detail on how you actually work with the GPU for 3D graphics, and then another follow-up on how you can leverage the GPU for incredibly fast 2D graphics as well.

One caveat—I may say a few things that aren’t strictly true, mostly because I might be deliberately oversimplifying, but also because I might just be ignorant. Overall, I don’t think this picture of the world is too misleading, but please feel free to correct me in the comments.

Update: One fundamental point I meant to make when I originally wrote this post, but forgot to add, is that Molehill rendering is completely separate from display list rendering. All of the drawing that Molehill does basically ends up in a single layer that essentially draws into the background behind all of your display list content—the two don’t interact at all. I’ll discuss how you can leverage Molehill for 2D in a future post.


Digg!digg this | | 5 Comments