Looking at Delphi game development with Asphyre

Delphinian pointed out two Delphi game-development SDKs I hadn’t known about: Pyrogine and Asphyre.

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 license

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.

Concerns

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.

But…

Screenshot of the “Shooter” example, from the sprite engine add-on for Asphyre eXtreme

they certainly can do graphics.

Leave a Reply

Your email address will not be published. Required fields are marked *