4

Okay, this is a really strange question and I'm not sure how to phrase but, but I can't seem to find anything on it anywhere, most likely because I'm not using the correct terminology. Also, this may be operating system specific, if it is, I'm using Debian.

Basically, when you boot an older computer or a modern server computer, or stuff along those lines, they boot to a terminal screen. Where all you do is type stuff. And if you want to do anything graphically, you usually download a desktop environment.

But I'm wondering, how could I go about drawing graphics without a desktop environment?

I remember back on MS-DOS you could use QBASIC to change the screen mode and you could then draw colored lines onto the screen like that. It's probably much more complicated in C++, but I'd still like to be pointed in the right direction.

Sorry if this question is a bit unspecific, but I'd really like to be pointed in the right direction.

McFatty Joepants
  • 59
  • 5
  • You can use, for example, allegro library (http://alleg.sf.net), which works quite independently on graphical environment, and it allows you to use framebuffer, as mentioned in answers. – nothrow Nov 12 '12 at 00:36

5 Answers5

6

This is done by using a framebuffer console. Then you use a framework/library that can draw on that. For example DirectFB. There's also some small libraries floating around, like libFB. I think SDL can also use the framebuffer. Never tried it myself though.

Then there's framebuffer versions of GUI toolkits like Gtk+ and Qt, if GUI widgets is that you want.

There's also SVGAlib, which talks to graphics cards directly, but it's outdated by now. Not recommended. In general, you're looking for "Linux framebuffer graphics". That should get you a few starting points.

To get a framebuffer console, you need to configure your kernel accordingly. Usually you enable a KMS driver for you graphics card, and also enable the KMS framebuffer. If there isn't a KMS driver for your card, you can use a generic VESA framebuffer console that works on most hardware (although, it being just generic VESA, is slow and non-accelerated.)

Nikos C.
  • 50,738
  • 9
  • 71
  • 96
  • [Paint Pixels to Screen via Linux FrameBuffer](https://stackoverflow.com/q/4996777/995714), [Programming the Linux Framebuffer](https://cmcenroe.me/2018/01/30/fbclock.html), [Low-level (Linux framebuffer) graphics programming tutorial](https://www.raspberrypi.org/forums/viewtopic.php?t=30720#p267107) – phuclv May 01 '19 at 01:01
0

Commonly, a "desktop environment" (on Linux) is made of two parts: XWindow-like graphics "library" plus a "window management" (Gnome, KDE, Xcfe,..). So, if I understand your question, you only have to setup a XWindow system without a window manager.

Paco Barter
  • 182
  • 1
  • 3
0

On MS-DOS, you could write software which wrote to the screen, either by writing into a range of RAM which was shared by the video controller, or calling a BIOS API.

A newer O/S (i.e. Windows) will prevent you from doing either of those: instead you call an O/S API, which calls to an O/S-specific video device driver, which outputs to the hardware.

ChrisW
  • 54,973
  • 13
  • 116
  • 224
  • Actually the Linux framebuffer can pretty much be used like in the DOS days. It's mapped into memory and you just write to it like in VGA mode 13h. – Nikos C. Nov 12 '12 at 00:28
  • Btw, IIRC it was ported from the Amiga version of Linux. The Amiga didn't have a text mode, so it needed a framebuffer. That was then ported to x86 and other architectures as well since it turned out to be a good idea. – Nikos C. Nov 12 '12 at 00:31
  • @NikosC. I've tried writing to INT 14h on Windows NT, and found that the O/S traps and translates those into calls to the serial port driver (e.g. serial.sys or whatever NT driver is installed for that port). Perhaps the Linux framebuffer works like that? As far as I know, modern video hardware doesn't necessarily read from CPU-accessible RAM? – ChrisW Nov 12 '12 at 00:42
  • 1
    The framebuffer is presented as a /dev device file. When you map it into memory and write to it, the kernel driver translates it of course. This how /dev files work in general on Unix; you treat everything as a normal file and do I/O on them. You can write images to /dev/fb0 and they show up on screen. Or you write WAV files to /dev/dsp and they play on the sound card. It's a Unix thing that's been there for ages now. – Nikos C. Nov 12 '12 at 00:52
0

As I read it you're asking how to deal directly with the graphics hardware.

That depends on the hardware.

If you have an old PC at hand and want to experiment with it, then you need correspondingly old development software that can run on that hardware under the particular OS, i.e. some C compiler from those days running in MS-DOS. You may be able to do this is in a "DOS-box" in Windows (not a console window but an emulation of the old PC). 64-bit Windows 7 does not support DOS boxes, but there is a free alternative called DOSbox.

Then, if you go that route, you can search for "graphics adapter" graphics modes etc. on the net.

Basically, with the old PC architecture and a program running under DOS, you used a DOS service to switch the graphics mode, and then you accessed the graphics memory at a known memory address for the mode.

Cheers and hth. - Alf
  • 142,714
  • 15
  • 209
  • 331
-1

The curses (or ncurses) library is the old way of doing it in Unix flavours, although these days there is probably something better...

John3136
  • 28,809
  • 4
  • 51
  • 69
  • No, (n)curses is a terminal library. – Tamás Szelei Nov 12 '12 at 00:18
  • Agree it is not a fully functional graphical lib, but even the ncurses wikipedia page says `It is a toolkit for developing "GUI-like" application software that runs under a terminal emulator`. Without knowing exactly what the OP wants, I still think curses is still a reasonable (but probably not the best) answer to the question. – John3136 Nov 12 '12 at 00:31
  • OP never said anything about GUI, he only said he wants graphics. Sorry, but I still think this is not a good answer in its current state. – Tamás Szelei Nov 12 '12 at 01:02