Meine Welt in meinem Kopf

Sicherlich habt ihr entweder am Programcode oder beim Testen der Spielfunktionen bemerkt, dass die Kollisionsabfrage nur bedingt funktioniert. Sie ist zwar einfach, aber hier fehlt die Einschränkung, dass man sich nur von Block zu Block bewegen kann. Offen gestanden war ich kein Fan davon, das sich die Figur weiter bewegt bis der nächste Feld oder Kachel erreicht wurde. Zu dem Thema Spieleprogrammierung und Kollisionsabfrage für 2D Spiele, können verschiedene Lösung im Internet gefunden werden. Ein Beispiel wird hier auf spieleprogrammierer.de/wiki beschrieben, wie man mit Geometrischen Objekten die Kollision Abfragen kann. Die simple Form für die Kollisionserkennung ist das Verwenden von zwei Rechtecken. Im folgenden Code zeigt die Methode die wesentliche Abfrage von überschneidenden Rechtecken. // Kachel Position mit zukuenftiger Position der Figur abgeleichen, // durch ansetzten von Rechtecken und ob diese sich ueberschneiden. boolean checkCollide(byte

Der Arduino oder auch vielmehr der verwendete Mikrocontroller hat für viele Anwendungen genügend Arbeitsspeicher. Im ersten Teil der Blogpost Reihe verwendete ich einen Arduino Nano, der einen ATmega328 hat und einen Arbeitsspeicher von 2kByte besitzt. Der Arduino Esplora verwendet den ATmega32u4 der wiederum 2,5kByte Arbeitsspeicher aufweist. Trotz des etwas größeren Arbeitsspeichers muss für dieses Projekt dennoch sparsam damit umgegangen werden. ATmega328P und ATmega32u4 Arbeitsspeicher verbrauch Ein Sprite Bild besteht selbst aus 160 Bytes. Das klingt jetzt nicht viel, aber verbraucht den Arbeitsspeicher bereits mit über 6%. Würde man die Sprite Animation der Figur nicht mit dem Trick einzelner Bilder spiegeln, dann würden insgesamt 2,92kByte Arbeitsspeicher anfallen. Stattdessen werden momentan 1,12kB verwendet, dass allerdings für das Ziel immer noch zu viel ist. Und dann kommt noch die Karte mit 160 Bytes hinzu, die noch sehr grob ist. Da bleibt am Ende nic

Eine Figur durch einen leeren Raum zu steuern, ist auf Dauer sehr öde. Man kann nun den Hintergrund zunächst eine Farbe geben, ist aber dennoch sehr eintönig ist. Schauen wir uns andere Spiele an, könnte man meinen, dass alles in der Umgebung in Blöcken unterteilt ist. Und so wird dies auch in diesem Beispiel umgesetzt. Die Karte wird Blockweise angelegt. Das ermöglicht uns weiterhin nur die Bereiche neu zu rendern, die sich auch geändert haben. Karten Eigenschaften Mit der Unterteilung in Blöcken, kann ein Block verschiedene Eigenschaften aufweisen. Hier stellt die '0' die Frei Begehbaren Blocke da, in dem sich die Figur bewegen kann. Der Wert '1' wiederum stellt eine Mauer da, an dem die Figur nicht hindurch gehen kann. Die Fläche eines Blockes ist etwas größer als die der Figur. Daher weist die Kanten länge 16 Pixel mal 16 Pixel auf. Ordnung ist das halbe Leben Zunächst muss vorweg etwas Ordnung eingebracht werden. Zwar habe ich bereits mi

Die Adafruit GFX Bibliothek gibt uns die Möglichkeiten Pixel für Pixel auf das TFT zu schreiben, womit sich dann auch ein Bild zusammen setzen lässt. Bei größeren Bilder sollte klar sein, dass der Bildaufbau mit 16MHz nur langsam abläuft. Als Ziel ist jedoch eine Darstellung zur Laufzeit zu verändert, wie z.B. eine Runde Analoge Anzeige. Relativ schnell stellte sich heraus, dass die Umsetzung einer solchen Anzeige zwar einfach ist, aber ab einer bestimmten Größe zu langsam gerendert wird. Alternative und einfacher ist die das Verwenden von bereits fertigen Bildern in 16 mal 16 Format. Zugegeben ist eine Analoge Anzeige mit dieser Auflösung sehr grob und auf Dauer nicht zu friedend stellend. Eine Low Pixel Figur wiederum würde passen und das kombiniert mit den Tasten, könnte die Figur auch über den Bildschirm gesteuert werden. An dieser Stelle erinnerte ich mich wieder an den Anfang von Octoawesome von Tom Wendel, der in seinen ersten folgen ähnliche Schritte unterna

