I feel like I've gotten the hang of C, stdio.h, and stdlib.h; how do I go about programming 3d graphics?

[comradejonathan]

I feel I pretty much know how to use all the keywords and features in C as well as the functions provided by both the stdio.h and stdlib.h libraries. This includes dynamic variables, linked lists, and even qsort.

So, I decided to begin my quest figuring out how to program moving graphics. I decided to try using a for loop to store pixels obtained from a bit map in a multidimensional array... that didn't work out so I tried to use linked lists to change the scenery a little at a time. well, it didn't work go figure :P I just assumed since they used to write games using C and assembly even for consoles, I could just jump right in, but that's clearly not the case.

(by not work I mean it compiled and no run time errors, but the terminal was blank)

so I have a few questions:
-how did the first C programmer display graphics without a library made for graphics?
-is it really wrong to reinvent the wheel for learning purposes?

Note: I don't really know any object oriented programming, I'd prefer to just use C if possible.

[Disch]

-how did the first C programmer display graphics without a library made for graphics?

For your purposes, it doesn't matter. Computers are not the same as they were 30+ years ago, so however it was done then is not how it is done now. Just use a library.

Here's a good starting point for OpenGL:
http://www.arcsynthesis.org/gltut/


Though if you really want to know.... here is a very simplified explanation of why you don't do things like they used to be done (note I'm fudging a lot here to keep it simple.. this is not really a technical explanation):

I/O on computers back in the day was accomplished by accessing the hardware directly... typically by performing reads/writes to specific addresses which were mapped to hardware registers. This communication allowed programs to communicate to the hardware and tell it what they wanted it to do.

The problem with that is that each piece of hardware behaves differently. So a program written to use one kind of graphics card would not work on another because the registers would be mapped differently. A solution to this is the idea of "drivers", which provide an abstract interface. The driver communicates with the hardware-specific registers and provides a common interface for the program to use, so it does not need to care which hardware it is using.

The problem with that is that modern computers are multitasking, and giving one program exclusive access to hardware through the use of drivers would prevent other programs from accessing it. Furthermore.. giving one program exclusive access makes the machine more vulnerable. If the program with exclusive access crashes, the entire computer crashes... so no other program will be able to do anything.

So now... the OS is really the only running program that has (or at least should have) direct access to anything. And everything else goes through libraries which allow secondary access. This protects the OS by allowing it to share resources and hardware access as necessary, allowing the machine to be more stable and more multi-tasking friendly.

is it really wrong to reinvent the wheel for learning purposes?

No. But the question is... "what do you want to learn?"

If you want to learn how to program graphical applications... then yes... learning how to communicate directly with hardware is a complete waste of time.

But if you want to learn how to write drivers, then no... it wouldn't be.

[comradejonathan]

Hi Disch,

Thanks for the quick reply, I've been reading the online book concerning OpenGl and it is a very useful read. I haven't run into this issue yet, but I am hoping that there is a minimal amount of object oriented programming required, as I am not very familiar with it at this moment in time. I just recently finished a full length traditional course in C. Well I suppose we'll see when it gets to that point in my reading.

Thanks again for pointing me towards the recourse and for your explanation. I find this stuff on the topic fairly fascinating.