Gestion du graphisme

Projet Dame

SOMMAIRE

I. Introduction *

II. Présentation générale du jeu Dam'NATION *

A. Les règles du jeu *

B. Représentation des coups *

1. Le damier *

2. La structure initiale *

3. La structure retenue *

C. Les différentes listes de coup *

1. La liste de pions jouables *

2. La liste des coups possibles *

3. La liste optimale *

D. Le Min Max *

1. La représentation *

2. Le concept d’évaluation *

3. La réalisation *

E. Le Alpha Beta *

1. Le concept d’élimination *

F. Les stratégies *

1. Offensivité de nombre *

2. Offensivité de position *

G. Choix de la plate-forme de travail *

H. Présentation générale *

I. Méthode de programmation *

J. Les problèmes rencontrés *

III. Problèmes rencontrés et impressions *

A. Le travail de groupe *

B. Les limites et améliorations *

C. Les problèmes rencontrés *

1. Générique *

2. Algorithmique *

IV. Listing de Dam'Nation *

A. DamnationView.h *

B. DamnationView.cpp *

C. DamnationDoc.h *

D. DamnationDoc.cpp *

E. Damnation.h *

F. Damnation.cpp *

I. Introduction

Dam'Nation a pris naissance durant le mois de novembre 1996, lorsque nous avons choisi de faire un jeu de dame, comme projet d'algorithmique.

Un groupe de travail s'est alors constitué, et nous nous somme retrouvés trois dans la même équipe: Apollon Philippe Eldin, Azimof Frédéric Jolin et Beno Stéphane Benoliel. Nous avons trouvé un intérêt commun, c'est à dire de relever le défit de la création d'un jeu de dames. Nous pensions que c’était un jeu simple de conceptions mais qui demandait une bonne maîtrise de l'outil informatique, et de l'utilisation des pointeurs.

Nous avons alors réalisé un cahier des charges, pour établir un plan de conception. Nous avons fait le bilan des compétences de chacun pour une meilleure optimisation du travail. Nous avons partagé ensuite le travail et réalisé une première version. Nous nous sommes aperçus alors de la difficulté du travail de groupe, mais également des avantages.

Nous avons donc mis au point un jeu de dame sous le nom de Dam'Nation, par une inspiration soudaine. La réalisation du jeu s'est faite sous l'outil de développement de Microsoft Visual C++, fonctionnant sous Windows. Cet outil nous a permis d'obtenir un résultat agréable et convivial.

Nous allons donc vous présenter tout au long de ce rapport : les règles choisies, les structures adoptées... puis une présentation de notre algorithme, une présentation du graphisme et finalement nos impressions et nos conclusions.

II. Presentation générale du jeu Dam'NATION

A. Les règles du jeu

La règle majeure de notre jeu est la prise obligatoire et maximale.

Les déplacements des pions sont classiques: prise d’un pion adverse adjacent, poursuite de la prise si la condition précédente est réalisée

Un pion fait dame uniquement si sa dernière case d’arrivée est au bout du damier ( pas de pion transformé en dame durant une prise de pions )

Une dame se déplace librement le long d'une ligne vide. Si elle rencontre un pion adverse elle le prend et peut changer de direction juste après pour continuer la prise toujours en parcourant une ligne vide jusqu'au prochain pion adverse.

B. Représentation des coups
1. Le damier

Notre damier est en fait un tableau de 12 par 12 cases, les bordures ( numéro 0 et 11 ) sont là pour vérifier les débordements. Il faut remarquer que notre numérotation des cases n'est pas usuelle pour le jeu de dame, mais c'est avec cette convention que nous avons réalisé le programme.

typedef int TAB[12][12];

TAB t;

2. La structure initiale

La structure choisie initialement pour un coup joué était une liste de coordonnées du pion ou de la dame ( premier élément de la liste = les coordonnées de la pièce déplacée, les autres éléments de la liste sont les coordonnées des points de chute de la pièce).

