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.
Related
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.
I have access to both OSX and Windows. I have built my demo in Visual Studio 2010 using C++ and DirectX 10. I have read that C++ can be run on the iPhone using XCode, but that any input has to handled in objective-c.
At present there is no input so that's not an issue right now.
What are the steps I would have to take to get it running on the iPhone?
also - was not quite sure how to tag this question. by all means edit them if they're wrong.
Yes, you can run C++ code fine on an iPhone. I've released a couple games which have a large C++ component. Of course, the graphics will need to be redone.
Likely you'll need a little bit of Objective-C++ code to communicate between the UI layer and the underlying engine.
There's no DirectX on iOS (being that it's made by Microsoft) so any code that calls DirectX is going to need to be ported over to something that can be run on iOS, like OpenGL.
Other than that you'll be treating your code like a library. With a layer of objective-c that sets up the app, and calls the necessary parts of your C++ code.
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.
In Windows XP the Win32 API renders the controls using GDI/GDI+.
Now I'm on 7, so if I use the API's functions, will the rendering automatically be handled by the DWM/WDDM (so by DirectX)? or will it continue to render with GDI?
Or likewise, will an old app written with WinAPI, be rendered with GDI also in Windows 7?
Thank you in advance for the help :)
In my experience, if the Aero display is on everything will render via that system, it just won't be obvious to your application. You'll still render in GDI, but it will be to a back buffer and not directly to the screen buffer (in fact it's more complicated then that). That way your older app can get the benefits of the new features, like the live preview effects, without having to be aware of them.
Really though, your application doesn't really notice a difference. The API is still the same API as before and works as you expect it. There are ways to take advantage of this, but you have to opt in to really use it.
If your application is written to use GDI, then it will continue to use GDI. The underlying implementation has changed quite a bit (as I recall, most hardware acceleration was removed in Vista, and put back in, in a new form, in Win7)
But it won't magically be transferred to Direct2D, no.
On performance front, it is the same old farce and as per usual 'Do Your Own Benchmarking' across OS-es. But, almost a decade old OS for anything GDI still slams Windows7 and plenty of apps will be incredibly more responsive on XP.. Sadness.. especially when you consider that translation of such an old API (as a compatible interface) should be trivial to any new driver or display tech.
Apparently some ops like blitting are supported but look at the result of your target 2D GDI app and judge for yourself..
Here are some observations, but please do your own for a dozen scenarios and compare, especially if it is GDI intensive like a million audio/video apps out there (no wonder iFruit boys are gaining share).
http://www.passmark.com/forum/showthread.php?t=2233
And while you will find all the typical and fluffy MSDN blog explanations that get 'technical' (ie. surface-style nonsense) the reason is very simple: buy a new OS, pull the carpet on old API and complicate it further by allowing new APIs to work with it (but not benefit the old one, easily doable by providing a new dll and .lib ).
For one history lesson and how hard it was to translate GDI calls to Direct2D or use libgdiplus from Mono and derive ideas etc, here is the propaganda:
http://blogs.msdn.com/directx/archive/2009/05/12/2d-drawing-apis-in-windows.aspx
The scenario is such: there's a program which loads my .dll/.so and calls a function from within it, possibly multiple times, each time expecting a different pointer to state. It uses the different states later in other calls into the dll. (It's a game AI, if you need context; each state is a AI player.)
What I want is a cross-platform way of creating a canvas window for each of those states (for visualization, debugging, etc.) I tried wx, but put it on hold, since it didn't appear to be easy at all. Are there any neat and small libraries that could do that or should I just go with WinAPI/X...?
Edit: Assume I cannot modify the host program.
Qt is simpler to set up and drive than Wx, in my experience. It's very cross platform too.
If you want to render some graphics from inside your DLL function without passing in any pointers to QImage or QWidget type things, probably the thing to do is use OpenGL. Your DLL should just render to the current OpenGL context, which is global state and can just be setup outside the DLL (maybe using QGLWidget).
Update: Ah, I just noticed your edit re not being able to modify the host code. This is a problem: any windows you create really need to be plugged into the host apps' event loop to work properly (e.g receive WM_PAINT when exposed/resized). It's certainly possible in win32 for any old code (e.g your library) to just CreateWindow and draw its contents with GDI whenever it gets the chance, but the general window behaviour may be pretty broken (it may not work at all with Vista's double buffering; I haven't tried). What I typically find easiest in this situation is simply to dump out image files and review then afterwards with image viewer of choice. IMHO this is actually more useful for debugging than a "live" window because you can step backwards and forwards, zoom in, apply image-enhancement to highlight various issues, compare against previous runs for regression testing etc etc. (If you really want the "live" views, write an image displayer which monitors a directory for new images, or streams them through a named pipe or something).
If you just want simple graphics, no widgets, SDL is very easy to use. If you do need complex controls, use Qt, as timday said.
You might check out IUP. It interfaces really well with Lua, and can be used entirely from an extension DLL there so it seems plausible that its C API could be used from a DLL plugged into something else.
IUP will get you a framework for opening a window containing the usual suspect kinds of controls, including a canvas. Its related library CD will give you the usual drawing operations in that canvas.
Current releases are portable between Windows and *nix. The next major release will support MacOSX too.