Puissance 4 basé sur les expressions régulières

Citation:

---

Envoyé par Roland Chastain

...qui (si je comprends bien) permet de sortir de la méthode OnPaint pour la rappeler aussitôt, tout en permettant à la machine de "respirer" entre temps ? :roll:

---

Ca permet de gérer la cadence d'affichage mais seul un sleep permet de faire "respirer la machine".
Ici on ne recalcule pas systématiquement l'image mais on ne s'arrête pas pour autant puisqu'une repeinture est immédiatement ordonnée.

Citation:

---

Envoyé par Roland Chastain

L'autre différence, c'est qu'il n'y a pas de Sleep(). Peut-être justement le code ci-dessus en tient-il lieu ?

---

Les deux provoquent un ralentissement du mouvement mais la comparaison s'arrête là.

Citation:

---

Envoyé par Roland Chastain

J'ai ouvert le gestionnaire des tâches après avoir lancé TetrisRun : le programme occupe entre 40 et 50 % du processeur, ce qui est encore raisonnable, non ?

---

Ca dépend. Si l'app est au premier plan, on peut l'admettre aisément. Si elle est en arrière plan, définitivement pas.
Tu as manifestement un machine bi-coeurs, l'app est mono-thread (donc utilise un seul cœur) et cette tâche tourne à fond (en boucle sans sleep). 50% des ressources CPU sont utilisées, elle ne peut pas en consommer plus !

Le principe est très bien et assure un mouvement plus uniforme. Il manque peut-être juste un test if GetForgroundWindow <> Handle then Sleep(1); pour que si tout à coup tu devais utiliser une autre app (lire tes mails par exemple) sans pour autant quitter le jeu, cette autre app ne subisse pas de ralentissement.

(L'app au premier plan a une priorité légèrement supérieure aux autres, elle fonctionnera mais à la vitesse petit "V")

Citation:

---

Envoyé par Roland Chastain

Maintenant rien ne me prouve que demain en lançant TetrisRun je ne vais pas observer le même phénomène de ralentissement. C'est ça qui est embêtant : que le phénomène se produise de façon irrégulière. :roll:

---

Le seul cas serait des tâches de priorité supérieure parce qu'ici, TetrisRun accapare un cœur pour son seul usage. Ce sont les autres apps qui risquent d'être ralenties mais pas lui ;)

@Andnotor

Merci pour ces explications. Je commence à y voir plus clair.

J'ai vérifié : oui, il y a bien deux cœurs sur ma machine.

J'ai essayé d'ajouter dans TetrisRun la ligne que tu proposais :

Code:

---

1 2 3 4 5

if not FGameOver then begin InvalidateRect(Handle, nil, False); if GetForegroundWindow <> Handle then Sleep(1); end;

---

Ça fonctionne très bien : c'est-à-dire que si TetrisRun est au premier plan, ça ne change rien, mais s'il passe au second plan, par exemple lorsque j'ouvre le gestionnaire des tâches, on voit que l'animation devient moins fluide, et l'occupation du processeur n'est plus que de 30 % environ.

Citation:

---

Envoyé par Roland Chastain

...

Code:

---

1 2 3 4 5

procedure TForm1.ButtonClick(Sender: TObject); ... begin if FDropping then Exit;

---

---

arf j'aime pas ce genre de code :D
si tu veut que la personne n'appuie pas sur le bouton lors du fonctionnement
tu conditionne la disponibilité du bouton vis a vis de ta variable

Code:

---

Button.enabled := not(FDropping);

---

ainsi tu rend ton bouton invalide le temps du traitement.

Ps : les exit dans le code m'horripile, même si il m'arrive de l'utiliser.
j'essai par dessus tout les moyens de ne pas l'utiliser ... c'est comme le goto c'est a proscrire le plus possible ;)

Voici une nouvelle version, avec une option "Highest animation speed".

Code:

---

1 2 3 4 5 6 7

procedure TForm1.FormPaint(Sender: TObject); ... begin ... InvalidateRect(Handle, nil, FALSE); if not ActionHighestAnimationSpeed.Checked then Sleep(1);

---

:arrow: Puissance 4

