Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: graphics.h equivqlent under Linux

  1. #11
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,129
    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.

  2. #12
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    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.

  3. #13
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,129
    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.

  4. #14
    Member Regular Contributor
    Join Date
    Jun 2013
    Posts
    498
    Quote Originally Posted by RigidBody View Post
    in linux, there are loads of 2D graphics functions, check this page for details: http://tronche.com/gui/x/xlib/
    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.

  5. #15
    Newbie Newbie
    Join Date
    Jul 2013
    Posts
    2
    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!

  6. #16
    Newbie Newbie
    Join Date
    Jul 2013
    Posts
    2
    As I couldn't find the lib I was asking for, I created it: www.raylib.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •