i am creating a library for game development, it uses directx 2d, however i want that some variables (ID2D1Factory, ID2D1HwndRenderTarget and others) be invisible to the end user. for example, the SDL library even using the directdraw (i guess), the directdraw classes are invisible for the end user of the SDL, and the user don't need to have the ddraw header in the includes folder of the compiler.
how can i turn these members independent(some way that the end user don't need to install the DirectX SDK for use my library), and turn these members invisible for the end user?
You don't need to install the DirectX SDK to link against a DLL .lib, or to compile with a .h, as long as you don't expose any DirectX objects (which you don't want to do).
Also SDL doesn't use DirectDraw. In fact it doesn't even exist since DirectX 7 (12 is coming out this September, so you're really out of the loop).
Related
How can graphics functions be used in Visual Studio 2017 (C++) without using a BGI library? What header file is used? I want to use these functions to do things like drawing a circle.
The header file <windows.h> allows you to use Windows API for many functionalities including but not limited to functions that you will use to do graphics by yourself such as SetPixel and GetPixel and many others you can see the code in this repository which contains C++ implementations for various circle drawing algorthims.
You have quite a few options:
Windows API - Quite difficult to use but runs incredibly fast. This is perhaps the most difficult option due to how complex and no-hand-holding it is.
MFC - Microsoft's tools for C++ graphics. Not too easy to use but certainly easier than WinAPI. A lot of people don't like using this as it's kind of old and there are better stuff out there.
OpenGL/Vulkan/DirextX - These three are very similar technologies. They are based around using your graphics card for drawing, using small programs called 'shaders' which can be edited and compiled on the fly. Most games use one of these, and they run pretty fast. DirectX is Windows only, and Vulkan is pretty low-level. I would recommend OpenGL out of these three.
External library - There are many libraries you can use such as Qt, wxWidgets or SFML. All of these have their own pros and cons, but they all are third party libraries which bridge the gap between commands like 'draw a circle' and the Windows calls that go on under the surface.
Chromium Embedded Framework - CEF allows you to code the guts of your program in C++, then create the GUI using HTML5 and Javascript. Essentially it's a web browser connected to a C++ backend. Looks really nice but some criticise it for its resource usage, which is much larger than the alternatives.
I would recommend staying away from WinAPI and MFC and either use a third-party library (for simple GUIs) or OpenGL (for complex rendering i.e. games). If you're confident in web programming then you can go for CEF.
guys! I'm currently working on new cross-platform application (iOS, Android, UWP). I have graphical library for UI written in c++, using freeglut for opengGL.
The problem is, I don't know how to use this library in my UWP application. I have read a lot of information about all the wrappers for OpenGL, but they all for WPF or written in C++. I also know about Microsoft ANGLE Project, but it is written in the c++ too, but I need to write the application in C# language.
So, how can I modify my own library using excluding freeglut and import it into my C# application?
By the way, sorry for mistakes in my English.
So you want to consume your legacy C++ assembly in your UWP application?
You can create a Windows Runtime Component(Universal Windows) project, in which you need to include the assembly, and declare as many APIs as you want to expose, all marked with DllImport attribute.
Eventually, this WinRT component will do the Platform Invoke, and works as a "wrapper" layer between your legacy code and UWP application.
It's up to your preference which language you use for the WinRT component, C++ or C#, either way, you need to worry about struct/type mashalling and unmashalling.
After you're done with above, you'll be able to reference the WinRT component in your UWP application, and call the APIs you declared in that assembly.
The same way works for Microsoft Angle project as well.
You might find this post useful.
One last word, you might want to avoid using forbidden APIs, otherwise your UWP app won't pass the Windows Store Certification.
According to https://msdn.microsoft.com/library/windows/desktop/jj714080.aspx there is an option to use DirectX and some native API functions including LoadLibrary and GetProcAddress functions https://msdn.microsoft.com/library/windows/desktop/jj714080.aspx
This should give you ability to use any native dll.
You can try to make RuntimeComponent project and put it there. Also you can try clr oldsyntax option to use native code as it is.
Is there some basic way to draw something in C++?
I know there are lot of engines, libraries etc. But these libraries have to use some most basic drawing function or whatever it is. I mean normally without any non-standart c++ libraries you are only able to make console applications. But the new libraries that can draw something, or atleast show something different than standard command line, have to use some basic function that allows to make something different without commandline.
I've heard about WIN32 API (I'm not targeting just Windows platform,vbut I'm using windows, still have Ubuntu(Wubi)). I just can't belive that the only way is to use WIN32 API.
So I guess my questions are as follows:
Are all GUI(or non-console) libraries using WIN32 API as basic?
Are linux developers required use some linux API for GUI?
(Sorry for my English, it's not my native language)
The operating system (on a modern computer) is in charge of the screen so you have to use it's functions to draw on the screen.
There are a whole range of libraries from very high level ones, where displaying a video is a single line of code, to low level ones where you can determine the details of every pixel.
As well as drawing on the screen a GUI library, or toolkit, is also responsible for handling keyboard and mouse, for dealing with other windows going over your window and for drawing all the standard controls such as file open boxes etc - that's why it's a bit complex.
See minimal cross-platform gui lib? fro some examples
I'm writing an app that's going to use 3rd-party created plugins to render all kinds of 3D trickery.
My main application is to create the context / render-object and a rendertarget/framebufferobject. The 3rd-party plugins are going to be rendering their fancy stuff to that, so they need access to that context / renderobject to perform their 3d-render-related calls.
I can choose to implement this using either OpenGL or Direct3D.
My decision will most probably be based on my understanding of the next problem :
Obviously, new versions of OpenGL / Direct3D will be coming out, and it would be nice if newly created plugins could benefit from newer versions of DX/OGL than the main program was compiled with. (if the computer running the application supports that newer version)
Using OpenGL (using OpenTK) I understood it's possible to create a forward-compatible context, as in "Give me the most up-to-date-version that is backward compatible with version X".
So when asked for a 3.2 context, if 4.0 is available it would return a 4.0 context.
For DirectX, I don't see anything like that, which would mean that if I create my main program with DirectX 11 for example, 3rd-party plugins would never be able to use newer versions when available ?
Am I getting this correct ?
Will OpenGL enable 3rd-party plugin writers to create plugins for newer versions of OpenGL, while DirectX will not allow me to do something like that ?
I'd be amazed if DirectX ever supported the sort of compatibility you're talking about within an application. Each version of the Direct3D APIs has basically been an independent (COM) object hierarchy with absolutely no acknowledgment that other generations of the system might exist, past or future. (Backwards compatibility at the platform level has generally been superb, of course, but you're after something quite different).
So either go with OpenGL (the support you mention at least sounds like it offers some hope), or maybe even consider a higher level API for plugins which somehow "compiles"/"adapts" to the actual target platform at runtime. That'd let you support OpenGL and Direct3D (although obviously shaders in particular would present severe difficulties; hence projects like AnySL).
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.