I’ll ignore Pyrogine, since it’s still vaporware at this point — nothing available to download. But Asphyre has some possibilities.
Editions of Asphyre
Asphyre comes in four different flavors, and they don’t try very hard to help you figure out which one you should use. As far as I can tell, though, it comes down to this:
- If you want bleeding-edge 3D effects, use Asphyre 4.1. It’s not yet release-quality (all they have are snapshots) and it always requires the latest and greatest version of DirectX.
- If you want something more stable, and don’t mind requiring DirectX 9, use Asphyre eXtreme. It’s billed as their “most stable” version.
- If you don’t want to require DirectX 9, use Asphyre Casual or Asphyre 1.5.2. Asphyre Casual is not yet release-quality (all they have are snapshots). Asphyre 1.5.2 is an older version and is no longer in active development. Take your pick.
Asphyre eXtreme looks like it’s probably the preferred choice for most applications.
Asphyre is open-source, released under the MPL.
This makes it a much better choice than (un)DelphiX, which has a license agreement saying it’s illegal. So I’ll definitely be looking at using Asphyre going forward.
The big downside I see so far is that Asphyre clearly wasn’t written by experienced Delphi developers.
- They don’t throw exceptions. They don’t even return numeric error codes. Everything is Boolean result codes: “it worked” or “it didn’t work”. With a rich exception system just waiting to be used, it’s pretty inconsiderate for them to give such crappy feedback, especially with something like DirectX where poor drivers can make so many things go wrong.
- They don’t seem to have heard of try..finally. As a rule, they don’t do any resource protection. (This may be because of the previous point, but it’s still pretty sloppy coding style.)
- They seem to like using global variables to hold non-global state. To take one specific example, the “Basic” sample project, in the Asphyre Casual package, stores form state in a unit full of global variables. Shouldn’t form state be on the form?
Less damning, but just as interesting, is the way they don’t follow common Delphi coding standards. They indent blocks by one space instead of the usual two. They clutter their code with empty parentheses after method calls and declarations. They don’t prefix field names with
F. They don’t use
FreeAndNil. In short, they don’t seem to have spent any time looking at Delphi code.
they certainly can do graphics.