C want to compile simple C graphics code.

Hi ,

i want to compile this.
C:
#include<graphics.h> /* header file */
#include<conio.h>

main()
{
/* the following two lines are the syntax for writing a particular
program in graphics. It's explanation is given after the program.*/

   int gd = DETECT, gm;
   initgraph(&gd, &gm, "C:\\TC\\BGI");

 
   setbkcolor (GREEN);

   getch();
   closegraph();
   return 0;
}
error message is that graphics.h is not found. fatal error

how to tell clang compiler where it is ?

the result of this code is a simple green rectangle.
graphics-1-output-1.jpg
 
I guess you will need some kind of DOS compiler to do this. As far as i know conio.h/graphics.h is pretty ancient (and non standard) stuff you won't find in modern compiler distributions.
 
  • Like
Reactions: a6h
Yes that graphics.h gives me fond memories of my hacking around in Borland's Turbo C++ :)
You could relive that with DOSBox and a copy of Borland from Winworld. You could even get a bit more modern and use OpenWatcom's recent DOS compiler instead.

Or if you want a native FreeBSD program, you might want to consider SDL or SDL2. Check out the following tutorials.

http://lazyfoo.net/SDL_tutorials/

Edit: Ah I knew something like this would exist. BGI was a cult classic after all!

http://libxbgi.sourceforge.net/

Basically it maps the graphics.h API stuff on top of SDL2 for non-DOS platforms.
 
yeah , the question is "what is the standard graphics library for very simple graphics nowadays in unix os" ?
extreme simple ones that are ready in minutes.
 
yeah , the question is "what is the standard graphics library for very simple graphics nowadays in unix os" ?

Probably libX11 (or the mentioned SDL if you want cross platform).

FreeBSD used to have vgl https://www.freebsd.org/cgi/man.cgi?vgl which was drawing directly to the framebuffer (most similar to graphics.h) but it was removed as we updated our VT.

Linux allows you to mmap the /dev/fb0 and literally draw pixels in that mapped memory. Works well actually. I don't think FreeBSD has similar.

As for OpenBSD and Solaris, I don't believe they have ever allowed direct frame buffer drawing.

I did see this FOSDEM talk / project about maintaining frame buffer backends: https://archive.fosdem.org/2020/schedule/speaker/nicolas_caramelli/
but it seems that the project itself hasn't made much progress.
 
hello ,
i understand. Not VGL but X11 Graphics.
The simplest one is SDL library.
Then SDL is the extreme simplest one to use. Far simpler to use as "open GL"

Thank you
 
how about to install the original libvgl ?
pkg install libvgl

If you do not have the vgl.h then you probably need to install an old version of FreeBSD.

if you do have it, then you probably need to disable newcons and re-enable the older syscons for it to work correctly.

As you can see from the manpage, it is a fairly tiny API. <25 functions. If you really like the API, perhaps instead just create a wrapper around SDL that looks like vgl.

If you would like a simple template project to start off with, this is a tiny SDL project I use during University open-days: https://github.com/osen/openday/blob/master/src/main.cpp

I am sure you can find many SDL examples to get you started however.
 
If you do not have the vgl.h then you probably need to install an old version of FreeBSD.

if you do have it, then you probably need to disable newcons and re-enable the older syscons for it to work correctly.

As you can see from the manpage, it is a fairly tiny API. <25 functions. If you really like the API, perhaps instead just create a wrapper around SDL that looks like vgl.

I couldn't really get a clear picture if this still exists or not but it's certainly really, really old and semi abandoned. There seems to have been kind of a poll on the usage in 2016 which had only a single person express interest. Besides the man page states it only works with syscons. So basically it's a crusty API (if it's actually still functional that is) with practically zero users that isn't portable and even where it's supported it only runs with legacy settings... I rest my case. I can nothing but agree. From my perspective there is little point in using this unless one has a VERY good reason. Learning SDL seems like a way better option (lots of resources, tutorials, uses cases, ...) and creating a wrapper might even be a nice exercise. To bad there seems to be more or less nothing that uses this API so the wrapper wouldn't serve much of a purpose.
 
I couldn't really get a clear picture if this still exists or not but it's certainly really, really old and semi abandoned.

Yeah. I only really know a little bit about vgl because for a bit of fun I wanted to port my 3D software rasteriser to run in a framebuffer rather than SDL. It turns out I missed this poll of "who uses VGL" by about a week! Not that my use-case was really a very good reason to keep VGL in all fairness ;)

