I'm a beginner programmer and all I've worked with so far are console applications in C++. Coding wise, how is the graphical side of programs created? I understand the logic that I am using from console apps will be the same, but how do programmers create the graphics that this logic is then used in? I know this is sort of an ambiguous question but basically I am trying to understand how I would go about creating a program that is not a console application, such as a video game or an iPhone application.
Basic answer: Graphics are made by pushing frames to a frame buffer.
Modern answer: You're going to be given an API to make a "Window" or a "Scene" or something like that. Find an API that fits your goals (GTK+, QT4, Windows (??)), and run through some tutorials for it.
If you're actually interested in games, or more low-level graphics, check out this SDL Exercises Page.
To learn GUI, all you have do is to put one idea in your mind, only one, which is: event-driven.
That's it, the pattern appears in all GUI/gaming stuff. Then, what is event driven? Before we goes into details, let's see the common sequence console program first
ask user for some parameters read file calculate some values write to the file close the file ...
It appears to be some code like this, and here, let's see how an event driven program looks like.
while event_queue is not empty: event = event_queue.get_event() if event is quit_event: break else if event is mouse_click_event: do something to response user else if event is key_board_event: do something to response user ....
As you can see, the major difference between common console applications and GUI applications is: there is a main loop in GUI application. So, what's the loop? And why it is event-driven? That's simple, in an GUI application, we don't know what will the user do next, user might click a button "about", "ok" or "cancel". What we can to do here is to wait, see what user do and make a response. That's it, the "event" is exactly the "action" user took, and our response is driven by the event, therefore, it is so call event-driven.
And let's talk about the loop. That loop is simple, it checks is there any event in the queue, if there is, it pops the event from the queue and react. So, where are those events from? It's usually from OS. When an user takes some actions on our interface, let's say, a button in our window frame, OS put corresponding events in the event queue.
Still don't understand? You can imagine that there is a store, a staff named Bob, and here comes the customers, they line up in a queue, the staff can only serve one customer one time, when there is no customer, the staff can only sit there and play his finger. The staff is the main loop, and customers are the events.
Then, what would happen if Bob took all his time to deal with one customer and never finish it? Let's say, a customer make such a request
I would like to order some elixir.
And here Bob starts his trip for looking elixir. Can you hear those dirty words from those customers in the queue now? Yes, a major common problem appears in event-driven is that it we get blocked in handling one event.
while event_queue is not empty: event = event_queue.get_event() if event is mouse_click_event: # I will never release the control! while True: pass ....
As you can see, when the event is mouse_click_event, we goes into the scope, and it is an endless loop. Did you ever see "No response" windows? Yes, that's it, some event gets blocked in the main loop, which caused the main loop can't handle any other events.
You may say "Hey! I'm using wxWidget, what's the matter with the event-driven", as what I said, event-driven pattern appears in all GUI applications, including QT/wxWidget/MFC/VB/.Net Framework.... at least all GUI stuff I know. Therefore, once you can understand what is event-driven, they are all the same.
From a GUI perspective there are basically 2 different kind of desktop applications.
- Standard windowing application
The difference is that a standard window application will typically use the native OS API provided to provide a similar experience to other applications that exist on the OS. A game typically takes over the user experience and excludes any paradigm that exists in the OS. The approach to developing each is completely different.
Since I haven't done any game development I'm not going to pretend to talk to that topic. From a standard windowing (*nix/Windows) perspective though the development experience is quite different from a console application. Typically console applications assume a fairly serial user experience (i.e. the app has a good idea of what the user will do next). In a window/GUI based application, the user can do more or less whatever they want so at the application level everything tends to be (user) event driven.
If you are looking for a way to learn more about developing a GUI application I would suggest reinventing the wheel and doing something that you know how it should work. A good example would be a reimplementation of NotePad, or something similar that is simple but gives a good feel for some of the basics of developing a windows app.
First you might want to look into the curses library, which facilitates the creation of terminal-based interfaces.
On the truly graphical side of things, the OS windowing system is responsible for most of the heavy lifting. Generally the OS draws a bunch of stuff to an in-memory bitmap, and then says to the graphics card "Hey, can you show this crap on the monitor please?". Repeat 60x per second.
As such, when you're wanting to write a proper graphical interface, a lot of the stuff you're going to be doing is basically just talking to the operating system - "I want my window to be placed here", "let me know when the mouse is over this part of the window", "alright can you change the mouse pointer to an hourglass please" etc.
Of course for most uses you want to be using a graphics library to handle that talking-to-the-OS stuff, leaving you free to code up your UI in a platform-independent manner.
Expanding on Ken answer, from the perspective of game development, there are two ways of seeing this, since there is an game engine and the various games that are made typically in a game engine.
A game engine, makes the calls to graphic api (opengl and direct3D come in mind) in order to draw the different game scenes and animations, supports the loading of 3d shaped modeled in programs like 3d max, supports the loading of shaders, helps calculating the intersections of all objects, and tells when two or more of them collide, provides an interface to the sound library in order for one to play sounds if a character gets a head shot (like your boss) (and in this case openal, DirectSound and FMOD come into mind), and provides an way to implement characters controlled by AI, that go after donuts as soon as the game begins (tasty donuts, ahahahah).
Then, there is the game that implements the game logics (if the player starts farming, he gets head shoted, or if the warrior player, finds a mage he is immediately iced and then the mage uses the ice cube and a stool to put is feet), and also the characters modeled in some software, and everything that is specific to a game, since all the general things are provided by the engine. (Gamedev.org and gamasutra excel in this)
There is (at least) one big issue that you're likely going to run into as a CUI-developer when moving to GUI: GUI programs need to continue to run to keep displaying and reacting to the user (the user expects continuous reaction from the interface).
When you're going to run functions that take somewhat longer (or need to run continuously) you should be aware that your GUI might be frozen if you don't do it the right way - for a GUI to continue to run normally it must keep running in foreground. So continuous (or time-consuming) functions should almost always be fired in another thread, while sending events to the GUI when a status changes.
Some GUI systems provide this for you and abstract these details away for you (mostly systems that have seperate markup- and code-languages like WPF/Silverlight), but in others (like GLADE) you have to manage this by yourself.