Graphics.h equivqlent under Linux

I’am checking the feasibility of introducing gcc compiler for sophomores in undergraduate course instead of TurboC compiler.Kindly advice me if OpenGL can serve as replacement for graphics.h header file in TurboC?

I haven’t used Borland Turbo Pascal/C for decades, but scanning the graphics.h functions, it looks like basically yes. Drawing points, lines, polygons, etc. The graphics.h functions are more pixel centric though (flood fill ops, fill style, etc.) whereas in OpenGL you’d define the region you want to fill and draw triangles/polygons on it. The one thing that you would have to pull in another library for is text rendering as that’s not part of core OpenGL, and there are a number of choices there (such as those built on freetype).

What are your specific needs here? What type of applications have you got in mind?

And please be aware: The stuff Dark Photon is referring to is all legacy OpenGL functions.

Nah, not all. Drawing triangles is meat and potatoes stuff, whether compatibility profile (“legacy”) or core profile. Polygons is relegated to the compatibility profile though. For core, you need to tessellate them yourself.

There’s more helper tools in the compatibility profile (the default), which you can use when getting your graphics legs. Think of them as training wheels, which you can jettison when you know what’s going on (and know why there’s a benefit to doing so). Or you can be a purest and build all your own furniture from scratch from the get go.

Like thokra says though, what you want depends on your needs. What are you trying to train your students to do, and what kind of students are they (e.g. CS majors learning GPU rendering, or some other major/specialization aiming toward a different goal)?

Nah, not all. Drawing triangles is meat and potatoes stuff, whether compatibility profile (“legacy”) or core profile

Just to be clear, I wasn’t arguing that there isn’t a triangle or a line primitive type in core OpenGL - of course there is and of course there are ways to render such primitives. I overreached a little and I think it’s because I was thinking of Qt and the rendering functions QPainter offers when writing my comment. I should sleep more. :smiley:

But yeah, there’s nothing like a drawLine() or fillQuad() OpenGL function which handles everything for you, like many software graphics APIs offer(ed) - including the ancient TurboC stuff layered on top of Xlib if I got it right.

tbh, i don’t know turboc at all, but i suppose the graphics.h you mentioned serves for 2D graphics.

in linux, there are loads of 2D graphics functions, check this page for details: http://tronche.com/gui/x/xlib/
those functions do not use OpenGL.

and of course, you can use OpenGL for 2D graphics too.

so, it’s up to you to choose what would be better.

in Xlib, you would draw line with
XDrawLine(display, d, gc, x1, y1, x2, y2)

in OpenGL, it looks like
glBegin(GL_LINES);

glVertex2i(x1, y1);
glVertex2i(x2, y2);
glEnd()

in my opinion, the xlib version might be more comprehensive for a beginner.
and, if you use xlib, you learn more about the linux system than when you use OpenGL.

but OpenGL is, in my opinion, the better choice. it can be used in linux, unix, windows, and on mobile phones.
it is usually hardware-accelerated. and while xlib is limited to 2D graphics, you can do 3D stuff with OpenGL using
exactly the same commands a line in 3D would be

glBegin(GL_LINES);

glVertex3f(x1, y1, z1);
glVertex3f(x2, y2, z2);
glEnd()and, in OpenGL you have full access to all the cool stuff (shaders etc)

It depends. OpenGL is a better choice if you opt for high performance applications that need a lot of computational power. If you’re fine with drawing some primitives (and honestly, the TurboC stuff isnÄt good for anything else), something like Qt is much more suitable. You get cross-platform, convenience window system abstraction which is reasonably fast in a lot of cases on the desktop and mobile platforms.

qt is basically a widget library which requires good understanding of c++, including inheritance, virtual functions and all that stuff.
i would not recommend making students learn how to use it if you just want to make them draw something.

qt is a great lib which makes programming GUIs pretty easy (if you know how it works), but i wouldn’t use
it for an application that does not have a GUI with at least one button.

Looks like OpenGL and Xlib are good alternatives for graphics.h!!!

have you tried the example from the wiki?
http://www.opengl.org/wiki/Programming_OpenGL_in_Linux:_GLX_and_Xlib

qt is basically a widget library which requires good understanding of c++

