[gelöst]DrawGrid wird beim Programmstart nicht richtig...

[Mathias]

Wenn ich unter Windows die Bildschirmauflösung auf 125% oder 150% hochsetze, tritt das beschriebene Problem auf.

Wen man im OS etwas skaliert, muss man immer damit rechnen, da etwas falsch dargestellt wird.

[wp_xyz]

Eher nicht. Ich habe das Programm auf dem 144dpi-Windows bearbeitet, übersetzt und gestartet, da sollte eigentlich nichts mehr skaliert werden. Ein Formular sollte eigentlich zur Laufzeit genauso aussehen wie zur Designzeit, egal, ob man unter 96 dpi oder 144 dpi arbeitet - wenn das anders ist, steckt irgendwo ein Fehler (natürlich kann es zwischen 96 dpi und 144 dpi unterschiedlich aussehen).

[Marsmännchen]

Seltsam, bei mir startet das Programm gleich in der richtigen Darstellung. Sorry, ich kann dir da konkret nicht helfen.

Gehe in die Projekt-Optionen und entferne vorübergehend unter "Konfiguration und Ziele" das Häkchen vor "Win32-GUI-Anwendung". Dann kannst du per WriteLn Variablenwerte auf der Konsole ausgeben (das ist einfacher als mit dem Debugger mit Klassen zu arbeiten). Nicht vergessen, die WriteLn-Anweisungen wieder zu entfernen, wenn du das Win32-GUI Häkchen wieder setzt, sonst stürzt das Programm am WriteLn ab. Folgende Grid-Größen fallen mir im Zusammenhang mit dem beschriebenen Verhalten ein:
- Pitch.RowCount --> Zahl der Zeilen im Grid
- Pitch.TopRow --> Index der ersten oben sichtbaren Zeile, muss 0 sein.
- Pitch.Top --> Pixel-Koordinate des oberen Randes des Grids, muss 0 sein.
- Pitch.DefaultRowHeight --> Höhe der Zeilen
Da du diese Größen nirgendwo explizit veränderst, würde ich die writeLn's in die FormCreate-/FormActivate-/ und FormShow-Methoden setzen und prüfen, ob die ausgegebenen Werte irgendwo von den erwarteten abweichen.

Unabhängig von deinem Problem ist mir aufgefallen, dass du eine TFPGList verwendest, in der du TPos-Objekte speicherst. Im Zusammenhang mit irgendwelchen TList-Objekten blitzt bei mir gleich die Warnlampe: Speicherleck! Und tatsächlich, wenn du in dem Compileroptionen / Debuggen die HeapTrace-Unit aktivierst, das Programm neu kompilierst, startest und gleich wieder beendest, wird dir beim Programmende eine Liste von Speicherlecks angezeigt. Das liegt daran, dass TFPGList eigentlich nur Zeiger speichert und nicht weiß, wie die zugehörigen Speicherbereich wieder freigegeben werden müssen. Nimmst du stattdessen TFPGObjectList, werden statt nackten Zeigern Objekte gespeichert, von denen die Liste weiß, dass es eine Destroy-Methode gibt --> keine Speicherlecks mehr.

Und eine kleine Anregung noch: die immer nach oben weisenden Spuren sehen etwas seltsam aus, wenn der Spieler sich nach links/rechts/unten bewegt. Drehe das Bitmap in einem Bildbearbeitungsprogramm doch um 90, 180 und 270 Grad und nimm diese gedrehten Fußabdrücke ebenfalls in die ImageList mit auf, so dass du dann das in Bewegungsrichtung weisende Bitmap auswählen kannst.

Ich wollte dir nur sagen, dass deine Hinweise nicht vergeblich waren. Wir haben nicht nur das Problem mit der Darstellung im ersten Level gefixt, sondern ich habe jetzt auch die TFPGObjectList eingebaut, die HeapTrace-Unit ausprobiert (ich weiß jetzt also auch, wie man Speicherlecks nachspüren kann) und die Fußspuren zeigen jetzt immer in die Richtung, in die der Spieler gegangen ist

[wp_xyz]

Na dann!