DÉMINEUR UTILISANT UNE TDRAWGRID ET AVEC LEQUEL ON PEUT TRICHER
Utilisateur anonyme
-
8 déc. 2007 à 21:05
japee Messages postés 1727 Date d'inscription vendredi 27 décembre 2002 Statut Modérateur Dernière intervention 6 novembre 2021 - 12 déc. 2007 à 18:17
japee Messages postés 1727 Date d'inscription vendredi 27 décembre 2002 Statut Modérateur Dernière intervention 6 novembre 2021 - 12 déc. 2007 à 18:17
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/44977-demineur-utilisant-une-tdrawgrid-et-avec-lequel-on-peut-tricher
https://codes-sources.commentcamarche.net/source/44977-demineur-utilisant-une-tdrawgrid-et-avec-lequel-on-peut-tricher
12 déc. 2007 à 18:17
To do pour la prochaine version :
- chargement des ressources son en mémoire pour éviter un accès répétitif au disque dur, comme me le suggère Cirec (ta dernière solution me convient tout à fait) ;
- ajout du clic simultané droit et gauche comme suggéré par Kenavo. Mais pour ça il faut que je refasse complètement le logigramme... y'a du boulot.
A plus.
11 déc. 2007 à 16:58
Tu avais peut-être utilisé "getHeapStatus.totalFree" au lieu de "getHeapStatus.TotalAllocated", non?
"getHeapStatus.totalFree" est en effet peu fiable à cause du système d'exploitation qui alloue de l'espace quand nécessaire...
Enfin, j'dis ça, j'dis rien. Car on peut te faire confiance en général, quand ton PC n'est pas envouté. ;)
11 déc. 2007 à 14:04
Voici une méthode très simple propre et rapide ;-)
Le fichier ressource ressemble à ça :
Tic WAV "Tic.wav"
Tac WAV "Tac.wav"
{$R Sound.res}
Uses MMSystem;
var
PTic, PTac : Pointer;
procedure TForm2.FormCreate(Sender: TObject);
Var
HRes : THandle;
begin
{Charge la ressource en mémoire}
HRes := LoadResource(hInstance, FindResource(hInstance, 'Tic', 'WAV'));
{Renvoie un pointeur sur la ressource
Il n'est pas utile de faire appel UnLockResource
Les libérations se font automatiquement par Windows à la fin de l'application
http://msdn2.microsoft.com/en-us/library/ms648047.aspx}
PTic := LockResource(HRes);
HRes := LoadResource(hInstance, FindResource(hInstance, 'Tac', 'WAV'));
PTac := LockResource(HRes);
end;
Penses tu que ce soit assez rapide ;-)
En l'appliquant sur tous les sons l'application peut ainsi devenir autonome,
pas de fichiers annexe.
@Caribensila :
"Mais pourquoi n'utilisez-vous pas "getHeapStatus.TotalAllocated"
pour détecter les fuites de mémoire?"
Turbo Delphi le fait très bien juste en mettant un boolean à vrai
et qu'il me dit dans la majorité des cas quel objet en est responsable ;)
J'avais déjà fait des testes avec "getHeapStatus.TotalAllocated" sous D4
mais il ne détectait pas toujours toutes les fuites, mais je m'y suis peut être mal pris ?
L'autre possibilité est d'utiliser MemCheck " http://v.mahon.free.fr/pro/freeware/memcheck/ "
11 déc. 2007 à 00:11
Y'a comme une odeur d'éther quand on arrive au bout de ce couloir...
Nix a médicalisé le service?
Bon! Vous allez dire que j'ai encore un métro de retard... Mais pourquoi n'utilisez-vous pas "getHeapStatus.TotalAllocated" pour détecter les fuites de mémoire?
Ca marche pas bien?
10 déc. 2007 à 23:53
N'aurais-tu pas fait ton service national dans la marine éponyme ? ;-)
10 déc. 2007 à 23:38
10 déc. 2007 à 21:46
Bien compris pour le double clic, en théorie ça ne devrait pas être trop difficile à mettre en oeuvre (si j'ose dire).
Oui, si on tombe sur une mine, les cases contenant les autres mines doivent être dispersées façon puzzle, sinon c'est vrai que c'est frustrant. J'avais pas fait attention, mais il faut avouer que j'ai beaucoup triché pour le débogage, et du coup ça m'a échappé.
Je n'avais pas limité le nombre de mines pour que les curieux s'en donnent à coeur joie, dans la mesure où ça ne plante pas le jeu. Je voulais faire de même pour les dimensions de la grille, mais en-dessous d'une certaine taille c'est pas beau, et au-delà, ça risque de déborder de l'écran. C'est une sorte de démineur expérimental, quoi. Mais si je fait une version "normale", je tiendrai compte de tes remarques. Je note aussi que l'affichage des mines est un peu exigü.
"Attention, tout abus de ce jeu peut causer des névralgies cervicobrachiales !". Et pourquoi pas des hémorroïdes, tant qu'on y est ?
Ce démineur, il va finir par me causer quelques nuits blanches, et des "nervous breakdown" comme on dit de nos jours.
Merci pour tes remarques utiles et constructives, je les mettrai en pratique dans une future mise à jour, mais pas tout de suite. Je suis un peu fatigué et je me demande si je ne vais pas me retirer, je sais pas moi, à Montauban par exemple, pour y vendre... bof pourquoi pas des tracteurs ou des bâtonneuse moisseuses.
A +.
* je suis parfaitement bilingue.
10 déc. 2007 à 20:50
10 déc. 2007 à 20:45
Pour les constantes typées (premiers posts) c'est une option du compilateur sous D7 ("constantes typées affectables" à cocher ou {$J+})
Pour la taille max en mode personnalisé, j'ai poussé à 70 x 56 (écran 1280 x 1024) ... et ça tourne !
Pour le nombre de mines, en mode personalisé tu peux limiter à col x row - 1. J'ai mis -1 parcequ'il est quand même plus intéressanat de jouer à la roulette russe en ayant au moins un trou dans un barillet ayant 3920 balles (ça laisse une chance ! Sinon autant y aller au kinder-suicide)
Du coup l'affichage du nombre de mines est trop petit (que 3 caractères)....
Par contre là, sans le truc du click simultané droite-gauche, c'est galère !
(pour mémoire, ce click simultané sur une case découverte portant le nombre de mines adjacentes peut produire deux effets :
- si le nombre de "drapeaux" est inférieur au nombre de mines indiquées, les cases adjacentes non découvertes changent d'aspect (mise à plat sans effet 3D).
- si le le nombre de "drapeaux" est égal au nombre de mines indiquées, toutes les autres cases adjacentes sont cliquées.
(si le le nombre de "drapeaux" est supérieur au nombre de mines indiquées, rien ne se passe)
Et pour finir je te conseille d'apposer une mention du type :
"Attention, tout abus de ce jeu peut causer des névralgies cervicobrachiales !"
10 déc. 2007 à 17:23
Tout s'éclaire d'un coup.
Et la fin du monde (des mondes ?), c'est peut-être pas pour tout de suite. ^^
C'est donc finalement dû au fait que Turbo Delphi et D7 (et antérieur) ne compilent pas de la même manière.
Quoi qu'il en soit, tu m'as ouvert des horizons, et je vais m'intéresser d'un peu plus près à cette utilisation des Streams.
10 déc. 2007 à 17:18
que l'application fonctionne également très bien sur cette machine !!!
C'est bien le compilateur !!!
et j'ajoute aussi ... que si j'enlève les deux fichiers vaw
ben ça fonctionne pas ... ce n'est donc pas dans l'application sous quelques formes que ce soit.
voilà ... désolé lol
10 déc. 2007 à 16:58
Bon plus sérieusement, j'ai été jusqu'à redémarrer la machine pour être sûr du coup et ... (plus de trace dans la mémoire)
J'annonce que ça fonctionne éffectivement sous Turbo Delphi
et ne fonctionne pas sous Delphi7 ... Dommage
Il semblerait donc que le nouveau compilateur permet plus de flexibilité dans le code tout en assurant et la disponibilité des données et leurs libérations.
Que c'est beau le progrès ;-)
Mais c'est pas bien grave, pour D7 au lieu de ne déclarer qu'une variable
tu en déclares deux que tu libère à la fin et plus de fuites et le code reste compatible entre version.
10 déc. 2007 à 16:51
Décidément, c'est pas que je sois têtu (enfin un peu quand même...), mais chez moi, il n'y a que ce code qui marche, et j'ai trouvé comment tout libérer/désallouer proprement :
uses MMSystem;
var
MemoryStream: TMemoryStream;
Data1, Data2: PByte;
PTic, PTac : Pointer;
procedure TForm1.Button1Click(Sender: TObject);
begin
PlaySound(PTic, 0, SND_SYNC Or SND_MEMORY);
PlaySound(PTac, 0, SND_SYNC Or SND_MEMORY);
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
MemoryStream := TMemoryStream.Create;
with MemoryStream do
begin
LoadFromFile('Tic.Wav');
GetMem(Data1, Size);
ReadBuffer(Data1^, Size);
PTic := Data1;
LoadFromFile('Tac.Wav');
GetMem(Data2, Size);
Seek(0, soFromBeginning);
ReadBuffer(Data2^, Size);
PTac := Data2;
end;
end;
procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
FreeMem(Data2);
FreeMem(Data1);
MemoryStream.Free;
end;
Si le code de Cirec fonctionne sur un autre PC que le sien (qui est certainement ensorcelé), pourrait-il nous le faire savoir ?
Ca fairai avancer le aaachimilimili...achimilimilimilblic.
10 déc. 2007 à 16:14
Oui, j'ai testé ton code dans des conditions rigoureuses :
- nouveau projet (donc aucun code qui puisse interférer),
- fichiers .wav placés dans le répertoire (sinon plantage),
- compilation sous D4, puis sous D7 (on ne sait jamais ;-) )
Résultat : aucun son au click de Button1.
2 explications à priori :
1) tu n'as pas testé dans les mêmes conditions que moi,
2) nous sommes dans la 4ème dimensions, nous vivons dans deux mondes parallèles qui n'auraient jamais dû se rencontrer, et l'univers va incessament s'autodétruire. Brrrr....
Sérieux, je ne comprends pas.
10 déc. 2007 à 15:29
je confirme tes craintes ...
avec ton code tu as des fuites de mémoire ;-(
ce qui est normal en soit.
Je m'explique, tu alloues deux fois de la mémoire pour "Data" et tu la libères qu'une fois. Donc ton premier appel à GetMem est perdu. (#^.^#)
10 déc. 2007 à 15:12
tu penses bien que j'ai testé le code avant de le poster ici ^^
et je te garanti que ça fonctionne tel quel
l'as tu au moins essayé ?
je sais le code prête à confusion mais ça fonctionne (je viens refaire les teste)
sinon pour SND_SYNC je l'ai mis dans l'exemple c'est justement pour être sur d'entendre les deux sons
Pour les fuites de mémoire il existe une variable très pratique :
ReportMemoryLeaksOnShutDown mais que pour les utilisateur de Turbo Delphi pour les autres il y a MemCheck qui, me senble-t-il, est gratuit
10 déc. 2007 à 14:58
Ensuite direction le gestionnaire de tâche, si il y a une fuite on voit très rapidement la charge dediée augmenter sans raison.
Bien sûre ça ne dit pas précisement où est le problème mais ça peut permettre de gagner du temps si on utilise beaucoup de procedures "douteuses".
Si ca peut aider ...
10 déc. 2007 à 14:42
J'ai pas trop l'habitude de faire joujou avec.
Mais il me semble que tu libère trop vite le stream et que les pointers sont désalloués avant leur utilisation dans Button1Click1 => donc pas de son.
Je l'ai refait comme ça, mais je ne suis pas sûr qu'ainsi il n'y a pas de fuites mémoire :
var
MemoryStream: TMemoryStream;
Data : PByte;
PTic, PTac : Pointer;
procedure TForm1.FormCreate(Sender: TObject);
begin
//ReportMemoryLeaksOnShutDown := True;
MemoryStream := TMemoryStream.Create;
with MemoryStream do
begin
LoadFromFile('Tic.Wav');
GetMem(Data, Size);
ReadBuffer(Data^, Size);
PTic := Data;
LoadFromFile('Tac.Wav');
GetMem(Data, Size);
Seek(0, soFromBeginning);
ReadBuffer(Data^, Size);
PTac := Data;
end;
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
PlaySound(PTic, 0, SND_ASYNC Or SND_MEMORY);
end;
procedure TForm1.Button2Click(Sender: TObject);
begin
PlaySound(PTac, 0, SND_ASYNC Or SND_MEMORY);
end;
procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
FreeMem(Data);
MemoryStream.Free;
end;
Qu'en penses-tu ? That's right ?
(j'ai aussi remplacé SND_SYNC par SND_ASYNC, mon côté prudent, même si les sons utilisés ici sont très brefs).
10 déc. 2007 à 13:04
C'est une alternative pour le son afin d'éviter de nombreux accès au disque inutiles ;-)
Var
PTic, PTac : Pointer;
procedure TForm1.Button1Click(Sender: TObject);
begin
PlaySound(PTic, 0, SND_SYNC Or SND_MEMORY);
PlaySound(PTac, 0, SND_SYNC Or SND_MEMORY);
end;
procedure TForm1.FormCreate(Sender: TObject);
Var
Data : PByte;
begin
//ReportMemoryLeaksOnShutDown := True;
With TMemoryStream.Create do Try
LoadFromFile('Tic.Wav');
GetMem(Data, Size);
ReadBuffer(Data^, Size);
PTic := Data;
FreeMem(Data);
Finally
Free;
End;
With TMemoryStream.Create do Try
LoadFromFile('Tac.Wav');
GetMem(Data, Size);
ReadBuffer(Data^, Size);
PTac := Data;
FreeMem(Data);
Finally
Free;
End;
end;
et il n'y a pas de fuites de mémoire ^^
10 déc. 2007 à 00:51
Merci pour ton appréciation.
"l'utilisation d'un thread dans ce code serait elle une erreur ? "
Cela dépend. Je ne vois pas à priori quelle tâche je pourrais vouloir placer dans un thread.
Je pense améliorer la vitesse d'affichage en utilisant la méthode que me suggère Cirec. Ca devrait largement suffire.
Je serai très heureux si ce source peut te rendre service.
9 déc. 2007 à 17:50
Question : l'utilisation d'un thread dans ce code serait elle une erreur ?
9 déc. 2007 à 16:35
"à la place de créer un bitmap pour récupérer l'image et ensuite la dessiner pourquoi ne pas avoir utiliser directement la méthode Draw de l'ImageList"
Oui, il faut que j'essaye, ça me plait. Et si on peut grignoter en rapidité d'affichage...
"et désolé de t'avoir fait tant de frayeurs ^^"
Bah, t'en fais pas, même pas eu peur...
Quoi que... S'il avait fallu que je refasse tout (cas extrême, certes) parce que ça compilait nulle part... pas lol du tout ! :-(
Et merci pour ton appréciation. :-)
9 déc. 2007 à 13:42
C'est le menu "Tricher" qui m'a "enduit d'erreur" (© Japee) ^^
Et tout comme Caribensila je n'ai jamais joué au démineur ...
enfin grâce à ton explication "PRÉCISIONS CONCERNANT LES CASES A COCHER : " tout fonctionne correctement.
Pour le code :
On pourrait certainement le accourcir mais il y perdrait en lisibilité
Par contre dans DGUtils (même si la fonction n'est plus utilisée c'est juste pour faire avancer le schmilblik)
à la place de créer un bitmap pour récupérer l'image et ensuite la dessiner
pourquoi ne pas avoir utiliser directement la méthode Draw de l'ImageList ?
à mon avis (je n'ai pas testé) ça sera aussi rapide que la méthode actuellement utilisée voir même moins lourd que l'utilisation de plusieurs TImage .... non ?
Dans tous les cas c'est du chouette boulot ... Bravo
et désolé de t'avoir fait tant de frayeurs ^^
9 déc. 2007 à 00:46
Alors le 1er coup, pour boumer ça a boumé!
'suis tout estourbi...
En tout cas, le son y marche super bien !
9 déc. 2007 à 00:38
Justement, en trichant, on voit mieux la logique, il me semble, et ça vaut toutes les explications et règles du jeu du monde, toujours un peu ch...es.
Je vais rajouter là-haut quelques explications concernant les options des checkboxes, car ce n'est forcément évident d'en intégrer la logique.
Bien content que ça compile chez toi aussi, Cantador.
Sinon, vous, ça boume ?
9 déc. 2007 à 00:23
Après avoir changé:
var IsTic : Boolean;// = True;
begin
IsTic := true;
dans "procedure TMainForm.TimerTimer(Sender: TObject);"
ça compile à l'aise sur D7.
Mais comme je n'avais jamais joué au démineur... attends un peu avant la défenestration, Japee! ;)
9 déc. 2007 à 00:17
j'aime bcp l'explosion de la mine..
@+
9 déc. 2007 à 00:01
mais de Directive de compilation
sinon pour le reste je dois être trop mauvais ou trop c...
puisque même avec les trois versions que tu m'as envoyé je n'y arrive toujours pas !!!! j'ai toujours le même résultat à savoir pas de changement pour ces deux options (Voir mines et Indication sous mine)
Pour ce soir je laisse tomber
peut être que demain ça fonctionnera mieux ;-)
8 déc. 2007 à 23:38
8 déc. 2007 à 23:28
8 déc. 2007 à 23:16
Je verrai ça en profondeur plus tard, là je gave grave sur ce code, le débogage m'a vraiment pris la tête.
C'est pas sympa pour toi, mais j'espère que tu es le seul à avoir la poisse avec mon code, car j'aurais aimé avoir ton avis, même s'il doit être sévère (mais juste, hein ?) ;-)
8 déc. 2007 à 22:58
la modification que tu as apportée à la ligne 371 ne jouera qu'un seul son
pour que les deux sons soient joués il faut la déclarer en globale comme je l'ai fait dans mon post
8 déc. 2007 à 22:51
j'ai compilé le code sous D7 et Turbo Delphi et rien à faire ...
les deux me donne le même résultat !!!
Si tu le veux bien envoie moi l'exe (sur ma boite Hotmail ... tu sais ou la trouver ;-) ) afin de pouvoir comparer
8 déc. 2007 à 22:36
Cirec, en corrigeant la ligne 371, ça fonctionne chez moi sous D7, je viens de tester.
Par contre, je n'aime pas du tout l'aspect que ça donne avec le XPMan sous D7... Berk... (voir capture pour la différence)
8 déc. 2007 à 22:18
MatrixFlag est toujours à zéro chez moi et du coup ne peut donc pas afficher les images
Pourquoi .... mystère et boule de gomme ;-)
8 déc. 2007 à 22:05
Je viens de vérifier sous D7, effectivement la constante typée ne passe pas (il doit y avoir une option d'environnement à cocher.
En attendant que je corrige, ceux à qui ça pose problème peuvent remplacer par :
var
IsTic: Boolean;// = True;
à la ligne 382.
Désolé.
8 déc. 2007 à 22:05
je n'obtiens pas le résultat escompté
et la seule modification que j'ai apporté au code pour qu'il compile c'est :
Var
IsTic: Boolean = True;
{ Gestion du temps écoulé, affichage et son }
procedure TMainForm.TimerTimer(Sender: TObject);
{Const
IsTic: Boolean = True;}
Begin
...
8 déc. 2007 à 21:57
Bizarre.
J'ai pourtant vérifié 2 fois plutôt qu'une avant d'envoyer.
Je télécharge le zip et je vérifie...
Ah oui...
Pour que "voir indices" et "voir mines" soient opérationels, il faut que "tricher" soit coché.
Et pour "indications sous mines", il faut que "voir mines" soit décoché, sinon les mines empêchent de voir.
8 déc. 2007 à 21:39
8 déc. 2007 à 21:05
Dans l'unité Main ligne 382 : Error: Left side cannot be assigned to
Pourquoi avoir choisi une constante ?
Pour le reste j'ai pas encore regardé le code ....
mais j'y travail ;-)