graphics are almost always done with specialized libraries in C++. These libraries, like opengl, directx, and sdl, have their own frameworks all completely designed toward graphics. You have to learn a lot about the library to use it well, but that's how games and other graphics stuff is made.

Sounds like he was asking more about GUI type stuff rather than 3d graphics? In linux, there are a couple of main GUI libraries like QT and GTK. I'm not sure about windows. They usually have some kind of graphical designer that you can layout buttons and textboxes and whatnot, then they use some variation on the idea of "callbacks" - an event gets triggered when the user does something in the GUI and then you have to "handle" the event in the code.

Sorry, I don't know anything about windows GUIs in c++.

Good luck.

Dave

There is freeware Qt for Windows now (from April 2009). There are some other freeware GUI libs for Windows - as usually, they are portable too.

The difference between the DOS command line and the GUI is due to alot of things.

If you are programming in windows, you would use the Windows Application Programming Interface (WinAPI).

The libraries and namespaces:
GUI programs dont use the std:: namespace, because that is designed for DOS output like cin and cout. Instead of including things like <iostream>, it is <windows.h>, <commctrl.h>.
The graphics are actually controls (widgets), that are defined by window, all you do is have to call CreateWindow() or CreateWindowEx(), and store the value from that in a HWND variable. like: HWND hwnd = CreateWindow(...blah blah blah...);

You can learn more about CreateWindowEx() at: http://msdn.microsoft.com/en-us/library/ms632680.aspx

There is actually alot more to it though, but once you get started it isnt too confusing.

Take for instance, Instead of int main(int arg, char arg[]), it is
int WINAPI WinMain

The proccess goes like:

Create all global variables and processes

WinMain
--->Register the window class
--->Create the window
--->Recieve messages from the windows and controls (like when they are clicked, typed in, ect.) and send them to WndProc

WndProc
--->Process the messages, and do something with them.

You can learn how to program GUI applications using the Windows API at: http://www.winprog.org/tutorial/

I hope this helps you understand the concept of, and gets you into programming GUI applications using the Windows API.

>If you are programming in windows, you would use the Windows Application >Programming Interface (WinAPI).
And always get struck with windows and make unportable GUIs. Well, there is a very cute library which is called wxWidget. Learn it. It will save you time as it is portable, so would not have to learn a new toolkit when porting your application to other platform.
Even QT and GTK+(which comes with the binding gtkmm for c++) are good alternative.
But please don't settle with windows MFC or any other platform-dependent toolkit.

The beauty of wxWidget is that it uses the native API for the particular platform: like WinAPI when in Windows, GTK+ when in Linux GNOME, QT when in Linux KDE. So, you always get the native feel.

>And always get struck with windows and make unportable GUIs.
siddhant3s, you don't have to take a strike at my integrity just because you don't like my approach. I was just telling him what the jump from command lin to Windows GUI.

WinAPI is the most commonly used and best documented API there is. Just because of a few compromises doesn't mean it has to be taken out of the equation completely.

It is a matter of oppinion, let him decide which he would like to choose. Also, with QT (like another suggested) you dont really code it yourself, its approach is completely indirect. I actually don't recommend it even for beginners, because if you start with it, then you will be reluctant to ever go back to hard coding.

Like when I started with visual basic, I was completely overwhelmed when I moved on to C++.

But there is 2 sides to this, because on the otherhand, if you start with a visual drag 'n drop program, it can ease you into hard coding.

You see siddhant3s, there is problems with both.

Either way it is your choice (@ the thread owner).

>siddhant3s, you don't have to take a strike at my integrity just because you don't
>like my approach.
"strike at my integrity"..... what does that means? I never 'stroked' at your integrity.
Your approach? Which approach?
>GUI programs dont use the std:: namespace, because that is designed for
>DOS output like cin and cout.
I thought toolkits don't use std namespace so that they won't clash with the names with those of std ( which is exactly why namespaces are invented).
Also, std is not designed for command-line output. It is implemented to contain the standard names.


>WinAPI is the most commonly used and best documented API there is.
I can bet you would find more documentation for QT and GTK+. Naturally, M$ cannot compete us( the open-source hackers community). So, you would never find as much quality docs as you would for an opensource toolkit.

>Just because of a few compromises doesn't mean it has to be taken out of the >equation completely.
You call non-portability a minor compromise? I would never use a proprietary toolkit and become a slave of a private firm.

>Also, with QT (like another suggested) you dont really code it yourself, its
>approach is completely indirect.
I don't code? Then who do? And its approach is perfectly fine. It is open-source. You can proceed further development of QT itself; can you proceed the development of any WinAPI yourself? No, you can't as only M$ hired developers are given the source code and not the public. You loose.

>I actually don't recommend it even for beginners, because if you start with it,
>then you will be reluctant to ever go back to hard coding.
Let me tell you one thing: hard coding isn't sexy. QT, GTKmm and wxWidget provide abstracted interface on all platform so you don't need to know what is inside. Which is a good thing. This is all encapsulation is all about. And if you want to see the inner code, you are always invited.

So, there is actually no problem. You learn a good, free, open-source toolkit and start programming GUIs on all platforms.
Yes, of course the choice is of OP.

>No, you can't as only M$ hired developers are given the source code and not the public.
I have every single source code file of the windows API, provided by Dev-Cpp under the Open Source lisence.
The files were not created by MS, they are created by BloodShed developers, see this code from <windows.h>:

Siddhant, what I meant by strike at my integrity was that you were saying my approach had downsides, but yet yours did and you didn't even explain what they were, thus basically saying that any WinAPI approach was the worst ever way to go possible, so disregard anything killdude69 says. I have tried QT, it is like visual basic, you wouldn't tell a C++ programmer to go back down to VB programming would you?

I think people shouldn't be so reluctant to try and learn something new, rather than use these programs that program for you like QT. It is not a good thing if you actually plan to stick with it forever. Yes they are good for multiple OSs, but you should also learn how to design the UI yourself without the aid of Drag 'n Drops.

What if everybody didn't know how to hard code, and always used QT? Nobody would actually know how to use C++ in its native form, only being able to code with help from a program that provides indirect functionality.

People should learn multiple APIs and kits. Not just stick with a drag and drop interface that does everything for you.

If you dont know what is inside, then it is more difficult to utilise its full potential.

You can't claim you can win a race if you dont know whats under the hood. All I am saying is if you are ACTUALLY serious about programming then use something that doesn't do everything for you.

Yes, the WinAPI always has its issues, but so does every other API and kit.

>I have tried QT, it is like visual basic, you wouldn't tell a C++ programmer to go back down to VB programming would you?
Are you sure that it looks like VB?