1

Straight to the point: in C there are structures that allow to work with multiple variables "at the same time". Now suppose to have:

struct point{
    double x,y;
}

this will represent a point in a not-yet-defined space. Building from that we could create a segment:

struct segment{
    struct point a;
    struct point b;
};

And spanning this segment over the observable space we could create a line (with that then an actual 2d plan with finite point in it).

Knowing that now, I ask you, is there any way to show on screen (create graphics) of this geometrical entities (and even 2d gemological figure (rect, circle and so on...) and furthermore more complex one, like 3d objects) only using C from scratch? From scratch I mean without using any lib or in case write that on my own. I would like to emphasize that this is a learning process, hence respectful and pertinent answer will be really appreciate. Thanks.

KmerPadreDiPdor
  • 35
  • 5
  • Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. – Community Sep 02 '22 at 18:33
  • 1
    Yes, you can represent graphical elements in memory using 100% portable C, as you've just shown. But displaying points, lines, etc. on the screen, for your eyeballs to see, is unfortunately going to require some (actually quite a lot of) system-dependent coding. Of course there are libraries available to make it easier, and some of them claim to be cross-platform, but none of those libraries are part of Standard C. – Steve Summit Sep 02 '22 at 18:40
  • I do this in pure C by creating an image file, which is loaded and active in an image viewer. Whenever I change the image, the viewer is informed by the OS and it updates the display to the new version. My library has the usual `line` `rectangle` and `floodfill` etc functions, written in C, to an RGB image array. – Weather Vane Sep 02 '22 at 18:42
  • This [code](https://stackoverflow.com/questions/61648601/obfuscated-code-in-c-and-what-does-this-program-code) produces raytraced detailed graphics, directly from C, with no libraries. The output is an image in `.PPM` file-format. – abelenky Sep 02 '22 at 18:53
  • Warning: the executable generated from the code linked by @abelenky was flagged and deleted by my AV as containing a **trojan virus**. – Weather Vane Sep 02 '22 at 19:16
  • The original source of the code can be found at: https://www.ioccc.org/, and does not do anything malicious. As obfuscated code, it might be doing "sketchy" things that trigger a virus scanner, but I'm quite confident its a false-alarm. – abelenky Sep 02 '22 at 19:20
  • @abelenky I was curious to see what it does, but I'll have to wait until just before I do a 'restore' operation to turn off the AV. – Weather Vane Sep 02 '22 at 19:21

3 Answers3

1

Yes you can do your own rendering engine (just google rasterization) in C alone without any libs however to output gfx to screen (or any other device) You have to interface with device and here OS/platform stuff goes in. I assume PC (x86)...

For example in old MS-DOS you could use BIOS (with few lines of inline assembly) and or use direct in,out functions (yes there where time that in,out was in C) however in nowadays C/C++ languages there is no in,out so you have to use assembly again. With such you could set up desired video or text mode and from there just use direct access to framebuffer on VGA (as simple as writing to array + some page flipping for bigger resolutions)

On modern OS is this no longer possible as all HW and Memory access must comply priviledges ... So in order to access gfx card you have to connect to gfx driver or write its own however that requires ring0 priviledges so you either need to create and install device driver (not easy and from win10 also not cheap and you need Driver SDK for that which is also sort of lib) or use universal driver like JUNGO or use OS and gfx vendor provided gfx api like OpenGL,DirectX,GDI however all of these are considered lib,api ...

The only workaround is use what you have at disposal which is text console output (text mode window or console) along with ASCII art.

see Display an array of color in C

If you are on MCU or whatever platform where you have unrestricted access then writing own driver is OK for example see:

However writing driver for gfx on PC is not good idea as you would need to support all the gfx cards used and that is too much work (and you would have hard time to obtain relevant info needed to do it anyway) so in reality using existing gfx api along with existing drivers is the only way which means you HAVE to use libs/apis if you want "real" graphic...

Spektre
  • 49,595
  • 11
  • 110
  • 380
0

I dont know about writing them without any libraries, because you will ultimately have to use some library to interface with the GPU for graphics. The most common graphics APIs for C and C++ are OpenGL and Vulkan, both being great hardware accelerated APIs developed by Khronos, with the latter being lower level than the former. There's also SDL which isn't hardware accelerated, but it is easier to use.

Edis Hasaj
  • 11
  • 1
0

ISO C does not have a notion of computer graphics. It only has a notion of a stream, which may be connected to computer screen. How the data sent through this stream is interpreted (i.e. whether it is interpreted as ASCII codes for text or as coordinates for lines to be drawn) is out of the scope of the ISO C standard.

On most platforms, you require some kind of API provided by the operating system to draw graphics to the screen. For example, on Microsoft Windows, you can use Direct2D or Direct3D, and on Linux, you can use OpenGL.

You can also use a cross-platform library such as SDL, so that the code you write will run on different platforms. This library will then call the respective native API functions for you, so that you don't have to deal with the individual native APIs yourself.

Andreas Wenzel
  • 22,760
  • 4
  • 24
  • 39
  • 1
    Re “ISO C does not have a notion of computer graphics. It only as a notion of a stream” is not entirely true. C 2018 5.2.2 specifies character display semantics, which includes notions of positions on a display device, including movement toward earlier or later positions on a line and advancing to the next line or page. This is generally of little use for graphics, but it is not nothing. – Eric Postpischil Sep 02 '22 at 19:01