Hallo mal wieder

Sweeper ist ein Klon des Windows-Spiels Minesweeper. Viel zu erklären gibt es nicht, bis auf einige 'Comfort'-Optionen:

• Autoflag isolated mines, mit der Minen markiert werden wenn sie die einzigen verdeckten Felder um ein aufgedecktes Feld sind
  
• und Autosubstract flagged Mines: Eine der Hauptaufgaben des Spielers ist es, die bereits gefundenen Minen im Kopf von den Zahlen in Feldern abzuziehen. Diese Option veranschaulicht die Wirkung dieses Prozesses.

Für große Spielfelder kann mit dem Mausrad und DragNDrop gezoomt bzw. gescrollt werden. Zum exakteren Zoom kann mit gehaltener rechter Maustaste ein Bereich ausgewählt werden.
Seit Rev 12 gibt es auch einen Solver, der aber noch ein besseres Interface braucht.

Programm (exe, 1000.5 KB)
Quelltext (rar, 31.88 KB)


Bugs:

• Zu dem Modal-Dialog bei Programmstart gibt es leider keinen Taskleisten-Eintrag. (klick)
  
• Der Preview beim Rauszoomen srimmr nicht.

ich wünsche viel Spaß beim ausprobieren

Hallo Hidden,
ich habe Dein Programm ausprobieren wollen, aber es geht leider nicht.
Zuerst meldet Win8, dass eine "Gefahr" von Deinem Programm ausgeht (habe ich ignoriert ) und dann kommt eine Fehlermeldung (5), was das auch sein mag.
Den Quelltext kann ich nicht übersetzen. Das liegt aber an meinem Steinzeit-Delphi.

Beste Grüße
Mathematiker

Mathematiker hat folgendes geschrieben :

und dann kommt eine Fehlermeldung (5), was das auch sein mag.

Dein Windows 8 ist komisch. Bei mir funktioniert die Rev1 einwandfrei.

Allerdings sollte das Spiel doch enden, wenn ich eine Mine aufdecke, oder nicht? Das ist nämlich nicht mehr Fall.

Marc. hat folgendes geschrieben :

Mathematiker hat folgendes geschrieben : und dann kommt eine Fehlermeldung (5), was das auch sein mag. Dein Windows 8 ist komisch. Bei mir funktioniert die Rev1 einwandfrei.

Hmm, ok. Habe schon meinen Mitbewohner überredet, dass ich das gleich mal bei ihm testen kann.

Marc. hat folgendes geschrieben :

Allerdings sollte das Spiel doch enden, wenn ich eine Mine aufdecke, oder nicht? Das ist nämlich nicht mehr Fall.

Japp, ist so gewollt Die rote Mine wirst du nicht mehr los, ansonsten wirkt sie auf das Spiel wie eine geflaggte.

Hallo,

Hidden hat folgendes geschrieben :

Hmm, ok. Habe schon meinen Mitbewohner überredet, dass ich das gleich mal bei ihm testen kann.

Sorry, musst Du nicht.
Starte ich das Programm aus dem Windows Explorer heraus, ist alles in Ordnung. Das Programm läuft tadellos.
Ich habe es zuerst aus dem TotalCommander heraus versucht, und der spinnt scheinbar.

Beste Grüße
Mathematiker

Unter Wine gibt es zahlreiche grafische Artefakte. Zusätzlich ist dein Hit-Test falsch, so dass es insbesondere beim Zoomen des Feldes dazu kommen kann, dass er das Feld rechts daneben anklickt.

Ferner ist deine Aufdeck-Methode derart langsam, dass man entweder auf dem Spielfeld den Fortschritt animieren sollte ODER aber aber das Aufdecken durch BeginUpdate/EndUpdate instantan gestalten sollte.

Auch sollte die farbliche Hervorhebung von Mienen, explodierten Feldern, ... besser gestaltet werden.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben :

Unter Wine gibt es zahlreiche grafische Artefakte.

Die beobachte ich unter Windows auch, wenn ich das Programm nicht in den Vollbildmodus schalte. Was relativ seltsam ist, alles was passiert ist ein artefaktfreies Bild per StretchDraw auf eine Paintbox zu packen Und StretchDraw scheint runterskalieren nicht zu mögen

