computer programming
October 15, 2007 9:24 PM Subscribe
How do you program computer graphics?
I know most operating systems are written in c or c++, but how do the graphics fit in? Do you somehow program them into c or what? And how does any program create an interface?
I know most operating systems are written in c or c++, but how do the graphics fit in? Do you somehow program them into c or what? And how does any program create an interface?
There's graphics libraries that draw things on to the screen by talking to the display hardware, typically a graphics card.. Most interfaces these days are heavily abstracted using object-oriented techniques.
The graphics libraries are also written in C++ or C, and you access them by including them in your binary and then calling various functions to print to the screen.
Graphics are a really advanced subject and require a pretty in-depth knowledge of computer science, logic, and math. I've been working in various branches of IT for a few years, and it's beyond my ken and not in my skillset.
posted by SpecialK at 9:29 PM on October 15, 2007
The graphics libraries are also written in C++ or C, and you access them by including them in your binary and then calling various functions to print to the screen.
Graphics are a really advanced subject and require a pretty in-depth knowledge of computer science, logic, and math. I've been working in various branches of IT for a few years, and it's beyond my ken and not in my skillset.
posted by SpecialK at 9:29 PM on October 15, 2007
You make use of pre-written "APIs", which are chunks of code ("frameworks") that someone else wrote, which simplify drawing a picture somewhere on the screen.
In the case of application development, you might have a chunk of code that says: draw the graphics for the main application window with so-and-so dimensions at such-and-such position on the screen. Add together a bunch of code that draws elements like buttons and text, and you get yourself a complete interface.
In Mac OS X, this framework is called "Cocoa". In Windows, it can be called Microsoft Foundation Classes ("MFC"). In Java, you can use AWT, Swing or SWT. There are many other frameworks which can work on one or multiple operating systems.
If you're doing game programming, you use other frameworks which are built atop OpenGL or DirectX, which are themselves frameworks.
posted by Blazecock Pileon at 9:32 PM on October 15, 2007
In the case of application development, you might have a chunk of code that says: draw the graphics for the main application window with so-and-so dimensions at such-and-such position on the screen. Add together a bunch of code that draws elements like buttons and text, and you get yourself a complete interface.
In Mac OS X, this framework is called "Cocoa". In Windows, it can be called Microsoft Foundation Classes ("MFC"). In Java, you can use AWT, Swing or SWT. There are many other frameworks which can work on one or multiple operating systems.
If you're doing game programming, you use other frameworks which are built atop OpenGL or DirectX, which are themselves frameworks.
posted by Blazecock Pileon at 9:32 PM on October 15, 2007
Serious 3d graphics (like for video games) are done with special purpose libraries like OpenGL or DirectX.
2D graphics are typically handled by OS specific libraries, hence the general lack of portability of applications from Windows to Mac to Linux. Well, Linux to Mac is pretty easy 'cause Mac can run KDE.
There are quite a few tutorials on OpenGL, and it exists on all platforms so it's a good one to learn if you're interested in moving beyond the idle curiosity stage.
OpenGL also interfaces with non-C-like languages such as Python, in case the combination of 3d math and compiled languages all at once is overwhelming.
posted by TeatimeGrommit at 9:36 PM on October 15, 2007
2D graphics are typically handled by OS specific libraries, hence the general lack of portability of applications from Windows to Mac to Linux. Well, Linux to Mac is pretty easy 'cause Mac can run KDE.
There are quite a few tutorials on OpenGL, and it exists on all platforms so it's a good one to learn if you're interested in moving beyond the idle curiosity stage.
OpenGL also interfaces with non-C-like languages such as Python, in case the combination of 3d math and compiled languages all at once is overwhelming.
posted by TeatimeGrommit at 9:36 PM on October 15, 2007
What, LORES or HIRES?
posted by fleacircus at 9:54 PM on October 15, 2007 [1 favorite]
posted by fleacircus at 9:54 PM on October 15, 2007 [1 favorite]
If you want to program graphics into a computer game, I've found the cross-platform Allegro library to be very helpful and easy to use.
posted by pravit at 10:21 PM on October 15, 2007
posted by pravit at 10:21 PM on October 15, 2007
From your last question, I'll assume you are a relative beginner using C/C++ on a Linux environment. It would really help to know what sort of program you're trying to create.
If you're trying to add an interface to a desktop application, then what you want is some sort of GUI toolkit. Examples would be Qt, Tk or wxWidgets. I don't know enough about these to make a recommendation, but they should all come with interfaces for C/C++.
Those toolkits might also be a good start if you wanted to make a 2D game for the desktop. Since you're on Linux where most stuff is Open Source, you could find simple applications like the one you want to develop and see what they use.
If you're making 3D games (or complicated 2D games), then you're probably better of looking around gamedev.net or a similar site. They recommend using the SDL Library in their Linux Programming article.
I'll second the Allegro Library, as well. I haven't used it in years but have very fond memories of it. It wasn't the fastest around but it was quite intuitive and focused on letting you draw cool stuff on screen instead of worrying about buffer alignment and vram allocations.
posted by Gary at 11:32 PM on October 15, 2007
If you're trying to add an interface to a desktop application, then what you want is some sort of GUI toolkit. Examples would be Qt, Tk or wxWidgets. I don't know enough about these to make a recommendation, but they should all come with interfaces for C/C++.
Those toolkits might also be a good start if you wanted to make a 2D game for the desktop. Since you're on Linux where most stuff is Open Source, you could find simple applications like the one you want to develop and see what they use.
If you're making 3D games (or complicated 2D games), then you're probably better of looking around gamedev.net or a similar site. They recommend using the SDL Library in their Linux Programming article.
I'll second the Allegro Library, as well. I haven't used it in years but have very fond memories of it. It wasn't the fastest around but it was quite intuitive and focused on letting you draw cool stuff on screen instead of worrying about buffer alignment and vram allocations.
posted by Gary at 11:32 PM on October 15, 2007
Graphics are a really advanced subject and require a pretty in-depth knowledge of computer science, logic, and math. I've been working in various branches of IT for a few years, and it's beyond my ken and not in my skillset.
What? Almost all 2d graphics tasks can be done with API calls, at least in Java. And you don't need to know much to make those calls. I've been doing "graphical" programming since high school. Within one year of owning my first computer, I was doing graphical programming in windows 3.1 (using C++) and DOS (using x86 assembler). And things are far easier today. Using Flash or Possessing you're going to basically start with graphics programming, and I know in flash it's more work to use text then it is graphics!
Today I have pretty in-depth knowledge of computer science, logic, and math, and I don't really need to use much of it to draw things on the screen.
(Stay away from action script, though).
The basic algorithms to draw circles, squares, and lines are not that hard. You need to have a facility for mathematics, but it's all just basic arithmetic.
Graphics programming isn't some mystery. It's not any more complex then textual programming, really. More introductory programming courses should teach it, IMO, because I think too many people believe it.
posted by delmoi at 11:41 PM on October 15, 2007
What? Almost all 2d graphics tasks can be done with API calls, at least in Java. And you don't need to know much to make those calls. I've been doing "graphical" programming since high school. Within one year of owning my first computer, I was doing graphical programming in windows 3.1 (using C++) and DOS (using x86 assembler). And things are far easier today. Using Flash or Possessing you're going to basically start with graphics programming, and I know in flash it's more work to use text then it is graphics!
Today I have pretty in-depth knowledge of computer science, logic, and math, and I don't really need to use much of it to draw things on the screen.
(Stay away from action script, though).
The basic algorithms to draw circles, squares, and lines are not that hard. You need to have a facility for mathematics, but it's all just basic arithmetic.
Graphics programming isn't some mystery. It's not any more complex then textual programming, really. More introductory programming courses should teach it, IMO, because I think too many people believe it.
posted by delmoi at 11:41 PM on October 15, 2007
As others have stated, modern graphics programming is generally a matter of coding in C/C++ using existing APIs - which stands for Application Programmer's Interface. That is, they are blocks of code which provide an interface for programmers writing applications to code against.
For 2D programming, Windows users can use Win32 for lower-level application programming, WinFX (a significant overhaul thereof) for Vista-and-beyond, and then if you want a more abstracted, high-level graphics programming experience, Microsoft Foundation Classes (MFC).
Here is the Win32 API code for an extremely simple Windows application.
Speaking as someone who has written a lot of Windows apps that tap into the more abtruse areas of Windows graphics chicanery like true alpha-blending of apps (including rendering windows beneath your application), I hate and despise MFC with an unbridled passion. I would recommend you avoid it - you will learn far more about how Windows actually works writing Win32 apps.
OS X uses Cocoa for application programming. Linux depends on whether you're targeting KDE or Gnome, but if you're looking to write XWindows apps for Linux and are asking this question, you either don't need my help or are in way over your head.
For 3D graphics such as those used in games, there's two major APIs: Direct3D (part of DirectX) which is used by Windows and the Xbox 360, and OpenGL - which is used by Windows, Macs, and Linux.
You might think that makes OpenGL sound like a better deal, but for gaming you'd be wrong. Modern graphics cards are having the internal structure of how they support shaders revamped so heavily with each year's new generation of cards, that you wind up writing several different rendering paths under OpenGL. Under Direct3D the situation is far better, but you sacrifice some of the simplicity and low-level access to the naked hardware that OpenGL provides you.
The ease of developing major applications in Direct3D and the ubiquity of Windows (and the relative failure of the PS3 vs. the Xbox 360 in the North American market) has left developers overwhelmingly doing graphics programming for games in Direct3D.
Here is a good Win32 tutorial.
Here are some good OpenGL tutorials.
I don't have any good Direct3D tutorials handy other than what ships with the DirectX SDK.
Hope this helps some.
posted by Ryvar at 11:48 PM on October 15, 2007
For 2D programming, Windows users can use Win32 for lower-level application programming, WinFX (a significant overhaul thereof) for Vista-and-beyond, and then if you want a more abstracted, high-level graphics programming experience, Microsoft Foundation Classes (MFC).
Here is the Win32 API code for an extremely simple Windows application.
Speaking as someone who has written a lot of Windows apps that tap into the more abtruse areas of Windows graphics chicanery like true alpha-blending of apps (including rendering windows beneath your application), I hate and despise MFC with an unbridled passion. I would recommend you avoid it - you will learn far more about how Windows actually works writing Win32 apps.
OS X uses Cocoa for application programming. Linux depends on whether you're targeting KDE or Gnome, but if you're looking to write XWindows apps for Linux and are asking this question, you either don't need my help or are in way over your head.
For 3D graphics such as those used in games, there's two major APIs: Direct3D (part of DirectX) which is used by Windows and the Xbox 360, and OpenGL - which is used by Windows, Macs, and Linux.
You might think that makes OpenGL sound like a better deal, but for gaming you'd be wrong. Modern graphics cards are having the internal structure of how they support shaders revamped so heavily with each year's new generation of cards, that you wind up writing several different rendering paths under OpenGL. Under Direct3D the situation is far better, but you sacrifice some of the simplicity and low-level access to the naked hardware that OpenGL provides you.
The ease of developing major applications in Direct3D and the ubiquity of Windows (and the relative failure of the PS3 vs. the Xbox 360 in the North American market) has left developers overwhelmingly doing graphics programming for games in Direct3D.
Here is a good Win32 tutorial.
Here are some good OpenGL tutorials.
I don't have any good Direct3D tutorials handy other than what ships with the DirectX SDK.
Hope this helps some.
posted by Ryvar at 11:48 PM on October 15, 2007
This is akin to asking, ''how do you paint?' or 'how do you build a house?'. Any kind of complete answer will be so complex it won't make sense, and any answer that makes sense won't tell you enough to be actually useful. You can spend years learning how to do this well. Here's a superficial overview...perhaps it will help.
At one time, computer graphics were an exciting new idea; being able to turn or off any individual pixel on the screen was really interesting and novel. (prior to that, many displays were text only; you had an 80x24 screen that could display alphanumeric characters and nothing else.) People started inventing algorithms quickly to draw lines and circles and boxes and the like. In the early days of home computer graphics, most folks rolled their own routines completely from scratch. That's why the early computer games often look so very different; the systems used to generate their graphics were unique and custom. (also, the graphic hardware tended to be special and different per computer, so you got wildly different results from machines that were roughly comparable in terms of CPU power.) On those early machines, if you wanted a dot turned on or off, you did it yourself -- one dot at a time.
Even now, all these years later, 2D graphics are still just manipulating dots on the screen. But you don't generally directly turn the dots on and off yourself. instead, there are many layers of libraries available. You can use the operating system's abstractions for graphics, or you can use toolkits that run on top of operating systems, and allow your graphics to work on more than one kind of computer. It's pretty common to program these in C or C++, because those languages are fast and graphics, generally, also need to be fast, but there are bindings to use almost any language you want. (The libraries themselves are usually written in C for speed, but you don't really care about that part. You just call the routines embedded in the library; it doesn't matter how they were written, just whether or not they work quickly.)
There's also "3D graphics", which is still 2D, but which is a represntation of a 3D world. This kind of graphics is at least an order of magnitude harder to handle. The sheer complexity of rendering a 2D image of 3D space is enough to send even intelligent people into fits of frothing. It's extremely math-intensive, and requires a vast amount of computation, so that's what the video cards mostly do.... accelerate the number-crunching required for 3D. The sheer power in modern graphic cards is mind-boggling, if you have any background to realize just how fast they are.
There are also libraries available to help you with 3D graphics. The most common ones are OpenGL (which is somewhat cross-platform), and Direct3D (Windows only). There are probably others that layer on top of those and make them easier, but I'm not familiar with any offhand.
posted by Malor at 11:50 PM on October 15, 2007 [2 favorites]
At one time, computer graphics were an exciting new idea; being able to turn or off any individual pixel on the screen was really interesting and novel. (prior to that, many displays were text only; you had an 80x24 screen that could display alphanumeric characters and nothing else.) People started inventing algorithms quickly to draw lines and circles and boxes and the like. In the early days of home computer graphics, most folks rolled their own routines completely from scratch. That's why the early computer games often look so very different; the systems used to generate their graphics were unique and custom. (also, the graphic hardware tended to be special and different per computer, so you got wildly different results from machines that were roughly comparable in terms of CPU power.) On those early machines, if you wanted a dot turned on or off, you did it yourself -- one dot at a time.
Even now, all these years later, 2D graphics are still just manipulating dots on the screen. But you don't generally directly turn the dots on and off yourself. instead, there are many layers of libraries available. You can use the operating system's abstractions for graphics, or you can use toolkits that run on top of operating systems, and allow your graphics to work on more than one kind of computer. It's pretty common to program these in C or C++, because those languages are fast and graphics, generally, also need to be fast, but there are bindings to use almost any language you want. (The libraries themselves are usually written in C for speed, but you don't really care about that part. You just call the routines embedded in the library; it doesn't matter how they were written, just whether or not they work quickly.)
There's also "3D graphics", which is still 2D, but which is a represntation of a 3D world. This kind of graphics is at least an order of magnitude harder to handle. The sheer complexity of rendering a 2D image of 3D space is enough to send even intelligent people into fits of frothing. It's extremely math-intensive, and requires a vast amount of computation, so that's what the video cards mostly do.... accelerate the number-crunching required for 3D. The sheer power in modern graphic cards is mind-boggling, if you have any background to realize just how fast they are.
There are also libraries available to help you with 3D graphics. The most common ones are OpenGL (which is somewhat cross-platform), and Direct3D (Windows only). There are probably others that layer on top of those and make them easier, but I'm not familiar with any offhand.
posted by Malor at 11:50 PM on October 15, 2007 [2 favorites]
10 CLS
20 FOR X = 0 TO 640
30 FOR Y = 0 TO 400
40 PLOT X,Y,1
50 NEXT Y
60 NEXT X
posted by Jimbob at 3:37 AM on October 16, 2007 [2 favorites]
20 FOR X = 0 TO 640
30 FOR Y = 0 TO 400
40 PLOT X,Y,1
50 NEXT Y
60 NEXT X
posted by Jimbob at 3:37 AM on October 16, 2007 [2 favorites]
To some extent it depends what you mean by "program". A hard core 3d games designer might with with the guts of, say, OpenGL - but those whose business is interactive media or animation in 2d or 3d are also programming graphics. They may be working on a more abstracted level but the techniques they use are still part of your answer.
The sort of programming environment originally developed by people like Marc Canter for (what is now) Adobe Director has now been widely copied in other applications. This uses a theatrical metaphor involving a stage (that shows you what everything looks like at a given moment), a cast (which shows a library of graphic elements that you need to interact together), a score (that allows you to see that many different elements are doing over time) and some kind of scripting language to give finer programmatic control.
Further refinements include multiple camera viewpoints on the stage, the potential for cast elements to be created programmatically and some techniques from animation such as onion skinning.
posted by rongorongo at 3:46 AM on October 16, 2007
The sort of programming environment originally developed by people like Marc Canter for (what is now) Adobe Director has now been widely copied in other applications. This uses a theatrical metaphor involving a stage (that shows you what everything looks like at a given moment), a cast (which shows a library of graphic elements that you need to interact together), a score (that allows you to see that many different elements are doing over time) and some kind of scripting language to give finer programmatic control.
Further refinements include multiple camera viewpoints on the stage, the potential for cast elements to be created programmatically and some techniques from animation such as onion skinning.
posted by rongorongo at 3:46 AM on October 16, 2007
I have a program that outputs medical graphics on the screen in 3D on Windows. When I wrote it, I made function calls to two different graphics-related libraries. One is wxWidgets. That library, which I downloaded, sends commands to the OS to request it to create windows and menus. Another is OpenGL, which is provided by the OS. I make OpenGL function calls as well. These function calls interface with the graphics card driver (which Windows eventually does as well, to create its interface graphics). The video card driver sends commands to the video card, eventually creating a bitmap of my screen image that is stored temporarily in memory on the video card. The hardware outputs that bitmap in a way my monitor can understand, finally displaying the graphics on the screen.
posted by demiurge at 8:22 AM on October 16, 2007
posted by demiurge at 8:22 AM on October 16, 2007
certain languages like processing (www.processing.org) which was recommended to me here,actually, have their own 3d graphics libraries. processing generates java code, but has a c like syntax, and it's open source and works on mutliple platforms.
if you want to create simple apps where performance is not an issue, using processing will save you the hassle of dealing with external libraries and frameworks and whatnot.
As a side note, back in highschool I C++oded a 3d game basically from scratch, using tutorials on graphics then available. I wish I still had the code but it got lost :(
Basically I had the formulas for 3d translation, rotation, perspective, triangle elements and those became an array of points that would be dumped directly into the video memory.
If you're serious about learning 3d graphics, I think starting with the basics and understanding 3d space and its rules for shwoing it on a 2d screen.
posted by spacefire at 8:33 AM on October 16, 2007
if you want to create simple apps where performance is not an issue, using processing will save you the hassle of dealing with external libraries and frameworks and whatnot.
As a side note, back in highschool I C++oded a 3d game basically from scratch, using tutorials on graphics then available. I wish I still had the code but it got lost :(
Basically I had the formulas for 3d translation, rotation, perspective, triangle elements and those became an array of points that would be dumped directly into the video memory.
If you're serious about learning 3d graphics, I think starting with the basics and understanding 3d space and its rules for shwoing it on a 2d screen.
posted by spacefire at 8:33 AM on October 16, 2007
« Older Maybe they could try this on Joe Morgan for a few... | Do my cats prevent me from getting tail? Newer »
This thread is closed to new comments.
posted by null terminated at 9:28 PM on October 15, 2007