Friday, July 25, 2008

Silver Eagle Dixie Chopper

OPENGL and GLUT for Mac OS X

Le opengl sono già installate e si possono reperire al seguente path :
Macintosh HD / Sistema / Libreria / Frameworks / OpenGL.framework
Inoltre bisogna installare il framework GLUT che per il mac è reperibile al seguente indirizzo : http://developer.apple.com/samplecode/glut/index.html, scaricare il file zip e decomprimerlo. Aprire un terminale e spostarsi dentro la cartella appena decompressa e digitare :

xcodebuild install

sudo ditto /tmp/GLUT_External.dst/System/Library/Frameworks/GLUT.framework/System/Library/Frameworks/GLUT.framework

Ora la libreria GLUT è installata per fare una verifica portarsi nella cartella frameworks, dove precedentemente abbiamo controllato se erano presenti le opengl e controllare che ci sia la cartellla : GLUT.framework.

Se ne file sorgente is GL / glut.h must change with GLUT / glut.h.

Open Xcode, create a new C + + Tool, enter the name you want, press the button, right mouse over the name of the newly created project with the icon of Xcode and choose add and sub menu, choose External Framework and select the folder OpenGL.framework and GLUT.framework, delete the file main.cpp and enter your source files. Now press the Build-and-go and the program should start.

Tuesday, July 22, 2008

Washing Hair After Thermal

Principles of Object Programming - Part 3

Prefer composition to inheritance

Skep, after completing the design of its soldiers, who now can conquer the world, you realize one important thing: choosing a has-a relationship rather than inheritance gave more flexibility his plan. Not only has the choice of a family of algorithms easily, but also gave him the opportunity to change at runtime the algorithm to use .

If, as it should be the aim of a design object is the easy reuse and maintainability of the code, the composition definitely wins in the efficiency with respect to inheritance. This concept, or maintainability, it is important also for the fact that during the course of vito software, the stage longer and perhaps harder is definitely the maintenance, which often also involves deep changes to the software created. Giving the ability to dynamically change the software can make maintenance much faster: even the implementation of the methods can remain the same and can only change their call dynamic. Sometimes the

choice between inheritance and composition can be very complicated : In some occasions the two principles may seem absolutely equivalent until we reach a point (applying Murphy usually towards the end of the design of a component) in which one of two behaviors becomes obviously better to use.

In general, during the design, it is good to keep in mind this rule:

Using inheritance as a objects behave like any other, rather than when it seems a subtype .

A case of this example is: Suppose two classes, Rectangle and Square. Obviously, an initial analysis would say that the proper relationship between the two is an is-a relationship in the sense that Square is-a Rectangle, quantp in the square is a special case of the rectangle with the sides all having the same size. But suppose that the class Rectangle abbia ragionevolmente due metodi, setHeight() e setWidth() che ne modificano altezza e larghezza. Square eredita i due metodi ma una volta che vado a chiamarne uno di essi su square evidentemente non succede ciò che volgiamo, rompendo il principio che Square dovrebbe essere un diretto sostituro per Rectangle. Quindi in questo caso l'idea is-a si applica logicamente ma i due oggetti non si comportano allo stesso modo, finendo per dare risultati inattesi.

Comunque sia Skep si ricorda di aver già visto uno schema delle classi come il precedente. Quello finora descritto infatti è il design pattern Strategy , che formalmente può essere descritto così:

Strategy ha lo scopo di definire a family of algorithms, encapsulate it and make them interchangeable. Strategy lets algorithms vary independently from clients and use them.
(Design Patterns, Gamma, Helm, Johnson, Vlissides)

Strip Joints Bartending Work

Principles of Object Programming - Part 2

Program to interfaces not to implementations

The next problem facing Skep is how to implement the new idea that has been fantastic. With the new system, thought you get a new advantage: you can now change the behavior of every soldier to run through some simple setter methods. Also in this way the Soldier classes should not know the implementation details of their behavior.

