I want to switch to new c++/lua game engine far away from marmalade and I choose irrlicht.
Does irrlicht support boost and c++11 standard for mobile devices ?
What is practice, to use containers provided by irrlicht or stl/boost?
Irrlicht supports mobile devices(not sure about Androids though as it is Java based). Irrlicht is designed to support powerful rendering across all platforms. As there is no problem with old c++ versions, there won't be any compatibility issues with c++11.
Related
The version compatibility of Vulkan SDK is documented in LunarG's whitepaper, but I'd like to know whether those extensions controlled by the flags listed below are following the same rule as well.
VK_USE_PLATFORM_DIRECTFB_EXT
VK_USE_PLATFORM_ANDROID_KHR
VK_USE_PLATFORM_FUCHSIA
VK_USE_PLATFORM_IOS_MVK
VK_USE_PLATFORM_MACOS_MVK
VK_USE_PLATFORM_METAL_EXT
VK_USE_PLATFORM_VI_NN
VK_USE_PLATFORM_WAYLAND_KHR
VK_USE_PLATFORM_WIN32_KHR
VK_USE_PLATFORM_XCB_KHR
VK_USE_PLATFORM_XLIB_KHR
VK_USE_PLATFORM_XLIB_XRANDR_EXT
VK_USE_PLATFORM_GGP
VK_USE_PLATFORM_SCREEN_QNX
VK_ENABLE_BETA_EXTENSIONS
I believe if the VK_ENABLE_BETA_EXTENSIONS is enabled, then the version compatibility is not guaranteed, but how about those platform extensions?
For the time being, SDK copies the versioning of the specification. If the SDK version is same or higher, the headers should include all the functionality published with a given spec version(and protected by an appropriate macro, as you listed them), and layers should not break (exept for an occasional bug).
I'm playing around a little bit with a hooked DirectX 9 application. As you may know, the D3DX framework has been deprecated in Windows 8. Microsoft advises us to "investigate alternative solutions to working with the Direct3D API". What are alternative solutions to using the handy D3DXCreateFont in Windows 8? I am working with DirectX version 9. If I am still able to reference the D3DX framework somehow in Windows 8, this is my preferred solution.
Use D3DX.
In this particular case, because you are hooking an application already using DirectX 9, using the libraries and resources provided by that version of the API is your best solution. When working with D3D9, using D3DX for the utility functions is perfectly acceptable and recommended practice.
The recommendations apply to software designed for Windows 8. While your software may be intended to work on that platform, hooking into applications that was not imposes significant restrictions. You have to work with what's already in use, and in this case, D3DX is going to be far more compatible than trying to rope in new libraries. In fact, given how many D3D9 and earlier apps use D3DX, there's a good chance it's already in use, and you may be able to just reuse that.
Note that this does not mean the D3DX DLL(s) you need are present; depending on the application, there may only be a single version present, so you may need to provide the DLL(s) or installer.
I have worked with < iostream> and other general c++ libraries. Other than that i have also worked with libraries like < pthread.h>.
Now, i have read that system calls which are operating system dependent allow an interface between libraries and functionality implementation on hardware. This is evident in the working of < pthread.h> which we can use in Linux but not in Windows. My explaination for this is that inside the < pthread.h> functions are defined using UNIX system calls which will not be understood by Windows.
But < iostream> seems to work fine in both Linux and Windows. Now my question is that even
< iostream>'s function will need to be defined in terms of system calls which are different for Windows and Linux, then how is it that < iostream> works fine on both OS.
PS: I know that according to my idea above, all libraries(i.e. APIs) will be divided according to operating systems or libraries will come in different forms for different operating systems.
<iostream> is part of the C++ standard which provides users an interface so that you can run the same C++ code on different operating systems although they are implemented with different system calls underneath.
<pthreads> is part of the POSIX (Portable Operating System Interface) standard with a similar aim for implementing multithreaded applications.
So far so good.. Now the tricky part is that windows doesn't seem to support pthreads as well as most of the other POSIX standards because.. well, it's unconventional. It has its own threading library something like win32-threads instead.
Regarding operating systems, I guess it's fair to divide them into two classes namely windows and other unix-like operating systems (linux, macos, solaris etc.). That's not to say that windows is an evil operating system it's just that they have different goals.
If you need a portable multithreaded application you may want to use an higher level library such as OpenMP (which is implemented using pthreads in Linux and probably something like win32-threads in windows) or Intel TBB and so on.
Also C++11 will have it's own built-in threading support which you can safely use in the same way in windows and others assuming those C++ compilers will be fully standard compliant.
EDIT: I forgot to mention, there are some projects aiming to implement POSIX standards on windows such as Cygwin or Interix (developed by microsoft but deprecated in windows 8). If you want to use <pthreads> in windows you can use these as well. Threading calls you made using <pthreads> functions will be mapped to native windows threads.
I'm evaluating components for a new embedded platform. CPU is an ARM9 and OS is Linux. Because the platform will be in use at least for 10 years I think the language should be chosen carefully as well. I'm already running Mono on possible target platform. Beside that I'm to dumb to compile Mono with my Compiler (according to Google more or less everyone else has the same problems), it's already running. I've written some benchmarks for our specific needs and I was quite impressed that Mono was never more than twice as slow compared to plain C. Memory usage is OK, and when I remove all unneeded files the footprint is acceptable. I just like to know if anyone else uses Mono on an embedded platform? Did you have any problems? Things which everyone should consider?
Given that the iPhone and Android are ARM, Mono is very well supported on ARM. And because Novell sells supported versions of Mono targeting those platforms, it is likely to stay well supported for quite some time.
One thing to note is the Mono runtime is licensed under the LGPL, so you need to ensure your usage complies with the license, or you will need to purchase a commercial license for Mono.
I was currently developing a desktop application in C# using mono and testing in SuSE and Windows. The concept doesn't matter much, but it is a "web lint" program that will scan a web site and return possible issues with security and/or cross browser compatibility. However, I want to be able to offer binaries for multiple platforms. Should I stay with Mono, or is there another platform that would give me a better availablility of platforms, such as on Macs, Windows, Linux, and others (possibly mobile platforms), and make it easier to port?
Well, your best bet always is to use a language that actually exists on all the platforms. That usually means Java, I think, though even perl has flavours for mobile platforms (depending on the mobile platform in question).
I do most of my cross-platform work in C and perl, but there are some headaches with C (lots of #ifdef's), and perl may not be on a mobile platform you care about (yet). You'll have to evaluate the languages/compilers/interpreters that are common to all the platforms you want to target and then choose from that list. Without knowing the full list of such platforms, we'll have a hard time telling you what to use, though Java has enough buzz-wordness to likely be a strong candidate.
Iff you know C++, Qt will cover many platforms.
C# and Mono is probably cross-platform enough for most desktop environments. The trick will be the "mobile platform" requirement.
Mobile operating systems are wildly diverse and there's not a lot you can do to generalize. Some have Java, like the Blackberry. C# may get you onto Windows Mobile-based platforms. iPhones do their own thing. You pretty much have to pick a platform and target that. That may end up informing your desktop platform choice.
Just stick to the Mono, make sure that you have Gendarme code inspector (FxCop for Mono) checking your code for portability issues, and you should be fine.
Java will run on Windows, Linux and Macs. Should be easy to transition from C# - use Apache HTTPClient for grabbing the web content you are scanning, and the scanning code should be more or less the same. However the downside is requiring the user to have the Java runtime installed.
Python is another option - you can build stand-alone executables for Windows, and it comes with most Linux distributions by default, and also Mac OS X (citation needed ;) ). This is a lot less hassle for Windows users (language is compiled into the executable, no other downloads required).
If mono runs on Mac OS X then surely that is a good platform as well?
It really depends what you want to do. For web development, if HTML/JavaScript is enough then stick with it. If you need more advanced stuff I would use ASP.NET with Mono (what you probably did) since you already know that. (You can use Visual Studio here.)
Another option might be (since you are a C# developer) to use Silverlight. That gives you Windows and Mac platforms covered and hopefully Moonlight will cover Linxu platform later. (You can use Visual Studio and Expression Blend here.)
If you need desktop application then Java is probably the easiest since you already know C#. But if you know C/C++ try to take a look at wxWidgets for example.
Why limit yourself to the traditional C#/Java? Have a look at Adobe AIR and Microsoft SilverLight