Monday, November 29, 2004

OpenGL - The Industry Standard for High Performance Graphics

OpenGL - The Industry Standard for High Performance Graphics: "The OpenGL Architecture Review Board has released the OpenGL 2.0 specification (pdf format). New features of OpenGL 2.0 include:
Programmable shading - With the new release, both OpenGL Shading Language and its APIs are now core features of OpenGL. New functionality includes the ability to create shader and program objects; and the ability to write vertex and fragment shaders in OpenGL Shading Language.
Multiple render targets that enable programmable shaders to write different values to multiple output buffers in a single pass.
Non-power-of-two textures for all texture targets, thereby supporting rectangular textures and reducing memory consumption.
Two-sided stencil with the ability to define stencil functionality for the front and back faces of primitives, improving performance of shadow volume and constructive solid geometry rendering algorithms.
Point sprites which replace point texture coordinates with texture coordinates interpolated across the point. This allows drawing points as customized textures, useful for particle systems. "

Friday, November 26, 2004

Roaming charges: Taken with BREW

BREW is a tradeoff. On the one hand, it's a viable choice for the mobile developer, particularly when it comes to breaking into the subscriber services market. The BREW ecosystem combines developmental efforts with an integrated business plan and worldwide delivery mechanism, providing a simple way to get an app from being coded to being a revenue generator. On the other hand, the technology is both proprietary and centralized. This kind of development won't be for everyone. If you want to distribute your code on your own and cut your own distribution deals, you might chafe under BREW's centralized model. Apps written in BREW only run where Qualcomm sends them; and at Qualcomm's discretion. That said, the general consensus on BREW seems to be that it's a proven moneymaker, which is a huge consideration if you're running a business instead of a hobby shop. Once again, Qualcomm has carved its own niche."

Roaming charges: Taken with BREW

BREW's certified security
The first thing folks at Qualcomm want known about the BREW system is that it has many checkpoints built into it, and not all of them are aimed at filtering the types of apps that get distributed. Some are technical (a BREW application does not run on a handset without a specially assigned ID number, for example), while others are structural. But, first and foremost, Qualcomm plays traffic cop with commercial developers, preventing anyone not meeting its criteria from disseminating a product over the carrier networks.

The fact that Qualcomm uses criteria at all flies in the face of how most developers work. While Sun Microsystems developed the functional specs of the Java platform and its J2ME variant, it doesn't try to officiate which Java-based apps get released. Qualcomm does, and for very specific reasons. It wants to guarantee to the carrier (which is really the end customer to Qualcomm) that BREW-based apps won't harm their networks or the handsets that use them. It's an attractive proposition for the carriers, having quality control as part of the process, and I understand that it can be portrayed as a competitive advantage compared to uncertified programs. It is a radical change in how apps are developed. But then, so is the whole Qualcomm distribution model. When was the last time a language proponent delivered the end product to the distribution channel?

One of Qualcomm's criteria is that commercial BREW developers are required to obtain and maintain (at $400 a year) a Class 3 digital certificate from Verisign. (Note that this is the standard Verisign fee, not Qualcomm's.) This simple requirement serves two major purposes: Qualcomm can use the certificate to derive the unique ID that it assigns to a developer's apps for "non-repudiation," and it adds some assurance (because Verisign does some background checks) that the developer is part of a true business and not a malware generator.

Qualcomm insists that it wants its SDK to be accessible to a wide range of developers and projects, including the "two-guys-working-at-night-in-a-garage" company. But it also wants to ensure that developers using BREW will be around in six months to update or fix the apps that carriers are distributing. So, Qualcomm encourages the casual developer, but it won't do business with you unless you can prove you're serious.

Interestingly, the Qualcomm ecosystem never requires that you reveal your source code. The company might test it like crazy (for a price that starts around $1K per app), but it only uses the compiled binaries for the testing. Qualcomm just wants to see that your app fits into its parameters; it's not interested in how you coded the thing. The company says it doesn't want to compete with its own developers.