I installed SDL 1.2 long time ago with my package manager and now I have just installed from source the new SDL version (2.0).
Do you think it is safe to keep both version on the same OS? I need the old versions for other applications so I would prefer to have both..
PS I am on Linux.
Cheers!
I think it should be fine, I've already tried it for the same reason (I needed to use the older version, but I wanted to try the newer one) and it worked for me, just be sure to keep them in separate places and use one version at a time.
You can let the SDL 1.2 and use the SDL 2.0 by loading in the execution (with LD_LIBRARY_PATH). Also, when compiling, you have to specify the include (-I)/library(-L) path of SDL 2.0
Related
I'm maintaining a piece of legacy software, written in C++, that uses QuickDraw when compiled on the Mac. I know Apple is doing their best to kill this thing. In a few months I hope to have time to give my program more modern underpinnings, probably SDL, but meanwhile I need it to survive.
On MacOS 10.7 and XCode 4, I was able to still get access to quick draw by building for the MacOS 10.5 SDK. Moving to Mac OS 10.9 and XCode 6, still using the MacOS X .5 SDK, I find that it can no longer find the QuickDraw header file. I'm having to boot back to 10.7.5 to get work done on this program. Ouch.
Is this really how bad it is? Has Apple managed to completely stomp QuickDraw, even when one is using an old SDK? Or is there some way to fiddle with include paths and library paths to keep on making this work?
Yes, it is that bad. QuickDraw has not made it to 64bit-land, and 10.8 removed dev support. You can try grabbing the headers from an old SDK, or use something like this workaround, but success is not guaranteed.
I am trying to modify a current MFC application running on Windows NT4 to use boost libraries for ethernet communcications (originally, it used CommX for serial) and general increased performance, effieciency, and clarity of code.
I started out modifying it in VS2010, but I found that I was unable to produce a valid NT4 app with VS2010. I googled the issue and found that VS2005 was the last version able to create an NT4 app. I got everything to compile in VS2005, but found that I had to change certain #define statements in stdafx.h in order to get the app to run on NT4. However, even after doing that, when I execute the program on NT4, it immediately quits with no error. It doesn't show anything. I even checked the Task Manager processes while executing it. It is like it never executed at all.
I got desperate and tried compiling the app in VS2003, but I got so many errors that I gave that up.
My last attempt was VC6, but again, I got 262 errors and started wondering whether it was even possible for boost to run in VB6 or on an NT4 machine.
Is it even possible to compile and run an MFC app with boost libraries on an NT4 machine? If so, which environment/compiler do I need and how do I configure it to work correctly?
This is a very tight-schedule project, so any (prompt) help would be very appreciated! Thank you!
If you're trying to use VC6 to compile code that uses Boost, you may need an older version of Boost. Try 1.34.1.
You might try using STLport as the standard library implementation instead of the built-in STL that comes with VC6. I'm using boost 1.32 and STLport 4.6.2 successfully in VC6 with an MFC project. I haven't tried moving up to newer versions of boost or STLport, but STLport might be enough to get you going.
I'm trying to setup VC++ to compile code with OpenGL 4.1 functionality. I downloaded the 3 header files from from opengl.org; put them in the correct paths and include them - but keep getting errors like this:
error C3861: 'wglSwapIntervalEXT': identifier not found
I have the latest video drivers. OpenGL says the problem is MS includes only version 1.1 with their compiler when though the vendor/driver supports 4.1.
One of the big pains of using OpenGL on Windows is that the Windows SDK only ships with OpenGL 1.1. There's probably a really good technical (and non-political) reason for this, but the fact remains, if you want to do anything with OpenGL on Windows, you're on your own.
What you need then, is something to bring the Windows SDK up to current standards (OpenGL 4.1 as I write this.) When I was originally trying to solve this problem (around the time of OpenGL 3.0), I came across GLee http://elf-stone.com/glee.php which is a cool library which makes the full OpenGL spec available easily. I didn't like their license, so I decided to write my own extension loader.
I don't think anyone should ever have to do this again, so I've made mine public domain, do with it as you will. I'd like to hear if you use it in something, but that's not a requirement.
http://www.onemanmmo.com/index.php?cmd=newsitem&comment=news.1.28.0
I have recently started learning C++, but I require a compiler. I have tried the one packaged with Code::Blocks, but I have been told it is out of date.
I have tried reading the instructions on the website, but I simply don't know which files to download and un-zip. Is there a list of files to download? (latest version) and a folder structure I need?
I was the person that pointed you at the more up-to-date version at Twilight Dragon. The file you want there is http://sourceforge.net/projects/tdm-gcc/files/TDM-MinGW%20Installer/1.908.0/tdm-mingw-1.908.0-4.4.1-2.exe/download which is a Windows binary installer - you just run it. Note that you don't actually need to do this - the version that comes with Code::Blocks will work OK for someone starting to learn C++.
I recommend using a pre-packaged MinGW that includes some common APIs like Boost, SDL etc: http://nuwen.net/mingw.html
If I remember correctly, the only thing you must do to get it working is to modify Windows's PATH environment variable.
edit: OpenAL is not included in this package.
Here are some instructions to have a MinGW setup that I used to build Octave modules.
I have switched to using the build environment for msysgit. Just download the netinstall file and it will setup GCC, Make, etc. along with Git.
More out of interest than anything else, but can you compile a DirectX app under linux?
Obviously there's no official SDK, but I was thinking it might be possible with wine.
Presumably wine has an implementation of the DirectX interface in order to run games? Is it possible to link against that? (edit: This is called winelib)
Failing that, maybe a mingw cross compiler with the app running under wine.
Half answered my own question here, but wondered if anyone had heard of anything like this being done?
I've had some luck with this. I've managed to compile this simple Direct3D example.
I used winelib for this (wine-dev package on Ubuntu). Thanks to alastair for pointing me to winelib.
I modified the source slightly to convert the wchars to chars (1 on line 52, 2 on line 55, by removing the L before the string literals). There may be a way around this, but this got it up and running.
I then compiled the source with the following:
wineg++ -ld3d9 -ld3dx9 triangle.cpp
This generates an a.out.exe.so binary, as well as an a.out script to run it under wine.
If this is not about porting but creating, you should really consider OpenGL as this API is as powerful as DirectX and much easier to port to Mac or Linux.
I don't know your requirements so better mention it.
You can't link against wine as it's essentially a call interdictor/translator rather than a set of libraries you can hook into. If linux is important go OpenGL/SDL/OpenAL.
I believe(I've never tried this) you can can compile Linux binarys against winelib. So it works just like a Linux executable, but with the windows libraries.
http://www.winehq.org/site/docs/winelib-guide/index
go to the directory with the source and type in:
winemaker --lower-uppercase -icomdlg32 -ishell32 -ishlwapi -iuser32 -igdi32 -iadvapi32 -ld3d9 .
make
wine yourexecutable.exe.so
If you get this Error:
main.c:95:5: error: ‘struct IDirect3D9’ has no member named ‘CreateDevice’
make sure you have named your file main.cpp and not main.c.
There is currently no way to compile DirectX code to directly target Linux. You would build your application like you normally would, then run it using a compatibility layer like Wine/Cedega.
you can compile a directx apps in linux, but not launching it straight away.
if you use a crosscompilator that makes windows exe and point to the windows sdk and directx sdk.
Although this question is dated, I decided to updated on it, because it keeps popping up for me as the first suggestion for this particular problem.
As the previous answers already suggested you can compile against winelib. However, there are yet another two solutions.
The first solution would be either to use the MinGW provided for your distributions. MinGW is a 'cross-compiler', that compiles either from macOS or linux to windows and has support for DirectX. Note, that C++ libraries compiled with MinGW are not compatible with the MSVC compiler's ABI, thus cannot be consumed. However, the resulting binaries can be executed using Wine.
The second solution would be to use clang as a cross compiler. Clang usually includes the Compiler and Linker needed for Windows out of the box. However, it'll require you to include provide the headers and libraries yourself. On the other hand, libraries compiled this way are compatible with MSVC and, thus, can be consumed by it.
Side note:
Latter allows you to setup an CI server using linux (I did so on a raspberry pi), which creates compatible binaries for end users.
Wine is the only way to run DirectX in Linux