3D to D

Good day, Habr!

I met language D at the 3rd year, but I decided to use it only one year later, when the book Alexandrescu was published. Immediately took to write laboratory, coursework. The main problem was the lack of necessary libraries (graphics, convenient mathematics) or inconvenient installation. Now much has changed, libraries are being written ( gfm , dlib , dlangui , etc.), dub has appeared. With one of these libraries I want to introduce in this post. Her name is DES . She grew up from the institute's groundwork, therefore, perhaps, it will be useful for someone to study and / or become a catalyst for learning the language.

Let's write a simple application that draws some abstract mesh on the screen.
')



The first thing that is usually done is creating dub.json with the necessary settings.

Read more about dub here .

Create a couple of folders:

• src - source will be here
• data - there will be a file with a shader

Let's do the source.


The DesApp class initializes SDL, GL, redirects SDL events to windows, and stores windows as such.

Let's move on to more interesting things.


Let's start the explanation with a strange construction

 obj = newEMM!Sphere( 1, 12, 12 ); 

And let's start from afar. In D, there is an unpleasant feature associated with the garbage collector: you cannot manage memory in a destructor. And sometimes you want. Yes, and the destructor is not called explicitly. EMM - short for ExternalMemoryManager - external memory management. This is the basic interface for almost all classes in the library. External memory refers to objects that are difficult to deinitialize using GC. For example, these are OpenGL buffers, pointers to SDL windows, and so on. ExternalMemoryManager can store other child objects that implement this interface. All salt in the destroy method, which calls selfDestroy and destroy for all child objects. It turns out some object ownership model: when a parent is deinitialized, all child objects are deinitialized. To add a new bar object as a child in foo, you need to write the following code:

 auto bar = new Bar; foo.registerChildEMM( bar ); 

This situation occurs frequently, and to shorten it was decided to put this into the ExternalMemoryManager interface method:

 auto bar = foo.newEMM!Bar(); 

The newEMM method is parameterized by the class to be created and the list of arguments that are passed to the class constructor inside the method, then a new one is returned and registered as a child object.

Let us turn to the signals. DesWindow is a descendant from DesObject, in which the connect method is declared. Each DesObject is the keeper of such a concept as SlotHandler. When a Slot object is created from a delegate, the SlotHandler is also passed, without which this is impossible. And already the Slot object is transmitted to the signal for registration. The question may arise: “Why not just write delegates to an array?”. Such difficulties are introduced into the architecture for further convenience. When we simply write a delegate to an array, everything is in order, the context reference is stored, the GC does not touch objects, but this is a different situation. The object that implements the ExternalMemoryManager may still exist, but now the call to any of its methods is no longer appropriate after the call to destroy (). For example, we can free the OpenGL buffer by this point, and the delegate in the signal will be recorded. Not good. SlotHandler is the impersonation of the context via the ExternalMemoryManager. It is a child of any DesObject, and when it is deleted, it disconnects itself from all connected signals, so we don’t need to worry about it. The signal has a connect method and we could write

 draw.connect( this.newSlot( { obj.draw( cam ); } ); 

In any case, we need someone who can be blamed for the validity of the delegate context.

ivec2 is just an alias for Vector! (2, int, "xy | wh | uv") ...

Next file src / draw.d

And the data / object.glsl file

A little bit about the camera and SpaceNode. In OpenGL to the 3rd version there was a concept of a stack of matrices, separately specific and matrix models. Everything is a bit simpler here, although you can make the same stack if you wish. Each SpaceNode contains a pointer to the parent SpaceNode and a transformation matrix from the local to the parent coordinate system. The parent SpaceNode can also be null. The camera is also a SpaceNode, but with some additional fields and methods. The main difference is the presence of the method of resolve, which takes SpaceNode and returns the transformation matrix from the object's coordinate system to the camera's coordinate system. For this, a separate Resolver class is used. In fact, it can be used to look from any SpaceNode object to any other.


But in general, that's all. Run the dub build and get the binary in the bin folder.

It is clear that there is little information in the article, so I suggest that interested people collect the documentation.
We focused on the documentation for the harbored-mod project, so if you want to generate a dock using the built-in dmd function, the result will disappoint you.
For unix systems, go to the ~ / .dub / packages / des-1.3.0 folder and run path / to / harbored-mod / bin / hmod and open doc / index.html in your favorite browser. Just do not forget about the package descore, which should lie next to the des, for him in the same way going to the documentation.
There are many interesting things, ranging from linear algebra, to logging and localization systems.

By the way, this example is in the folder des- / example / object_draw.

I hope someone will find this useful, thank you for your attention.