I have been programming on DirectX12 since last year, and I've experienced DX10 and 11. There is something bizarre I found in my application DX12 and i am not able to find why or a solution. I cannot show my original code, but it's ok, because it happens in any simply DX12 sample.
We can use directly the Triangle Sample (provided by DirectX12 officials) for example. I integrate it without modifying anything basic in a MFC SDI application, and until now everything works fine. But after I change the Swap Chain format to DXGI_FORMAT_R16G16B16A16_FLOAT, the application produces flickers when other windows or apps are staying/moving on the top of it but without entirely covering it. You can find here the video I made (sorry for the quality) to show the flickering, and also here the visual c++ 2015 mfc sample.
I tried something like changing erasebackground method, but still can't find a solution... Is this a programming level problem? but in which level, MFC, DirectX12, or DXGI? Or is this a os or hardware level problem??
I have already give the whole project vc++, so i suppose I can jump the step of giving the "Minimal, Complete, and Verifiable example". I dont show the code, because I dont know which part of code may be the cause of the problem, and also I am not sure if it is coding problem. And I would like to mention that the problem arises only when I replace the DXGI_FORMAT_R8G8B8A8_UNORM by DXGI_FORMAT_R16G16B16A16_FLOAT. And by the way, the flickering does not happen with DirectX11 if i do the same "integration to MFC" thing.
PS. There is no error or warning when debugging in VC2015.
PS. the same thing happens when I integrate the sample (by making it dll) into an C# Winforms apps.
Related
I don't know if I had gotten it all wrong, so I'm asking for directions here.
Let's take for example, back in college, when you learned C++ and used Turbo C++ or GCC to compile, you get an idea of what a low level programming language is.
Now let's say I want to make a basic 2D video game, just as a personal project, nothing fancy, and I want to develop it using C++ just because. I'd code it using Visual Studio since it's a pretty good IDE.
Is it right to say "I'm going to use MFC" for this kind of project? (Consider the fact that I'd be using OpenGL).
MFC is a C++ framework that encapsulates the core elements of the Windows API. It's primarily intended for creating standard, windowed applications that the user interacts with on the desktop.
It comes with a built-in graphics framework: GDI. The one that was introduced with Windows, revolutionary for its time because it abstracted away hardware-specific details and allowed programmers to write general code that ran on any machine Windows ran on. But it was never particularly good for games; it was designed for Windows-style business applications. It was awesome for text (and is still arguably the best option that there is—have you looked at how Direct2D renders text lately?), and handled simple graphics, but consider that before alternative graphics-specialized frameworks like OpenGL were available, most game developers stuck with DOS, where they could/were forced to interact directly with the graphics hardware at a low level.
So if you want to use MFC and OpenGL together, you can, but I don't really see the point. The only real benefit you'd be gaining from MFC is a reduction of 100-some-odd lines of code that sets up the fundamental skeleton of any Windows application. For example, considering this sample OpenGL program, using MFC would essentially allow the WinMain and the MainWndProc functions to be buried deep in the bowels of the MFC framework code, rather than appearing directly in your code. But, like I said, big deal. The majority of your code is going to be OpenGL-specific, and MFC won't help there.
The only way it might make sense for the two to interact is if you wrote the launchpad/host for the game using MFC and GDI (i.e., the part that displays windows and dialogs on screen), and then the game portion itself in OpenGL (launched once you clicked a "Start" button on the dialog interface).
And of course, even if you wanted to do this, MFC is not your only option. There are tons of C++ frameworks for writing Windows applications. Everyone has their favorite. Despite what some may tell you, there's nothing wrong with MFC if you already know it and/or are comfortable with the Windows API. But don't waste time learning it. Use WTL instead.
You would NOT use MFC simply because it is meant for general application development giving you features and classes that you will most likely never use!
A good start would be to look at SFML http://www.sfml-dev.org/ or (my personal favourite) SDL http://www.libsdl.org/. These libraries were written to develop games or at least multimedia applications using them.
Writing a Game Editor in MFC can be a good idea though!
I'm actually in charge of a FIP networking c++ application, working for the first time with Embarcadero C++ Builder XE5.
The app is nearly finished, but I can't find how to implement the last feature...
I wanted to open an external Windows HyperTerminal in order to see what happen on a given COM port, for this purpose I'm using ShellExecute() to launch it from my application but it's a bit ugly since there is 2 different windows.
I was wondering if it was possible to integrate this newly opened HyperTerminal into an existing form (Panel for instance). I couldn't find nothing related excepted this =>
Delphi style, but i don't understand a byte of #mghie answer since it's delphi.
If anyone have a clue I'm really interested, even the most basic clue!
For almost all of my projects where COM port interaction is needed I use AsyncPro. The project is very well documented with a ~1000 page reference manual.
Reference Manual
Developer's Guide
For this case, the package provides a VCL terminal that simply drops onto a form. It's quite flexible with a lot of options to configure its behaviour.
I wanted something similar in past but with no success.
1.The only thing I was able to do is the exact opposite.
dock my VCL window inside another (not VCL app) but that solved my problems
If you terminal is console window then I doubt even this can be done.
anyway find handle of desired window
find handle to a dockable subcomponent
set the parent of your subwindow to it / or use manual dock
2.maybe you can do some funny stuff
like hide terminal somewhere
and continuoslly copy its graphics to your window
newer done that hide thing
but copy the contents is doable (although on windows a little unstable sometimes)
done it once to feed my App with IR-camera feed from different App
while 'focus' stays on hidden terminal it should work
also you can try to post messages to it somehow if you need the focus ...
Sorry for a vague answer but at least you see some approaches of mine
maybe someone has a better way to do this
I'm working on a project to show an overlay on any DirectX11 games. Now the overaly can show in some DX11 games but cannot in some others.
I hooked the DX11 API IDXGISwapChain::Present() using the MS Detour. In the function Present(), I setup each pipeline, call the DrawIndex and ResourceCopy update my overlay texture to GPU's memory, then call the original Present to bring the back buffer to front buffer. It works fine in some games like Unigene and DIRT2 but it doesn't work on some others like LostPlanet2 and DragonAge2.
Doing some logging with hooking all DX11 functions, I found an interesting things - those not working games call ResourceCopy and ResourceCopyRegion before calling Present.
Like I said previously, I also called the ResourceCopy in my Present(). Is it the reason why it doesn't work? How can I workarround it?
Thanks,
Marshall
I am also developing a similar D3D11 proxy hook. However, I begin from the entrypoints D3D11CreateDevice and D3D11CreateDeviceAndSwapChain. Then use replacement classes as hooks to my own. I found that some cases Detours cannot actually perform the detour properly:
Error detouring EntryPoint(): 6
I worked around this by actually modifying the Detours 3.0 source code to trampoline the function correctly.
I am working with 64 bit Windows 7 but compiled for x86 Detours 3.0. I can try out those binaries to work. It's quite hard to explain where ResourceCopy can influence the call path other than rendering style used by the programmer. If you like, you can send me your project code and I might be able to help.
Yes, I hate Objective-c, plus my project will be portable, so I'd like to code as much of it in C++ as possible, ideally 100%.
So I have a regular C++ project made with Xcode, and want to open some OpenGL windows.
edit: Damn, Glut takes over the app's control with glutMainLoop() and I'll like to have more control over the loop.
Will try freeglut, although I can't find OSX binaries, and I always have such bad luck trying to compile someone else's code.
Update:
I tried yet again to link to SDL 1.3 and this time I could get it to work! yoo-hoo!
I always wanted to work with SDL, but using more than one window was mandatory, and that's a feature of version 1.3 which is under development and I never could get it working.
As it is portable to a zillion OSes, and handles 2D graphics as well as OpenGL I'm going with it. Thanks to all!
If you don't want to use objective-c you're going to have to use either the deprecated carbon libraries, X11, or another library like GLUT to create the window. If portability is a concern either go the GLUT route, or you'll need to write your own window management code for each platform you want to support.
If you don't go the GLUT route you will need to write window management code fore each operating system so I strongly suggest you bite the bullet and write the window management in objective-c++. The only thing you really need to know is that a pointer is always a pointer no matter which language it is in, so just store objective-c ids as void* and cast them back to ids, it actually works out pretty easy.
i guess NeHe tutorials could help;
GLUT works fine for your stated purpose, although you will probably wish for a nice C++ wrapper for it. I ended up hacking my own, and although GLUT isn't friendly to wrapping, it was doable.
EDIT: Since you have a problem with glutMainLoop(), you may be trying to do more than GLUT was designed to do -- it is mainly intended for hacks, one-off projects and opengl demos. And freeglut doesn't compile OOB on the mac, at least that was my experience.
For a portable, fuller featured app, Qt may be the way to go for you. Otherwise, design your C++ for portability and use a thin GUI layer on each platform. If getting something running on each platform is most important, go for the former. If the best user experience on each platform is most important, go for the latter. You may find that "thin" is not the most descriptive term for what is involved.
I found this demo to be useful for getting a simple Cocoa/OpenGL window working, even though the code has a number of ridiculous bugs: http://developer.apple.com/library/mac/#samplecode/CocoaGL/Introduction/Intro.html
This question has been asked over 3 years ago, yet remain quite fresh. I just recently went through similar exercise for planning school curriculum, and trying to figure out what's the best portable library to work with on Mac/Windows/Linux/mobile with OpenGL projects. Perhaps my notes will help someone make a decision. I only mention the main options that I've considered.
Higher level APIs, for window management plus additional goodies, like sprites, fonts, sounds, event handling, etc:
SFML and github repo: nice&tidy, C++, object oriented library that integrates with OpenGL natively. Portability for managing windows and OpenGL 3.3 contexts out of the box on MacOS, Win and Linux. Mobile support provided in the 2.2 branch (github).
SDL2: all major platforms, including mobile, supported. The OpenGL context needs to be manually managed somewhat, so use of GLEW for example comes really handy (see below). A bit lower level than SFML.
Lower level APIs, mostly for window and OpenGL context management:
GLWF: This is pretty much a GLUT replacement for modern OpenGL. Rather low level, but portable across: Win, OSX, Lin. In active development.
GLEW: I only mention it for completness. It doesn't manage windows, but helps managing OpenGL contexts and you might use it together with GLWF or SDL for example.
Others:
Freeglut: Open source continuation of GLUT. Suitable for small demo projects. I have not used it myself, but seen good docs and demo code. In active development.
GLUT: old one, discontinued. Legacy demos and code around the net.
Background: I'm currently debugging an application written over a custom-built GUI framework in C++. I've managed to pin down most bugs, but the bugs I'm having the most trouble with tend to have a common theme.
All of them seem to be to do with the screen refreshing, redrawing or updating to match provided data. This is a pain to debug, because I can't break on every refresh, and most of this stuff is time-sensitive, so breakpoints occasionally "fix" the bug.
Q: Does anyone have any tips for debugging Windows-based GUIs, especially regarding the refreshing of individual components?
I agree with dual monitors or even remote debugging to reduce interfering with the messages.
I also highly recommend Spy utilities. These let you see what messages are being sent in the system. One such program is Winspector.
http://www.windows-spy.com/
This may not help, but I've found using dual monitors useful in this scenario. I have the debugger on one screen and the application on another. I can then step thru the code and see the application refreshing or doing whatever it is on the other screen.
There is still issues with focus doing this way, but at least I can see when it repaints.
Logging is pretty much the only answer. Without knowing your framework I can't give an exact answer but basically open a file and append messages in the various procedures of interest. Finally close it.
In the message include the values of the variable that you are interested in.
Also using the window Message Box is useful to see if you are in the correct branch or procedure. This has minimal effect on over all flow.
Finally try downloading any of the express version of .NET and use Winforms to try to make test of particularly problematical areas. While Winform is it own framework there is a high degree of correspondence between it's control and the ones provided by Windows.
I maintain a simulation of the Project Mercury Capsule as an add-on for the Orbiter Space Simulator. It is written in C++ and has to use Win32 directly for some of the panels and dialogs. There were times I fired up VB6 (VB.NET later) to work out some complex interaction and then translated it over to it's Win32 equivalent in C++.
However this is a last resort.
Having a dual screen really help when debugging refresh/redraw problem for Windows controls and UI.
Having the application on the second screen will not have the debugger generate "invalidate" on the main UI screens when it breaks for a debugging breakpoint.
If you cannot have a second screen, try to have both application side-by-side so that the application and the debugger will not interfere.