Just got the idea - you need to find some kind of hobby. Otherwise, you can move out of the coils. And since I’m a very useless person, I don’t know how to poke buttons, this will be my hobby: at least once a week to make a stream with writing a toy. After stream record is published on Habré. (You can try to post on Habr live straight, but it is very difficult).

Writing is very feedback driven - if someone needs an explanation, then I can explain as I can. If you have any suggestions, I will try to take into account. On Habré read all the comments to the last, in other places - as it will.

The first pancake is here:

Under the cut - a thesis description for those who just broke to spend an hour and a half to watch.

Guiding ideas

The first interesting aspect is that I want to write everything without the grummers. How does an ordinary javist do? There was a problem - figachish in the dependence of the airgame, and he solves the problem for you. The price of this is because of such a swine project turns into a pigsty, and no one can exactly determine what is happening. I want to try to write without this pig farm, clean and neat. Perhaps this is impossible - please report in the comments.

Second aspet. I've been kodil on java and php all my life. There was the experience of developing toys, but only the server side with the answer over the network, and never - a real desktop application in C ++. Therefore, in essence it will be a freak show - a person who does not understand the question will try to somehow describe in his own words what is happening.

No, all this has no practical significance. This is not to move out of the coils, and to motivate adult bearded uncles, too, take up the keyboard and gash some toy.

Rutina strikes a nickle

Unfortunately, programming never begins with easy and enjoyable entertainment. Initially, there is a period of painful digging in the settings of the environment and the IDE.

The first thing I understand about Visual Studio is a great tool for a professional, but it makes a very frustrating impression on a beginner. After Eclipse and IntelliJ IDEA everything, you know, is some kind of unnatural, lilac and hopeless with re-subduction. The matter is not in any way VS, it’s about me :-)

And with the plugins there is always some kind of trouble.

Therefore, by a strong-willed decision, we reject Vizhalki and see what else is there. Vim, Emacs, and other editors who do not understand the source structure are sent by the forest. The very first attempt to use Eclipse failed, so the CLion tool was chosen .

The problem with CLion is that it still does not know how to fully work with the Visual Studio compiler. If you try to do something in it, it will be like this:

Of course, there would be a thread in the goshniki and start screaming in a hysterical voice that there will be enough debug prints for everyone. But we will not listen to them, of course.

Therefore, you need what CLion can do well, and this is MinGW.

Choose MinGW

There is a large version table .

And it shows that it makes sense to look only at Cygwin and Msys2. Msys2 is some kind of weird - it has few committers, the packages lie on one of the authors' own githubs . On the other hand, it is really cool - there is a fresh compiler and a lot of packages. This is crucial.

The installation consists in squeezing next-next-ok, and then repeatedly running the update command ( pacman -Syu , as in Archlinux) with restarting the Msys2 terminal, until he says that everything turned out in the best possible way.

If you simply install Msys2 according to the instructions and try to add it to CLion, not a single toolchain will be found. You need to install it yourself; this is done with the pacman -S mingw-w64-x86_64-toolchain command.

After installing this package, CLion launches helloworld (which is automatically generated when creating a new project) and debugging works in it.

Check feature # 1: simple window

First of all, I want to understand if at least some desktop application will start. Still, this is not the native PlatformSDK, but MinGW.

For this, an uncomplicated prog would be suitable, drawing a window using WinPi.

And yes, with MinGW it starts up. But with the Visual Studio toolchain, it pours some errors, but I didn’t deal with them, because why, if the target platform is already working with us?

Check feature # 2: triangle with shader

It is clear that to write something viable is not enough to display pixels on the window. It is brake, inconvenient, there are no fancy stuff. In short, we need DirectX.

The key question about CLion + MinGW is exactly that. If they can not use DirectX, then go to the trash.

For testing, a very short tutorial consisting of only two files was loaded: in one, all C ++ code, in the other - a shader. The challenge is to stumble it to work.

In addition to single-file, this tutorial is very good because it tells how it works on the fingers. Perhaps this article should be transferred to Habr (write in the comments).

The finished result is here GitHub . Here I will describe what problems met.

Little things and trash

Many L-lines have become just lines. You can delete small letters L. In many places, you need to replace NULL with 0 so that it does not fall.

Despite the fact that set(CMAKE_CXX_STANDARD 17) used set(CMAKE_CXX_STANDARD 17) , nothing interesting happened to this plan at all, nothing fell apart.

Headers and libs

The point, of course, is that this example is a very ancient one, written at a time long before Windows 10. DirectX is no longer in a separate DirectX SDK as it was at the time of our ambiguous youth, but is stuffed directly into the Windows SDK.