Skep plan to use an interface for each behavior (shoot and heal) and different implementations for different subtypes of conduct in order to remove the chains of slavery arising from the implementation of a method rather than another. It should be noted that the word interface is used incorrectly when you consider only as a java interface to interface here is meant as a supertype, even such an abstract class with abstract methods which do an override.
The scheme comes to design is the following:

What is the difference between planning and programming to interfaces to implementation?
Program is to make the code to implement static and extremely difficult to maintain, as new changes involve the creation and change of large parts of the existing code.
A programming implementation in our case might be this:

 
Marine Marine m = new ();
m.shoot ();


In this case, declare the variable m with static Marine, and then concrete implementation of a Soldier, forcing us to use the actual code implementation, or to the sea.
Programmare ad interfacce/supertipi invece significa sfruttare il polimorfismo, ad esempio in questo modo:

  
Soldier soldier = new Marine();
soldier.shoot();


In questo caso dipende dall'implementazione che diamo a shoot nella sottoclasse Marine: sappiamo che è un soldato ma possiamo usarne il riferimento in maniera polimorfica. Ciò ci permette anche l'iferenza del tipo a runtime in questo modo:

  
s = getSoldier();
s.shoot();


qui addirittura non ci interessiamo di che tipo sia il soldato, ci interessiamo solo che risponda al comando spara.

Un altro vantaggio di questa implementazione è che altri oggetti possono riusare il comportamento dei nostri soldati. Supponiamo che Skep voglia inserire nel gioco dei mezzi corazzati, e che un tipo di mezzo corazzato faccia gli stessi danni e spari allo stesso modo di un soldato con il bazooka. E' sufficiente richiamare nell'oggetto che rappresenterà il nuovo mezzo corazzato il comportamento definito precedentemente per il soldato e il gioco sarà fatto. Inoltre è facile aggiungere nuovi comportamenti senza modificare di una virgola i comportamenti definiti precedentemente.

L'idea generale è quindi questa: un Soldier delega il suo comportamento di attacco o cura invece di utilizzare metodi definiti nella classe Soldier o nelle sottoclassi.
Let's see how
Skep decides to really integrate the project.

1. Data fields and methods for the conduct
First, for each Soldier is necessary to add two data fields, one for a shoot and to heal. The nature of these data fields will be the type of interface or ShootBehavior HealBehavior, so you can instantiate in a sucessivamente using polymorphic subtypes defined. Also in Class Soldier you must define two methods, one for the shot and one for care, they will replace the old shoot and heal. The resulting matrix is \u200b\u200bas follows:

2. Implementing performShoot
 
public class Soldier {
ShootBehavior shootBehavior;

performShoot public void () {
shootBehavior.shoot ();}

}

Ext shootBehavior.shoot () embodies the idea of \u200b\u200bdelegating to other management behavior of the soldier. In this way, the soldier class will never be touched to change the implementation you shoot short, we do not care here as gunfire, only that shots. Rigurda exact same speech as the behavior of care

3. Implementation of the subtypes
Now Skep must implement the subtypes of a soldier, and do it this way:
 
Marine extends public class Soldier {public

Marine () {
shootBehavior ShootWithGun = new ();
healBehavior NoHeal = new ();}


public void display
{/ / Prints the marine
}}


While making an assignment of this type and shootBehavior healBehavior might seem erroneous in light of the programming interfaces, in reality, the static type of the variable is an interface and then you can, thanks to polymorphism, easily change the type runtime.

4. Implement behavior
It 's finally time to implement the behavior of sodati. Here I will show the implementation of behavior only shootBehavior, heal is very simple. First define the interface ShootBehavior

 
public interface ShootBehavior
{public void shoot ();}



Now we define the classes that implement this interface
 
public class ShootWithGun

{public void shoot () {
/ / firing the gun

}} public class

ShootWithBazooka

{public void shoot () {
/ / firing the bazooka
}}


In theory, our simulation a soldier would be ready, but Skep acora decides that it should be made more dynamic, in anticipation of future developments.

