I am using an old machine with windows xp on it, and xp supports only DirectX9, and i want to learn directx 11 and use it, so my question is : is it okey to begin learning directX 9 then go to 11 after getting my new machine with windows 8 ?
What are the major differences between Directx 9 and 11 ?
PS: my goal is to create a 3D Game.
The main difference between D3D 9 and 10/11 is that the fixed pipeline no longer exists, so when working with 9 I recommend avoiding the fixed pipeline and writing your own shaders for everything. I would also consider avoiding the effects framework as this has moved out of the main libraries in 10/11 (although it is still available).
Another difference is in how D3D handles its device contexts. A lot of the functions have been moved from the Device to the Context class, this is done to allow better multithreading support with deferred contexts. This shouldn't affect you too much though, it will just require a bit of refactoring when you upgrade.
If you plan to make your game with legacy support for xp/dx9 then beginning the project using 9 might not be a bad idea anyway, good luck!
Related
Note: I just wanna say at first that I tried literally everything I could find about the subject (MSDN, Stack Overflow, D3DCoder, etc.) without any success (after solving one, another error was waiting for me). So I am posting here by pure demotivation (there are similar posts already, yes, but none of them actually helped me out).
Here is how it goes:
A few months ago, I decided to start learning modern OpenGL by pure curiosity, and finally decided to switch to DirectX after reading the downsides of OpenGL (I was also only targeting Windows platform). I think it was one of the worst move I ever made: I heard that OpenGL was lacking of documentation and everything was a mess with third party libraries, but I realized that DirectX was way worst than what it seemed to be compared to OpenGL. In fact, trying to code in modern DirectX 11 using Windows 7 and VS2013 is just a pain (especially shaders) and the time it takes to figure it all out is just a time waster. After reading a lot of porting articles on MSDN about alternative libraries, like DirectXTK, DirectXTex, DirectXMesh, Effects11 and DXUT, I still don't know what to do and how to setup a fully working modern project in Windows 7. Specifically, the 5 (/5_0) shader model (deprecated) combined with the new Effects11 library (not deprecated) is the thing that confuse me the most.
By the way, I am currently reading the latest Frank Luna book about the subject ('Introduction to 3D Game Programming with Direct3D 11') and I still can't get his samples working at all (even with DirectX SDK). Also, I don't know if what I am learning is relevant or not since he wrote it before the Windows SDK switch. For your information, the latest error I am trying to solve with his samples (for those who know the book) is a E_NOINTERFACE from D3DX11CreateEffectFromMemory function (at runtime):
HR(D3DX11CreateEffectFromMemory(compiledShader->GetBufferPointer(), compiledShader- >GetBufferSize(),
0, md3dDevice, &mFX));
// Done with compiled shader.
ReleaseCOM(compiledShader); -> crash here
All that being said, here is what I wanna know:
Are there any clear step-by-step tutorials on how to setup a modern DirectX 11 project in Windows 7 using VS2013 or it is still in pre-alpha stage (just kidding)?
What is actually going on with the shader model, the HLSL compiler, and the .fx files and what should be used (I hear everywhere that it is deprecated but no replacement seems to exist yet)?
For those who know the book, any idea on how to build the old DirectX SDK samples without getting this silly runtime error?
Thanks a lot!
E_NOINTERFACE is an usual error in that context, so likely there's something wrong with the code around it you are not showing in your question.
You can still use the legacy DirectX SDK with VS 2013, but it takes a slightly different procedure than was used with VS 2010. In VC++ Directories set Executable to $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x86 or $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x64;$(DXSDK_DIR)Utilities\bin\x86, Include to $(IncludePath);$(DXSDK_DIR)Include, and Library to $(LibraryPath);$(DXSDK_DIR)Lib\x86 or $(LibraryPath);$(DXSDK_DIR)Lib\x64. Read MSDN for some other details of doing this. I've also made some notes w.r.t. to that book here.
You actually don't need the legacy DirectX SDK, but you may find it easier to do that for now using that book. VS 2013 comes with the Windows 8.1 SDK that has all the OS headers for DirectX 11 along with D3DCompile #47.
You can use the Direct3D tutorial for a simple example of setting up a Win32 desktop app (i.e. one that works on Windows 7) with a device, swapchain, and window. This makes no use of legacy DirectX SDK.
There are some additional Effects Tutorial Win32 Sample you can use as well. Instructions on adding the Effects 11 library is on the CodePlex wiki under Documentation / Effects 11 / Adding to a VS solution.
Your questions about FX vs. not are also covered on the CodePlex: Is Effects 11 deprecated? and How do I avoid using fx_5_0?. Also on StackOverflow.
Many of the older DirectX SDK samples have been reposted to MSDN Code Gallery and do not require the legacy DirectX SDK to build. You should read these posts for the fate of various DirectX SDK things:
DirectX SDK Samples Catalog
DirectX SDK Tools Catalog
Living without D3DX
DirectX SDKs of a certain age
The story for learning DirectX 11 with Windows Store apps / Windows phone 8.x aps is a lot cleaner, and is well supported by VS templates and MSDN documentation. Win32 desktop apps are of course a completely reasonable option, but you have to distinguish between legacy and modern with a bit of research. You still start with the standard Win32 desktop app project template in VS.
Note: Windows by default only supports OpenGL v1.5 software renderer. You have to install 3rd party ICD to get anything else, and there are no OpenGL VS templates.
We've been using Delphi 7 for our in-house development environment for several years now, and we're looking into updating to the newest version of Delphi. (At the time, this appears to be XE6.) However, many of the old programs we maintain were originally written in the Delphi 7 CLX environment, and I'm worried that we won't be able to keep maintaining them once we've set up XE6.
I know that there's always the option of just keeping the old compiler around on an old machine or a VM, but I'm thinking that as programs from XE6 go out, we'll be getting asked to add new functionality (from the new version) to those old programs as well.
Because of all of this, I'm trying to find information on either the proper way to, or else the best tool for, converting programs explicitly written in the CLX environment into a form that XE6 can handle. What is/are the best option(s) for doing this?
I am encountering an issue where nothing is rendered when running a simple OpenGL application through VS 2012 on Windows 8.
I had a little debug renderer I was using to prototype some projects and had it up and running on Windows 7 using VS 2012 Express Edition.
I upgraded to Windows 8, and cloned the git repository with my work on. After installing the latest drivers and installing VS 2012, I ran my application, but nothing displayed, all I get is the screen clear colour. I was getting an exception before but that's because I didn't have the right drivers so when calling glGetIntegerv(GL_MAJOR_VERSION,...) I'd get -1 as OpenGL wasn't set up correctly. It is initialised correctly now and when stepping through, it looks like everything is working fine, the only problem is I'm not seeing anything.
To make sure it wasn't just my code I downloaded some of the Swiftless OpenGL examples and got the exact same thing. My application was using OpenGL 3.2 and no deprecated functionality. My hardware can support up to 3.3, and if it is of any use I am running Window 8 through Boot Camp on a Macbook air.
I have been bashing my head against a wall for the last couple of days trying to solve this but I'm not having much luck, I thought I'd throw it out there to see if anyone has had a similar problem, I'd be really grateful if anyone can offer any information. If someone with Windows 8 could download and build a simple OpenGL application though VS just to see if they can get something up on screen that would be interesting!
Do you use the good old and deprecated fixed function pipeline, namely immediate mode draw calls like glBegin(), glVertex*() and glEnd()? If so, try to draw your stuff using vertex arrays. Even if this doesn't help in your specific situation, immediate mode draw calls should be avoided at all cost to make the code forward compatible. The OpenGL 3.x core profile doesn't contain these old API functions anymore. I had also a blank screen on my new Win 7 notebook (OpenGL 3.3) because of some stale immediate mode draw calls (FTGL).
EDIT:
For independent GL debugging, I recommend this:
http://www.gremedy.com/
This program allows you to pause the execution and investigate buffer contents, shader programs and more.
After installing the latest drivers
Where did you get the drivers from? Only drivers you download directly from the GPU vendor's website ship with proper OpenGL support. The drivers automatically installed by Windows have only poor OpenGL support.
opengl support is not available for windows 8.their are still techniques to use it on windows its better to search on google coz i tried for minecraft game or u can check here too
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
If you open the page "Graphics and Gaming (Windows)" on microsoft.com
the last category is described as
Legacy Graphics: Technologies that are obsolete and should not be used in new
applications.
This category includes (among others) the following APIs:
GDI
GDI+
OpenGL
What's your opinion? If i want to roll out a new software today it must support Windows XP (still about 50% of all installed systems). Direct2D requires Windows 7/Vista. What else should be used?
I suspect that Microsoft's definition of "legacy" has little to do with what any sensible developer should do, and is instead based on some Grand Rewrite of the Windows API.
Starting at around Windows Vista, Microsoft has been redesigning many of their API's. We now have MMDevAPI as the One True Sound API, WIC is the One True Image File API, etc. From what I've seen/heard, these new API's are much better than the old ones, and the "legacy" systems all work based on the new ones. In Windows Vista and later, DirectSound is entirely based on MMDevAPI, and components that need to read image files do it via WIC.
Windows 8 will have an ARM version, which it appears will support only a subset of the current Windows API. We won't know for sure until Windows on ARM is released, but, based on the libraries included for the ARM platform in Visual Studio 11 (ref: http://www.winehq.org/pipermail/wine-devel/2012-March/094559.html), it's looking like GDI+ and OpenGL will not be available. GDI is available for linking, but that doesn't necessarily mean it's intact.
This new API's from Vista and later roughly correspond to the libraries in the VS11 ARM target. I'm guessing that anything on that list is there because it's either the latest and greatest way to do what it does, or it's too technically important to discard (for now). Thus, "legacy" is anything that's not the latest and greatest way to do at least one thing.
I'm not sure what is the One True Graphics API. Already we have Direct2D, Direct3D, DirectComposition (which, by the way, is not available until Windows 8), DirectWrite, and DXGI. DXGI seems the closest, but I don't have a deep enough understanding of the graphics API's to say. I suspect gdi32 is technically very difficult to get rid of. How are non-legacy applications meant to find out when part of a window has been revealed and therefore must be painted, without using WM_PAINT, which involves an HDC, and how could a library do that on an application's behalf without replacing its window procedure? How are we meant to make semi-transparent windows without using UpdateLayeredWindow, which takes an HDC? How much does user32 depend on gdi32, and can they really be separated?
From a technical standpoint, Windows can easily get rid of GDI+ and OpenGL, but I'm not convinced that getting rid of OpenGL will work out, even on a new platform that doesn't promise any backward compatibility. It seems too valuable to developers. GDI+ isn't so important, but it's very easy for a third party to provide a replacement.
I would say use any of the API's you listed, and the worst that's likely to happen is that you have to rewrite your UI if you want to port your app to metro or Windows on ARM. GDI is a fine choice if your needs are simple and you'll be coding directly for the Windows API. There aren't many situations where I'd recommend GDI+ over OpenGL as a drawing API. GDI+ is slow, limited, and only available on Windows. The GDI+ API is simpler because it's 2D, so maybe it's worthwhile if you need to do something very simple but with anti-aliasing.
OpenGL isn't deprecated, Microsoft's implementation of it is. Microsoft's implementation is stuck at version 1.1, which is old. The current version of the standard is past version 4. If you want to use OpenGL, it is fully supported by NVidia, ATI, and Intel graphics cards on the Windows desktop, but not in Metro Windows Modern UI apps, is an industry standard, and also works on Mac and Linux. If you need a software fallback implementation, Mesa has got you covered, and it even works on DOS. (Since Mesa can render into memory buffers, there's no reason it won't work in Modern UI apps, but you probably don't want to do this because it can be slow.) One thing of note is that WGL, the API for accessing OpenGL functionality on the Windows desktop, depends on GDI (which is deprecated) so you probably want to use something like FreeGLUT or SDL instead if you want to future-proof your application, which also nets you platform independence.
OpenGL ES is a variant of OpenGL which works on Android and Apple iOS. It is also accessible in JavaScript via WebGL, which Internet Explorer 11 will support (and pretty much every other browser already does.) ANGLE provides a hardware-accelerated implementation of GLES for Windows which piggybacks off of DirectX (version 9 or 11) and thus should work in Modern UI apps as well. Once again, Mesa's got the software implementation covered.
TL;DR: OpenGL is not only not deprecated, it is cross-platform, standard, and has tremendous momentum in the industry. GDI and GDI+, well, not so much.
If you want to support Windows XP, then you're supporting a "legacy" operating system, and as such, using a "legacy" graphics framework is the logical choice.
Even if that weren't true, let's just say that I disagree with the advice given by the linked MSDN article. The "legacy" status here has more to do with which technology the Windows team thinks is cool this week. The status designation of "obsolete" just means that the group responsible is no longer accepting or fulfilling bug reports (except for critical security issues). Not too big of a deal—these technologies have been around long enough that they're fairly feature-complete and stable.
GDI isn't going anywhere, so if you need something rock-solid that is guaranteed to be supported anywhere and everywhere, that's what I would go with.
If you need a bit more 2D capabilities than GDI offers (e.g., alpha channel transparency), then you could consider using GDI+. It's nearly an order of magnitude slower than GDI, but that's not too big of an issue on modern machines with more power than you could ever want. This, too, is going to be supported for a very long time to come.
That said, if I were writing a new app today, I probably wouldn't bother with OpenGL. There's very little that it offers in benefits over Direct2D and DirectWrite, which are both what Microsoft is pushing as the replacements for GDI/GDI+. There might be some benefit to using OpenGL if you absolutely must target Windows XP because as far as I can tell, Direct2D/DirectWrite are only supported on Vista and later, but that's because (as I mentioned originally), Windows XP falls squarely into the "legacy" or "obsolete" camp itself. Alternatively, if you already know OpenGL well and don't have time or the desire to learn Direct2D/DirectWrite, then it might make sense to continue using it in a new application.
Don't let the verbiage of the MSDN article scare you. Choose whatever technology makes the most sense for your specific use case given all of the available information. By the time any of these technologies go away completely, you'll have to re-write the app completely for a dozen other reasons.
Edit: Hmm, it looks like DirectWrite has also been declared (by some people at least) "obsolete" as well, having been replaced by Direct2D. That's funny, it hasn't even been around long enough for me to bother learning it. I guess that only goes to support my earlier argument that "obsolete" simply designates that a particular technology is not what is currently considered to be in vogue by the Microsoft devs.
I'm personally waiting until all the bugs get worked out of this stuff (and we decide on a semi-permanent standard) before I make the switch for any of my applications. Everything I've seen written in DirectDraw or Direct2D has had serious rendering bugs and is a performance nightmare, even on reasonably competent machines. Sure, they only show up sometimes, under the right conditions, but that's too much for me. And I swear, the blurry text shows up all the time. Not being able to read what's on screen is a deal-killer for me and my users. GDI doesn't have this problem, and it's not going anywhere.
Are GDI, GDI+ and OpenGL really obsolete/deprecated?
This is not true for OpenGL. OpenGL 4 allows you to use geometry shaders on winxp. Which isn't possible with DirectX (DirectX 10 and up isn't supported on WInXP). It is also one of the only cross-platform 3D APIs out there.
From a business point of view MS is interested in promoting DirectX since it is their technology that lock Developer into windows platform (they're also interested in making DirectX more attractive for developer, but that's another story). So it makes sense that they aren't keen on promoting OpenGL.
What else should be used?
I'd advise to stop using platform-specific tecnologies when possible. Grab cross-platform framework and use it for your application. There's Qt, GTK, wxWidgets and other toolkits for GUI apps, and SDL(and alternatives) for games. This way when platform developer decide to make ridiculous decision (like not supporting DX10 on WinXP) you dislike, you'll be able to move elsewhere with minimum development cost. Qt is also ridiculously powerful and at the moment I have no reason to use something else for GUI development. Still, situation can change in the future.
In short, while developing for certain platform you should keep in mind that platform developer might have their goals that are not compatible with your wishes. Discovering that your source has become locked into single platform isn't very pleasant experience. Your own goals should be the first priority, and if os developer tries to make you use certain technology you don't like, then you shouldn't support that technology.
Because OpenGL is a standard, it should be considered equally deprecated as C or C++ so it is a matter of time before the entire Windows API -- which today has become a compile once run on every x86 machine API thanks to Wine -- is considered deprecated in favour of .NET and C#.
I use GDI for simple graphics and OpenGL, when I need accelerated 3d.
Another aspect is that Microsoft's build-in implementation of OpenGL is definitely to be considered as deprecated since it is just version 1.1 or something, but that has been for a long time.
Yeah, about OpenGL, it actually outperforms DirectX in many ways both resource and display wise. It will never be promoted by Microsoft because it can't own OpenGL, not to mention most people don't do their research and Microsoft can claim it is old. Truth is opengl is opensource standard and evolves at a much faster rate than closed does because it is more than 1 room of developers paid to work on it. Also Microsoft has contracts with many companies to release using only Microsoft's software, this causes more business for Microsoft and less to use the more advanced OpenGL standard. It is a interesting lock up if you will, Microsoft creates these contracts so that many programs are written in DirectX to keep business for Microsoft, and no company will refuse it because Microsoft has about 80%+ home user market.
I want to make a 2D desktop GUI application with DirectX but I don't know which version to use. I initially tried Direct2D but it never really gained popularity, thus there isn't a lot of community support or documentation for it compared to the rest of DirectX, so it's not an option.
So I have three options:
DirectX 9.0c
DirectX 10
DirectX 11 (not 11.1, I'm not getting Windows 8)
A knowledgeable friend of mine strongly encouraged DirectX 9.0c saying that's all I need, but I am wary of using an 8-year old platform. Microsoft is pretty much the zenith of legacy support but I think that they must have a limit. I have no idea of the difference between DX10 and DX11.
Keep in mind that I'm very much a novice programmer so this is mostly a learning project.
Any advice is appreciated!
Edit: I'd also appreciate advice on any significant differences in functionality or programming paradigms between the versions.
What version of DirectX should I use to make a 2D desktop GUI application?
DirectX 9, because you'll get more users.
A knowledgeable friend of mine strongly encouraged DirectX 9.0c saying that's all I need, but I am wary of using an 8-year old platform.
Many DirectX 7 and DirectX 5 games still work just fine, not to mention titles that use DirectDraw. So there's no problem with 8-year old platform. Using newer (than 9) version might not even benefit you, so blindly going for higher version number isn't a good idea.
Depending on your circumstances you could also consider using OpenGL but that choice makes sense only if your app has to be cross-platform. If you know that application will be windows-only, then choosing DirectX 9 makes sense.
Microsoft's primary commitment is to its Windows customers. Who still run 15 years old games that use whatever DirectX version was in use back then. IDirectDraw is alive and well. Clearly you'll benefit from that as a developer secondarily. And sure, DX 9 is most widely supported by hardware so that's an excellent choice. Consider something higher if your game performs poorly on old hardware, the DX version is an automatic selector.
Are you writing this for work, or for fun?
If it's for work, then you have to go by the minimum system requirements that someone in business or marketing has defined. If your minimum OS can be Win7 or Vista SP2 w/ Platform Update, then Direct2D is a viable option. Otherwise, DX9 is the way you have to go.
If it's for fun on your own personal time, then do whatever you think will be the most fun :) Direct2D will certainly be MUCH easier to work with if you just want to do 2D graphics. I wouldn't worry much about the "it hasn't gained popularity/community support" angle, especially because it's being used by all the major desktop apps nowadays (Firefox, Internet Explorer, and even the next version of Paint.NET). Also, Win8 will update Direct2D with a whole bunch of interesting new features (and this update will also be available for Win7 from what I understand).
Direct2D can be clumsy to work with at first, but that's mainly due to all the COM stuff. Once you get used to it and build up your own little utilities warchest, it's really not any more complicated than GDI+. In fact, I've been able to port a bunch of old GDI+ code to using Direct2D/DirectWrite and often it's just a line-by-line substitution, e.g. SolidBrush -> SolidColorBrush (this is in the Paint.NET 4.0 code base, btw).
I used the Direct 2D to render graphs of functions and it's pretty easy to use - I'd say, as simple as GDI+. I'd guess, that level of complexity of DirectX 11 and DirectX 9 (in terms of 2D graphics) is quite similar, so don't worry about that.
DirectX 9.0 runs on (let's say) all modern computers, and 11 restricts you to Windows Vista (with platform pack) and Windows 7. Take into consideration, though, that Windows XP will eventually vanish and DirectX will evolve, so I'm not sure, is it worth investing your time into technology, which won't be developed anymore. I would suggest DirectX 11's Direct2D then.