“They don’t throw exceptions. They don’t even return numeric error codes”

Throwing exceptions in full-screen Direct3D app will ruin your app and your IDE (when debugger is enabled) and you won’t be able to save your work. Exceptions inside the framework increase Coupling, so you will need to know more about internal working of Asphyre in order to handle its errors properly. Thus, exceptions were not used.

Many Direct3D calls silently fail and the error code is usually given later on. In most cases, Asphyre intercepts and handles known failures. Also, it is usually easy to determine the cause of error depending on what method failed. Finally, Direct3D debug runtimes give all the necessary debug information for each method and each failure, in detail. End users don’t need to know this as their technical level is probably much less than yours. Thus, numerical values are not used. Check our game Wicked Defense to see how errors are handled.

“They don’t seem to have heard of try..finally. As a rule, they don’t do any resource protection.”
You haven’t explained what you meant by “resource protection”. As for “try..finally” - read above about exceptions.

“Then why was I just able to whip up a proof-of-concept that put two (un)DelphiX TDXDraw instances on the same form? Not to mention the possibility of multiple forms (MDI and/or SDI).”
Your argument is still very weak. Direct3D needs window handle to present the final rendering on some surface, however, this handle can be changed at any time and thus is independent of a particular instance of TForm, not to mention that technically, it needs to know nothing about Delphi’s TForm class. (un)DelphiX does things differently and is heavily dependant on VCL, whereas Asphyre is not. Suffice to say that Asphyre can be used in FPC/Lazarus, while (un)DelphiX cannot.

“Form size (DisplaySize). Classes used to draw on the form (GameDevice, GameCanvas). Variables that are populated by the form, only used by the form, with the same lifetime as the form.”
DisplaySize is the rendering surface size and is independent of form size. Try resizing the form and you will see your rendering rescaled to fit new size.

The form creates these variables as in Factory Pattern. The variables are not necessarily used by the form itself (in Asphyre examples they do for simplicity of code).

Ideally, Asphyre components must be placed in a separate class called TGraphicsCore. This is an ideal architecture.

“I do still dislike the globals…”
Apparently, your whole review is based solely on pure personal taste. You could as well write about how you dislike eating apples or oranges.

Just because you like or dislike something does not mean that a certain feature is badly used. In fact, it makes your review biased and less objective.

I tried my best to clarify few things to you politely even though you have shown a certain arrogance and disrespect to Asphyre developers.

This has been discussed to death on PGD. Read thread named “Error handling considerations”.

Cool. I’d love to read more about this. But it would help if you could give me some idea of where to look.

I took a guess that your reference to “PGD” might have meant “pascalgamedevelopment.com”, but there aren’t any threads in their Asphyre forum with “error” in the title. I couldn’t find anything in the afterwarp.net forums, either. And a Google search for error handling considerations site:pascalgamedevelopment.com turned up nada, as did error handling considerations asphyre.

Could you post a URL or something?

if you want to “seriously work with Direct3D” my friend, you’d be using debug runtimes.

Could be. I know very little about the DirectX debug runtimes at this point. Although I don’t quite see how they would make Asphyre return anything more interesting than False.

And they wouldn’t do any good when someone else tries to run my program. With no opportunity to get anything more meaningful than Boolean result codes, I expect any problems would be a bitch to troubleshoot.

Nonsense. Direct3D device *is* global, and it has nothing to do with VCL.

Hmm. Then why was I just able to whip up a proof-of-concept that put two (un)DelphiX TDXDraw instances on the same form? Not to mention the possibility of multiple forms (MDI and/or SDI).

In fullscreen mode, yes, it might as well be global. But in windowed mode, not so much.

Where did you see “form state”?

Form size (DisplaySize). Classes used to draw on the form (GameDevice, GameCanvas). Variables that are populated by the form, only used by the form, with the same lifetime as the form.

They are all variables related to Asphyre, which is unrelated to FORM and/or VCL in any way.

I will grant you that Asphyre is GUI-library agnostic. I hadn’t thought about that angle, and I can see using globals to make the code more easily cross-compilable to other libraries. (Although if that was the goal, wouldn’t all the drawing code live outside the form, too?)

I do still dislike the globals, but if the reason is easier cross-library compatibility, then that becomes more of a personal preference. There are other ways to do it, but globals do have simplicity going for them.

It’s not cluttered, it’s just happens you don’t like it.

I suppose that’s fair. But it’s not a coding style that Delphi developers would find familiar.

This has been discussed to death on PGD. Read thread named “Error handling considerations”.

2) “They don’t even return numeric error codes.”

This is how older versions of Asphyre did it. However, if you want to “seriously work with Direct3D” my friend, you’d be using debug runtimes.

3) “They seem to like using global variables to hold non-global state.”

Nonsense. Direct3D device *is* global, and it has nothing to do with VCL. Same applies to other Asphyre components, which are stored as global variables.

4) “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?”

Where did you see “form state”? They are all variables related to Asphyre, which is unrelated to FORM and/or VCL in any way.

P.S. The coding style is propietary. It’s not cluttered, it’s just happens you don’t like it.

When you are talking about the “experience of Asphyre developers”, please search on Google the following article:

“Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own
Incompetence Lead to Inflated Self-Assessments”

It will help you improve the quality of your reviews.