5. Controlled from the dynamic behavior
Skep says it is a pity that created everything and then dynamically assign the behavior at compilation time. He decides to enter a new method in the class Soldier
 
public void setShootBehavior (ShootBehavior sb) {
this . ShootBehavior = sb;}


In this way we can call these methods every time I want to change the behavior of the soldier. For example, suppose that a soldier is able to collect bazooka found on the ground from dead enemies. It would be so easy to change the capacity. At this point it would be logical to create a class model for every soldier and dynamically assign the various behaviors.

Skep has new ideas! In the next post we will see that this design has also taught another rule to our nice friend ...

Monday, July 21, 2008

Pave Diamond Rings Cartier Trinity Ring

Principles Programming with Objects - Part 1

Identify aspects of your application that vary and separate from those that do not vary

Suppose Skep has decided to spend the free time between a cigarette and the next cigarette in a useful way: it has decided to design a simulation of war, perhaps an RTS. The game can simulate battles between soldiers for now ruled out armored vehicles or other amenities, for sheer simplicity (after all believed that good planning simulation, add items later is not so complicated). After a brief brainstorming session (from which came out for the most porn actresses names and insults) and 'time to design in the game, or the soldiers.

beginning Skep uses a standard technique of object-oriented programming, which creates a Soldier superclass from which all the different types of soldiers will inherit.

This clearly missing in this scheme is the ability to shoot, which Skep decide to implement a method shoot () in superclass Soldier.

The sick mind of Skep innvative always manages to produce ideas: one day decided that it would be great if your in the simulation are also present special soldiers, able to deal with other soldiers on the battlefield but are not able to shoot . Here the pattern is modified accordingly


Skep wanted to show everyone his skills in OO design, but made a serious mistake: the next day, when he started to do the first tests on its software, is a lot of healers who run for the field battle by killing enemies left and right, which was not clearly provided for the initial project. This is because the subclass inherits the method Healer shoot which is not defined as abstract as it indicates the order to shoot the gun, and it is hoped that the soldiers all shoot the same way if they have the same gun. Although it may seem trivial, the problem becomes serious when you have multiple subclasses that do not have the ability to shoot: take for instance the implementation of a class for masters, able to only give orders, or soldiers of genius, capable only to make bombs.

Skep, after yet another brainstorming (this time the main theme is "who will win the title? "), considers appropriate two completely different solutions:

1. Override
Skep think that might just make an override of the method to shoot all those classes who can not implement. The override would either give an implementation nothing about the method, so that when you ask for a unit that does not have the ability to shoot, it does not perform any action. But if one day were to invent some other peculiar behavior, such as a soldier who does not run and do not fly because Shoot, it should override both methods. And if it was worth for 20, 30 different classes, how much time would be spent unnecessarily in maintenance?

2. Interfaces
Skep finally understand that probably the inheritance is not the solution to your problem. Then, as a good Java programmer, she started on the interfaces, which presumed to solve the problem. Sums up his thoughts in this scheme:


But it is even worse than before! If the first thought wrong to override some methods in some instances, in which case the override is systematic for all subclasses that want to implement specified interfaces. Until it comes to a small number of classes the idea is applicable, but a maintenance of a detail of the shoot such method would lead to the need for change shoot all methods of all classes. Hard to think even for a workhorse like Skep.

At this point it is easy to think that the problem has already been solved by a very nice design any pattern, but Skep decides that he prefers the good old way, or by applying the sound principles of Object-Oriented Programming. (Actually Skep test for years to memorize the patterns correct but does not remember ever applying ...). The idea is, however, to write the software easier to maintain as possible, ie that the changes made by a correction cause the fewest side-effects can tap the fewest lines of code possible.

Here comes in. the planning principle discussed in this article: what changes need to be taken more often and encapsulated, so that it has the least possible impact on the rest of the code. The result will be fewer unexpected result from the code change and greater flexibility in the system .