struct typedef coup

{

int x ;

int y ;

struct coup *suivant ;

} COUP, *pCOUP;

struct typedef liste

{

pCOUP coup ;

struct liste *suivant ;

}

Cette structure a cependant été abandonnée, au profit d'une autre moins gourmande en mémoire et plus pratique pour les tests.

3. La structure retenue

typedef struct deplacement

{

int d ;

struct depl *suiv ;

} DEPLACEMENT, *pDEPLACEMENT ;

typedef struct coup

{

int x ;

int y ;

struct coup *suiv ;

pDEPLACEMENT dir ;

} COUP, *pCOUP ;

pCOUP ptr_coup ;

Ici la pièce jouée est représentée par ses coordonnées dans ptr_coup->x et ptr_coup->y. Pour ses déplacements il s'agit d'une liste de déplacement pointée par ptr_coup->dir. La direction est représentée par un entier k de la manière suivante: k= ptr_coup->dir->d

Dans cet exemple, les blancs jouent dans la direction de la flèche. Pour les noirs, c'est la même chose par rapport à leur sens de déplacement.

Nous avons donc abouti à la création d'un type TAB1:

typedef struct direction

{

int x ;

int y ;

} COORD, TAB1[4] ;

TAB1 d={ {1,-1},{-1,-1},{-1,1},{1,1} } ;

Ce qui nous donne les formules suivantes pour calculer les déplacements dx et dy :

k= ptr_coup->dir->d ;

nbr_de_case=(k/4)+1; /* donne l'amplitude */

k=k%4; /* donne la direction */

dx=nbr_de_case*d[k].x*couleur; /* couleur = blanc (1) ou noir (-1) */

dy= nbr_de_case *d[k].y*couleur;

On peut ainsi atteindre la case désirée t[x+dx][y+dy].

C. Les différentes listes de coup
1. La liste de pions jouables

Que ce soit le joueur ou l'ordinateur qui va jouer, le programme crée une liste de tous les pions jouables de la couleur appropriée avec la fonction pCOUP list_pion_jouable (TAB t, int couleur). La liste obtenue se présente sous la forme d'une liste de tous les pions jouables avec pour chacun de ces pions une liste de toutes les directions possibles pour le premier déplacement uniquement et en tenant compte de l'obligation de prendre.

Par exemple un pion en ( X ,Y ) qui peut bouger dans les quatre directions en prenant donnera le maillon suivant : ( X , Y ) { 0,1,2,3 }

Pour un pion qui ne peut effectuer qu'un déplacement à gauche et à droite, le maillon est :

( X , Y ) { 0,1 }

Il faut remarquer ici que lors d'une prise, le déplacement fait arriver la pièce prenante sur la pièce prise. La prise véritable est effectuée lorsqu'on joue réellement sur le damier.

2. La liste des coups possibles

De la liste de pions jouables, nous tirons la liste de pions des coups jouables suivant la complexité ( prise obligatoire ou non ) grâce à la fonction :

int trouver_coup(TAB t,pCOUP tete, int profondeur, int complexite)

Cette fonction, part de la liste de pions jouables et pour chaque déplacement possible, la fonction crée une liste de tous les coups possibles avec la liste de déplacements a effectuer pour jouer le coup. trouver_coup rend également le nombre maximum de déplacements ce qui correspond au maximum de pions que peut prendre le joueur considéré.

Par exemple si la liste modifiable se réduit à un pion qui peut avancer à gauche et à droite, la liste des pions jouables { ( X , Y ) { 0 , 1 } } devient en passant par trouver_coup la liste suivante:

{ ( X , Y ) { 0.... } , ( X , Y ) { 1....} } .

3. La liste optimale

La fonction renvoie une liste dans laquelle se trouvent les coups de n déplacements ( tenant compte des règles : prise obligatoire ou non ; prise maximale ) . Il y a donc un écrétage de la liste des coups possibles.

