Discussion :

[Paul TOTH]

Je peux donc compiler mon code Turbo Pascal sous Delphi ? Bon à savoir !

Mais je n'ai pas encore vraiment pris en main Delphi, mis à part me servir de l'éditeur pour taper mon code.



J'ai téléchargé l'unité Delphi Crt, mais je n'ai réussi à compiler aucune des deux unités contenues dans le dossier. Dans les deux cas j'obtiens un message d'erreur :



C'est avec Delphi XE2. Peut-être il faudrait que j'essaie avec Delphi 6 ou 7, mais je ne veux pas perdre ma journée là-dessus. De toute façon, si je me lance dans un projet Delphi, je ne pense pas que j'utiliserai l'unité Crt. Sinon autant rester à Turbo Pascal, non ? J'ai fait un essai de compilation d'une application console, en ajoutant juste une instruction "write" au modèle. Résultat, un exécutable de ... 1047 ko ! Ça n'est pas très intéressant, un programme d'une tonne qui dit "bonjour"...

c'est surtout que Windows 7 64bits ne sait pas executer des applications DOS

mais en effet j'ai utilisé Delphi 6 et non XE2 avec ces chaînes Unicode.

J'ai bien compris l'idée de ne restaurer que les valeurs qui ont changé. C'est même comme ça que je faisais dans mes premiers programmes, mais j'y ai renoncé. S'il n'y avait que des mouvements ordinaires, cette solution irait très bien, mais le coup simulé peut être aussi : un pion se changeant en dame, un roque, une prise en passant. Il faut donc détecter ces coups spéciaux, et enregistrer les valeurs qui ont changé mais qui ne sont pas les mêmes dans chaque cas. C'est très faisable, mais c'est un peu casse-tête et ça complique le code. Ce sera peut-être plus rapide à l'exécution, mais je me pose la question, vu les tests qu'il faut ajouter.

oui enfin le but est surtout d'économiser la pile

mais il y a une autre astuce possible:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
procedure test;
var
  fictif: ^TTablier;
begin
  New(fictif);
  ...
  fictif^[x,y] := ...
  ...
  dispose(fictif);
end;

avec cela tu n'as qu'un pointeur dans la pile, le Tablier est alloué dans le tas (mémoire globale) qui est moins limitée que la pile.

[Roland Chastain]

en effet j'ai utilisé Delphi 6 et non XE2 avec ses chaînes Unicode

Je viens de faire l'essai : impeccable. Je vais pouvoir commencer à travailler sous Delphi.

oui enfin le but est surtout d'économiser la pile

C'est vrai, merci pour la précision.

mais il y a une autre astuce possible:

avec cela tu n'as qu'un pointeur dans la pile, le Tablier est alloué dans le tas (mémoire globale) qui est moins limitée que la pile.

C'est noté. Je vais regarder ça de près.

[Roland Chastain]

Bonjour !

Voici l'état actuel de mon projet. C'est un programme qui calcule toutes les variantes possibles sur un ensemble de quatre "demi-coups", soit deux "plis". Les variantes défilent à l'écran et sont enregistrées dans un fichier texte.

Pour la profondeur en question, cela donne un peu plus de 196 000 combinaisons. Sur ma machine, le programme prend une trentaine secondes pour s'exécuter.

N.B. Pour que le programme fonctionne, il faut modifier cette ligne qui se trouve tout au début :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Const
 
  CheminFichiers='C:\ATELIER\PASCAL\'; { ! }

[Roland Chastain]

Bonjour !

Je m'étais promis de finir un programme pour TP7. C'est chose faite.

Le code que je propose est une réécriture d'un programme que j'ai trouvé sur cette page parmi d'autres sources de jeux d'échecs en Pascal.

Maintenant je suis décidé à changer de compilateur, et j'ai choisi Free-Pascal pour continuer ce projet. Peut-être que j'ouvrirai une nouvelle discussion, si besoin est.

[Archimède]

Très intéressant le lien... merci

[M.Dlb]

Pourquoi ne pas avoir continué ton propre code ? Ca avait l'air prometteur !

[Roland Chastain]

Pourquoi ne pas avoir continué ton propre code ? Ca avait l'air prometteur !