To achieve this you must first define what are the parts that vary from class to class. Skep far as he knows, the only two methods are changing shoot and heal. The problem can be solved by creating two sets of separate classes, one to represent the behavior of "shoot" and another to represent the behavior "heal". For example, we have to all "shoot" a class that implements shoot () and a class that implements noShoot ().

The Soldier class is still superclass for the other, but we extrapolate the behavior to define the newly created external families, according to this scheme

In the next section we will see another important principle of object-oriented programming that will allow Skep to achieve what they want.

Friday, July 18, 2008

Blue Screen Appear On Pokemon Soul Silver

Clipboard OpenGL - primitive data types and nomenclature of the OpenGL functions

OpengGl defines some data types primitives used during programming to facilitate the porting from one platform to another. They are exactly the same data types defined atraverso most modern programming languages, but with a different nomenclature:


OpenGL Data Type internal representation equivalent C
GLbyte 8-bit signed char integer
GLshort 16-bit integer short
GLint 32-bit integer long
GLfloat 32-bit floating point float
GLdouble 64 bit floating point double
GLbyte 8 bit integer signed char
GLubyte, GLBoolean 8 bit unsigned integer unsinged char
GLushort 16 bit unsigned integer unsigned short
GLuint, GLenum, GLbitfield 32 bit unsigned char unsigned long
GLchar, GLsizeiptr 8 bit charachter char


Tutti i tipi di dato che cominciano con GL denotano membership in the OpenGL framework.

As for the functions defined by OpenGL, the Convention on nomenclature can be summarized with the following method:

\u0026lt;area of \u200b\u200bdll> \u0026lt;command> \u0026lt;Number of argomenti> type> of argomenti>

where number and type of arguments are optional elements. Here is the function to define a color's signature:

 glColor3f ([....]) 


with variations

 glColor4f ([...]); 
glColor4d ([....] )
glColor3i ([....]);


and many others, categorized according to the type of data accepted parameters and their number.

Vegetable Side Dish Thanksgiving

Notes - Introduction

In this first post notes on OpenGL introduce 's API, looking to first understand what is OpenGL and then introducing the high-level functions.

What is OpenGL?
OpenGL software interface is defined as the graphics hardware: OpenGL essentially provides a quick and portable way to draw 3D environments on a computer screen.

Developed by Silicon Graphics Inc (SGI), questa API è progettata attraverso algoritmi ottimizzati per essere il più veloce e potente possibile. Ciò significa che fornisce pochi comandi molto potenti, la cui combinazione può generare ogni ambiente 3D possibile. OpenGl non è un linguaggio di programmazione come C o C++, somiglia più a Standard Template Library del C++: è una API che durante la stesura di un programma "capita" di usare nel momento in cui si vuole disegnare qualcosa su schermo.

Opengl è studiata appositamente per fornire una interfaccia veloce verso le schede grafiche , sfruttandone appieno le possibilità, anche se, come vedremo, ne esiste una implementazione software ben progettata che sfrutta il più lento software rendering.

Come funziona OpenGl?
OpenGl è una API procedurale più che descrittiva : piuttosto che descrivere la scena per come dovrebbe apparire, fornisce una serie di comandi che descrivono dei passi da compiere per raggiungere lo scopo prefisso di disegnare la scena sulla schermo. Non è incluso alcun comando per la gestione delle finestre, l'interazione utente e l'input/output, in quanto questi compiti vengono lasciati nelle mani del sistema operativo. Uno degli scopi dei programmatori di questa API è stato proprio creare un framework capace di funzionare indipendentemente dal sistema operativo di utilizzo, e l'implementazione di un window management system, for example, would affect the performance of this While working.

OpenGL in its software implementation, has a precise place during the execution of a program, which can be summarized by this scheme:

The example is defined for the Windows environment, as GDI (Graphical Device Interface) is a component of its Windows, but that finds its counterpart in all other operating systems, with different names.

Usually a program calls many functions, some of which are provided by the operating system from the apparatus and input / output, some of which were specially designed by the programmer. The windows you turn to show something on the screen interface to it via calls to the GDI (Windows environment). The software implementation of OpenGL receives requests from the application and builds (rasterize) to reproduce the image on the screen, thus passing the GDI . This means that many are transparent to the programmer of low-level operations drawing on the screen.

