Forum Replies Created
I don’t think this should be too difficult. Yes, you’ll derive from DrawableGameComponent and add an instance of your component to the Game::Components vector.
Irrespective of watching the DirectX Essentials LiveLessons, if you want a bit more modern codebase, you can use the code from https://bitbucket.org/pvarcholik/directx-essentials-livelessons. Be certain to clone the VS2015 branch instead of the master branch. Among many other changes, that code removes the Effects 11 library dependency altogether.
I’d be happy to create such a code sample. However, I’m still a bit in Hurricane Irma cleanup mode, and have quite a bit of catch up to do teaching classes this semester. Thus, this request may have to wait a bit.
In the meantime, I already have such a sample for DirectX. Indeed, this topic is Chapter 20 in my book. You can find the code for this here. It should be pretty straight forward to port this code to OpenGL.
I’m running on Windows 10 and I don’t see this error. There are two calls to mGame->UnbindPixelShaderResources(0, 3) from ShadowMappingDemo::Draw; on lines 252 and 278. That method calls PSSetShaderResources using an empty array of shader resource views (to unbind the textures associated with the pixel shader).
I suspect it’s one of those UnbindPixelShaderResources calls that’s causing the error. Have you stepped through the code to see which? And/or examined the call stack and local variables? Might something be null that should not be?
PaulSeptember 23, 2016 at 10:58 am in reply to: Any way to make the book work on Windows 7x 64 pro #433
Yes, you can absolutely use the book’s code under Windows 7. First note that, under Windows 7, the DirectX SDK is a standalone download and is not part of the Windows SDK. Here’s a link to the DirectX SDK for June 2010 — which is the revision you’ll need for Windows 7. Also note that this supports DirectX 11, not 11.1 or greater. But, that’s really not an issue when you are learning Direct3D. There’s nothing, in the beginning of your exploration, that you won’t be able to accomplish with DirectX 11 that you could with DirectX 11.1 or greater.
That said, portion of the DirectX 11.1 Runtime are available on Windows 7 Service Pack 1. Chuck Walbourn, from Microsoft, has a post about this.
Also note that there is a known issue installing DirectX SDK June 2010. It’s an error labeled “S1023”. If you get this error, here’s a Microsoft support site that describes the fix.
Then, the book’s code should happily build using Visual Studio 2015. Just be certain to say ‘no’ to upgrading the book’s VS 2013 projects to VS 2015 projects. VS 2015 has no issues loading VS 2013 projects without requiring them to be upgraded. But if you do upgrade them, I suspect you’ll find numerous issues.
All that said, I have a series of companion videos called DirectX Essentials LiveLessons than nicely compliment the book. I just recently updated that code to use VS 2015 projects, NuGet packages, more C++11 constructs, and much more. All around that’s a better code branch that what I’ve provided in the book. The source for those lessons is available at Bitbucket.org just as is the code for the book. If you choose to use that code instead, make certain that you clone (or download) the VS 2015 branch and not the master branch.
I do have plans to update the book’s source to match what I’ve done in the videos, but it’s a time consuming process.
I hope this helps. Please let me know if you have additional questions or problems.
First, I recommend that you download the latest drivers for your video card. Second, you can specify a lower GLSL version when compiling your shaders. At present, all of the shaders in the OpenGL Essentials LiveLessons use version 440, but you might consider dropping down to version 420 (which dates back about about 5 years). You can go even further back (e.g. version 330) but you’d have to make some syntax changes to some of the shaders.
PaulJune 16, 2016 at 7:48 pm in reply to: please upload project files of OpenGL Essentials Live Lessons #416
Sorry it’s taken me so long to respond. I haven’t been receiving notifications of forum posts and didn’t see your post.
No, the code is not restricted to VS 2013. However, I do see an issue linking against GLFW.
My solution will be to create a VS 2015 branch on BitBucket that changes a few things about the project configurations. Specifically, I’m updating the Lesson projects to use project references to the Library project, replacing the versions of the GLFW, assimp, and glm libraries to use NuGet, and modifying the various search paths accordingly. I should have this branch committed shortly.
- This reply was modified 1 year, 8 months ago by Paul Varcholik.
Yes, that’s something like what happens. And yes, authoring visual effects typically falls to an artist.
Glad you are enjoying the book and are inspired by amazing games!
A typical day for a graphics programmer is to work on engine and shader code, attend meetings, profile and debug code, and research techniques that are required by (or could be useful to) your game. A graphics programmer would definitely be involved in rendering water and sky — but they won’t do this alone. Artists are supplying assets that you’d render, and how much/what type of any of this work varies from company to company.
When you ask about special effects, I assume you are referring to particle effects (e.g. explosions, smoke, dust, etc.). Yes, you’d be involved in this as well but it’s less about authoring specific effects and more about creating a platform for such effects to reside within.
Yes, from the perspective of what DirectX libraries are installed with the operating system, Windows 7 does make a difference. Windows 8.1 installs d3dcompiler_47.dll, but Windows 7 does not. Just make sure that you’ve installed the Windows 8.1 SDK. Note: the Windows 8.1 SDK runs just fine on Windows 7.
As to specifying the path to that .dll, no you don’t need to do this. An .exe will look in C:\Windows\System32 (assuming that’s where you’ve installed Windows) and the directory of the .exe file to file dependent .dll files. However, if you haven’t installed the Windows 8.1 SDK, that’s likely your problem.
It’s possible that you’re having a shader compilation error. For Chapter 14, the shader that’s used (BasicEffect.fx) is being compiled at run-time. You mentioned a missing d3dcompiler_47.dll file — which is the library that’s compiling that shader. I would expect the same behavior both within Visual Studio’s debugger and outside, but this is one place to look.
Specifically, I recommend that you put a breakpoint on line 45 of TriangleDemo.cpp. That’s the call to D3DCompileFromFile. Step through the code from line 45 to the end of the TriangleDemo::Initialize method and see if you get any errors.
That you have this shader working in FX Composer is great. But I wouldn’t discount a shader model 5 issue just yet — even though you tried changing it to shader model 4. Here’s why: whenever you modify the .fx files within the project itself (e.g. the source\Library\Content\Effects\BasicEffect.fx file) that is not the file that’s being loaded by the Game.exe. As you discovered through our earlier discussion, those content files have to be copied to the location of Game.exe (e.g. build\Debug\Content\Effects\BasicEffect.fx).
That copy only happens when a build is initiated, and only when the build actually runs. Those .fx files (when compiled at run-time and not at build-time, as they are in Chapter 14) will not trigger a build when they are changed. You’ll need to either modify a C++ file or perform a “Build | Rebuild” in order to trigger a build so that the pre/post-build events fire and copy the .fx files to the .exe location.
It’s easy to see if your modified .fx file has been copied to the .exe location, just open it up (e.g. from build\Debug\Content\Effects\BasicEffect.fx) and see if it has your changes in it. You could also edit the file directly at this location. However, it’ll be overwritten the next time you perform a build/rebuild.
Glad to hear you got your code working and that you’re enjoying the book. Shout if you have any other questions.
In order to run the Game application in the Visual Studio debugger, right click on the Game project and choose “Set as Startup Project” from the context menu. Then you can press F5 or choose Debug | Start Debugging to launch the application. Alternately, you can right click the Game project and choose Debug | Start New Instance.
No, HLSL is very much in use by graphics programmers in the games industry. For the most part it’s either HLSL or GLSL (the OpenGL Shading Language). But graphics programmers also, commonly, write in C++. Whereas technical artists are more apt to write shaders in HLSL and less likely to write in C++. It just depends on the company and the individual. I’ve met many technical artists that are hard-core programmers, and their title just implies that they focus on the art side of the pipeline.
Glad you figured out the build step error. To your run-time error, step through the code in the debugger to see where it’s crashing. I can’t say what the error is before knowing a bit more, so I won’t jump to a conclusion that it’s a hardware issue. That said, if you’re using an older video card, check its specs to be sure that it supports DirectX 11 and install the latest drivers.
As to what a graphics programmers spends more time on… In my experience it’s often that graphics programmers are also engine programmers. But more and more you see shaders being written by technical artists or other non-engine-specific engineers. It largely depends on the company you’re working for and if they are using a third-party engine or something homegrown.
Have you tried building the unmodified source from the bitbucket.org repository? I’m wondering if this could be a path issue to xcopy.exe. By default that file exists at c:\windows\System32\xcopy.exe. It would be strange not to have c:\windows\System32 in your PATH environment variable, but that could be it. If you build my code and still see the error, this could be the problem.
Alternately, it could be a space somewhere in one of your paths. Make certain that you have double quotes around all of your path references.
Give that a shot, but as a final ditch you could upload your code somewhere and I could take a look.
You’ll need to create a Content directory in whichever Library location you want that content to exist, and then update your Library project’s post-build copy script to match. My advice would be to put that Library Content directory in the same directory as your Library.vcxproj file. That way you can access it, through your Library post-build script, as simply $(ProjectDir)Content.
Irrespective of “where” you put things, just understand that your scripts reference those locations. The goal here is to copy Library and Project-specific content to the output directory of your Game project (where your Game.exe lives). In Chapter 12, the only content that’s required is a .spritefont file, but more content gets add as you continue in the book.
You might start by manually creating the OutDir content directory (actually that .spritefont file lives in content\fonts) and manually copying files just so that you understand what your script should be doing. Then mimic that action in a post-build event.
Finally, you’ve mentioned a couple of times that you aren’t happy with your directory structure, so my advice there is to change it. Personally, I find that storing the .vcxproj files alongside the source (and content) files to be very helpful. It makes referencing those locations in between projects and in build events easier.
And look at my versions of the projects, on bitbucket.org, for comparison.