Anyone know of a simple graphics libary I could use ?

[bilateralrope]

I'm writing a small program that outputs an image consisting of lots of vertical and horizontal lines. Calculating where the lines should go is a simple recursive algorithm. The problem comes in that I'm working in C (changing to something else isn't an option) and I have no idea how to do graphics.

I'm writing this on a Linux machine that does support OpenGL, but when I look for help with it I find lots of stuff for 3d work, or doing 2d shapes, but I can't find anything that helps me.

So do any of you know of either where I can find the information I need for OpenGl, or of another free graphics library that I could use ?

[Resinence]

I assume since your using C your comfortable with low level stuff? You could take a look at SDL, more specifically using SDL with OpenGL, there is pretty decent documentation on the site for most things. I've used it before (with directx in a .net program through a C++/CLI wrapper) and it was fairly straightforward.

SDL

[Dooey Jo]

What kind of image is it? Is it static and has power of two dimensions? If not, OpenGL is probably a bad idea, unless you can do your computations as a pixel shader. (Or you could display all the pixels of your graphic as coloured points...)

If it is static, maybe you can use FreeImage to save the graphic as an image file. Otherwise, SDL is probably easiest (even though I have never used it directly myself).

[bilateralrope]

It's just a static image.

[Namarie]

My boyfriend suggested this:

OpenVG

[bilateralrope]

I've taken a quick glance at both, and I should be able to work through the documentation on SDL at least, although I still feel a bit overwhelmed. But it's going to be a few days before I get started.

Beyond doing this program, I have no interest in doing graphics, so it doesn't matter if I don't understand exactly what the code is doing. So which pieces of documentation should I look at to get the code to:

- Initialise the window the lines are being drawn in.
- Draw a line between two points in that window.
- Some code to make sure the window doesn't close till I tell it to.

Copy/paste code is preferred, but I understand if you guys want me to work at it myself.

[Sarevok]

http://cone3d.gamedev.net/cgi-bin/index ... xsdl/index

It's got me writting a 2D game in a few hours.

[Resinence]

http://www.libsdl.org/intro.en/toc.html and read through at least parts of it, they provide example code snippets and explain how the library can be used in an acceptable level of detail.

I could help a bit more if you explain what you actually want to do, are you just displaying a logo somewhere or making an image viewer? If it's static images I think SDL is massive overkill.

[bilateralrope]

http://www.libsdl.org/intro.en/toc.html and read through at least parts of it, they provide example code snippets and explain how the library can be used in an acceptable level of detail.

I could help a bit more if you explain what you actually want to do, are you just displaying a logo somewhere or making an image viewer? If it's static images I think SDL is massive overkill.

The program takes some numbers entered by the user, then generates an image from the input via a recursive method. The recursive method would draw a line, then call another method twice with slightly different parameters. The other method would draw a line, then call the first one twice. One does the vertical lines, the other does horizontal. Since all these lines need to be displayed, I don't see it mattering much if the lines are drawn before or after calling the other methods. I'll need the image to be displayed till I tell it to close.

So SDL does look like massive overkill. As does every other graphics library I've been able to find.

Sarevok, those instructions look to be exactly what I would need, if I was working on a windows machine. I think I can see how to adapt them to Linux though.

[Resinence]

Linux? You could try using GTK, if I recall it has a "drawline" class that you can use in a gtk drawing area, and it's not overkill since you can use GTK to draw your window and controls as well, should keep things lite. I'll have a look at GTK2's docs and see if I can find anything about drawline.

EDIT: Figures, "Drawing Area" is listed under "undocumented widgets"

EDIT EDIT: Found the docs for it, I think it's exactly what your trying to do?
http://www.gtkmm.org/docs/gtkmm-2.4/doc ... /ch15.html

[Sarevok]

So SDL does look like massive overkill. As does every other graphics library I've been able to find.

Software libraries are like that. They will draw a bitmap, fix your computer, buy you a house and get you a girl friend. But you will never figure out how to call that damn function that draws a bitmap on the screen.

Sarevok, those instructions look to be exactly what I would need, if I was working on a windows machine. I think I can see how to adapt them to Linux though.

I would recommend getting SDL installed and tested by compiling a sample app first. With that done the hard part is over.

Remember you would not need all these fancy bitmap and buffer flippers. So don't panic at the sight of all those tutorials with buzzwords. You only need to draw lines on screen it seems. SDL function putpixel is your friend here. Once SDL is installed just make a 50 line function of your own that draws a line between two points. And after that your done. You now have a brush and it is upto you what you want to draw with it.

[phongn]

Do you need to write it to the screen, or is writing it to a file good enough?

Rolling your own Windows .bmp file creator is trivial, and writing a little draw line function for it is similarly easy. Then you can open the bmp in almost any program to convert it into what you want or view it.

Even easier are the pixmap (PPM, etc.) formats that used to be common in the UNIX world.

EDIT: Oh cool, I already did write a lib like this for 24 bit bmps. It is in D, but I can quickly convert it to C. Will post shortly.

WTF? D? Why?!

[EnsGabe]

All done.

http://arsdnet.net/bmp.c

Not portable across platforms. Endianness will bite you if you try to use this anywhere that isn't little endian, which won't be problem 90% of the time

EDIT: And to be helpful, here's a macro to help you out:

Code: Select all

#define LITTLE_ENDIAN 1
#define BIG_ENDIAN 2

//Here be magic to set BYTE_ORDER to the proper endianness.
//<endian.h> works for unix platforms, but I don't know about Win32.

#if BYTE_ORDER == LITTLE_ENDIAN
#define TO_LITTLE_ENDIAN_INT(B) (B)
#define TO_LITTLE_ENDIAN_SHORT(B) (B)
#endif
#if BYTE_ORDER == BIG_ENDIAN
#define TO_LITTLE_ENDIAN_INT(B) (                                       \
                                 ((0xFF000000 & (B)) >> 8*3) +  \
                                 ((0x00FF0000 & (B)) >> 8) +    \
                                 ((0x0000FF00 & (B)) << 8) +    \
                                 ((0x000000FF & (B)) << 8*3)    \
                                                                        )
#define TO_LITTLE_ENDIAN_SHORT(B) (                                     \
                                   ( (0xFF00 & (B)) >> 8) +     \
                                   ( (0x00FF & (B)) << 8)       \
                                                                        )
#endif
#if ( BYTE_ORDER != BIG_ENDIAN ) && ( BYTE_ORDER != LITTLE_ENDIAN)
#error Endianness not defined
#endif

Finding out the endianness is something I haven't discovered a way to do portably yet.

EDIT2: And yes, I know you can do this with a function that checks at runtime, but it just seems silly to me to check something at runtime which was already decided at compile time and eat the cost every for something so trivial.