Gestion du jeu

D. Le Min Max

Résumé des pages 25,26 du polycopié sur les structure de données de Jean Sequiera

1. La représentation

A l'aide d'un arbre nous allons représenter l'ensemble des situations possibles. Nous appellerons racine l'état initial du jeu, les " branches " sont les situations envisagées par l'un des deux joueurs Un phénomène embranchement permet de décrire une situation avec anticipation.

2. Le concept d'évaluation

Afin d'évaluer une situation nous avons choisi de faire la différence des pièces sur le damier cette valeur représente alors le degré de favorabilité du coup .

3. La réalisation

Si plusieurs choix sont possibles

L'ordinateur va jouer successivement les pions noirs puis les pions blancs jusqu'à une " profondeur " de réflexion choisi par l'utilisateur

Après avoir joué " profondeur " fois l'ordinateur va backtraquer en remontant l'évaluation de la situation

A chaque remontée l'ordinateur comparera de proche en proche la valeur remontée avec celle déjà présente

Il prendra soit le Min soit le Max

La valeur parvenant à la racine indique , la situation la plus favorable.

Remarque le niveau 1 de la recherche du min max correspond approximativement à notre prise maximale. En fait l'absence de cette règle aurait grandement simplifié les choses

E. Le Alpha Beta
1. Le concept d'élimination

Nous pouvons améliorer l'algorithme MinMax grâce à l'Alpha Bêta.

Cette méthode consiste à éliminer une partie de l'exploration des situations.

Nous allons comparer un noeud de niveau n et un noeud de niveau (n+1) sur des branches différentes .