Therefore, the first thing to do is to run the Visual Studio installer and check that the latest version of the Windows SDK is installed.

The second question is in the headlines.

 #include <d3d11.h> #include <d3dx11.h> #include <d3dx10.h> 

They are no more, you need something like:

 #include <d3d9.h> #include <d3d10.h> #include <d3d11.h> #include <dxgi.h> 

And then in CMakeLists add the search to them at the end of the file:

 set(LIBS d3d9 d3d11 d3dcompiler_43) target_link_libraries(src ${LIBS}) 

Missing APIs

Previously, there was such a structure :

 typedef struct D3DXCOLOR { FLOAT r; FLOAT g; FLOAT b; FLOAT a; } D3DXCOLOR, *LPD3DXCOLOR; 

And it is no more. However, in all the places where it was really needed, it turned out to replace D3DXCOLOR(0.0f, 0.2f, 0.4f, 1.0f) by {0.0f, 0.2f, 0.4f, 1.0f} .

The problem was more interesting with D3DX11CompileFromFile . She is no more!

In the article Living without D3DX, they suggested replacing it with D3DCompileFromFile .

But here's the problem, D3DCompileFromFile is also inaccessible for some reason too!

A small investigation revealed that Microsoft’s documentation suggests using a very new version of the API:

And MinGW sends us into the past for several years:

However, in the 32-bit version there is a newer header, but I didn’t figure out how to add it to 64-bits. 32 bits probably did not give up in FIG.

On the one hand, this is very sad, because it foreshadows hemorrhagic relations with MinGW in the future. I wonder who mantelins all these cases.

On the other hand, if you take the missing D3DCompile and the present D3DCompileFromFile :

 HRESULT WINAPI D3DCompileFromFile( in LPCWSTR pFileName, in_opt const D3D_SHADER_MACRO pDefines, in_opt ID3DInclude pInclude, in LPCSTR pEntrypoint, in LPCSTR pTarget, in UINT Flags1, in UINT Flags2, out ID3DBlob ppCode, out_opt ID3DBlob ppErrorMsgs ); 

 HRESULT WINAPI D3DCompile( in LPCVOID pSrcData, in SIZE_T SrcDataSize, in_opt LPCSTR pSourceName, in_opt const D3D_SHADER_MACRO pDefines, in_opt ID3DInclude pInclude, in_opt LPCSTR pEntrypoint, in LPCSTR pTarget, in UINT Flags1, in UINT Flags2, out ID3DBlob ppCode, out_opt ID3DBlob ppErrorMsgs ); 

it turns out that there is only a difference:

  in LPCWSTR pFileName, 

vs

  in LPCVOID pSrcData, in SIZE_T SrcDataSize, in_opt LPCSTR pSourceName, 

Unfortunately, I do not know C ++, so I knew how to do it myself: I just added the file reading and redirecting this data to D3DCompile .

 void WINAPI D3DCompileFromFile(const char *filename, const D3D_SHADER_MACRO *defines, ID3DInclude *include, const char *entrypoint, const char *target, UINT sflags, UINT eflags, ID3DBlob **shader, ID3DBlob **error_messages) { SIZE_T data_size; char* buffer; ifstream infile; infile.open(filename, ios::binary); infile.seekg(0, ios::end); data_size = infile.tellg(); infile.seekg(0, ios::beg); buffer = new char[data_size]; infile.read(buffer, data_size); infile.close(); D3DCompile(buffer, data_size,filename, defines, include,entrypoint, target, sflags, eflags, shader, error_messages); } 

The only important difference between the D3DX11CompileFromFile in the darkness of ages and our self-made D3DCompileFromFile is that the new API has no ID3DX11ThreadPump as a parameter. Is this something asynchronous, maybe some kind of trappool? However, it was not used in the tutorial, there is 0 in its place.

Results

A bunch of DirectX + MinGW + Msys2 + CLion is viable enough to cut down a simple game. It is possible not only to use basic WinPi, but also to draw, and even with shaders.

In general, everything. I remind that the simple result lies on GitHub .

Please remember that this is not my code, but a modified text from the tutorial - however, I hope that its use is fair and targeted. But nevertheless, that is why there is no normal license there .

Feedback

Please write in the comments your comments and suggestions. For this, everything is done, listen to what you say. Especially if you are a seasoned igroprogrammer, straight bison, a bison, and do not fit into the thread in size. Be sure to go and write something.

I remind you that I, like any other blogger, eat likes and designs. The more furiously you will arry up the arrow under this post, the more likely the next post and stream will be released.

© Alexander Raevsky