Easy 2D graphics for C

[SourSW]

In my sophomore year at college for Comp Sci and have gotten into C programming with GCC. I'd like to fool around with doing 2D graphics. Are there any good/easy libraries out there that I can start out with? Am I able to stay in C or must I use C++? One thing though, I would like something easily portable between different OS's. So if I write this for Linux, I can easily compile it on Mac OS, Unix, or Windows. If I'm gonna learn graphics I'd rather learn something that I can use on multiple platforms. Thanx!

[JohnyDog]

Depends on whether your aim is pixel or vector graphics, however good start is SDL library (http://www.libsdl.org/).

[SourSW]

What is the difference between pixel and vector graphics? Going off the words themselves, would it be right to say with pixel, you generate the graphics one pixel at a time? And in vector you generate the graphics with vector coordinates? Sorry but I'm very new to this graphic stuff.

[JVene]

Work backwards....

Yes - vector graphics are those draw as lines, arcs and other geometric primitives like that.

Raster graphics (pixel graphics) are the generation of images by drawing pixel by pixel.

You'll probably get involved with both.

It will be easier in the long run to move toward C++ for this study, because there's a little more work involved doing this in C, but either might do.

Also, 2D graphics is a basic component of all GUI environments, which means that you're not always invoking a graphics library, strictly speaking, but the graphic drawing components of the operating system or framework for development.

As a fair example that's portable, consider WxWidgets. This is a free, open source framework that takes the general position of MFC for Windows, but works with the GCC compiler under Linux, (reportedly) the Mac and Windows. It also offers an OpenGL control, which gives you a good, generic, portable graphics drawing interface for 2D and 3D.

Beyond that, if you move into image work (displaying, loading, saving and manipulating bitmaps, like photos), you'll want to consider a library for that. CImg (google for it) is a free C++ library for doing that, and with the recommended free extension it can load and save bitmap images in various formats.

Don't assume you can ignore raster images easily, either. Every icon and button decoration is probably a bitmap, and many of the controls you use in a GUI are displayed with a combination of vector instructions (for the edges and surface of a button, for example), and raster instructions (to show the icon on the surface).

This study can go quite deep. Whole PHD's have been awarded in the domain of vector drawing methods and raster image processing. Still, the basics are hardly any more complicated than the average high school geometry course, and much of it is simpler than that.

You'll also discover the annoying fact that there are several different ways of doing the same thing, especially from an operating system/framework standpoint. For example, there are ways of drawing vector primitives in the GUI components of WxWidgets (which mimic the same in MS own MFC). There are similar methods within OpenGL, but they programmer's interface is quite different, and the performance of the two methods are also very different. If you're drawing a graph, the GUI components are adequate, but if you're creating a rudimentary animation then OpenGL is the faster portable way.

Another point to make, especially as you become more advanced, is the fact that graphic presentation can invoke the processor in the graphics system (a graphics card these days, but in the future we may see new ideas that fuse the general CPU duties with that of the GPU). This means that many of the advanced methods (OpenGL, DirectX, etc) are moving much of the processing of graphic work out of the general CPU (and it's 'language' in assembler) into the the GPU (with it's unique language and interface).

In the beginning phases of your study you won't see this, but as you reach for higher levels of performance, and move from 2D to 3D (which you will, despite your assumption to the contrary), your code will increasingly involve the GPU, and that means the method for development will become centered around the paradigms in OpenGL or DirectX. You will be required to provide data structured according to the GPU's needs, provide instructions that tell it to go do the work, and let it rip!