BenBE hat folgendes geschrieben :

Zusätzlich ist dein Hit-Test falsch, so dass es insbesondere beim Zoomen des Feldes dazu kommen kann, dass er das Feld rechts daneben anklickt.

War lokal schon gefixt, beim hit-Test empfiehlt es sich wohl ausnahmsweise mal mit / zu arbeiten statt div wie im Rest des Programms

BenBE hat folgendes geschrieben :

Ferner ist deine Aufdeck-Methode derart langsam, dass man entweder auf dem Spielfeld den Fortschritt animieren sollte ODER aber aber das Aufdecken durch BeginUpdate/EndUpdate instantan gestalten sollte.

Ist eigentlich bereits instantan, d.h. alles was geändert wurde wird auf einmal eingezeichnet. Ich vermute das Application.ProcessMessages zwecks Log-Update zeichnet die Paintbox zwischenzeitlich mehrfach neu. Da könnte BeginUpdate helfen, du hast Recht [Edit] ggf hilft es auch schon, die extra angelegte Buffer-Bitmap nicht bei JEDEM Paintbox-Repaint komplett neu zu zeichnen [/Edit]. (Problem bei der Aufdeck-Methode ist, dass mit beiden 'Comfort'-Hilfen eigentlich nur noch eine Heuristik zum komplett-Lösen fehlt. Und das ist dann Turing-Vollständig, also weiß ich nicht wie viel sich da noch optimieren lässt. )

BenBE hat folgendes geschrieben :

Auch sollte die farbliche Hervorhebung von Mienen, explodierten Feldern, ... besser gestaltet werden.

Du meinst ohne Autosubstract? Da gefällt es mir eigentlich schon ganz gut, mit Autosubstract treten gefundene Minen absichtlich ein bisschen in den Hintergrund.

lg,
Daniel

Hidden hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Unter Wine gibt es zahlreiche grafische Artefakte. Die beobachte ich unter Windows auch, wenn ich das Programm nicht in den Vollbildmodus schalte. Was relativ seltsam ist, alles was passiert ist ein artefaktfreies Bild per StretchDraw auf eine Paintbox zu packen Und StretchDraw scheint runterskalieren nicht zu mögen

Ja, in den Standardeinstellungen macht das nur Nearest Neighbor, das sieht bescheiden aus
HALFTONE fixt das ein wenig (ist nicht wirklich AntiAliased, aber geht schon). StretchDraw verleiert da einiges wieder, also direkt StretchBlt aufrufen:

Hi,

Revision 2 und nun auch schon 3 ist online. In [2] ist die Grafik sehr viel runder geworden und eine weitere 'Comfort'-Option ist hinzugekommen (Autosubstract-Heuristik bei unveränderter Spielfeldoptik). [3] ist ein Hotfix: wurden zu viele Minen markiert, so ist der Minenzähler nicht ins negative gegangen sondern bei Null nach unten übergelaufen.

Das Programm startet nun im (fast)-Vollbildmodus, das heißt mit voller Breite; die Fensterhöhe wird nach wie vor so festgelegt, dass das Minenfeld ein Format von 30:16 hat. Wenn das Fenster übermäßig klein gezogen wird, gehen die Minensymbole und Zahlen über die Kästchengröße hinaus, gegebenenfalls könnte ich das Fenster vielleicht auf eine Mindestgröße beschränken.

Zu dem Modal-Dialog bei Programmstart gibt es leider keinen Taskleisten-Eintrag.

Als bekennender Minesweeper Fan musste ich mir Dein Spiel mal reinziehen. Nach einer Runde habe ich es aber wegen unüberwindlicher Differenzen wieder gelöscht.
Wenn ich am Fensterrand ziehe dann wird mir der Rand aus der "Hand" gerissen umd flackert wild rum. Warum legst Du die Feldgröße nicht via Option fest und packst alles in eine Scrollbox? So wäre es dann auch möglich endlich mal Spiele mit utopischen Abmessungen also, hunderten Feldern, zu erzeugen.

