Download Assignment No

WWW.VUTUBE.EDU.PK
Solution Assignment No. 6
Q1.
What is the importance of event driven programming in GUI? Name some major
sets of events in openGL.
10
Answer.
What is event driven programming?
All GUIs (Graphical User Interfaces) and graphical games, like Counter-Strike, Halo, are
written in as event driven programs. Event-driven programs break from the traditional
programming structure.
In traditional programming languages, the application, rather than a specific event,
controls the portion of the computer code which is executed. In addition, the traditional
programming coding executes from the beginning of the code and follows a predefined
pathway through the application, calling procedures and functions as needed. Flow charts
are often used by programmers to structure the programs. Some examples of traditional
programming languages are Pascal, C, FORTRAN, COBOL, and Lisp.
Computer languages such as Visual Basic are known as event-driven programming
languages. This means that the user executes an event procedure such as clicking a
button to run part of the code. Event-driven programming does not have a predefined
pathway in the execution of the code, as opposed to traditional programming. User
actions determine the sequence of code executions. An advantage of this type of
programming is that no pre-structure for the code is necessary. Its high flexibility allows
the user to modify parts of the code easily without interfering with the rest of the code.
In procedural-driven or top-down architectures, the application executes a set of
instructions in a specified sequence to perform a task. The structure and sequence of the
program, not user actions, control the execution order of a procedural-driven application.
The program execution begins in main and then flows through method calls and control
statements in a fairly predictable manner.
In an event-driven program, the program first waits for events to occur, responds to those
events, and then returns to waiting for the next event. How the program responds depends
on the code written for that specific event. The order in which an event-driven program
executes depends on which events occur and on the order in which those events occur.
While the program waits for the next event, it might perform other processing tasks. If
you do not write any code for a specific event and that event occurs, the program does not
handle the event. Several programming environments use callback functions, which are
software routines that respond to particular system events.
Rather than our program having a well defined flow, the control flow of an event-driven
program is completely dependant on the events passed into the program. Event-driven
programs will idle in some state. When events come in, the program will wake up,
process the event, and then go back and idle.
For example, instant messengers are event-driven programs because program idles until
an event, a message from the front end or network, is received and then an avalanche of
processing occurs in order to respond to the event, and the program goes back to its idle
state.
This pseudo code models an event driven program:
while (TRUE) {
while (there is no event) {
keep waiting....
}
if (an event occurs) {
switch (event) {
case event 1:
process event 1;
case event 2:
process event 2;
.
.
.
case event N:
process event N;
}
}
if (exit is signaled by event) {
break;
}
}
GUI & Event-Driven Programming
One might think,” But this is a graphics library, why would I want to do this event-driven
thing?” It’s very handy for the two things that a graphics library is usually used to create:
GUIs and games.
What is a GUI? Well a GUI is basically any program that receives a majority of its input
from a user. Almost all programs with which you are familiar are GUIs, such as MS
Word, Internet browsers, AIM, iTunes, etc. Another good thing to notice is that a game
like Quake or Halo is just a very specialized GUI. Like any of the other aforementioned
programs, a computer game will react from input from the user and continue doing so
until the user tells the program to close.
So why is event driven the way to go? The answer: Users are unpredictable. If we were
to write a non-event-driven program that would handle inputs from users, the problem
would be untraceable, assuming at least one of the inputs does not designate that the
program should close. There are literally an infinite number of combinations of events
that could occur that you would have to account for.
However, if we write the same program as an event-driven program, the task becomes
much easier. Now we only have to write code that will respond to each event. If that code
is correctly called when each event occurs, we have covered all input combinations from
the user.
Event Driven Programming in OpenGL
We know function pointers? Well they are the primary way we write event-driven
programs in OpenGL. The events that GLUT lets us react on are:
• Keyboard Events - If the user presses a key, you know about it.
• Mouse Events - The user can also press your buttons, now isn’t that mean?
• Timer Events - If we want to do things on a timer, like update the screen if things fall,
for instance, this will be our friend.
• Reshape Events - This is the one that might not be obvious. If the user reshapes the
window, we might want to reshape everything so our aspect ration is preserved. We
might also want to show less of the scene. What we choose is up to us and that’s why this
is an event.
We first have to tell OpenGL what functions to call when one of these events occurs. For
example, if the function that processes keyboard events is keyFunc(), you would tell
GLUT to use this by passing it to glutKeyboardFunc() as a parameter. Whenever a key
that is mapped to an ASCII value is pressed, keyFunc () will be called. Finally, to enter
the infinite loop that waits for events, one calls glutMainLoop ().
To get out of the loop, destroy all windows with glutDestroyWindow. If this does not
work, feel free to call exit.
Q2.
Explain Double Buffering, Coordinate Systems, The Matrix in reference of
openGL.
Answer.
10
Double Buffering
For graphics applications, often times not just a good idea, but required. Double buffering
lets us get around this problem.
So, with double buffering, the user sees one image while the program creates another
image in another buffer. When the new image is finished, you can display it by swapping
the buffers. Basically, this way you hide all your edits from the user.
Coordinate Systems
A source of much confusion in OpenGL is the fact that there are three coordinate
systems. Which are:
• Window Coordinates  This is what the user sees and is counted in pixels. (0, 0) is in the
upper-left corner. x increases as you go right, and y increases as
you go down.
 glViewport will really be the only thing that will utilize window
coordinates. We should call this whenever the window is resized as
we will need to reset the size of the window.
 When the coordinates of a mouse curser are given in a GLUT
callback function, they are given in window coordinates.
• World Coordinates  This is what we will be drawing on. We can think of it at 3-D or 2D.
 We use gluOrtho to set up how the coordinate system works.
• Object Coordinates  We know that describing a sphere is most natural in spherical-polar
coordinates and a cylinder in cylindrical-polar coordinates. Well,
this is the OpenGL analogue. If we are drawing a complex shape,
we can tell where that shape is in the world, and then draw the
shape in its own coordinate system.
 glLoadIdentity makes the object coordinates equal the world
coordinates. We probably want to do this before we draw anything
in OpenGL.
 For 2-D stuff, we probably always want to be in world coordinates
when we deal with reshaping the window and switch to object
coordinates when drawing. However, there is almost no
distinction, because we should also call glLoadIdentity as soon as
we switch coordinates. Again, this is primarily applicable to 2-D
stuff!
The Matrix
Matrices are the way OpenGL stores where everything is in your world, objects, shapes,
and everything. There are four different matrices in OpenGL:
• GL MODELVIEW
• GL PROJECTION
• GL TEXTURE
• GL COLOR
However, we’ll probably only want to use GL MODELVIEW, which designates that we
are in object coordinates, and GL PROJECTION, which designates that we are in world
coordinates. We can switch which coordinate system you are in by using glMatrixMode.
As glLoadIdentity makes your object-coordinates matrix equal the world-coordinates
matrix. However, we can also do more fun things with these matrices. Well OpenGL uses
some of transformations to rotate, scale, and translate the matrices. Usually we will only
want to do this to an object, since we will want to move it around in the world. Now the
way these transformations associate is a bit odd, rather than the left-to-right precedence
that characterizes standard arithmetic operations, matrix operations associate from rightto-left, so we write all our transformation in the reverse-order from what we want to
happen.