Trying to setup a graphics C/C++ invironment

Hi,

I have been using CodeBlocks IDE for some time to code in C++. Earlier I had programmed a 3D drawing program in Basic and now want to try in a faster language.

All I could find are old graphics libraries like graphics.h and similar.

I don't need more functionality that graphics.h can provide, but I struggle to find a solution.

Best wishes

Ivan
https://www.libsdl.org/
or
https://www.sfml-dev.org/

Even if you don't currently "needs" more than graphics.h, what you don't need is the obsolete mindset of ancient graphics.

Thanks.

Facinating, but way over my head - maybe later, when I master C++ better than I do now.

I'm using lot of my basic skills in C++ and enjoy the similarities and I can grasp.

For now I only need basic functionallity in graphics to start with.



I tried Borlands 5.5 and ran in it virtuel Windows 2000 just to see if it was possible - it was.

CodeBlocks had just released a new version. I tried the sfml guide in Codeblocks and had "millions" of errors even with the help of sfml guidelines.

I really like C++ and wish I was to use simple and no fancy 2D graphics library.




Borland 5.5 is an ancient, non-standard compiler. Get yourself a modern compiler. (If you are using C::B, then chances are you are close enough.)

There is indeed a lot to learn about using graphics. The old BGI library is very easy to use, but it was designed with business graphics in mind.

You really should give SDL a second look. Lazy Foo’s SDL2 tutorials are very easy to read and worth your time. https://lazyfoo.net/tutorials/SDL/index.php They will get you set up properly and take you through everything you need to know.

“A drawing program”, while ubiquitous, really is a fairly odd piece of software, requiring some additional care. For example, modern graphics libraries do not usually provide line-drawing primitives — you would have to do that yourself by modifying a bitmap/image/whatever your graphics library calls it.

Good luck!
I will take a second Lazy Foo’s SDL2 tutorials.

Actually I did a 3D-drawing program and can rotate, zoom, move and edit.

My goal is to learn math and english which I did not do in school.

It started with my robot lawn mover and thought it not be that difficult to calculate angles - I was wrong at least for me self.

After a while I stumbled over the unit circle and had to relate to sin and cos. It is facinating how degrees, radians, cos, sin and tan are related. It's a new world to me.

While doing lots of x,y drawing (I did not know about vectors) I saw z and tried to draw 3D vectors and had a hard time. But now I can change x, y and z in an existing drawing and can rotate my drawing.

Then I did a 3D-function x,y,z,colour,draw|move and I had never thought it was possible for me.

Sometimes the rotations could look strange until I realized it was the Gimbal lock I saw.

Now the bar har had raised to a new maybe not obtainable level and I'm challenging quarternions...

I find it very pedagogical using simple graphics while learning math and geometry.



Last edited on
I did install SDL 2 successfully via Yanson Tech: Install SDL With Code Blocks

https://www.youtube.com/watch?v=lJRgwbRVtP0

and I thought this was a one time setup session, but not for me.

For me Code Blocks is huge and sld.h is not known...

Do I need to setup a project for each ccp file i'm trying to compile ?

Then I tried to compile with MingW:

C:\MinGW\bin>c++ test.exe -o test.cpp
c++: error: 01.exe: No such file or directory
c++: fatal error: no input files
compilation terminated.

I can start c++ in any directory, so the path is ok, but I can't persude c++ to compile anything I try.







You have to tell C::B where the SDL headers and libraries are. You can modify either the global directories for the compiler, or you must add them for every project.

I am not a fan of YouTube tutorials. Lazy Foo’ is pretty pedantic about getting it right; hence my recommendation. It might still be worth a read through to see what you did differently.

(There is more than one path to consider. Your compiler’s executable path is just one. There are also all the paths for various includes, then paths for .lib/.a files, then paths for .dll/.so files. The compiler needs to know where these things are to work.)
On my Windows 10 computer is compiling from command line fine and on my Windows 7 computer I have to use Code Blocks. None can compile with SDL.

I was just trying to use graphics in c/c++ and I think it's way over my head. So for now I have spend enough time now on this and I will return to my geometry and math and spend enough time on these subjects.

I think I will wait and see if someone some day will make a library so I don't have to do all that digging in all kind of c++ stuff.

Lots of things had changes since I used Basic in the old days with inline 6502 assembler...