Was ich sehr gut finde, das man nach einer Miene die man kassiert weiter machen kann. Den Timer hätte ich gerne optional, also zu abschalten. Sowas finde ich bei Knobelspielen mehr als überflüssig. Es ist doch interessanter ob man es schafft zu lösen ohne eine Miene zu kassieren.

Hallo Sinspin,

Hidden hat folgendes geschrieben :

Bugs: Die Methode zum Anpassen der Spielfeldgröße auf 30:16 (für quadratische Minenfelder) verhindert das Vergrößern des Formulars am Rand (an der Ecke funktioniert es, also wenn Höhe und Breite gleichzeitg verändert werden).

Sinspin hat folgendes geschrieben :

Wenn ich am Fensterrand ziehe dann wird mir der Rand aus der "Hand" gerissen umd flackert wild rum. Warum legst Du die Feldgröße nicht via Option fest und packst alles in eine Scrollbox? So wäre es dann auch möglich endlich mal Spiele mit utopischen Abmessungen also, hunderten Feldern, zu erzeugen.

Hmm, das ist eine Idee. Ich implementiere das mal schnell in der Art.
Größere Spielfelder sind aber mit Vorsicht zu genießen: Das Aufdecken ist Turing-vollständig, also recht Zeitintensiv. Wenn Comfort-Optionen zum Aufdecken und Markieren aktiviert sind, kann das ggf auch mal 2-3 Minuten dauern.

Sinspin hat folgendes geschrieben :

Was ich sehr gut finde, das man nach einer Miene die man kassiert weiter machen kann. Den Timer hätte ich gerne optional, also zu abschalten. Sowas finde ich bei Knobelspielen mehr als überflüssig. Es ist doch interessanter ob man es schafft zu lösen ohne eine Miene zu kassieren.

Hmm, das ist ja nicht viel Aufwand. Wenn mich ein Timer nicht interessiert, ignoriere ich ihn meißt aber einfach

lg,
Daniel

Das AutoFlag tritt gewaltig auf Minen ...

Steps to Reproduce:
- Flag a non-mine

Actual Behaviour:
- Get hit by explosion nearby

Expected behaviour:
- Mine is left unopened

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Hi,

Ich hoffe, du meinst Autosubstract? Autoflag sollte gar keine Felder aufdecken o_O

Aktuell (bis ihr mich vom Gegenteil überzeugt) ist das as-intended: Ansonsten wäre Autosubstract geeignet, um zusätzliche Informationen zu erhalten, à la 'ich markiere mal ein Feld und schaue ob ich richtig liege'.

Autosubstract ist ein sehr mächtiges Werkzeug, mit dem ich ein 30x16-Feld auch mal in 6 Sekunden löse. Da sollte man sich schon sicher sein müssen, wenn man eine Mine markiert.

lg,
Daniel

Hallo,

der Effekt tritt bei autosubtract auf.
Wenn ich ein Feld als Miene markiere, das defintiv keine ist, dann entstehen Summen <0 und die richtigen Mienen werden aufgedeckt.
BenBe hat eben erwartet , dass das Programm dann stille schweigt.
Aber dann funktioniert das mit den Summen auch nicht mehr, weil, wie Du schon schriebst, man einfach mal probehalber markiert werden kann und autosubtract liefert einem die Mienen.

Diese Flackerei, schon bei Mausbewegungen, ist ja sehr nervig, wenn ich es mit TurboDelphi kompiliere.
In Lazarus 1.0.6 gibt es form.doublebuffered = true in der dfm nicht und es flackert trotzdem nichts ( GTK2, uuuh wie alt ).
Diese merkwürdigen Farben clWebDarkred habe ich mit Tcolor($000080) oder ähnlichem ersetzt.Ebenso Roundrect durch rectangle.
Zum Glück hat das Feld eine angenehme Größe für meine geschwächten Augen....

Gruß Horst

Horst_H hat folgendes geschrieben :

Hallo,

Hi

Horst_H hat folgendes geschrieben :

Zum Glück hat das Feld eine angenehme Größe für meine geschwächten Augen....