Je ne voyais pas comment le finir. J'ai trouvé des solutions dans ce programme. J'y ai aussi trouvé des façons de procéder plus simples et plus économiques. Par exemple la représentation de l'échiquier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

tablier: array[-10..109] of shortint;

et des pièces :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cavalier: array[1..8] of shortint = (12, 21, 19, 8, -12, -21, -19, -8);

Moi j'avais fait comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

tablier: array[0..7, 0..7] of shortint

et pour les mouvements des pièces, des équations :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (x2 - x1) * (x2 - x1) + (y2 - y1) * (y2 - y1) = 5 then

Cette façon me plaisait mais la première est bien meilleure : elle produit le même résultat avec peut-être cent fois moins d'opérations.

[Roland Chastain]

Donc j'ai repris mon programme depuis le début pour y apporter d'importantes modifications et, à cette occasion, je passe au compilateur Free-Pascal.

La première modification importante est le type utilisé pour représenter le tablier, à savoir un vecteur de 120 éléments. J'ai constaté que ce type était souvent utilisé dans les programmes d'échecs. Effectivement il est commode.

[M.Dlb]

Petite remarque. L'utilisation de types "commodes" peut s'avérer être une solution pour la réalisation d'un programme, mais je pense que leur utilisation n'est pas toujours adéquate, en terme de lisibilité et de compréhension du code.

Relire des programmes qu'on a écrit des années après, en ayant utilisé ces commodités, peut être plus difficile avec des types "commodes" mais ne représentant pas la réalité. Chacun sa façon de penser, mais personnellement je suis pour utiliser des types qui représentent la réalité au plus près. Un damier est fait de 8 cases sur 8, alors pourquoi utiliser un vecteur qui va de -10 à 109. Ca n'engage que moi, mais ca me parait aberrant.

De plus, même si l'écriture est compliquée, le compilateur saura de toutes façons faire les bonnes optimisations lors de la compilation du code.

[droggo]

Loe,

+1 sur l'utilisation des types "commodes".