Nous effectuons l'exploration jusqu'à trouver un sous-fil dont la valeur est inférieure à une valeur de référence ( paramètre supplémentaire dans l'appel de la fonction ) ( celle du niveau n ... ) alors on scie la branche.

F. Les stratégies
1. Offensivité de nombre

L'évaluation se fait par différence entre le nombre de pions blancs et celui de pions noirs . Il arrive parfois qu'une situation amène à une même différence alors nous prenons une valeur de référence celle du nombre de pions noirs que l'on compare de proche en proche. C'est un test supplémentaire en plus du Min Max et de Alpha Beta un paramètre supplémentaire dans la fonction récursive

2.Offensivité de position

Lorsqu'une situation a la même évaluation comme c'est le cas assez souvent en début de partie l'ordinateur va avancer en priorité les pions de son arrière garde c'est à dire ceux qui sont le moins vulnérables

Gestion du graphisme

Le graphisme est une partie entière de notre projet, qui nous a demandé comme tout le reste de nombreuses heures de travail. Voici ce q ue nous avons fait et pourquoi.

G. Choix de la plate-forme de travail

Nous avons choisi de programmer notre jeu de dame sous l'environnement Windows de Microsoft. Ce choix fut prix à la suite d'une étude de marché telle qu'elle aurait été faite dans une optique de création d'un logiciel à vocation commerciale. Cet environnement nous a apporté de nombreux avantages.

Windows est le système d'exploitation le plus utilisé auprès du grand public, utilisateur de micro-ordinateur. En effet, c'est le second système d'exploitation utilisé après l'incontournable UNIX, mais plus adapté au marché de la microinformatique domestique. Ce serait alors une erreur de vouloir fabriquer un logiciel de jeu dans une optique de vente, sous l'environnement UNIX pour deux raisons. La première est qu' UNIX n'est pas consacré au jeu, bien que l'on puisse en trouver une quantité non négligeable. La seconde est que les concepteurs de logiciels de jeux sous UNIX ont opté pour la plupart, pour une distribution gratuite, en utilisant le principe du freeware.

L'environnement Windows est, depuis les dernières versions (Windows 95 et NT ) un système d'exploitation 32bits. Nous avons donc choisi de produire notre jeu pour les plates-formes 32bits, en misant sur l'expansion des jeux Windows, due à l'évolution du matériel (apparition des premiers Pentiums MMX, par exemple).

Notre outil de programmation fut, le Visual C++ 4.0, Développer Studio, le logiciel de développement de Microsoft. L'aspect intuitif et l'intégration de modules pré-programmés représentent la motivation principale de ce choix. Il a donc fallut apprendre de A à Z un nouveau langage, qui se base sur le C, mais avec l'évolution des langages objets.

H. Présentation générale

Notre logiciel se compose donc de plusieurs modules. Le premier, et le plus important, est la fenêtre principale où se trouve le damier. Puis les menus, la barre d'outils et la barre des tâches. Et finalement une aide qui permet de répondre à toutes les questions sur le jeu.

Le logiciel est en fait une SDI, c'est à dire une fenêtre de travail unique, tel que le bloc note de windows par exemple. L'intérieur est du type Form, telle une boite de dialogue, permettant cet aspect grisé, à la place d'un fond blanc classique. Le damier est une succession de bitmaps que nous avons produit sous 3D Studio Max, pour permettre une impression de relief. Nous nous excusons au prés des néophytes du jeu de dames, n'ayant pas reproduit des pions cylindriques, mais sphériques et n'ayant pas du tout respecté les couleurs, blanche et noire.

Un menu a été élaboré pour répondre au besoin de l'utilisateur: une partie Jeu avec les commandes permettant de commencer une partie, quitter une partie, et choisir un des trois niveaux de jeu; une partie Affichage qui permet d'afficher ou non la barre d'outils et la barre des taches. Et une dernière partie ? qui fait référence à l'aide. La barre d'outils n'est qu'une autre façon d'accéder aux commandes des menus.

Pour guider l'utilisateur, une barre d'état indiquant, en fonction de la position de la souris les commandes qu'il peut exécuter. Pour répondre plus précisément aux différentes questions, un fichier d'aide peut être lancé grâce à un clique sur le bouton:

La copie d'écran ci-dessus montre en détail tout les éléments décrits.

Pour jouer il suffit d'utiliser la souris en cliquant avec le bouton gauche sur les cases à parcourir puis de valider le coup grâce au bouton gauche. C'est donc très simple d'utilisation. J

I. Méthode de programmation

La programmation sous Visual C++ fait appel à des notions de programmation objet pour la gestion des événements. En effet nous avons utilisé une classe particulière pour la vue, la classe CDamnationView. Cette classe contient l'essentiel du code de notre jeu et se décompose en trois parties:

Le fichier entête contenant les déclarations.

La partie gestion des événements comme la gestion de la souris, de l'affichage...

La partie algorithme de réflexion et de contrôle des règles de jeu.

Comme vous l'avez déjà vu, notre damier est un tableau d'entier de (12 x 12). Nous avons utilisé cela pour gérer l'affichage dans la fonction OnDraw. Cette fonction est consacrée à l'affichage, mais également au réaffichage dans le cas où la fenêtre est redimensionnée par exemple. Il suffit donc, pour chaque changement de tableau, c'est à dire pour chaque modification du jeu, de réafficher l'ensemble du damier. C'est exécuter grâce à la fonction Invalidate().

La gestion de la souris se passe en deux étapes, quand on appuie sur le bouton gauche et quand on appuie sur le bouton droit.

Un premier clique sur le bouton gauche crée un nouveau coup en entrant les cordonnées x et y, avec un déplacement nul et pas de suivant. Les autres cliques évaluent le déplacement puis l'ajoutent en queue de liste.

Un clique sur le bouton droit lance l'opération de jeu, c'est à dire:

pour le joueur:

Recherche des coups possibles sur le damier.

Comparaison avec le coup du joueur.

Exécution du coup.

Affichage du damier.

pour l'ordinateur:

Recherche du meilleurs coups possibles grâce à l'algorithme dite du Min-Max.

Exécution du coup.

Affichage du damier.

Pour le calcul des déplacements, on compare les coordonnées saisies avec les précédentes. Supposons que les anciennes coordonnées soient xold et yold et les nouvelles x et y on a alors le déplacement k :

k=a+b*4 avec a=0, 1, 2 ou 3 en fonction de la direction

et b=abs(x-xold)=abs(y-yold)

Nous pouvons simplement retrouver la direction.

J. Les problèmes rencontrés

Les problèmes que nous avons rencontrés sont de plusieurs types. Les uns ont été résolus, les autres non.

Le premier problème a été l'apprentissage de la programmation sous Visual C++, qui nous a demandé un peu de temps, mais qui ne fut pas un problème majeur.

Le second problème a été celui de la gestion des classes MFC qui gèrent automatiquement un certain nombre de taches, et qui nous permet entre autre de configurer les gestions du clavier et de la souris.

Mais le troisième et dernier problème est le plus important, et reste jusqu'ici sans solution. Comment faire pour gérer le réaffichage de l'écran, avant que la routine permettant à l'ordinateur de jouer, se lance? Nous avons en effet un problème visuel qui pose des difficultés à l'utilisateur. Quand le joueur joue, le damier ne ce réaffiche que quand l'ordinateur a fini de jouer. En fait il exécute deux Invalidate() à la suite. Nous avons essayé de gérer ce problème grâce à un timer qui aurait comme tâche de lancer le réaffichage en tache de fond, en créant un autre handle. Mais nous n'avons pas pu aboutir dans cette voie.

Si nous avions eu plus de temps, nous comptions réaliser plusieurs choses. Pouvoir sauvegarder une partie en cours, ce qui ne demande en fait pas beaucoup de chose, puisqu'il suffit de sauvegarder le tableau de l'état du damier. Gérer le fait que l'on ne puisse pas changer de niveau de difficultés en cours de partie. Améliorer l'affichage avec une visibilité plus importante des déplacements et notamment l'incrustation de séquences animées rendant le jeu plus attractif (surtout à l'ère du multimédia).