Nachdem ich viel probiert habe und dabei fast ein Spiel zusammen hatte (Nicht Pong, das ist zu einfach), entschied ich den Arduino Esplora zu bestellen. Normalerweise würde ich vom Breadboard umziehen und dann etwas selbst auf eine Platine mit den entsprechenden Komponenten zusammenlöten. Aber warum nicht eine fertige Plattform nutzen. Etwas enttäuschend, fand ich die Suche im Internet, weil ich keine aufwendigen Spiele für den Arduino Esplora entdeckt habe. Damit will ich das nicht schlecht reden, aber etwas mehr hatte ich schon erwartet. Der Umzug vom Breadboad auf den Arduino Esplora ist in wenigen Schritten erledigt. Als erstes werden die Adafruit Bibliotheken gegen die 'Esplora.h' und 'TFT.h' ausgetauscht. Die Beschreibung an welchen Pin vom TFT zum Arduino Uno (oder Nano) verbunden werden soll, sowie auch die Pin Variablen entfallen. Das Initialisieren der Pins sowie auch das TFT Display, wird durch ein 'EsploraTFT.begin()' ersetzt. Die Steuerricht

Damit die gemessenen Werte auch brauchbare Messeinheiten haben, müssen die Rohdaten zunächst umgerechnet werden. Daher kommen zwei weitere Methoden hinzu, die dies erledigen. Der Inhalt zum Lesen des einzelnen Wertes erhält eine eigene Methode, weil dieser Inhalt zweimal verwendet wird und sich nur im einzelnen zusendenden Byte unterscheidet. // Luftfeuchtigkeit Messen und Rohwert zurückgeben public int Read() {     // Inhalt in eigene Methode umgezogen } // Liest mit der Übergabe des Befehls den Sensor Teil aus. private int ReadSensorPart( byte command) {     // Befehl senden.     if ( this .Write( new byte [] { command }) == 0)     {         throw new SystemException ( "Fehler beim Senden!" );     }     // Warten bis der Sensor mit dem Lesevorgang fertig ist.     Thread .Sleep(50);     byte [] data = new byte [3];     // Messergebnis abrufen     if ( this .Read(data) == data.Length)     {         // Es werden für dieses Beispiel zwei Bytes verwendet       

Zuvor habe ich für meinem Weather Shield einen Feuchtigkeitssensor DHT11 verwendet. Wer diesen kennt, weiss sicherlich wie ungenau die Messwerte sind. Ich möchte den Sensor nicht schlecht reden, denn immerhin ist er sehr günstig. Möchte man allerdings für eine Anwendung mehr Genauigkeit und eine schnelle Abtastung der aktuellen Feuchtigkeit und Temperatur, bieten andere Sensoren deutlich bessere Ergebnisse. Ein paar interessante Daten zum Sensor: Schnittstelle I²C Betriebsspannung: 3,3V (max. 3,6V) Stromaufnahme: ca. 10mA Temperaturmessung ca. 50ms bei 14Bit (7ms bei 11Bit) (-40°C bis 125°C) Feuchtigkeitmessung ca. 16ms bei 12bit (3ms bei 8Bit) Kostet ab 6,50€ bei Ebay über einem chinesischen Händler Weitere Daten findet ihr im Datenblatt. Ansprechen lässt sich der Sensor über den I²C Bus und kann mit dem .NET Micro Framework mit geringen Aufwand programmiert werden. Das Einstiegsverhalten lässt sich mit dem Luftdruck Sensors BMP085 vergleichen, über den ich bereits geschri

Das Licht leuchtet hier in verschiedenen Farben. Mit Hilfe des TCS3200 Sensor, können die verschiedenen Farben gemessen werden. Anders als bei einem lichtempfindlichen Sensor, an dem sich der Leitwert verändert, liegt ein Pulssignal an. Für die Schaltung werden insgesamt fünf Digitale Ports und zwei Pins für die Spannungsversorgung benötigt. Wenn mal kein Breadboard zur verfügung steht, geht das auch so wie im folgendem Bild. Die Pins von S0 bis S3 und OUT auf die digitalen Ausgängen von Pin 2 bis Pin 6 steckt. Wie die Schaltung bereits verrät, ist das einlesen deutlich anders. Anstatt über OneWire , I²C oder eines Spannungspegel, kommt ein PWM (oder auch PPM) Signal. Je nach Farbe müssen die Anschlüsse von S0 bis S3 entsprechend geschaltet sein. Das bedeutet wiederum, dass die Farben nacheinander gemessen werden. Im .NET Micro Framework gibt es zum Einlesen die Klasse "InteruptPort", mit der auf das PWM Signal reagiert werden kann. Das erfordert etwas zusätzlic