Thanks for your efforts.
Well, not to put too fine a point on it, but you didn’t follow my recommendations and are now bothered that things aren’t working correctly?

Using external libraries has always been a pain in C and C++, especially on Windows, but not that much of a pain — it is part of using the language.


Now that you have been more explicit about playing with geometric shapes and the like, you will find that modern graphics libraries are not too helpful either: neither SFML nor SDL2 provide a whole lot of line-drawing primitives.

My WinBGIm library upgrade is still one of the best versions out there (shockingly!), but it is designed to work with GCC only.

I originally posted it just because people were having trouble getting the older (broken) one to work with modern versions of GCC.


I have often thought to myself that it would be nice to have a simple library for drawing primitives in C++, and have considered writing one myself.

But the reality is that they do exist.


So at this point, I actually recommend you check out Tk, as in Tcl/Tk (https://www.tcl.tk/). You can use Tk with C++, IIRC, but it is simpler just to use the wish interpreter.

Here is an example program to draw a simple graph:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

proc graph {canvas coords n xtext ytext points} {

  lassign $coords lt tp rt bt 

  incr lt  20
  incr rt -$n
  incr tp  $n
  incr bt -20

  # Draw the labels
  $canvas create text [expr {$lt+(($rt-$lt)/2)}] [expr {$bt+10}] -text $xtext
  $canvas create text [expr {$lt-10}] [expr {$tp+(($bt-$tp)/2)}] -text [join [split $ytext {}] \n]

  # Draw the axes
  $canvas create line $lt $tp $lt $bt -arrow first
  $canvas create line $lt $bt $rt $bt -arrow last
  
  # transform the list of points to our canvas's coordinate system
  foreach point $points {
    lassign $point x y
    lappend points2 [expr {$lt + (($rt - $lt) * $x)}]
    lappend points2 [expr {$bt - (($bt - $tp) * $y)}]
  }
  
  # draw the lines of the graph between points
  $canvas create line {*}$points2 -fill red
  
  # draw a dot at each point
  foreach {x y} $points2 {
    $canvas create oval [expr {$x-$n}] [expr {$y-$n}] [expr {$x+$n}] [expr {$y+$n}] -fill red -outline red
  }
  
}

canvas .c -width 420 -height 300
pack .c
graph .c {0 0 420 300} 3 Time Productivity {
  {0.0  0.00} 
  {0.1  0.20} 
  {0.2  0.07} 
  {0.3  0.50}
  {0.4  0.50}
  {0.5  0.69}
  {0.6  0.71}
  {0.7  1.00}
  {0.8  0.33}
  {0.9  0.46}
  {1.0  0.67}
}

Good luck!
On Windows, even Win 7 or 10, you can still use the "antiquated" GDI system.

A book that teaches how to create a 2D game engine using the Win32 GDI and multimedia libraries, about as bare-bones as it comes. All the functionality is built-in the OS, no need for additional 3rd party libraries:
https://www.amazon.com/gp/product/0672326590/

With Windows there is also DirectX. Another "part of the OS" multimedia technology.

Of course this is creating a Windows specific app, with WinMain, etc instead of C/C++ main as the execution entry point.

There are a few minor changes you will need to make if you get the book, changing a few Windows specific data types. LPSTR to PSTR for example. LPSTR is a long pointer to a C string, an artifact of 16-bit Windows. You should be able to decipher what a PSTR is.

Fair Warning, programming a Windows GUI/Game app is different than a C/C++ console app. Creating a 64-bit app with C/C++ doesn't change the source, it can for a Windows GUI app.

Windows Data Types
https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types

New Data Types for 64-bit Windows
https://docs.microsoft.com/en-us/windows/win32/winprog64/the-new-data-types

64-bit programming for game developers
https://docs.microsoft.com/en-us/windows/win32/dxtecharts/sixty-four-bit-programming-for-game-developers

Using a 3rd party multi-media library has one advantage. They are ported to operating systems other than just Windows.

Here's an old, outdated Win32 API tutorial you might want to look at for creating simple GUI apps.
http://www.winprog.org/tutorial/

It has some very basic graphics lessons. Using Windows 7/10 you will still need to make changes to adapt to the 32-bit programming model.
I would totally steer away from Win32 programming, though. Screwing around with the GDI is more pain than it is worth just to draw some lines and circles — get a library specifically for that and use it instead.
Registered users can post here. Sign in or register to post.