course there is also an implementation of OpenGL that takes advantage of GPU hardware acceleration, and works with the following method:

In this implementation OpenGL no longer speaks with GDI, but speaks directly to the functions provided a disposizione dai driver della scheda video , permettendole di disegnare direttamente su schermo con una notevole velocità di esecuzione. Anche in questo caso, al programmatore è risprmaito il tedioso processo di interfaccia con i comandi a bassissimo livello della scheda video per disegnare a schermo.

La Pipeline
La parola pipeline indica un processo che può essere composto di più stage successivi. Anche Opengl ha una sua pipeline interna, la cui rappresentazione semplificata può essere questa:

dove lo schermo sta all'estrema destra. Nel momento in cui un programma chiama un comando dell'API, il comando viene messo in un buffer dei comandi. When the buffer is cleared, by the will of the programmer or by the will of the system, commands are passed one by one the later stages of the system.

The first step is the movement and lighting of vertices, a stage of intense mathematical process of calculating and updating the coordinates for each vertex lighting (Tranform & Lightning). Once this process is complete, the vertices are passed to the rasterization, which combines all the information to create the desired image, thus passing it to the frame buffer or the memory of the graphics device interface: in essence, the image is drawn on the screen.

This pattern of high level can be refined to be more specific and correct this one:

Let each component of this pipeline refined.

Date Vertex and Pixel Data
Each geometric shape in OpenGL is represented by the specification of key points, which are called vertex and that is a representation computazionalee of vertices. In the case of a vertex point is exactly that point, in the case of a square are the vertex angles of it and so on. The pixel data rather represent the pixels for images and bitmaps.

Display List
E 'can be grouped in OpenGL vertex and pixel data for immediate use or for reuse futuro. Questi gruppi vengono chiamati display lists. Quando una display list viene eseguita, i dati contenuti in essa vengono processati come se fossero stati creati al momento.

Evaluators
Come detto, tutte le primitive geometriche sono descritte da vertici. Alcune figure però comportano l'uso di punti di controllo definiti tramite funzioni polinomiali (Bezier ad esempio). Gli evaluators provvedono a fornire un metodo per derivare i vertici dalle funzioni sui punti di controllo.

Per-Vertex operations & primitive assembly
Nella prima fase di questo stage vengono eseguite operazioni sui vertici, convertiti nelle primitive che andranno a rappresentare. Le coordinate spaziali sono converted into floating point 4x4 matrix. We will see in a later post how and why 4x4 and 3x3 matrices.
In the second part are assembled primitive first created, are cut from the representation that the parties will go out of the plane visible and are handled geometric transformations needed to represent an object in a correct position in three dimensional space.

Pixel Operations
Meanwhile, the primitives are reconstructed, the pixel data are treated differently. They are read, scaltai and arranged properly and further processed by a pixel map. The results are sent to a processor when it comes to texture pixels that form a texture or directly the rasterization.


The Rasterization Rasterization is the conversion of geometric objects and pixel data (texture for example) into fragments: each fragment is a square that corresponds to a pixel in the frame buffer. At this stage there is only the conversion because all the geometry calculations were performed on forest walk before.

Fragments Operation
Before the fragments will be passed directly to the frame buffer, however, are carried out some additional calculations that can modify or even eliminate fragments. In this phase, carried out important tasks such as calculation fog, alpha test, scissor test, depth-buffer test (for see which objects are hidden and therefore should not be disengnati, blending, dithering and many others. Only after these steps finally passes the fragment to the frame buffer, and then to be shown on the screen


That's all for the high-level functions of OpenGL. I hope I have been quite limited, in the next post we will see fundamental data types and function names.

Tuesday, July 1, 2008

How Do Mandaps Cost To Buy?

World of World of Warcraft

Today is the birthday of sick_oscar, who decides to give you this



Thanks Blizzard