The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
C++ Graphics Tutorial
IShallRiseAgain
Registered User regular
Registered User regular
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.
IShallRiseAgain on
0
Posts
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.
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...)
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.
www.libsdl.org
Start there, get it running, make an example skeleton project and go from there.
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.
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.
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.
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.