My question is that, how Can I draw one single pixel on the screen using C++ native libraries and functions? I mean not to use external functions or libraries. How is it possible?
Something Like this:
int rgb = {255,150,113};
nativeLibrary.drawPixel(0,1, rgb);
A fancy example just it is.
You can't. C++ does not (yet) have any native graphics or GUI libraries.
C++ may eventually add graphics into the standard (they were considering it), but for right now, the C++ standard does not include graphics.
You can take advantage of other standards in order to write a pixel to the screen, though. If you're on Linux, there is already an answer up.
If you're using VGA, you can actually write directly to the VGA buffer (WARNING: WAY OUTDATED Like "meant for DOS" outdated). You would probably use C++'s inline assembly to set the render mode instead of whatever that page uses, then use a regular unsigned char* instead of a "far" pointer to access it. Although you probably aren't using VGA and probably don't want to use assembly (especially inline assembly).
So what do you do outside of that? Nothing, really. You need to use an external library specifically to render, so probably OpenGL or DirectX or some library making use of either.
Like the previous answer, there no native library to deal with images. However, if you are working in Windows API and particularly MFC, you may use CBitmap class.
Related
I am relatively new to graphic programming so I wanted to start from the very basic. I see there is library like PyOpenGl which provides binding to the opengl api itself. Now, I really want to create things like PyOpenGl on my own so I can understand how everything work in the process.
Is it possible for me to creates library like PyOpenGl or GLFW? If so please give me some general tips of what should I do.
If not please explain to me why I can't create my own binding and I do apologize if my question above sounds absurd.
PyOpenGL is a fairly thin wrapper that, for the most part, simply turns Python function calls into calls of native machine code functions of the same name. There are a few little details like calling conventions in the mix, but these are actually boring stuff. The fact is that (as far as OpenGL is concerned) the source code you write in Python with PyOpenGL looks almost identical to the source code you'd write in C. There are a few "smart" things PyOpenGL does, like providing means to interface NumPy arrays to OpenGL calls that take a data pointer parameter, but that's just house keeping.
And when you do OpenGL calls in C or – even more extreme – assembly language (perfectly possible) that's the lowest level you can go (with OpenGL), short of writing your own GPU device driver. And writing a GPU device driver is super hard work; it takes literally millions of lines of C code (NVidia's OpenGL implementation is said to consist of about ~40M LoC, there are open source drivers for AMD and Intel GPUs, and each of them have MLoC, too).
If you're interested in some middle ground, have a look at the Vulkan API. If writing higher level wrappers for graphics is your thing I'd suggest you implement some higher level API / renderer for Vulkan and interface it to Python. This is likely to be much more rewarding, as a learning experience (IMHO).
The OpenGL API lives in the driver for the graphics card. All OpenGL functions are there. You only need to know how to get them. As Spektre said, the proccess is:
Create an OpenGL context. This is a job for the OS. Each OS has its
way and its issues. Read https://www.khronos.org/opengl/wiki/Load_OpenGL_Functions
Define function pointers as glext.h does and then extract them from
the driver. Apart from standard OpenGL funcs, vendors add their own
ones, called "extensions". You can see how GLEW does this job. If you want to set all functions and extensions then make a script that uses glext.h because there are about one thousand of them.
You can download glext.h from https://www.opengl.org/registry/
Doing something like GLFW requires, added to the previous two points, knowing how to create a window and handle its messages for keyboard and mouse. Again this is OS dependant. On Windows there is a way. On Linux it depends on the window manager used, GTK+ for example. Or X11 directly. Or...
Anyhow my best advise is that you can read how GLEW and GLFW did, looking into their code. BUT don't lose much time on it. Prefer getting experience on OpenGL and let those "diggins" for later time.
I am a student of programming, and have programmed in many different languages.
However, I have used c++ only once and in a very non-professional way.
I have had no formal training in c++, and yes I am doing something about that, as it causes tons of confusion when things look very different from say Java, which I have had formal training in.
A lot of help I try to find recently has been so non-concrete I have gotten no where with almost all my questions, and here is a very specific one:
I wish to make a very simple game. I have never been shown concretely how to render graphics. I want to use the most basic library I can to render them, which from what I can tell (in Windows that is) is GDI. I found this page: https://msdn.microsoft.com/en-us/library/d420az6e(v=vs.110).aspx
When I try to #include or use the namespace the classes say they are a part of, errors pop up like crazy.
Why is that? How to I import these classes so I can use them?
The link you have is for GDI+, not GDI. Despite almost identical names, they are not the same thing. GDI provides the most basic access to the display, via C calls only (no classes or any other OO stuff) and dates back to Windows 2.0.
GDI+ is more modern and has some improved capabilities, but it's still a bit outdated. As mentioned in the comments to your question, that link is for the .net API, if you're writing a native C++ application you won't be able to use it.
There is a native interface for GDI+, via COM. Take a look at this link.
I've been looking everywhere but cannot find an answer, is it possible to draw a pixel in C++ without a library, to the console, where I decide where to plot it(x,y).If not, how does a library manage to do this, I read it had something to do with the library gaining access to the drivers on the computer, but even then its still part of the C++ program.By the way I have never had formal programming education so this may seem silly.
This is possible, but highly dependendt on your operation system. You will have to use the OS API, because the C++ standard in itself doesn't have any idea of that kinda stuff.
For example, Windows has the SetPixel function that can be used on the console window. You can get the console window by using GetConsoleWindow and its context using GetDC.
That said, it's one of the less orthodox things to do, not portable and hard to predict - redraws of the console window will erase your content. Reconsider your options, and think about whether using a library might not be the better idea.
I'm currently in the process of writing a game engine which is about to go through a major rewrite. First off, I'm considering what library to use in conjunction with the engine. Obviously, I'm going with OpenGL here and am going to do what I can to make it forward as well as backward compatible.
The main issue, though, is that from most of my research, I've found that great libraries like SDL (except for 1.3 - which, I don't believe is stable? I may be wrong about this) only support up to OpenGL 3 and not 4.2. FreeGlut, however, does support the latest and greatest, and seems like a good way to go for the basics of an engine.
The only thing, however, is setting up something such as Keyboard I/O and sound input audio, along with other things. Thus, I'm considering to see whether or not it's possible to use glut to initialize opengl and use opengl with it, and then have SDL do window management along with keyboard I/O, sound, etc.
Of course, there's always the option of using Qt with OpenGL, but I'd like to definitely have control over my main loop if possible (is this possible with Qt and OpenGL?).
I've heard of SFML, too, but ultimately I'd like to stick with libraries written in C as I plan to write a C library to take care of most of the primitive rendering (for the sake of pure speed and memory management, procedurally).
Thus, I'm at a loss as what to do here. IS Qt a good choice for this, or is there another C-like alternative (such as FreeGlut) which allows main-loop control (like SDL) and offers the necessary customization I'm looking for?
The main issue, though, is that from most of my research, I've found that great libraries like SDL (except for 1.3 - which, I don't believe is stable? I may be wrong about this) only support up to OpenGL 3 and not 4.2. FreeGlut, however, does support the latest and greatest, and seems like a good way to go for the basics of an engine.
Your research is lacking.
First, FreeGLUT should never be used for anything that you would call an "engine". Whatever you mean by that, FreeGLUT is not the tool for the job. It's designed for creating demos, which is why it owns the main loop. I understand that FreeGLUT does have a way to allow you some control over the main loop, but the standard way to use FreeGLUT doesn't do that.
Second, you are correct that SDL 1.2 is not capable of creating an OpenGL 3.2+ core context. However, you don't have to be able to create a core context to use GL 3.2+; compatibility contexts work just fine at those versions. The only platform that has no compatibility context is MacOSX's 3.2 support. So I wouldn't worry about it.
You could try GLFW. It's sort of like FreeGLUT only more game-centric. It gives you control of the render loop and so forth. It provides better input handling than FreeGLUT, as well as some light image loading functions (only TGA files). It even has a threading API (though I wouldn't suggest using these functions. GLFW 2.0 will drop them since both C++11 and C11 have native thread APIs).
However, it has no systems in place for audio.
I've heard of SFML, too, but ultimately I'd like to stick with libraries written in C as I plan to write a C library to take care of most of the primitive rendering (for the sake of pure speed and memory management, procedurally).
I'm going to ignore the fallacy about C++ not having the "pure speed and memory management;" that's a common canard that I'll ignore. The important point is this: SFML, as far as your rendering code is concerned, exists solely to create and manage the window. Your rendering code doesn't even have to talk to it. You call some SFML functions, create a couple of SFML objects, and your "C library" OpenGL code won't even have to know those C++ objects are there.
However, if you absolutely cannot work in C++ at all, you can always use Allegro version 5. It has a C API, and it provides support for OpenGL core contexts, input, audio, and most of what SFML does. It also has pretty decent documentation, and is modular (though in a different way from SFML).
I have been looking all over the web for the simplest solution for this, and currently I have come across nothing that seems simple enough for my needs.
I am looking for a way to manipulate a matrix of pixels manually in C++, platform independent.
Does anyone know of a library that is simple to use that will help me obtain this?
Use SDL
Use OpenCV
By virtue of it being platform independent, you're probably not going to find a library that does only this. There are libraries like SDL and directFB that will let you do this, but not without extra baggage. X11 may even be a better choice. It supports things you don't need, but it also allows you to easily render pixels directly to the screen (or window, as the case may be).