Archive for the ‘graphics’ Category

Scourge, Part IV: Kneel before Quad!

Wednesday, April 3rd, 2013

I’ve realized recently that Scourge’s client has many layers, and jotting down a list of those layers helps maintain my perspective of the work yet to do. Distinguishing layers is an easy activity – if System A connects to System B, and A can invalidate B, but B cannot invalidate A, then A is a layer above B. That’s helped me identify the following layers, each of which has its own problem space:

  • Server connection – are we online? (HTTP/UDP comms)
  • Session – are we authenticated and up to date? (user object)
  • Battle – who are we fighting and what actions can we take? (the ROPES)
  • UI Narrative – what action/data is the player considering? (narrative tree nodes)
  • View – What does each button and view component look like? (view objects)
  • Renderer – What does each particle look like? (glyph objects, model arrays)
  • Graphics – What does each pixel look like? (GPU buffers, write-only)

And that’s only the stuff that’s going into the demo! I left out the AI stuff from this list, because like the state of the human player, it interacts with this layer cake at some level. It’s just a higher level than the one human beings interact with.

Anyway, while I’ve spent a lot of time focusing on the Session and Battle layers in the past, for this post I will focus on the Renderer and Graphics layers, which I’ve been working on for the past three months. They’re only a piece of the puzzle, and currently the Graphics layer is dependent on Flash and Stage3D, but that’s a small price to pay for the ability to work this stuff out while I wait for Haxe 3, H3D and NME’s OpenGL features to stabilize. (As I’ve previously mentioned, Scourge should be able to target every platform that one can target through NME, which is quite a lot. The graphics pipeline just needs to mature a little. I will color your pixels!) (more…)

Handling clipboard events in AIR

Tuesday, July 27th, 2010


If you read that last post, you know about Tyro. Since I designed Tyro to be able to handle clipboard events, I expected it to respond to my cut, copy and paste keystrokes when I put it in an AIR application. It didn’t work. Can you think of why?

If you guessed it had something to do with menus, you’re correct. You seem pretty clever; maybe you want to follow along and try this project at home? Clipboard commands are usually provided through the Edit menu of an application, such as a web browser. Most people have learned through experience to rely upon the common keyboard shortcuts that software developers commonly bind to the clipboard commands, but know this: if your browser’s developer didn’t think to include that overlooked Edit menu, all your absent-minded key tapping would do nothing. (more…)

Overthinking Text

Tuesday, July 27th, 2010

Remember 2008? What a great year. Especially in November, when we made history. I remember watching the ceremony on video feed with friends. People were cheering and crying.

No, wait. I mean 2007, not 2008. You know, when Adobe showed us a sneak peek of Flash Player 10, and Peter Elst’s posted video coverage gave his blog a bazillion hits as Flashmongers everywhere watched Emmy Huang spin a MovieClip in 3D. “Whoop dee doo”, you might say with hindsight-equipped eyes. It’s 2010 and all those new tricks are now old hat, right?

Not exactly. While the novelty of 2.5D and IK handles may have faded away, one of Flash Player 10’s new features– the advanced text engine– has lagged behind the rest. That’s because the text engine is very low-level, and wasn’t exposed to designers in the Flash Professional authoring environment. Until CS5 was released this past April, only developers had access to the FTE. That’s kind of ridiculous, and Adobe knew that. And so began the efforts (by many different people) to bring TextField-like usability and new text functionality to the Flash platform. (more…)

Crisp Rasterizations with Flash 10’s 3D

Sunday, March 14th, 2010

My last post was about guaranteeing beautiful vector graphics in Flash. Unfortunately, the project I’m working on that uses these graphics (which again I’ll talk about at length some other time) transforms them in 3D space. Unsurprisingly this leads to some complications.

Most people forget that Flash can do native 3D, and when they see it in use usually they think it’s “innovative”. Frankly it’s not; Flash has had a 3D API since late 2008, but there are reasons why most people don’t see much of it:

  • Most designers and developers aren’t taught much about 3D transformations, or even 3D aesthetics.
  • The tools Adobe’s released to design 3D Flash content are in their first lifecycle, and are only in one product (Flash CS4), which has a ton of other new features too, competing for user’s attention.
  • There are plenty of classic techniques for producing 3D media that does not require Flash’s 3D API
  • Perspective projection of objects means that a 3D object has to be redrawn each time it is moved in 2D space, unlike a 2D object

And the sneaky one which I’ll be talking about,

  • Flash’s beautiful vector graphics may become fuzzy or pixelated when you transform them in 3D.

Thus a skilled and determined designer-developer team who find themselves in the right scenario could end up producing 3D Flash content. But if they ignore the last issue, their output might have a lower visual quality than what they’d like. Let’s look at why that is. (more…)

Getting good vector shapes out of Flash embeds

Saturday, February 27th, 2010

A recent project I’ve been working on utilizes a couple faces from M+, a beautiful FOSS font set. There are several ways to embed fonts in Flash, and I prefer using the [Embed] meta-tag, which plays nice with the majority of the IDEs out there. However, a straight-up font embed tag wasn’t working well at all for me. The text that appeared onscreen was broken and misshapen in places.

It turns out that mxmlc, the Flash compiler, employs several “font managers” for taking embedded font files and “transcoding” them into Flash fonts. The primary manager relies on a Java library called Batik to convert the letterforms of the font file into Flash-friendly curves. I’m not sure why this was the case, but Batik was flummoxed by some of the faces in M+, specifically with the capital ‘O’ letterform.

I mean, you could trace a big O by hand if you wanted to. It’s cake. I can’t imagine why M+’s ‘O’ is so difficult to process, but if it can happen with this font, it could happen to any font.

I only managed to get good shaped text with one font manager- the one that also handles transcoding OpenType fonts and such, which uses the new Compact Font Format (CFF) system in Flash 10. (To learn more about this subject, here’s a post about the new CFF embedding system.)

It might seem subtle, but when you compare the text side by side, I think you’ll agree that all this CFF stuff I had to do was worth it. Below is the same SWF, one with M+ text imported with Batik, the other with CFF. (more…)