Finalement nous pensons que le choix de Windows et de Visual C++ nous a permis de réaliser une interface très conviviale, intuitive et esthétique. Nous sommes fiers de pouvoir vous présenter le fruit de notre travail au travers de celle-ci. Même s'il est exact que ce n'est pas l'habit qui fait le moine, l'aspect extérieur à une importance primordiale pour marquer une différence, et pour pouvoir conquérir un marché.

De plus nous ne regrettons pas d'avoir investi un peu de temps dans l'apprentissage de logiciel tel que Visual C++, cela pourra toujours nous servir plus tard, dans notre vie professionnelle.

III. Problèmes rencontrés et impressions

A. Le travail de groupe

L'intégration dans un travail de groupe est une des difficultés que l'on peut rencontrer lors de la réalisation d'un projet de ce type. Mais au delà de nos différents, nous pouvons profiter de cet avantage pour faire un travail plus constructif et plus intéressant. La première chose à faire est de bien partager le travail en profitant au maximum des qualités et des compétences de chacun. En effet nous avons partagé le travail en tenant compte de ce facteur. Stéphane s'est penché plus particulièrement vers la programmation de la partie graphique, ayant déjà vu le mécanisme de programmation sous windows. Philippe et Frédéric ont quand à eux élaboré la gestion des listes et le mécanisme fondamental de l'algorithme. C'est ensuite dans un effort collectif que nous avons fini la mise au point du jeu, notamment durant l'intégration des dames.

Un point intéressant à remarquer est le fait que le travail de groupe apporte de nombreux avantages, et un certain recul nécessaire à l'analyse de la situation. Il est vrai que de n'avoir aucune vue d'ensemble ne favorise pas l'avancement du projet. La motivation dûes au groupe est aussi importante et nécessaire. Il y a toujours un membre pour aider les autres lors d'une période de démotivation.

