C++ Graphics Tutorial

IShallRiseAgain

I was wondering if anyone could link to me a good basic graphics tutorial (just on how to draw pixels on the screen basically and perhaps something about palletes) for c++. I tried searching the ye old internet, but i couldn't really find anything. it would be greatly appreciated, since my C++ High School Class is way too slow for me.

Janin

C++ doesn't have anything built in for graphics, so you'll have to decide on which libraries to use. If you want to do fancy 3D stuff, try OpenGL. If you just want to do 2D graphics, try the Cairo Graphics Library, which runs on every major platform and is very powerful.

.:Orion

There's SDL for drawing stuff to your screen. I only used the .Net version with C# though but you could look into it.

If you've been following G&T, look at the TheSonicRetard's thread about a home-made Sonic to see what's possible with it.

IShallRiseAgain

ok thanks

Valkun

There's also DirectX if you really want to get advanced. Just do a search for DirectX tutorials and you'll find plenty of examples and walkthroughs.

Clipse

Can't believe no one has mentioned Nehe's Tutorials yet. They're pretty much the best source, with the possible exception of a university course, from which to learn about OpenGL at the beginners' level.

Philodox

DirectX and OpenGL are huge overkill if the OP just wants to do 2D drawing. DirectX and OpenGL are both fairly complicated.

LoneIgadzra

Clipse wrote: »

Can't believe no one has mentioned Nehe's Tutorials yet. They're pretty much the best source, with the possible exception of a university course, from which to learn about OpenGL at the beginners' level.

That guy's stuff drives me up a wall. The "tutorials" are incredibly bogged down by all the WIN32 API code, and it's next to impossible to take anything away from them since they fail to adequately summarize, from a conceptual standpoint, what the hell they're doing so that I can rework the important bits into my own programs (which tend to be very different, architecturally, from Nehe's code). They just ponderously go through the hilights or something of the program in a linear fashion, and it's very difficult to work with, since the code included inline in the page is insufficient to create a working program. Ultimately I just download the source code and try to figure it out on my own, if I have to resort to a Nehe tutorial.

So yeah, SDL is what you want for some 2D graphics. I'm not sure what a good tutorial is yet, since I have not currently found one that uses a method that both makes sense and ultimately results in an acceptable level of speed (what in God's name is that official "putpixel" function bullshit? It takes like an hour per pixel...)

Janin

LoneIgadzra wrote: »

So yeah, SDL is what you want for some 2D graphics. I'm not sure what a good tutorial is yet, since I have not currently found one that uses a method that both makes sense and ultimately results in an acceptable level of speed (what in God's name is that official "putpixel" function bullshit? It takes like an hour per pixel...)

Filling in a screen pixel-by-pixel will always be slow, no matter what API you use. If you're concerned about performance, try using BlitSurface or FillRect. However, in this case I would really advise using OpenGL - SDL is software rendering only, and will always be significantly slower than a hardware accelerated library such as OpenGL.

Caswynben

LoneIgadzra wrote: »

Clipse wrote: »

Can't believe no one has mentioned Nehe's Tutorials yet. They're pretty much the best source, with the possible exception of a university course, from which to learn about OpenGL at the beginners' level.

That guy's stuff drives me up a wall. The "tutorials" are incredibly bogged down by all the WIN32 API code, and it's next to impossible to take anything away from them since they fail to adequately summarize, from a conceptual standpoint, what the hell they're doing so that I can rework the important bits into my own programs (which tend to be very different, architecturally, from Nehe's code).

Here here.
www.libsdl.org
Start there, get it running, make an example skeleton project and go from there.

jothki

jmillikin wrote: »

LoneIgadzra wrote: »

So yeah, SDL is what you want for some 2D graphics. I'm not sure what a good tutorial is yet, since I have not currently found one that uses a method that both makes sense and ultimately results in an acceptable level of speed (what in God's name is that official "putpixel" function bullshit? It takes like an hour per pixel...)

Filling in a screen pixel-by-pixel will always be slow, no matter what API you use. If you're concerned about performance, try using BlitSurface or FillRect. However, in this case I would really advise using OpenGL - SDL is software rendering only, and will always be significantly slower than a hardware accelerated library such as OpenGL.