So … Xlib just comes naturally? If I had to choose between Xlib and a higher-level API which also has the benefit of being portable and being much better documented and which is not prone to possible succession by a new window system in the foreseeable future (namely Mir and Wayland), I’d choose the higher-level API.

including inheritance, virtual functions and all that stuff.

You don’t need to be a rocket scientist to understand how to use a to draw on a QPaintDevice. It’s fairly straightforward and the documentation is awesome.

i would not recommend making students learn how to use it if you just want to make them draw something

If they are being taught C, why would you not go to basic C++? And if they’re going to use Xlib they’re going to do it in C. An introductory course in C++ is definitely enough to do simple Qt stuff.

i wouldn’t use it for an application that does not have a GUI with at least one button.

So, QGLWidget, which is even more convenient than FreeGLUT, shouldn’t be used just because you don’t use the majority of the lib? What about all the stuff Qt offers that has nothing to do with GUIs, like XML parsing or filesystem access, or networking, or more basically QString? That argument doesn’t hold - at all.

If they are being taught C, why would you not go to basic C++?

Because C and C++ aren’t the same. They use different idioms to achieve various effects, and idiomatic C will not look like idiomatic C++.

Granted, that’s not a reason to avoid Qt. But if you’re teaching OpenGL, you shouldn’t be forcing students to learn whatever toolkit they use to stick a window on the screen.

Because C and C++ aren’t the same. They use different idioms to achieve various effects, and idiomatic C will not look like idiomatic C++.

True, but idioms aren’t a concern anyway if you’re just starting to learn the basics of a programming language. My point is, with a little C background, you at least should be able to deal with the C portion of C++ on a functional level. You can more easily explain what “new” does (even without explaining that it is actually an operator and all) if you know what a pointer is and how it works.

Incidentally, is pure C actually taught nowadays? I mean, taught in depth?

But if you’re teaching OpenGL

But the initial question was if OpenGL could be a viable alternative to the graphics.h stuff - and sure it can be. I’m just pointing out that if the goal is to get some very simple primitives on the screen, and the stuff in graphics.h isn’t capable of much more, than a software renderer as provided by Qt maybe a better and easier learning experience. At least as a start.

The OP has yet to state what their actual goal is. Changing the compiler and looking for a replacement for graphics.h doesn’t say much about the lecture.

I wouldn’t recommend teaching the Xlib API. More generally, I wouldn’t recommend any API which uses integer pixel coordinates. The trend is toward using floating-point coordinates with a user-defined transformation matrix (e.g. OpenGL, Cairo, PostScript, SVG), essentially treating the canvas as a rectangular region of the Euclidean plane, with pixels being treated as an implementation detail.

The main problem with using OpenGL (compared to e.g. Borland’s graphics) is complexity. If you’re only dealing with 2D, OpenGL has a lot of features which you don’t need but which may get in the way.

Whichever option is chosen, you have to deal with the fact that windowing systems add some complexity (i.e. you can’t use the DOS approach of just drawing stuff on the screen then forgetting about it, you need some form of event-based framework). In that regard, GLUT is about as simple as you can get.

Hi, I’m also looking for a graphics.h replacement based in OpenGL!

I work as a Videogames Programming teacher in a private institution and last years I used graphics.h lib (actually WinBGIm) to teach videogames development. My students were around 20 years old and most of them had never programmed a single line of code. I decided to start with something easy, C language. My tools: MinGW and Notepad++. The course was really focused on games programming; I started with the basics (calculator, text-game, files io) and then I decided to try with some graphics… I found graphics.h lib (never used it before) and it was great for teaching, very easy, clear, compact, understandable for students… In just one month every student got his own Pong programmed in C. I was really impressed…

Despite graphics.h worked really good for teaching, I would like to change it for some hardware accelerated lib, based in OpenGL. Anybody knows some OpenGL very basic lib for 2D, similar to graphics.h? I mean, a lib that just consist of an .h and .a/.lib files with basic 2D drawing functions, graphics device initialization/closing and some keyboard/mouse functionality.

Thanks for your reply!

As I couldn’t find the lib I was asking for, I created it: www.raylib.com

1 Like

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.