Development blog

YASM integration with Visual Studio 2010, 2012 and 2013

YASM is a great assembly compiler, it supports a lot of instruction sets, assembler syntaxes, output formats, … so since Visual Studio started to use the compiler intrinsics for some versions, in my case, for x64 code, I switched to use YASM as I don’t want to mind about different syntaxes or weird and crazy compiler keywords, I just want to create a single .asm file and rule all platforms!

As if all this was not enough, it can be integrated with Visual Studio, just unzip the package vsyasm and follow a few steps given in a readme.txt.

For the 2008 version, it worked fine but recently, I tried with Visual Studio 2010 and the latest YASM v1.3.0 but all I got, where error messages. Time for investigating it!

I checked the command line used by Visual Studio for calling YASM and quickly saw it was a problem with a parameter. YASM expected the parameter “-f” to be win32 or x64 but in newer Visual Studio versions (2010, 2012 and 2013), Win32 is used instead win32 so it caused the error.

I spent some time “googling” for it and I found that the issue was already reported and fixed by a patch on 2014-October-05:

So why it was failing then? Simple, the binary package I downloaded from the official YASM web site was compiled on 2014-August but the issue was fixed some months later.

At this point, I didn’t spend much time looking for a vsyasm binary compiled after 2014-October, I just went to the Git repository and downloaded a full copy of the source code (as of 2015-June-09). I thought it was very straightforward to compile it but well, sometimes I’m wrong :). It took me like 1 hour till I could build YASM with Visual Studio 2010. Finally, I got two packages, one for 32bits and other for 32/64bits, so I used them on my project and bingo! they worked fine as the patch promised!

I imagine that sooner than later, I new build will be available on the official web site that using recent code, will fix this and other bugs but in the meantime, I think it can help you (saving your time trying to compile it!) if I upload them ready to be used:


SDL2, Direct3D11 renderer and Windows 7

SDL2 has some good renderers, specially for Windows OS: Direct3D (version 9), OpenGL, software and since a few months, Direct3D11 (version 11) was also added.

The first three, have been extensively tested while developing CRM64Pro and some bugs were found, submitted and fixed so it is quite stable and ready for production games. Recently, I have interested on the Direct3D v11 renderer, it uses Direct2D so it could be faster than Direct3D v9 and I always have read that Direct3D v11 is cleaner than v9 and a big performance increase can be obtained. Well, now is where this history begins.

All my computers have installed Windows 7 SP1 and have some VMs running RHEL6, Fedora, Windows XP, Windows 8 and Windows 10 for testing purposes and I mainly use Visual Studio 2010 with Windows 8.1 SDK.

After downloading SDL 2.0.4 latest snapshot (as of today), enabling Direct3D v11 (it is disabled by default but you can enable it on sdl_config_windows.h file), compiling and linking against a test application (testrendertarget project), I started to take some performance numbers to be used as reference against Direct3D v11.

In general, Direct3D v9 is faster than OpenGL renderer although it depends on the video card and drivers (in my case, an AMD Radeon HD6950). The problem was when I executed the Direct3D v11 test… it miserably failed not matter what I tried! with this error:

Couldn’t create renderer: D3D11_CreateSwapChain, IDXGIFactory2::CreateSwapChainForHwnd: (random characters, aka garbage! Later on, during debugging, I could see that the error code was: DXGI_ERROR_INVALID_CALL)

I did the mandatory “googling it” and after spending some time reading several but non-related to SDL2 stuff about this interfaces, I started to think that probably the problem is the Windows 7 itself but well, I know it is able to support DX11 and my video card too so time for checking the SDL2 Direct3D v11 source code implementation.

I quickly see that it is using DX11.1 and not DX11.0. The former one was introduced on Windows 8 but later on, a patch was released for Windows 7 users that partially implemented some functionality of DX11.1 on Windows 7 systems. This patch is named “Platform Update for Windows 7” (KB2670838) and if you have updated your system, there are a lot of chances that you already have it.

The key here was the word “partially implemented”, so apparently, some functionality of DX11.1 is not available on Windows 7. I read the Microsoft documentation to exactly check what is supported and what is unsupported. It was not very hard to find that the CreateSwapChainForHwnd() method has a field for scaling and when it is set to DXGI_SCALING_NONE, Windows 7 with the platform update caused a DXGI_ERROR_INVALID_CALL. In other words, Windows 7 does not support calling CreateSwapChainForHwnd() when scaling is none.

Following the mandatory curiosity, I changed DXGI_SCALING_NONE by DXGI_SCALING_STRETCH, which is supported and, indeed, it succeeded! but while debugging the application I found that there are calls to other methods that are directly unsupported as IDXGISwapChain1::SetRotation() and more, so I stopped here and fully understand that SDL2 Direct3D v11 renderer does not work on Windows 7.

Now, I wanted to know what happen on a VMs with Windows 10 Preview installed, so I did the tests and voila! Direct3D 11 renderer works fine so, I imagine also works on Windows 8. The problem is that I can not test the performance on a VM as the numbers are not representative in comparison with a physical machine.

At the end, it was like a mix of feelings: I was able to understand everything so I was happy, but I could not test the performance of this renderer and that was my initial goal. At some point in the next days, I will reinstall one of my computers with Windows 10 and I could go on with this test. The final goal is to update glSDL Benchmark including this new renderer in order to have a good and reliable performance numbers.

The conclusion is that SDL2 Direct3D v11 renderer does NOT support Windows 7 and you need Windows 8+ for enjoying it.


CRM64Pro…

Ha pasado mucho tiempo desde el ultimo post, lo bueno es que durante 2014 estuve avanzando bastante con la nueva libreria y lo malo es que en 2015 me he puesto hace unos dias. Si no hay inspiracion es mejor no ponerse ya que las cosas no saldran bien pero ahora que ha vuelto, a ver si consigo dar el empujon final para terminar y hacer la release.

Los cambios con respecto a CRM32Pro son muy grandes, de hecho la API es totalmente incompatible y todo ha sido reescrito desde cero usando SDL2 y con los 64bits y Android en mente desde el principio.

En cuanto termine el componente GUI (faltan los sliders y un list box), colgare un ejemplo de como va quedando el invento.

Hasta entonces!


Fixed forum issues and CRM64Pro update

  • phpBB forum had some issues that were fixed and now it is again working fine.
  • Regarding CRM64Pro, Audio component is completed and the GUI system is finishing during next days. The idea is to release a beta version before July 2015.

New web site

We are moving to a new host and working on new web design.

Until we finish with these tasks you can experience the service offline for some hours.

In a few days, everything will be completed so sorry for any inconveniences it may cause you.