Ich spiele auch ausschließlich mit maximiertem Fenster, sonst klickt man viel zu schnell mal daneben

Horst_H hat folgendes geschrieben :

Diese Flackerei, schon bei Mausbewegungen, ist ja sehr nervig, wenn ich es mit TurboDelphi kompiliere.

Die gibt es lokal schon nicht mehr, dafür kann man jetzt mit dem Mausrad zoomen. Sowenn ich es denn noch schaffe, dass das Spielfeld auf die Mausposition zoomt statt auf (0;0)

So, jetzt gibt es was kaputtzutesten

Bekanntlich dauert Programmieren ja immer länger als geplant, vor allem dann wenn dem Entwickler ständig neue Dinge einfallen, die man einbauen könnte

Änderungen:

• Die Fenstergröße wird nicht länger angepasst, statt dessen kann mit dem Mausrad gezoomt und per DragNDrop in diesem Zoom navigiert werden.
  
• Die Schriftgröße in den Kästchen kann die Kästchengröße nicht länger überschreiten, auch wenn extrem weit herausgezoomt wird.
  
• Das Formular blinkt jetzt nach jedem Feld-Aufdecken in der Taskleiste, da dies mit Comfort-Optionen / Aufdeck-Heuristik schonmal länger dauern kann ( -> [Alt][Tab]bing ).
  
  
  markieren

  Weiß jemand eine Alternative zu den auskommentierten, nicht funktionierenden, Methoden um festzustellen wann dies nötig ist?
     

  1: 2:

  if not false {self.Showing}{self.focused}{self.Active} then   FlashWindow(Handle, true);

Horst_H hat folgendes geschrieben :

Diese Flackerei, schon bei Mausbewegungen, ist ja sehr nervig, wenn ich es mit TurboDelphi kompiliere.

Du meintest aber schon beim Vergrößern / Verkleinern des Formulars, oder? Anstonsten hatte bei mir nichts geflackert, ich habe aber auch kein Turbo Delphi zur Hand.

Dann mal,...
der Tragödie zweiter Teil. Feldgröße, Mienenanzahl, Timer, Größe ändern. Fein, Absolut!
Nur, zu was nochmal, ist dieses permanente blinken des Fensterrahmens und Taskbuttons da? Um den Nutzer zu verwirren? Das schafft es. Selbst wenn das halbe Spielfeld mit einem Schlag aufgedeckt wird dauert das nichtmal eine Sekunde und ich habe wahrlich keinen schnellen Rechner. Wenn Du den Output rechts schreibst, da frage ich mich ob da nen ProcessMessages dranhängt denn ich kann sehen wie die Zeilen kommen. Das wäre dann kein Wunder wenn das was Lahm wird.
Wenn man da was drehen wollen würde könnte man ja den Aufdeckvorgang an sich animieren. Aber darum geht es ja nicht. Sondern nur darum, so Klever zu sein die Felder zu umschiffen hinter denen sich eine Überraschung versteckt. Aber nichts Süßes und auch kein Bunny.

€dith:
Als Vorschlag, miss doch die Zeit die vergeht von Start bis Ende der Aktion und lass es nur blinken wenn es länger als 1 1/2 Sekunden gedauert hat.
€dith2:
Warum Zoom? Ich habe es mal mit 50x50 probiert. Ich treffe die Felder kaum noch mit der Maus. Was spricht gegen die Eingabe einer Rastergröße und die Verwendung einer Scrollbox? So das ich den für mich aktuell interessanten Ausschnitt betrachten kann egal wie groß das Spielfeld ist.

Hi,

Sinspin hat folgendes geschrieben :

Nur, zu was nochmal, ist dieses permanente blinken des Fensterrahmens und Taskbuttons da? €dith: Als Vorschlag, miss doch die Zeit die vergeht von Start bis Ende der Aktion und lass es nur blinken wenn es länger als 1 1/2 Sekunden gedauert hat.

Daran hatte ich auch schon gedacht, als Notlösung oder zusätzliche Bedingung wann das Fenster blinkt.
War so nicht vorgesehen, ich hoffte relativ schnell auf eine Antwort hierauf:

Hidden hat folgendes geschrieben :

markieren Weiß jemand eine Alternative zu diesen auskommentierten, nicht funktionierenden, Methoden um festzustellen wann dies nötig ist?     1: 2: if not false {self.Showing}{self.focused}{self.Active} then   FlashWindow(Handle, true);

Sinspin hat folgendes geschrieben :

€dith2: Warum Zoom? Ich habe es mal mit 50x50 probiert. Ich treffe die Felder kaum noch mit der Maus.

Verstehe ich nicht Wenn du das Mausrad scrollst, zoomt es rein und die Felder werden größer. Das behandelt doch genau dein Problem?
Als du von großen Feldern sprachst, hatte ich beim Coden mit 300x160, 9900 Minen getestet (siehe Anhang). Bei noch größeren Feldern treten dann aber Fehler auf, ich weiß noch nicht was ich als vernünftige Grenze festsetzen soll.

Sinspin hat folgendes geschrieben :

Was spricht gegen die Eingabe einer Rastergröße und die Verwendung einer Scrollbox? So das ich den für mich aktuell interessanten Ausschnitt betrachten kann egal wie groß das Spielfeld ist.

Als nächsten Schritt könnte man noch überlegen, ob man die h/v-Position des Ausschnitts auf dem Feld irgendwie anzeigt (abgesehen von den Koordinaten unten rechts).
Einfach die bestehende Paintbox auf eine Scrollbox zu packen, funtioniert leider nicht: Man muss schon auswählen, was gezeichnet wird, sonst wird es langsam. Wenn du die Rastergröße eingeben willst statt mit dem Mausrad zu scrollen, wirst du wahrscheinlich mehrmals probieren müssen bis es stimmt. Was ist da der Vorteil?

Sinspin hat folgendes geschrieben :

Wenn Du den Output rechts schreibst, da frage ich mich ob da nen ProcessMessages dranhängt denn ich kann sehen wie die Zeilen kommen. Das wäre dann kein Wunder wenn das was Lahm wird.

Nein, kein ProcessMessages. Memo1.Lines.BeginUpdate verhindert den Effekt, aber dann fühlt sich die Oberfläche "eingefroren" an (das ist sie auch so, aber man bekommt nicht mehr mit dass etwas passiert).
Hauptgründe für lange Aufdeckzeiten sind:

• Stark minengesättigte Felder: Aktuell wird so lange ein neues Spiel gestartet, bis am Anfang etwas aufgedeckt wird -- ohne Rücksicht darauf, wie unwahrscheinlich dieses Ereignis bei einem 100x100 Feld mit 9998 Minen ist.
  
• große Felder mit wenig Minen, besonders wenn Autosubstract + Autoflag aktiviert sind.

Hallo,

Zitat:

Stark minengesättigte Felder: Aktuell wird so lange ein neues Spiel gestartet, bis am Anfang etwas aufgedeckt wird -- ohne Rücksicht darauf, wie unwahrscheinlich dieses Ereignis bei einem 100x100 Feld mit 9998 Minen ist.

Man kann ja zu Beginn das Startfeld und eventuell seine Umgebung ausklammern.
Oder ganz simpel eine Umkehrung machen.
Alle Felder sind zu Beginn Minen-> Startfeld befreien und dann per Zufall die restliche Anzahl.
Wer zu viele Prüfungen dabei hasst, kann ja einfach eine Liste aller möglichen Feldkoordinaten machen, das Startfeld aber nicht einfügen, diese Liste mischen und die ersten ((N-1) - Anzahl Minen ) von Minen befreien.

Gruß Horst

Horst_H hat folgendes geschrieben :

Man kann ja zu Beginn das Startfeld und eventuell seine Umgebung ausklammern.

Aktuell wird das Spielfeld genau einmal durchgegangen und in jedes Feld mit einer Wahrschienlichkeit von p = MinenÜbrig / FelderÜbrig eine Mine gesetzt. Ich werde das anpassen, sodass die 9 Felder um die Startposition dabei ausgelassen werden und FelderÜbig entsprechend vermindert wird.