I don't know that much about graphics in C++, but would it be faster to fill a buffer with what you want and then dump the entire buffer into whatever the library uses? Of course, I assume that a good library would have built-in stuff to do that anyway.

Janin

jothki wrote: »

jmillikin wrote: »

LoneIgadzra wrote: »

So yeah, SDL is what you want for some 2D graphics. I'm not sure what a good tutorial is yet, since I have not currently found one that uses a method that both makes sense and ultimately results in an acceptable level of speed (what in God's name is that official "putpixel" function bullshit? It takes like an hour per pixel...)

Filling in a screen pixel-by-pixel will always be slow, no matter what API you use. If you're concerned about performance, try using BlitSurface or FillRect. However, in this case I would really advise using OpenGL - SDL is software rendering only, and will always be significantly slower than a hardware accelerated library such as OpenGL.

I don't know that much about graphics in C++, but would it be faster to fill a buffer with what you want and then dump the entire buffer into whatever the library uses? Of course, I assume that a good library would have built-in stuff to do that anyway.

That's basically what BlitSurface does. The idea is you load a sprite (or set individual pixels) in a buffer until it's the way you want, and then fast-copy it into parts of the screen as needed. This avoids the need to set pixels individually in the drawing buffer.

Philodox

If he's looking for an introductory tutorial I doubt he cares to much about it being "slow".

jothki

From my experiences in high school, slow graphics aren't terribly difficult to make. The hard part, and probably the part that he cares about, is learning how to not make them slow.

Clipse

LoneIgadzra wrote: »

That guy's stuff drives me up a wall. The "tutorials" are incredibly bogged down by all the WIN32 API code, and it's next to impossible to take anything away from them since they fail to adequately summarize, from a conceptual standpoint, what the hell they're doing so that I can rework the important bits into my own programs (which tend to be very different, architecturally, from Nehe's code). They just ponderously go through the hilights or something of the program in a linear fashion, and it's very difficult to work with, since the code included inline in the page is insufficient to create a working program. Ultimately I just download the source code and try to figure it out on my own, if I have to resort to a Nehe tutorial.

I agree his insistence on using WinAPI over GLUT or SDL is kind of irritating, but I never had any trouble understanding the important points of one of his tutorials (as long as I read the article, and not just the code). I suppose it varies from person to person.

Philodox wrote:

If he's looking for an introductory tutorial I doubt he cares to much about it being "slow".

If he's doing computer graphics, he's probably going to want to animate something after he understands how to draw things on the screen, and having a simple animation chug along at 2 frames per second is rather disappointing.

LoneIgadzra

Clipse wrote: »

LoneIgadzra wrote: »

That guy's stuff drives me up a wall. The "tutorials" are incredibly bogged down by all the WIN32 API code, and it's next to impossible to take anything away from them since they fail to adequately summarize, from a conceptual standpoint, what the hell they're doing so that I can rework the important bits into my own programs (which tend to be very different, architecturally, from Nehe's code). They just ponderously go through the hilights or something of the program in a linear fashion, and it's very difficult to work with, since the code included inline in the page is insufficient to create a working program. Ultimately I just download the source code and try to figure it out on my own, if I have to resort to a Nehe tutorial.

I agree his insistence on using WinAPI over GLUT or SDL is kind of irritating, but I never had any trouble understanding the important points of one of his tutorials (as long as I read the article, and not just the code). I suppose it varies from person to person.

It's a stylistic problem I have with a lot of tutorials. Instead of saying, "for this we need two GLuint's, the first for this, the second for that" they say "new items in this code: foo1, foo2 - storage for two textures" or something. I don't care about his goddamn code (which never works anyway, unless you download the completed version because the tutorial text invariably omits something important), I want to know exactly how the concept works so I can use it in my code. A lot of tutorials (including Nehe) rush through some frequently half-assed implementation, and leave me to do all kinds of tests and research to divine all the quirks of how the API actually functions and how a more useful, professional implementation might work.

And yes, I already use SDL with OpenGL for all my graphical programming efforts where I don't feel like dealing with something more complicated.