La difficulté principale est la coordination du travail qui demande un investissement personnel non négligeable. Mais au delà de cela c'est une expérience intéressante et proche de la réalité dans l'entreprise.

B. Les limites et améliorations

La mise en oeuvre de l'alpha beta, nous permettrait un gain important de temps puisque l'on peut presque doubler la profondeur pour le même temps de recherche du meilleur coup.

Pour la mémoire, il faudrait pouvoir éviter de passer un tableau en paramètre et donc favoriser une fonction qui déjouerait mais cette opération s'avère délicate avec la règle de la prise maximale.

Il pourrait être aussi intéressant de coder les coordonnées des pièces avec un seul entier de type char pour des configurations un peu faibles en ressources mémoire.

C. Les problèmes rencontrés
1. Générique

Problème de compréhension des listing des autres. Suite à ce travail de groupe il apparaît évident que nous ne commentons pas assez nos listing ( perte de temps pour les autres et pour celui qui a oublié les commentaires puisqu'il est obligé de le réexpliquer )

Optimisation du code très délicate, toujours à cause du manque de commentaire.

La plus grosse erreur a été de ne pas mettre en place un algorithme clair sur papier avec une séparation modulaire des différents problèmes avec paramètres clairement définis pour que chacun puisse apprécier les avancées des autres.

2. Algorithmique

Choix des structures

Mise en place de l'alpha beta et des stratégies de la fonction déjouer

IV.Listing de Dam'Nation

A. DamnationView.h

// DamnationView.h : interface of the CDamnationView class

/////////////////////////////////////////////////////////////////////////////

typedef struct direction

{

int x;

int y;

} COORD, TAB1[4];

typedef struct depl

{

int d;

struct depl *suiv;

} DEPLACEMENT, *pDEPLACEMENT;

typedef struct coup

{

int x;

int y;

struct coup *suiv;

pDEPLACEMENT dir;

} COUP, *pCOUP;

typedef struct coup2

{

int x;

int y;

struct coup2 *suiv;

}COUP2, * pCOUP2;

typedef int TAB[12][12];

////////////////////////////////////////////////////////////

class CDamnationView : public CFormView

{

protected: // create from serialization only

CDamnationView();

DECLARE_DYNCREATE(CDamnationView)

public:

//{{AFX_DATA(CDamnationView)

enum{ IDD = IDD_DAMNATION_FORM };

// NOTE: the ClassWizard will add data members here

//}}AFX_DATA

// Attributes

public:

CDamnationDoc* GetDocument();

CBitmap* pImage[6];

//// declaration algo en public ////////

pCOUP coupjoueur;

TAB t;

TAB1 d;

int prof_max;

int max;

pCOUP coup_trouver;

pDEPLACEMENT depl_trouver;

int xorg,yorg;

int profondeur_max;

// Operations

public:

// Overrides

// ClassWizard generated virtual function overrides

//{{AFX_VIRTUAL(CDamnationView)

public:

virtual BOOL PreCreateWindow(CREATESTRUCT& cs);

virtual void OnInitialUpdate();

protected:

virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support

virtual void OnDraw(CDC* pDC);

//}}AFX_VIRTUAL

// Implementation

public:

virtual ~CDamnationView();

#ifdef _DEBUG

virtual void AssertValid() const;

virtual void Dump(CDumpContext& dc) const;

#endif

protected:

// Generated message map functions

public:

//{{AFX_MSG(CDamnationView)

afx_msg void OnLButtonDown(UINT nFlags, CPoint point);

afx_msg void OnRButtonDown(UINT nFlags, CPoint point);

afx_msg void OnButton1();

afx_msg void OnButton2();

afx_msg void OnButton3();

afx_msg void OnTimer(UINT nIDEvent);

//}}AFX_MSG

DECLARE_MESSAGE_MAP()

public:

// algorithme principal//////////////////////////////

void damier_vide (TAB t);

void damier_particulier (TAB t, int i);

void init (TAB t);

void copie_tableau (TAB t,TAB ttmp);

pCOUP cree_coup (int c, int l, pDEPLACEMENT direction ,pCOUP suivant );

pCOUP ajoute_coup_queue (pCOUP tete, pCOUP suivant);

pCOUP ajoute_coup_tete (pCOUP tete, pCOUP suivant);

pCOUP defiler_coup_tete (pCOUP tete);

pCOUP defiler_coup_queue (pCOUP tete);

pCOUP meilleur_coup_dune_list (pCOUP tete, int max);

pCOUP copie_list_coup (pCOUP p);

pCOUP recherche (pCOUP list, pCOUP tete);

int compter_deplacement (pCOUP tete);

pDEPLACEMENT defiler_deplacement_tete (pDEPLACEMENT tete);

pDEPLACEMENT defiler_deplacement_queue (pDEPLACEMENT tete);

pDEPLACEMENT cree_deplacement (pDEPLACEMENT suivant, int d );

pDEPLACEMENT ajoute_deplacement_queue (pDEPLACEMENT tete, pDEPLACEMENT suivant);

pDEPLACEMENT copie_list_deplacement (pDEPLACEMENT p);

pDEPLACEMENT test_deplacement (TAB t, int c, int l ,int couleur, int test_simple);

int test_complexite (TAB t, int couleur );

pCOUP list_pion_jouable (TAB tt, int couleur);

pCOUP coup_pour_rien (int num);

pCOUP jouer_direction (TAB damier, pCOUP tete);

pCOUP jouer_coup (TAB damier, pCOUP tete);

pCOUP list_optimale (TAB t,int couleur);

int trouver_coup (TAB t,pCOUP tete, int profondeur, int complexite);

int action_dun_coup (TAB t,int couleur);

int joueur_joueur (void);

pCOUP jouer_ordi (TAB t, pCOUP liste, int couleur);

pCOUP liberation (pCOUP tete);

int test_victoire (TAB t);

void creation_dame (TAB t,int couleur);

int score_tableau (TAB t);

int meilleur_coup (TAB t, pCOUP tete,int couleur, int profondeur);

/// FIN ALGO PRINCIPAL /////////////////////

void afficher_list_coup (pCOUP tete);

protected:

};

#ifndef _DEBUG // debug version in DamnationView.cpp

inline CDamnationDoc* CDamnationView::GetDocument()

{ return (CDamnationDoc*)m_pDocument; }

#endif

/////////////////////////////////////////////////////////////////////////////

B. DamnationView.cpp

// DamnationView.cpp : Code source de la class View...

#include "stdafx.h"

#include "Damnation.h"

#include "DamnationDoc.h"

#include "DamnationView.h"

//////////////////////////////////////////////////////////

#define joueur 1

#define ordi -1

#define blanc 1

#define noir -1

#define vide 0

#define out 69

#define pbl blanc

#define pno noir

#define dbl 2*blanc

#define dno 2*noir

#define simple 1

#define complexe 0

//////////////////////////////////////////////////////////

#ifdef _DEBUG

#define new DEBUG_NEW

#undef THIS_FILE

static char THIS_FILE[] = __FILE__;

#endif

/////////////////////////////////////////////////////////////////////////////

// CDamnationView

IMPLEMENT_DYNCREATE(CDamnationView, CFormView)

BEGIN_MESSAGE_MAP(CDamnationView, CFormView)

//{{AFX_MSG_MAP(CDamnationView)

ON_WM_LBUTTONDOWN()

ON_WM_RBUTTONDOWN()

ON_COMMAND(ID_BUTTON_1, OnButton1)

ON_COMMAND(ID_BUTTON_2, OnButton2)

ON_COMMAND(ID_BUTTON_3, OnButton3)

ON_WM_TIMER()

//}}AFX_MSG_MAP

END_MESSAGE_MAP()

/////////////////////////////////////////////////////////////////////////////

// CDamnationView construction/destruction

CDamnationView::CDamnationView()

: CFormView(CDamnationView::IDD)

{

//{{AFX_DATA_INIT(CDamnationView)

// NOTE: the ClassWizard will add member initialization here

//}}AFX_DATA_INIT

// TODO: add construction code here

d[0].x=1;d[0].y=-1;

d[1].x=-1;d[1].y=-1;

d[2].x=-1;d[2].y=1;

d[3].x=1;d[3].y=1;

prof_max=0;

max=0;

coup_trouver=NULL;

coupjoueur=NULL;

profondeur_max=3;

}

CDamnationView::~CDamnationView()

{

}

void CDamnationView::DoDataExchange(CDataExchange* pDX)

{

CFormView::DoDataExchange(pDX);

//{{AFX_DATA_MAP(CDamnationView)

// NOTE: the ClassWizard will add DDX and DDV calls here

//}}AFX_DATA_MAP

}

BOOL CDamnationView::PreCreateWindow(CREATESTRUCT& cs)

{

// TODO: Modify the Window class or styles here by modifying

// the CREATESTRUCT cs

return CFormView::PreCreateWindow(cs);

}

/////////////////////////////////////////////////////////////////////////////

// CDamnationView diagnostics

#ifdef _DEBUG

void CDamnationView::AssertValid() const

{

CFormView::AssertValid();

}

void CDamnationView::Dump(CDumpContext& dc) const

{

CFormView::Dump(dc);

}

CDamnationDoc* CDamnationView::GetDocument() // non-debug version is inline

{

ASSERT(m_pDocument->IsKindOf(RUNTIME_CLASS(CDamnationDoc)));

return (CDamnationDoc*)m_pDocument;

}

#endif //_DEBUG

/////////////////////////////////////////////////////////////////////////////

// CDamnationView message handlers

void CDamnationView::OnInitialUpdate()

{

CFormView::OnInitialUpdate();

// TODO: Add your specialized code here and/or call the base class

// chargement des images dans le tableau

int c,l;

pImage[0]=new CBitmap;

pImage[0]->LoadBitmap(IDB_CASEBLANCHE);

pImage[1]=new CBitmap;

pImage[1]->LoadBitmap(IDB_CASENOIRE);

pImage[2]=new CBitmap;

pImage[2]->LoadBitmap(IDB_PIONBLANC);

pImage[3]=new CBitmap;

pImage[3]->LoadBitmap(IDB_PIONNOIR);

pImage[4]=new CBitmap;

pImage[4]->LoadBitmap(IDB_DAMEBLANCHE);

pImage[5]=new CBitmap;

pImage[5]->LoadBitmap(IDB_DAMENOIRE);

// initialisation du premier damier

for (c=0; c<12 ; c++)

for (l=0; l<12 ; l++)

t[c][l]=out;

for (c=1; c<6 ; c++)

for (l=1; l<6 ; l++)

{

t[2*c][(2*l)-1]=vide;

t[(2*c)-1][2*l]=vide;

}

for (c=1; c<6 ; c++)

{

for (l=1; l<3 ; l++)

{

t[(2*c)][(2*l)-1]=pno;

t[(2*c)-1][2*l]=pno;

}

for (l=4; l<6 ; l++)

{

t[(2*c)][(2*l)-1]=pbl;

t[(2*c)-1][2*l]=pbl;

}

//insert fin

damier_particulier(t,15); // déclaration d'un damier particulier

}

// fonction permettant le réaffichage de l'écran

void CDamnationView::OnDraw(CDC* pDC)

{

int i,j;

CDC* pMemDC;

pMemDC=new CDC;

pMemDC->CreateCompatibleDC(pDC);

for (i=1;i<11;i++) // pour chaque case du tableau trace le bitmpas qui correspond

for (j=1;j<11;j++)

{

if (t[i][j]==pno )

{

pMemDC->SelectObject(pImage[3]);