I'm creating a simple computer games framework using SDL, and am still deciding between using SDL's software renderer (Which is also much easier to use than OpenGL), or the supposedly faster OpenGL, despite the fact that in Visual Studio 2008 I'm having troubles linking the OpenGL libraries. Any suggestions for which graphical interface to choose?
The answer is .. depends.
You should ask yourself :
What is the number of polygons you will render per frame ?
What is the rendering rate (number of frames per second) that you wish to get ?
Do you expect the number of polygons to render increase in future ?
About Visual studio and linking problems, please find a sample project here that uses OpenGL. OpenGL Example.
Related
I have been developing this game in C++ in Visual Studio using DirectX 12. I used the Debug build configuration during development and the graphics were smooth as butter.
When I was preparing to publish the game on the Windows Store so I could share it with friends as play testers, I switched to Release build configuration. As soon as I did that I started getting this flicker of the back-ground color coming through my wall meshes.
Here is a short video that shows the flicker.
Here is a longer video that I made before switching to Release build configuration that shows there is no flicker.
I am new to DirectX 12. This project was my teacher. I studied Microsoft's Direct3D 12 Graphics, and I studied the DirectX 12 templates in Visual Studio.
I felt quite pleased that I was able to master DirectX 12 well enough to produce this game as well as I did. Then the Release thing, and the flicker thing, and I am at a loss.
Is this likely to be a shader issue? or a command queue issue? or a texture issue? or something else?
DirectX 12 is an API designed for graphics experts and provides a great deal of application control compared to say Direct3D 11. The cost of that control is that you the application developer are responsible for getting everything right, making sure it works across a broad range of hardware, and robustly handling stress scenarios and error cases all yourself.
There are numerous ways you can get 'blinking' effects in DirectX 12. A common one is failure to keep your graphics memory with constants, IBs, VBs, etc. unchanged between the time you call Draw and the time the actual draw completes on the GPU which often happens a few frames later. This synchronization is a key challenge of using the API properly. For an example solution, see GraphicsMemory in DirectX Tool Kit for DirectX 12.
If you are new to DirectX development, I strongly advise starting with DirectX 11. It's basically the same functionality, but takes care of buffer renaming, resource barriers, fences, VRAM overcommit, etc.
First off, I'm relatively new to this. I'm looking forward to picking up both SDL2 as well as SFML2 libraries for game dev. (and other stuff).
Now I know for a fact that both SDL2 and SFML2 are capable of creating OpenGL enabled contexts, through which OpenGL graphics programming may be done.
But online, I've read discussions wherein people said something to the effect of "SDL 1.2 is software accelerated, SDL2 and SFML2 are hardware accelerated by default". I know that software rendering is graphics using CPU alone. While Hardware rendering uses graphics cards/pipeline.
So my question is, with regards to these game libraries:
Part 1: when someone says one is software/hardware acc.by default, what does he mean? Is it that (my guess) if say SFML2 is hardware acc. by default, even basic 2d graphics are done by it using hardware rendering as the backend pipeline to do it, even if I didn't explicitly do any hardware-rendering programming in the code?
Part 2: And if that is true, is there any option within these libraries to set that to software acceleration/rendering?
Part 3: Which of these 2 libraries (SDL2 vs SFML2) has better overall performance/speed?
Thanks in advance for any answer and apologies if you found the question dumb.
Cannot say anything about SFML (but almost sure things are very close), but for SDL it is as you say. In SDL1 2d drawing implemented as blitting directly on display surface, and then sending this surface to display - so mostly software (although minor hw acceleration is still possible). SDL2 have SDL_Renderer and textures (which are GPU-side images or render targets) and any basic drawing that uses renderer may be accelerated by one or another backend. Which backend will be chosen depends on system your program runs and user settings - e.g. it would default to opengl for linux, d3d for windows (but still can use opengl), opengles for android/ios, etc..
You can use software renderer either by explicitly calling SDL_CreateSoftwareRenderer, or hint SDL to use software driver, or even override it by setting SDL_RENDER_DRIVER environment variable.
If you intend to use opengl for 3d graphics - then you just ignore all that and create window with opengl context as usual, and never use SDL_Renderer.
I am using OpenCV to show image on the projector. But it seems the cv::imshow is not fast enough or maybe the data transfer is slow from my CPU to GPU then to projector, so I wonder if there is a faster way to display than OpenCV?
I considered OpenGL, since OpenGL directly uses GPU, the command may be faster than from CPU which is used by OpenCV. Correct me if I am wrong.
OpenCV already supports OpenGL for image output by itself. No need to write this yourself!
See the documentation:
http://docs.opencv.org/modules/highgui/doc/user_interface.html#imshow
http://docs.opencv.org/modules/highgui/doc/user_interface.html#namedwindow
Create the window first with namedWindow, where you can pass the WINDOW_OPENGL flag.
Then you can even use OpenGL buffers or GPU matrices as input to imshow (the data never leaves the GPU). But it will also use OpenGL to show regular matrix data.
Please note:
To enable OpenGL support, configure OpenCV using CMake with
WITH_OPENGL=ON . Currently OpenGL is supported only with WIN32, GTK
and Qt backends on Windows and Linux (MacOS and Android are not
supported). For GTK backend gtkglext-1.0 library is required.
Note that this is OpenCV 2.4.8 and this functionality has changed quite recently. I know there was OpenGL support in earlier versions in conjunction with the Qt backend, but I don't remember when it was introduced.
About the performance: It is a quite popular optimization in the CV community to output images using OpenGL, especially when outputting video sequences.
OpenGL is optimised for rendering images, so it's likely faster. It really depends if the OpenCV implementation uses any GPU acceleration AND if the bottleneck is on rendering side of things.
Have you tried GPU accelerated OpenCV? - http://opencv.org/platforms/cuda.html
How big is the image you are displaying? How long does it take to display the image using cv::imshow now?
I know it's an old question, but I happened to have exactly the same problem. And from my observations I've concluded that the root of the problem is the projector's own latency, especially if one is using an older model.
How have I concluded it?
I displayed the same video sequence with cv::imshow() on the laptop monitor and on the projector. Then I waved my hand. It was obvious, that projector introduces significant latency.
To double-check, I've opended a webcam video, waved my hand in front of it and observed the difference on the monitor and on the projector. Webcam does no processing, no opencv operations, so in my understanding the only thing that would explain the latency would be the projector itself.
I just can't find them anywhere. The most important part for me is the hardware acceleration, and I have no idea if there is a performance or openGL version compatibility requirement that the video card has to follow.
The minimum system requirements will depend alot more on the application that you are writing than what SDL2 does.
If you just create a standard window and render SDL will use what it can find and what it thinks is best either OpenGL, OpenGL ES, Direct3D or use the old style software rendering for machines that can't do any of the other. So if a computer can support an OS that SDL runs on then you will almost always (I just said almost since there can possible be exceptions) be able to run these type of apps (Video card not a requirement, but having one will greatly increase programs drawing speed).
You can also be creating a OpenGL application directly and then it depends on what type of context you are making what the video card has to support.
You can find most of the information here: http://wiki.libsdl.org/moin.fcg/MigrationGuide
under the Video section. It's actually how to port from 1.2 to 2.0 , but it explains the new Video Pipeline pretty well.
Hope thats what you were looking for.
I've been looking for OpenGL version 2.0 or higher, but I haven't found anything I could use so far. There is no download section on the official website and google finds mostly stuff like OpenGL Viewer or OpenGL Screen Saver, but I am looking for OpenGL to develop games/graphics/vizualizations ( precisely version 2.0, but I know that higher versions are also compatible with 2.0 then they are also OK ). Could someone please give me a source, which I could get appropriate OpenGL for my project from? I've managed only to download one, but it didn't work, because it was created for 32bit OS, and I use 64bit windows 7. Does anyone know how to handle this problem as well?
this is my graphic card : NVIDIA GeForce 9600M GS
You don't have to download an SDK to use OpenGL in 64-bit applications on Windows. All you need is a 64-bit capable compiler, and the Windows Platform SDK (which comes bundled with Microsoft Visual Studio).
But there is a catch: Microsoft's OpenGL implementation hasn't been updated since OpenGL 1.1, and to use functionality from later versions OpenGL, you need to use OpenGL-extensions. Luckily, some nice people has made GLEW, a library that does the extension-work for you and allows you to simply compile OpenGL 2.0 (and later, as GLEW is updated) source code for Windows. Perhaps this is what you're looking for?
kusma is completely right, but maybe you'll need more precise directions.
First you'll need OpenGL libraries. These will be given with your Visual Studio / mingw / whatever installation.
Then you'll need to create an OpenGL window. You can do it with windows functions, but it is a nightmare. You should go for something like GLFW.
Then you'll need something to deal with openGL extensions ( as kusma said, you don't want OpenGL 1.1 only ). Use GLEW.
You will also need some math stuff : create a vector ( on the C++ side ), compute your projection matrix... GLM can do that for you.
Last but not least, you may want to use Cg for your shaders (but you can use GLSL instead, which is "built-in" in OpenGL)
Here's the OpenGL SDK site. LINK Is this what you are looking for?
The easy way to tell is if your using glBegin/glEnd statements you using old context methods (good for quick demos and prototyping, bad if your looking to do something that needs to look professional). When you start dealing with opengl topics that cover buffers and hint to VBO- vertex buffer objects and FBOs - Frame buffer objects your in the area of more modern opengl methods. If you want to get up to speed in the shortest amount of time, start with buffers and keep working your way forward. Just remember when your dealing with device contexts (methods to create your windows) if you stick with OGL 2.1 or lower your limiting yourself ( Think roughly DirectX9/early DirectX10) . Your video card handles DirectX10 and OpenGL 3. Best bet start there. Check out NVidia's developer site, http://developer.nvidia.com/ And, take a look at http://opengl.org site check out the forums - http://www.opengl.org/discussion_boards, the guys there are helpful (be careful not to re-post old questions).
Also check out http://swiftless.com - its a good start - and he labels his tutorials by ogl versions.