Currently, our framework only supports loading binary shader code. The way we do it in Visual Studio is through custom build tool per shader file. Now we also want to support shader recompilation when a user presses some key. This is tricky since now we don't have access to the source files. So I was thinking, if there is some way to export all the commands from the custom build tool to a text file, then we can just load that text file and execute all commands inside and then just do the regular shader loading as we do it right now.
Example custom build tool command for a shader which has vertex, pixel, and geometry shader stages:
fxc %(Identity) /E VSMain /T vs_5_0 $(HLSLCompileFlags) /Fo %(Identity)\..\Binary\%(Filename).vert.bin
fxc %(Identity) /E PSMain /T ps_5_0 $(HLSLCompileFlags) /Fo %(Identity)\..\Binary\%(Filename).frag.bin
fxc %(Identity) /E GSMain /T gs_5_0 $(HLSLCompileFlags) /Fo %(Identity)\..\Binary\%(Filename).geom.bin
So here is the process-
- Run custom build rules for the shader files
- In post-build event of the project, collect all these custom build tool commands and dump them to a text file
- Now if user wants to recompile, just load this text file and execute all commands inside
How would I get access to these custom build tool commands in the post-build event?
I'm not sure if this is the right place for this question, but I'll give it shot
Using Visual Studio Code, I have the task.json set up to launch a batch file that is set up like follow:
call "Z:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86
set INC_PROJECT_PATH="Z:\Asus\Documenti\VS Code\Projects\Packman Clone 1"
set SOURCE1_PATH="Z:\Asus\Documenti\VS Code\Projects\Packman Clone 1\source\*.cpp"
set SOURCE2_PATH="Z:\Asus\Documenti\VS Code\Projects\Packman Clone 1\Engine\*.cpp"
set OUTPUT_PATH="Z:\Asus\Documenti\VS Code\Projects\Packman Clone 1\Debug\Pacman.exe"
cl /std:c++latest /W4 /ZI ^
/I %INC_SDL_PATH% /I %INC_PROJECT_PATH% ^
/EHsc %SOURCE1_PATH% %SOURCE2_PATH% ^
/link /SUBSYSTEM:CONSOLE ^
/LIBPATH:%LIB_SDL_PATH% SDL2main.lib SDL2.lib ^
I'm not totally sure about what it's doing and I'm piecing it togeter as I go (trial and error + google), so if I got it right, the *.cpp at the end of those paths, it means that every time I build it will build all the .cpp that it finds in those 2 paths.
And that doesn't sounds good, so I was wondering, there is a way to tell it to re-compile only the files that have changed?
SFML is portable on windows Linux and Mac. So a game created on Windows to be ported to Mac must be compiled on that computer using portable C++ code?
Another problem/question that is more specific:
I am writing a game using Windows C++ and SFML. Using a resource for the image seems to be possible, but I will have to alter the code when porting because this 'belongs to' Window's Visual Studio C++?
The other option is to keep the images in a folder that would be viewable and loadable. This I think would run on Linux and Macintosh. It just doesn't seem to be to professional. Any advice?
Hi guys, so I have about 200 files isolated in their own folder [physics code] in my Visual Studio project that I never touch. They might as well be a separate library, I just keep em as source files in case I need to look at them or step through them, but I will never actually edit them, so there's no need to ever build them.
However, when I need to rebuild the entire solution because I changed the other files, all of these 200 files get rebuilt too and it takes a really long time.
If I click on their properties -> exclude from build, then rebuild, it's no good because then all the previous built objects get deleted automatically, so the build will fail.
So how do I make the built versions of the 200+ files in the physics directory stay where they are so I never have to rebuild them, but
do a normal rebuild for everything else? Any easy answers to this? The simpler the better, as I am a noob at Visual Studio settings. Thanks.
I am writing a level editor using Visual C++ and the win32 API. I have the game engine going working fine with Direct3D 11 (its not an off-the-shelf engine, its custom)
The plan for the editor is to have something like this:
The blue bit is going to be a standard win32 menu bar, the yellow bit will be a standard win32 status bar, the red bit will contain things like a list of objects to insert into the level (its contents will change depending on what the user is doing) and the purple bit will be a window that will be rendered into by the rendering code. I know how to do Direct3D11 rendering into a window that is the parent window and is the only thing the app is drawing (the engine runs a loop that lets the windows message loop run and process its messages before running the engine code and doing rendering) but I can't find anything out there on how you do Direct3D graphics (11 or otherwise) into a child window and how you handle things like resizing and painting and things. Its definitely possible since so many level editors and things do it but I dont know how they pull it off. (and Google isn't showing anything useful either)
Are there any examples out there of how you can create a win32 custom control/child window, set up a IDirect3D11Device to draw onto that window and then have that window play nice with all the other windows (the main parent window and the other child windows) whilst still triggering a once-per-frame render call to allow me to draw my stuff in there.