It might be stupid question, but I was looking for a long time for an answer and I can't find one for my DirectX 11 game engine. For example I have got two pixel shaders A and B and I don't want to repeat my code for gamma correction. So my idea was to move that to separate hlsl file and include them, but I don't know how to do that. When I was google that I was only able to find informations about .fx workflow, but I'm not using it. When I'm trying to make a new shader I always get an error, that my shaders need to have main function. How can I do this?
EDIT:
As VTT suggested I will provide example. Let's say I have my uber_pixel_shader.hlsl like this:
#include "gamma_utils_shader.hlsl"
...
float4 main(PS_INPUT input) : SV_TARGET
{
...
finalColor = gammaCorrect(finalColor);
return float4(finalColor, Alpha);
}
And there is no method gammaCorrect in HLSL, so I want to include it from another file named gamma_utils_shader.hlsl. This file looks like this:
float3 gammaCorrect(float3 inputColor)
{
return pow(inputColor, 1.0f / 2.2f);
}
When I'm trying to compile this, the comipler is throwing an error "Error 3501 'main': entrypoint not found". And it's true, becase I don't have main method in this file, but I do not need one. How can I solve this in Visual Studio 2017?
Your project settings by default specify that an HLSL file should be compiled with the HLSL compiler. This means that during the build, VS queues all your HLSL files, including your include file, for compilation by the compiler with the default entrypoint of main. Obviously this is not desired - an include file can't be truly compiled.
To solve the issue, right click on your HLSL include file in the 'Solution Explorer', click 'Properties', and change the 'Item Type' field from "HLSL Compiler" to "Does not participate in build". This will prevent Visual Studio from compiling your include file.
In the future, provide the '.hlsli' extension to your HLSL include files. Visual Studio will open those files with the HLSL editor, but automatically identify them as not participating in the build procedure.
Related
I am trying to work with Emscripten. I have the compiler set up and working and now I'd like to write some code.
However, the include for emscripten remains underlined in red and I can see this error:
#include <emscripten/emscripten.h>
#include errors detected. Please update your includePath. Squiggles are disabled for this translation unit (D:\MYPROJECT\cpp\main.cpp).C/C++(1696)
cannot open source file "emscripten/emscripten.h"C/C++(1696)
A "Quick fix" (quotes intended) takes me to the Microsoft C/C++ Extension - IntelliSense Configurations. And there I can edit include paths. I have created a new configuration named EMSCRIPTEN and set these paths:
${workspaceFolder}/cpp/**
D:\lib\emsdk\upstream\emscripten\system\include
But this has no effect. Now if I do add this to the default configuration that was there from the start (Win32), it works. But I don't want to use that one for my emscripten project! I was kinda hoping to convince to IDE to compile my programs as well.
So how do I set per-workspace C++ compiler settings to a given configuration?
Ok, I found it, it's to the right bottom of the screen next to language type selection:
TL;DR: Debuigging into MFC (CString) header code does not work on both my machines and as far as I can tell this is due to the peculiar way these headers are compiled.
Stepping through MFC header code when entered via disassembly works, but setting brealpoints does not work.
I'm looking for a workaround or at least acknowledgement of my analysis.
System:
Visual Studio 2019 Professional 16.9.6
Windows 10 / 1809 Enterprise LTSC
Setup: (I do apologize for this being rather long.)
Create a Visual Studio 2019 Example MFC Application Project (SDI App)
Make sure Enable Just My Codeis off under Options -> Debugging -> General.
Set the build configuration to Debug/x64 (does not make a difference, but let's all stay on the same page)
Navigate to MFCApplication1.cpp -> CMFCApplication1App::InitInstance()
Insert a CString init like this:
...
InitCommonControlsEx(&InitCtrls);
CWinAppEx::InitInstance(); // please put breakpoint 1 here
// Add this line and set breakpoints
CString this_is_text(L"Debugging into CString Header does not work!"); // breakpoint 2 here
Now, you can start the program under the debugger, and you should stop at the first breakpoint:
Now, make sure all symbols are loaded, easiest done via the Call Stack:
Just select all lines in the call stack window and hit Load Symbols in the context menu. Afterwards the call stack should look roughly like this:
> MFCApplication1.exe!CMFCApplication1App::InitInstance() Line 75 C++
mfc140ud.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00007ff7b5070000, ...) Line 37 C++
MFCApplication1.exe!wWinMain(HINSTANCE__ * hInstance=0x00007ff7b5070000, ...) Line 26 C++
MFCApplication1.exe!invoke_main() Line 123 C++
MFCApplication1.exe!__scrt_common_main_seh() Line 288 C++
MFCApplication1.exe!__scrt_common_main() Line 331 C++
MFCApplication1.exe!wWinMainCRTStartup(void * __formal=0x000000c2b7084000) Line 17 C++
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart() Unknown
Now, you can try stepping-into (possibly F11) the CWinAppEx::InitInstance() function, which should work without a problem, landing you in mfc140ud.dll!CWinApp::InitInstance() Line 394 - this is OK.
Step out again, and then then try to step-into the CString ctor:
This DOES NOT work on my machine(s)!
What I can do however, is (from the point above) switch to disassembly view, step into the calls there and get into the header code this way:
I can then successfully step through (but never into) the MFC header code. Trying to set a breakpoint will result in the error:
The breakpoint will not currently be hit. No executable code of the debugger's code type is associated with this line.
Possible causes include ...
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\atlmfc\include\cstringt.h
And this is where I'm at.
Analysis:
What we can see from the MFC code is that we can step into "regular" cpp code, but as soon as we try to step into (or set breakpoint) code that is inside this CStringt.h it breaks.
Peculiar here: This is template header code, and still the executed code (as shown by the disassembly) is not in the user module but in the mfc###.dll! I think they do some clever tricks with the preprocessor (see defined(_MFC_DLL_BLD) and somesuch) which enables this multi use of the header file, and maybe, possibly this is also what breaks the debugger.
Question:
Is this a known problem, does this happen with all VS2019 installs, is there something peculiar to my setup?
Maybe fixed in a newer VS version?
Iff this is actually broken, what would be a useable workaround, other than constantly switching to disassembly view when into the MFC headers.
The most interesting answer here would actually be as to WHY this breaks - where does the debugger get confused? Is this a general problem with re-define-ing code when debugging library code?
The source shipped with MSVC does not match.
I think this happen, as DLLs got updated with Windows Update or a new vcredist, but Visual Studio includes are not updated. If you build with /MT or /MTd and link MFC statically, the problem does not persist.
Probably this can be reported to http://developercommunity.visualstudio.com if you care.
Workaround 1
Do steps described by #selbie:
Set a breakpoint on the line of code I want to step into.
When
the breakpoint is reached, right click in the editor window and select
"Go To Disassemly".
In disassembly mode, step over until you get to
a call statement. [...] You
can flip out of disassembly mode by right-clicking again and selecting
"go to source code".
(skipped the part not relevant to this issue)
Then pick up the location of the header manually, the debugger will tell that it does not match. The difference seem to be insignificant though, so the header is usable.
Workaround 2
Link MFC statically, compile with /MT or /MTd
Workaround 3
ATL has a similar CString that does not suffer from the issue:
#include <atlbase.h>
#include <atlstr.h>
int main() {
ATL::CString this_is_text("Debugging into CString header works");
}
Analysis went sideways at some point, but we finally found one part of the problem here:
The Require source files to exactly match the original version option:
was the problem, but in a very peculiar way:
When you do NOT require source files to match (that is, disable this default option), then the erroneous behavior of the OP occurs: The debugger can no longer match the symbols to the cstringt.h file.
Unfortunately, I had this disabled on both machines. Pulling in a third machine showed that we could set breakpoints (though F11 still does not work) and by comparing the xml export of the VS settings we found that this was different.
So, long story short: For us, to be able to set breakpoints in the (unmodified!) MFC header, requires us to enable the Require source files to exactly match .. option.
If the option is disabled, which would imply a more lenient behavior by the debugger, it no longer works.
And, yes, we double checked it's always the same source file at C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\atlmfc\include\cstringt.h
The mystery with step-into/F11 persists, but I guess this would better be taken to a separate question.
Uncheck the Enable Just My Code option in Tools->Options->Debugging
I know that works for c++ std:: library code debugging. The other technique I do, when I forget to uncheck this option, is similar to what you describe above.
Set a breakpoint on the line of code I want to step into.
When the breakpoint is reached, right click in the editor window and select "Go To Disassemly".
In disassembly mode, step over until you get to a call statement. That's typically the std library. Eventually, you'll navigate into a mix of assembly and system code sources. You can flip out of disassembly mode by right-clicking again and selecting "go to source code".
I know a fair amount of Java and Eclipse IDE, but am new to Visual Studio and C++. In Eclipse/Java, if you use a predefined class, Eclipse helpfully suggests the appropriate header file to include for the code to compile. Wondering if Visual Studio has similar functionality.
For example every time I use a code sample from the web, I spend a lot of time Googling which header files to include so the code will compile. My current challenge: I'm writing a small utility that reads filenames in a directory into an array for batch renaming. For this, I'm using following code fragment:
DIR* dir;
struct dirent* dirEntry;
dirEntry = readdir(dir);
Visual Studio is giving the error message: "DIR" is unidentified. "readdir" is unidentified.Is there an efficient way to locate the appropriate header files for C++ code fragments to resolve error messages like these? Thanks.
I tested this feature in vs2019 community 16.3.6 and it works. When you hover the mouse at the location of an error, you can see an error light bulb. And click the drop-down arrow next to the error bulb to add missing #include.
You can also press Alt+Enter.
As mentioned in some answers above, Visual Studio has started offering some suggestions for header files. But as of this writing, some VS suggestions lead to other error messages. E.g. I just used getline(). VS gave error message: Identifier "getline" is unidentified. It suggested I add using namespace std::basic_istream; to my code. But this was not applicable to my code and produced additional error messages.
After stumbling around, I found a very simple solution: Visit the C++ reference website. There I searched for getline and found the header information at the following link: getline(). To fix the error, I needed to #include <string>.
I'm creating a project with openframeworks (the full source is here: https://github.com/morphogencc/ofxAsio/tree/master/example-udpreceiver), and the empty project seems to compile fine.
I added the ASIO library, and a few header classes, and now the project seems to be give me the following error:
1>------ Build started: Project: example-udpreceiver, Configuration: Debug x64 ------
1> main.cpp
1>cl : Command line error D8049: cannot execute 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\c1xx.dll': command line is too long to fit in debug record
1>cl : Command line error D8040: error creating or communicating with child process
I couldn't find any examples of error D8049 on stackoverflow or even on Microsoft's pages, and google turned up painfully few results. The only remotely useful one was this github issue:
https://github.com/deplinenoise/tundra/issues/270
But I'm still not sure what's causing the problem. Is anyone familiar with this error, and can recommend a method for troubleshooting what's causing it?
thanks in advance!
For me, working with UE4, this was an intermittent error.
I added "bLegacyPublicIncludePaths = false;" to the innermost block of project.Build.cs and recompiled without errors.
Then I removed that line and compiled again w/o errors.
The error message suggested adding "DefaultBuildSettings = BuildSettingsVersion.V2;" to project.Target.cs which worked.
This is a bit of a weird sounding error, as it is from essentially internally generated data. However, you do have control over that. Taking the error message at face value, you probably have many/lots of defined symbols passed in on the command line (or the the ones you do have have lengthy definitions), or you may have some lengthy file paths.
If you look under the project properties, one of the selections under the C++ section is "Command Line", which will show you exactly what gets passed to the compiler. When you view that you can see where you have many or lengthy parameters, and then make changes to shorten them.
Too many defines? Put them in a header (possibly stdafx.h) and include them that way.
Long file paths? Shorten the paths, put the files somewhere else, or set up file system aliases to your real directories that use shorter paths.
I am trying to use a code that draws Fruit Ninja style swiping effect using the code at https://github.com/hiepnd/CCBlade
When Compiling I get error at the line #include < list >
(CCBlade.h:14:0 CCBlade.h:14:15: error: list: No such file or directory)
It works fine when integrated with a .m file, but the error is when trying to use it with .mm
Any solutions for this ?
Did you correctly adjust build setup for compiler? In order to compile c++ source code, you need to change compiler properly in build option.
Do the following if you are using Xcode 4.2:
1. Click on the CCBlade.m file.
2. Look to the right panel (first panel is all your project files, middle panel is your codes and the last panel is the properties).
3. On the Identity and Type, select "Objective C++ Type" for the File Type.
4. Vice-versa for TouchTrailLayer.m.
Hope that helps!
I was getting errors 'inline function declared but never defined' when trying to build the project. This is due to inline C functions in the CCBlade class.
The solution to fix this is simple, rename all classes that use CCBlade with .mm file extension(Objective-C++ files). This fixes the errors.