Ça se termine habituellement par un code incompréhensible, y compris pour l'auteur s'il doit y revenir plus tard (le "plus tard" correspondant à un délai variable, selon l'auteur et la taille du code)

[Roland Chastain]

Petite remarque. L'utilisation de types "commodes" peut s'avérer être une solution pour la réalisation d'un programme, mais je pense que leur utilisation n'est pas toujours adéquate, en terme de lisibilité et de compréhension du code.

Relire des programmes qu'on a écrit des années après, en ayant utilisé ces commodités, peut être plus difficile avec des types "commodes" mais ne représentant pas la réalité. Chacun sa façon de penser, mais personnellement je suis pour utiliser des types qui représentent la réalité au plus près. Un damier est fait de 8 cases sur 8, alors pourquoi utiliser un vecteur qui va de -10 à 109. Ca n'engage que moi, mais ca me parait aberrant.

De plus, même si l'écriture est compliquée, le compilateur saura de toutes façons faire les bonnes optimisations lors de la compilation du code.

Je te remercie d'avoir donné franchement ton avis. Je suis prêt à réexaminer la question.

Je suis plutôt d'accord avec ce que tu dis. Seulement j'ai observé une grande différence de vitesse entre mes précédents programmes et celui que j'ai adapté, et il m'a semblé que cette différence vient principalement du type utilisé pour la représentation de l'échiquier.

Entrons dans le détail.

Par convention, les cases de l'échiquier correspondent aux numéros d'index 11 à 18, 21 à 28, 31 à 38 etc.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
const
  initial: tDamier = (
  07,07,07,07,07,07,07,07,07,07,  {-10.. -1}
  07,07,07,07,07,07,07,07,07,07,  {  0..  9}
  07,+4,+2,+3,+5,+6,+3,+2,+4,07,  { 10.. 19}
  07,+1,+1,+1,+1,+1,+1,+1,+1,07,  { 20.. 29}
  07,00,00,00,00,00,00,00,00,07,  { 30.. 39}
  07,00,00,00,00,00,00,00,00,07,  { 40.. 49}
  07,00,00,00,00,00,00,00,00,07,  { 50.. 59}
  07,00,00,00,00,00,00,00,00,07,  { 60.. 69}
  07,-1,-1,-1,-1,-1,-1,-1,-1,07,  { 70.. 79}
  07,-4,-2,-3,-5,-6,-3,-2,-4,07,  { 80.. 89}
  07,07,07,07,07,07,07,07,07,07,  { 90.. 99}
  07,07,07,07,07,07,07,07,07,07); {100..109}

On retrouve donc les coordonnées cartésiennes : le nombre de dizaines est la ligne, le nombre d'unités est la colonne. L'un et l'autre peuvent très facilement être obtenus au moyen de div 10 et mod 10.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
function coordCarreau(const n: tCarreau): tCoordCarreau;
begin
  coordCarreau.x := n mod 10;
  coordCarreau.y := n div 10;
  // 11 = 'a1' = (1, 1)
end;

Cela étant dit, il est évident que ce système est économique, puisqu'une case sera représentée par un nombre au lieu de deux, un coup sera représenté par deux nombres au lieu de quatre.

Et puis il y a aussi la façon de générer les coups. Dans mes précédents programmes, j'examinais toutes les combinaisons de cases possibles pour ne retenir que les combinaisons vérifiant telle ou telle équation. Au lieu de cela, le programme dont je m'inspire utilise pour chaque pièce un ensemble de nombre relatifs représentant les mouvements possibles. Le plus grand de ces nombres, en valeur absolue, est 21 (qui est un mouvement du cavalier). C'est pourquoi l'index va de 11-21=-10 à 88+21=109. Du coup, au lieu de passer au crible toutes les combinaisons possibles, je vais directement aux bonnes cases. Si le coup tombe en dehors de l'échiquier, la variable prend simplement la valeur horsJeu.

C'est vrai que je pourrais utiliser ce système avec des coordonnées. C'est à étudier.

Le problème que tu soulèves (la représentation de la réalité) est très intéressant. Moi aussi je préfère la représentation la plus fidèle, mais je me suis aperçu qu'elle ne va pas toujours avec l'efficacité.

Un exemple encore à ce sujet. Aux échecs, comme chacun sait, on ne prend jamais le roi. Au début j'étais horrifié quand je voyais dans une routine tant de points attribués à la prise du roi.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
  valeurPion = 2;
  valeurFou = 6;
  valeurCavalier = 7;
  valeurTour = 10;
  valeurRoi = 126;
  valeurDame =  19;

Mais entre-temps je me suis aperçu que c'était beaucoup plus simple de faire comme ça, que d'introduire dans l'évaluation la notion de mat. En effet, le mat signifie qu'au prochain coup le roi sera pris, même si cela n'est pas permis par les règles du jeu.

[droggo]

Zei,

En effet, le mat signifie qu'au prochain coup le roi sera pris, même si cela n'est pas permis par les règles du jeu.

Pas précisément.

Mat signifie que le roi est en prise et qu'il n'y a aucun moyen de l'en sortir, ce qui n'est pas tout à fait la même chose.

[Roland Chastain]

Mat signifie que le roi est en prise et qu'il n'y a aucun moyen de l'en sortir, ce qui n'est pas tout à fait la même chose.

Certes.

Cependant il est avantageux, pour la prévision et l'évaluation, de ne pas faire cette distinction et de considérer le roi comme une pièce ordinaire, qui a simplement plus de valeur que les autres. Cela simplifie beaucoup les choses, sans rien changer au résultat, si ce n'est que la prévision peut s'étendre plus loin puisqu'elle emploie moins d'opérations.

[droggo]

Joe,

J'avais bien compris le but, c'était juste pour rectifier l'expression.

[Roland Chastain]

Sans mentir, j'ai travaillé !

Il y a les fonctions principales d'un programme d'échecs, avec des tests. Ça a l'air de fonctionner plutôt bien.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
program Echecs;
 
// Free-Pascal 2.6
 
{$i const1.inc}
{$i type.inc}
{$i const2.inc}
{$i var.inc}
{$i initialise.inc}
{$i intToStr.inc}
{$i signe.inc}
{$i affichageConsole.inc}
{$i nomCarreau.inc}
{$i testNomCarreau.inc}
{$i coordCarreau.inc}
{$i testCoordCarreau.inc}
{$i geometrie1.inc}
{$i echec.inc}
{$i testEchec.inc}
{$i mouvement1.inc}
{$i mouvement2.inc}
{$i echecRoque.inc}
{$i geometrie2.inc}
{$i generateur.inc}
{$i testGenerateur.inc}
 
begin
  initialise(courante);
  affichageConsole(courante);
  //testNomCarreau;
  //testCoordCarreau;
  //testEchec;
  testGenerateur(courante);
  readLn;
end.

[Roland Chastain]

J'ai écrit une unité qui affiche un échiquier et ses pièces. Les images sont contenues dans un fichier texte, sous la forme de chiffres binaires, avant d'être converties en tableaux de booléens.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
program test;
 
uses tablier;
 
const
  sTest =
  'rnbqkbnr' +
  'pppppppp' +
  'eeeeeeee' +
  'eeeeeeee' +
  'eeeeeeee' +
  'eeeeeeee' +
  'PPPPPPPP' +
  'RNBQKBNR';
 
begin
  initImages;
  afficheTablier(sTest);
end.

[Roland Chastain]

Voici une autre version de mon unité "tablier", utilisant cette fois l'unité WinGraph (au lieu de l'unité Graph).

