Choose Visual Studio 2015 or 2017 per compile [Armory 3d / HaxeVLC / OpenFl]

#1

Is this possible ?
Had to install 2017 for Armory 3D built out of Blender projects to compile. No problem with OpenFl at all with 2017.

But the most excellent HaxeVLC lib that allows video on native with OpenFl ain’t having it, so my question is, is there a way to set the compiler that is going to be called on the next native for windows compile ?
Is it a case of running some batch file that sets the env properly for that to happen ?
Any problem going back and forth if that is even possible ?

Edit 1:
Noticed these
VS100COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools
VS140COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools
in the set so I’m guessing HaxeDevelop isn’t picking up on them either. Just using the latest though I don’t know through what it is finding it. I don’t have any cl.exe on the PATH.

Edit 2:
Found vcvarsall.bat under the install directory structure for each install, that fixes something that allows for the next compile to be done by the 2017 cl.exe but the moment I erase the /bin and try to compile from scratch with cl.exe from 2017 the error is back:

"Error: VlcBitmap.cpp
./src/vlc/VlcBitmap.cpp(681): error C2573: ‘vlc::VlcBitmap_obj’: cannot delete pointers to objects of this type; the class has no non-placement overload for ‘operator delete’.
Use::delete, or add ‘operator delete(void*)’ to the class
C:\HaxeToolkit\haxe\lib\HaxeVLC\bin\windows\obj\include\vlc/VlcBitmap.h(31): note: see declaration of ‘vlc::VlcBitmap_obj’

Build halted with errors."

So it is kind of a fix.

#2

For older (before 2017) versions of Visual Studio, you should be able to use the HXCPP_MSVC variable before doing a build to pick your version

For 2017, it uses a different mechanism and I’m not sure if it can be controlled, but using an environment variable for HXCPP_MSVC when you want 2015, and not setting it (to allow HXCPP to choose 2017) could probably work?

1 Like
#3

Thanks singmajesty, going to look it up and see what works best.

#4

I will look into this and see if i can make it VS2017 compatible. I’m still on 2015 as 2017 has given me issues both with Haxe and Unreal Engine…

1 Like
#5

Thanks @d0oo0p.
I’m more baffled by the .stop .pause .play .dispose, framecount stuff to be honest.
This MS weirdness is the same usual stuff from MS. Though I found two ways to make it use 2015.
So I guess it isn’t a deal breaker for anyone using it either. Thing is they decided to move stuff around in VS 2017 and somehow it puts an error out as if it isn’t being linked to standard lib for some reason.Though the solution is completely correct under VS 2015. If only their ticket forums were half as helpful as this board.
Also had some linker problems with Armory 3D.

Can’t wait to get a bit of free time to test your Unreal Engine integration in HaxeDevelop.

#6

Yeah, i saw the issue with stop pause etc… its weird because this was tested quite a bit… anyway i will look into that as soon as i can!..

Cool that you saw the UE4 Unreal.hx-Haxedevelop integration… yeah, i think its cool and for me it has changed how to work with UE4 totally… !! :slight_smile:

#7

The Unreal integration is massive.
Some 3D chroma virtual set tech is also getting the Unreal engine flavor.

full engine including internal chroma keyer in UE4:

or in a combined render engine solution with Brainstorm’s voxel approach:

Having a programmatic way to make/manipulate assets for this, mainly avoiding the weird UI these 3D virtual sets provide is a time saver.