@anapurna
Merci pour ta suggestion. Je vais y penser pour la prochaine mise à jour. ;)

Citation:

---

Envoyé par anapurna

Ps : les exit dans le code m'horripile, même si il m'arrive de l'utiliser.
j'essai par dessus tout les moyens de ne pas l'utiliser ...

---

Quelle idée !

Exit est très utile et encore plus depuis qu'il est possible d'y passer en paramètre le résultat de la fonction. Le code est beaucoup plus lisible grâce à des niveaux d'imbrication beaucoup moins profonds.

Sans Exit :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Cond1 := ...;   if Cond1 then begin Cond2 := ...;   if Cond2 then begin ... Result := TRUE; end else Result := FALSE; end else Result := FALSE;

---

Avec Exit :

Code:

---

1 2 3 4 5 6 7 8 9

Cond1 := ...; if not Cond1 then Exit(FALSE);   Cond2 := ...; if not Cond2 then Exit(FALSE);   ... Result := TRUE;

---

Pour moi, y'a pas photo, j'aime les Exit ;)

salut

je suis un vieux de la vielle qui aime bien pouvoir reproduire
les programme sous forme d'algorithme
ma représentation préfèré étant sous la forme de
diagramme Nassi–Shneiderman

de plus je suis persuadé que plus nous restons prés des règles élémentaire de l'algorithmie
plus il est simple de passer d'un langage à l'autre et plus il est simple de maintenir et de modifier le source

re,

tout d'abords merci pour les nouvelles images en couleurs ;)

ensuite, j'avoue ne pas comprendre le choix d'utiliser le Sleep pour gérer une animation ...
je veux dire que Sleep est une méthode bloquante elle met en pause (endort) le thread principale !

d'ailleurs on voit bien bien à quelle point l'animation est ralentie juste avec un Sleep(1)
1 milliseconde théoriquement mais rien que l'appel prend plus de temps d’où un ralentissement plus important que prévu.
et si tu avais une autre animation ou processus qui s'exécuterait en même temps sur le thread principale il subirait le même ralentissement !

Sinon as-tu retouché l'expression régulière qui contrôle le jeux depuis que tu as corrigé le fait qu'on pouvait gagner à tous les coups avec 2 séquence ?

Parce que depuis que tu as ajouté l'animation cette séquence :
D D C F E C
permet à nouveau de gagner à tous les coups (mais pas les 2 premières que j'avais trouvés) !!!!
alors qu'avec la dernière version juste avant l'ajout de l'animation ça ne marche pas !

je trouve ça assez bizarre parce que je ne pense pas que tu aies touché à ça pour ajouter l'animation ... !
mais bon le fait est là.

je viens de faire le teste et c'est bien l'animation (l'utilisation du Sleep certainement) qui permet de gagner avec cette séquence :aie:
quand on Disable l'animation la séquence ne passe pas :aie:

Cordialement,
@+

@Cirec

Merci pour l'essai et le compte-rendu.

C'est assez inquiétant ce que tu me dis là (que le fait de désactiver l'animation change le jeu de l'ordinateur). Cela mérite une vérification en profondeur. Je fais ça dans les jours qui viennent et vous tiens au courant.

Je te confirme que je n'ai pas retouché le code qui produit les coups de l'adversaire artificiel.

@Cirec

Chez moi, quelles que soient les options d'animation, la séquence que tu as indiquée est toujours gagnante. :roll:

Autrement, pour en revenir au problème du Sleep, c'est vrai que par moments l'animation est d'une lenteur insupportable, mais à d'autres moments elle est d'une rapidité très satisfaisante. Cela dépend, j'imagine, de l'occupation de la machine. En revanche, avec le Sleep, le programme sollicite moins le processeur.

En l'occurrence, comme l'animation ne dure qu'une seconde (le temps que le pion tombe), on peut sans trop d'inconvénient je crois se passer du Sleep. Voilà ce que j'ai retenu de cette discussion. ;)

Pour l'adversaire artificiel, c'est normal qu'il ait de grosses faiblesses, vu que l'évaluation se base sur la position suivant immédiatement le coup. Quand j'aurai le temps, je retravaillerai cette partie du programme.