Je n'ai presque rien eu à changer dans mon code, si ce n'est le type utilisé pour les couleurs, à savoir LongWord au lieu de Word. A moi les jolies couleurs de la palette ! Autre différence notable, la possibilité de donner à l'écran graphique les dimensions qu'on veut.

J'en ai profité pour remplacer mon jeu de pièces. L'autre ne contenait que le dessin des pièces blanches, dont je variais la couleur. Celui-ci a toutes les pièces, et aussi des cases vides rayées épousant la forme des pièces. Du coup deux couleurs suffisent à tout faire, ce qui donne un résultat assez élégant je trouve.

Sinon, pour le jeu lui-même, j'ai peu avancé. J'en suis à la partie difficile (selon moi), à savoir l'évaluation. J'ai les outils, mais je ne sais pas encore vraiment quoi en faire.

L'archive ci-jointe contient les fichiers suivants :

• pieces.txt
  tablier.pas
  test.pas
  wingraph.o
  wingraph.ppu
  wincrt.o
  wincrt.ppu

[Paul TOTH]

très joli

je te propose une astuce que j'utilise pour éviter des fichiers texte de ce type

tu écris un programme Pascal qui lit ton fichier piece.txt exactement comme tu le fais...ou éventuellement qui compresse un peu la choses en remplaçant 8 Boolean par un Octet...tes données étant de 1 à 40 ce n'est pas pratique, mais on voit de suite que 21 pièces tiennent dans un Entier 32 bits.

Du coup, au lieu de tester images[fig, y, x] = True tu testerais images[y, x] and (1 shl fig) = 1.

Ton programme génère alors un fichier .PAS sous la forme d'une Unité qui déclare une constante.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Unit Piece;
 
interface
 
const
  Pieces : array[1..40,1..40] of LongWord = (
    0,0,...
  );
 
implementation
 
end.

Il ne te reste plus qu'à inclure cette unité générée par programme dans ton projet pour laisser tomber Piece.txt

[Roland Chastain]

Merci Paul pour ton idée. J'ai dû relire une paire de fois ton message, mais finalement j'ai réussi à faire ce que tu disais. Mes nouvelles pièces pèsent beaucoup moins lourd, et c'était un bon exercice de programmation.

Pour extraire du nombre entier le bit correspondant à la figure, j'ai trouvé cette formule :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
  for y := 1 to 40 do
    for x := 1 to 40 do
      if ((images[y, x] shr fig) mod 2 = 1) or (cNoir and ((images[y, x] shr fig2) mod 2 = 1))
      then
        putPixel(xa + x - 1, ya + y - 1, cl1)
      else
        putPixel(xa + x - 1, ya + y - 1, cl2);

[Paul TOTH]

oui, sinon je t'avais donné la formule avec un "and" binaire et non booléen.

mais avec une petite erreur, la valeur n'est pas 1 mais "1 shl fig", qu'on testera simplement > 0

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
  if image[y, x] and (1 shl fig) > 0 then