I'm Using the SDL library in C to learn some game dev , however i'm quite confused as to what SDL_RenderClear does and when do we use it. I did check the SDL documentation about the same , however i still wasn't able to understand where exactly we would use it and what is its use.
It's like rendering background color to color you have set via another API namely SDL_SetRenderDrawColor as you already found on documentation online.
Imagine you have rendered several things on screen. To begin again, you need to clear it to start over. Underlying of SDL_RenderClear wraps specific native platform your application runs on top, it can be OpenGL, DirectX, etc. It helps in communicating with such specific function that platform provides in order for you to flexibly clear your screen without a need to know low level functions, and use SDL2 for other things else like windowing, inputs from keyboard/mouse/joysticks, sound, and even utility functions related to rendering to aid your own rendering implementation.
To add a few more, SDL2 provides minimal but optimized rendering capability. SDL_RenderClear is one of those several functions you can use in rendering category. Anyway, you can decide to go on integrating with what you prefer i.e. OpenGL, DirectX, Vulkan etc. yourself.
Related
I am interested in making a game trainer but I stumbled over the question of making a menu which the player can choose from. I am using C++ and my target client is windows based.
I searched around and people mostly use DirectX and hook into the game to draw (A little bit like the discord overlay) but I find it extremely difficult to use DirectX.
Here is an example I found:
I really like the way the SFML library draws but I can't seem to find any APIs which support that ease of drawing.
I once did manage to make a menu in C# by using System.Drawing to draw an external overlay which I could draw to using C#'s brush API, however I prefer to write in C++ as I feel I can do more in that language.
My question is:
Is the a way I could use something like the System.Drawing/SFML API to draw an overlay over another window in C++ (Which would be accessible in a console application)?
Is it easily portable (As a DLL or even including a header)? (Most of the solutions I have seen are not portable and/or widely supported)
Check out Qt for drawing images, text, etc.
http://doc.qt.io/qt-5/qtwidgets-painting-basicdrawing-example.html
It is widely supported, and also cross-platform
You can create a transparent window and use setWindowFlags(Qt::WindowStaysOnTopHint);
As I mentioned in a question before, I am trying to make a simple game engine in C++ with OpenGL.
I am currently using GLFW for drawing the OpenGL context and I chose it because I heard it's one of the faster ones out there. However, it doesn't support widgets and I really don't want to write them myself. So I decided to get into Qt a bit, because it would allow me to have a pane for the render context and different handy bars as well as all the fancy elements for editing a world map, setting OpenGL rules, etc.
I want to use GLFW on the exported version of that game, though. Is that possible without an abstraction layer of some kind?
Thanks in advance! :)
Yes it is definitely possibile, infact I'm writing a 3D engine that is not coupled to any windowing library and can be used with Qt, SDL or whatever.
You of course have just to wrap regular GL calls into a higher level layer, this require you don't call "SwapBuffers" inside your GL code.
If by abstraction layer you mean "inversion of control" so, you don't want to override a "Render/Update" method that's exactly what I done. If by "abstraction layer" you mean you want to use GL directly than it is still possible.
Basically every windowing system have "some place" where you can make your GL calls (between MakeCurrent and SwapBuffers). Just read documentation of your windowing system.
I have been using a few cross-platform GUI libraries (such as FLTK, wxWidgets, GTK++), however I feel like none fulfil my needs as I would like to create something that looks the same regardless of the platform (I understand that there will be people against building GUI's that don't have a native look on the platforms but that's not the issue here).
To build my controls, I usually rely on basic shapes provided by the library and make my way up binding & coding everything together...
So I decided to give it a try and do some opengl for 2D GUI programming (as it would still be cross-platform. With that in mind, I couldn't help to notice that the applications that I have written using wxWidgets & FLTK usually have a average RAM consume of 1/2MB, whereas a very basic openGL window with a simple background ranges from 6 to 9 MB.
This brings me to the actual question for this thread,
I thought that all the rendering of the screen was made using either opengl/direct (under the covers).
Could someone please explain or link me some sort of article that could give me some insight of how these things actually work?
Thanks for reading!
These multiplatform toolkits usually support quite a lot of backends which does the drawing. Even though some of the toolkits support OpenGL as their backend, the default is usually the "native" backend.
Take a look eg. at Qt. On Windows it uses GDI for drawing for its native backend. On linux it uses XRender I think. Same on Symbian and Mac. Qt also has its own software rasterizer. And of course there is an OpenGL backend.
So why the application using some of these GUI toolkits can take less memory than a simple OpenGL application? If the toolkit use the "native" backend, everything is already loaded in memory, because it is very likely that all visible GUI uses the same drawing API. The native APIs can also use only one buffer representing a whole screen in which all applications can draw.
However when using OpenGL you have your own buffer which represents the application window. Not to mention that an OpenGL application usually has several framebuffers, like z-buffer, stencil buffer, back buffer, which are not essential for 2D drawing, but they take some space (even though its probably the space in graphics card memory). Finally, when using OpenGL, it is possible that the necessary libraries are not yet loaded.
Your question is exceedingly vague, but it seems like you're asking about why your GL app takes up more memory than a basic GUI window.
It's because it's an OpenGL application. This means it has to store all of the machinery needed to make OpenGL work. It means it needs a hefty-sized framebuffer: back buffer, z-buffer, etc. It needs a lot of boilerplate to function.
Really, I wouldn't worry about it. It's something every application does.
I've been challenged with a C++ 3D application project that will use 3 displays, each one rendering from a different camera.
Recently I learned about Ogre3D but it's not clear if it supports output of different cameras to different displays/GPUs.
Does anyone have any experience with a similar Setup and Ogre or another engine?
At least on most systems (e.g., Windows, MacOS) the windowing system creates a virtual desktop, with different monitors mapped to different parts of the desktop. If you want to, you can (for example) create one big window that will cover all three displays. If you set that window up to use OpenGL, almost anything that uses OpenGL (almost certainly including Ogre3D) will work just fine, though in some cases producing that much output resolution can tax the graphics card to the point that it's a bit slower than usual.
If you want to deal with a separate window on each display, things might be a bit more complex. OpenGL itself doesn't (even attempt to) define how to handle display in multiple windows -- that's up to a platform-specific set of functions. On Windows, for example, you have a rendering context for each window, and have to use WGLMakeCurrent to pick which rendering context you draw to at any given time.
If memory serves, the Windows port of Ogre3D supports multiple rendering contexts, so this shouldn't be a problem either. I'd expect it can work with multiple windows on other systems as well, but I haven't used it on any other systems, so I can't say with any certainty.
My immediate guess, however, is that the triple monitor support will be almost inconsequential in your overall development effort. Of course, it does mean that you (can tell your boss) need a triple monitor setup for development and testing, which certainly isn't a bad thing! :-)
Edit: OpenGL itself doesn't specify anything about full-screen windows vs. normal windows. If memory serves, at least on Windows to get a full screen application, you use ChangeDisplaySettings with CDS_FULLSCREEEN. After that, it treats essentially the entire virtual desktop as a single window. I don't recall having done that with multiple monitors though, so I can't say much with any great certainty.
There are several things to be said about multihead support in the case of OGRE3D. In my experience, a working solution is to use the source version of Ogre 1.6.1 and apply this patch.
Using this patch, users have managed to render an Ogre application on a 6 monitors configuration.
Personnaly, I've successfully applied this patch, and used it with the StereoManager plugin to hook up Ogre applications with a 3D projector. I only used the Direct3D9 backend. The StereoManager plugin comes with a modified demo (Fresnel_Demo), which can help you to set up your first multihead application.
I should also add that the multihead patch is now part of the Ogre core, as of version 1.7. Ogre1.7 was recently released as a RC1, so this might be the quickest and easiest way to have it working.
I've been programming opengl using glut as my window handler, lately i've been thinking if there are any advantages to switching to an alternate window handler such as wxWidgets or qt.
Are there any major differences at all or is it just a matter of taste? Since glut provides some additional functions for opengl-programming beyond the window handling features, would there be a point in combining an additional toolkit with glut?
I can only speak from experiential of using QT:
Once you have the basic structure set up then it is a simple case of doing what you have always done: for example, the project I am working on at the moment has an open gl widget embedded in the window.
This widget has functions such as initializeGL, resize...paintGL etc. Advantages include the ability to pass variables to an from the other windows / widgets etc. QT also has additional functions for handelling mouse clicks and stuff (great for 2d stuff, 32d stuff requires some more complex maths)
You need to move from glut as soon as you want more complex controls and dialogs etc.
QT has an excellent openGL widget there is also an interesting article in the newsletter about drawing controls ontop of GL to give cool WPF style effects.
wxWidgets also comes with an opengl example but I don't have much experience of it.
Well - glut is okay to get a prototype going.
It depends on the OS, but later on you may want to prevent the screen-saver from starting, you may want to disable the task switch (only the bad guys do this though), You may want to react to power down events. You may find out that glut can't deal with dead-keys on one or another operation system, or, or, or... There are thousand reasons why you may want to get rid of it.
It's a framework designed to make the start easy and do 90% of the usual stuff you need, but it can never do 100%. You can always hack yourself into glut or lift the init-code, but one day you will find out that it's easier to redesign the init-code from scratch and adjust it to your task.
Opening a window and initializing OpenGL is not rocket-science . Use glut as long as it works for you, but as soon as it makes problems get rid of it. It'll take you just a hand full of hours, so you won't loose much.
For a toy project glut is the way to go though.
SDL, while not just a window handler, will make it easier to use OpenGL than raw Win32 code. However, my experience with Qt, GTK and wxWidgets has not been too bad... certainly not that much better than Win32, its probably a matter of taste in those cases.
I'd recommend avoiding widgets and wrappers like GLUT if you want a fine level of control over the window and resources, but if you are just looking for speed of development then these tools are ideal.