To bad there seems to be more or less nothing that uses this API so the wrapper wouldn't serve much purpose.

Very true. In some ways, I do feel it would be useful to be able to draw to the frame buffer rather than require Xorg but at the same time I don't know why I feel this... Obviously there isn't much of a requirement for it haha.
 
hi, thank you all again. i changed my direction again.
back to the roots...
i do Xlib graphics lo level.
book

Xlib can be OK if you simply draw to an array of pixels and then map that data to an Ximage, ignoring all the other fairly horrible Xlib related stuff. You can see an example of this here:
https://github.com/osen/software-3d-renderer/blob/master/src/x11_platform/main.cpp

And for completion, the SDL and SDL2 equivalents ;)

https://github.com/osen/software-3d-renderer/blob/master/src/sdl_platform/main.cpp
https://github.com/osen/software-3d-renderer/blob/master/src/sdl2_platform/main.cpp

For what you seem to want, I would recommend either SDL1 or Xlib. The fact that SDL2 is more focusing on GPU accelerated drawing involving a SDL_Renderer is a little overkill IMO. When drawing pixel by pixel, SDL2 is also the slowest of the 3 because of this additional overhead. Obviously if you get onto rotating images, SDL2 ends up much faster.
 
Yeah. I only really know a little bit about vgl because for a bit of fun I wanted to port my 3D software rasteriser to run in a framebuffer rather than SDL. It turns out I missed this poll of "who uses VGL" by about a week! Not that my use-case was really a very good reason to keep VGL in all fairness ;)

Neat!

Very true. In some ways, I do feel it would be useful to be able to draw to the frame buffer rather than require Xorg but at the same time I don't know why I feel this... Obviously there isn't much of a requirement for it haha.

It would make sense in an installer as a backend for one of those stateless UI libraries or if one needed a simple graphical output in a very resource constraint environment i guess and there is likely other use cases too. I certainly wouldn't call it pointless. Just a bit archaic and pretty specific.

And for completion, the SDL and SDL2 equivalents ;)

Very well meaning but i doubt you will be heard. Let him cut his horns on Xorg if he wants to ;)
 
Thinking about this: Why not hack up Mesa to use VGL as backend for EGL and then port Androwish's renderer to it. Voila a nice little GUI. If one likes TCL/TK that is at least. If not the next step would be to port the renderer into Little (https://little-lang.org). Seems like a great plan. Just that i am probably not going to do it ;)

Edit: Seems Androwish's (or probably rather Undrowish's) "renderer" is really just SDL so writing an SDL backend for VGL would likely be a bit saner. It doesn't have as much mad scientist flavor though so my vote is still on Little -> Androwish -> SDL -> EGL -> hacked up Mesa -> VGL ;)
 
that makes sense.
i want to program for unix only. no cross compile.
so i take that that is on board.
 
If you are referring to my last post please don't take that serious. I was basically joking around with kpedersen. There would be no cross compilation involved though. It's just a lot of C code stacked up in a rather bizarre manner.
 
thank you.
yes , what i want to do is assemble little tools for unix only.
for example a simple "status bar" for an application that has gui already.
my intention is not to draw games or high definition paints.

ps.
if i see a cross platform guy who says "everything works on any platform"
i don't care , only a small grin comes over my face.
 
The topic title suggests C/C++ so I don't think the OP is against it.

Whilst there are some benefits to sticking to C I think the real reason is that C++ doesn't provide anything especially important when it comes to low level drawing APIs. Many C++ developers just use a C API for this.

That book uses FLTK GUI library which (although quite minimal vs Gtk/Qt) seems to be a bit overkill for simple drawing.

That said... I would generally consider it for most projects, rather than using Xlib directly ;)
 
If you wish to do X programming, don't use Xlib. The API is synchronous despite an asynchronous client / server protocol under the hood. This makes animation loops hard to do or at least not perform well.
For low level X, use XCB. For a higher level API use something like Imgui.

These APIs are quite complex but you need only learn a small subset to be useful.
 
Since kpedersen mentioned framebuffers, in XCB you can create a pixmap as a shared memory object. The X server and the client process both see the shared memory without having to copy pixels back and forth. Since a pixmap is also a 'drawable', XCB primitive draw operations are supported. The shared memory pixmap becomes an effective frame buffer.
 
Back
Top