Browsing posts in: XNA und Spieleprogrammierung

Dirt Rally – Joystick zum Schalten

Dirt Rally ist eine bekannte Autorennsimulation. Die teils sehr anspruchsvollen Kurse zu meistern ist ohne Lenkrad quasi unmöglich. Praktischerweise hatte ich ein altes Lenkrad herumstehen um ein wenig Dirt Rally zu spielen. Mein altes Lenkrad besteht nur aus dem Steuerrad und zwei Fußpedalen, es kommt daher ohne einen zusätzlichen Schalthebel aus. Praktischer und realistischer wäre es doch wenn man sich irgendwie einen Schalthebel aus einem alten Joystick bauen kann! Und genau dieses Projekt mit all seinen auftretenden Problemen soll in diesem Blogpost beschrieben werden.

Die Grundidee besteht aus einem externen Programm welches im Hintergrund mit dem Joystick kommuniziert. Sobald eine Schaltbewegung (= Joystick nach vorne/hinten und wieder in die Ruhelage) detektiert wird soll das Programm den Tastendruck zum Hoch- bzw. Runter schalten an Dirt Rally senden. Zum Auslesen des Joysticks gibt es ein nettes Tutorial mit dem Managed DirectX Framework mit dem das gewünschte Verhalten schnell implementiert werden konnte. Dabei wird die Y-Achse des Joysticks abgerufen ob sich der Wert auf 0 (= Vorne) oder 65535 ( = Hinten) befindet. Falls dieser Zustand erreicht wurde und wieder verlassen wird findet das „Schalten“ statt.

Joystick1

Nun ging es nur noch darum die Taste zum Hoch- bzw. Runterschalten an Dirt zu senden. Dazu gibt es verschiedene Wege wie z.B. SendKeys unter .NET oder die nativen Methoden wie SendMessage/SendInput . Problematisch war dass selbst nach mehreren Stunden des Experimentierens keine Tasteneingabe von diesem externen Programm an Dirt Rally gelangte. Ich weiß bis heute nicht warum das Programm nicht auf die Signale reagierte. Die Vermutung ist dass direkt mit dem Tastaturtreiber kommuniziert wird. Aber dieses Verhalten für den Blogpost ist es eigentlich sehr positiv denn sonst wäre er nie entstanden. Man musste sich also einen anderen Weg überlegen Tastatureingaben an Dirt Rally zu schicken.

Continue Reading

0

EarthCore – Injecting, Sicherheit und Spieldaten

Earthcore: Shattered Elements ist ein Online Kartenspiel für Android und iOS, programmiert mit dem Unity Framework. Von den vier Handkarten spielt man drei auf das Spielfeld aus, wobei jede Karte eines von 3 Elementen hat: Feuer, Wasser oder Erde. Am Ende der Runde wird das eigene Kartenelement mit dem Element der gegnerischen, gegenüberliegenden Karte verglichen. Nun schlägt Wasser Feuer, Feuer Erde und Erde Wasser. Der Verlierer auf dem jeweiligen Feld bekommt Lebenspunkte abgezogen, die sich aus dem ausgespielten Kartenwert berechnen. Sollten sich gleiche Elemente gegenüberliegen, wird der Angriffswert jeweils für die nächste Runde gespeichert. Im Grunde also ein „Schere-Stein-Papier“ auf drei Feldern gleichzeitig. Spannend wird das Spiel, wenn man die Skills der Karten dazunimmt. Man kann Karten auf Feldern tauschen, die Elemente von Karten ändern oder auch Direktschaden am Gegener verursachen. Mehr möchte ich an dieser Stelle garnicht über das Spiel erzählen, hier geht es um die Internals, das Injecten und natürlich das Daten auslesen.

earthcoreNicht ohne Grund habe ich direkt im ersten Satz erwähnt, dass das Spiel mit Unity entwickelt wurde. Für den Programmierer ist das praktisch, da er Plattformunabhängig und sogar mit .NET Programmieren kann. Für uns hat das den Vorteil, dass wir den kompletten Sourcecode unobfuscated vor uns liegen haben! Dabei befinden sich alle interessanten Klassen in der Assembly-CSharp.dll, die wiederrum in den Ressourcen der APK liegt. Zwar hat man alle Daten unverschlüsselt vor sich liegen, nur ohne die Möglichkeit des Auslesens oder Veränderns bringen uns die schönsten Klassenstrukturen nichts. Wir müssen also eigenen Code in die Android Applikation bekommen. Während schon bei dem Hearthstone-Artikel das CLRHosting mit Mono fehlschlägt, haben hier hier nichtmal die Möglichkeit den Mono Kontext zu kapern. Nach einigem hin und herüberlegen fiel mir eine passable Lösung ein: Benötigt ist ein Loader, der wiederrum weitere DLLs zur Laufzeit nachladen kann. Dieser Loader wird mit in die APK gepackt und muss nun irgendwo im Spiel aufgerufen werden um den eigenen Thread zu starten. Was ist da passender, als die Init-Funktion des Hauptmenüs? In Unity erbt jede Klasse die Renderlogik enthält von „MonoBehaviour“. Davon wird die Start()-Methode aufgerufen sobald die Klasse initialisiert wird, und genau hier packen wir einen call auf unsere statische Loader-Klasse rein. Die will ich nun etwas genauer Besprechen:

Continue Reading

0

Age of Empires 2 – External Entity Hack

Ich glaube annährend jeder Besucher dieses Blogs hat früher, oder sogar in letzter Zeit als HD Remake, Age of Empires 2 gespielt. Dieses Kultspiel wird hier exemplarisch herrangezogen, um die Schritte beim Programmieren eines Hacks nachvollziehbarer zu machen. Genaue Offsets und Klassen gibt es nicht, wohl aber die Möglichkeit die Schritte nachzumachen. Damit stösst man unweigerlich auch auf die Offsets und lernt den Umgang mit IDA Pro und dem Debugger. Es ist definitiv nicht meine Intention, die Grundlage für einen Hack zu schaffen. Vielmehr hab ich gemerkt, wie schön man das Finden der Entites als Beispiel nutzen und abstrahieren kann.

Am Ende des Blogposts werden wir die Positionen aller Entites und aller Spieler auf eine Grafik plotten können. Natürlich wären weitere Features möglich, aber es geht nur um den Weg bis zu diesem Punkt 😉

Fangen wir mit etwas allgemeinen Informationen an. AoE2 ist wie eigentlich jedes ältere Spiel in C++ geschrieben. Konkret heißt das für uns, dass wir eine Entity-Basisklasse haben, von denen alle Einheiten und Gebäude erben. Im Speicher befindet sich also immer die Basisklasse, gefolgt von den speziellen Attributen je nach Klassentyp. Damit wissen wir auch, dass der erste Eintrag in diesen Entity-Klassen die VTable ist. Das Konzept dahinter wurde schon bei Siedler3 und Interfaces erklärt: Um bei einem Aufruf von „Building->Update()“ und „Unit->Update()“ bei unterschiedlichen Funktionen zu landen, wird der Update()-Funktionszeiger überschrieben, der sich an einer fixen Stelle innerhalb der VTable befindet. Das hat den Vorteil, das wenn wir ein riesiges Array von Entites haben, einfach alle durchlaufen und die Update()-Funktion aufrufen können. Die VTable sorgt dann schon dafür, dass die richtige spezielle Methode aufgerufen wird und wir müssen uns nicht darum kümmern.

Soviel zur gleich gebrauchten Theorie, los gehts in der Praxis mit Memory Scanning. Wie brauchen nämlich eine Variable, die sicher in der Entity-Klasse steht. Optional sollte sie noch leicht zu verändern und eindeutig sein. Was gibt es da passenderes wie das Leben der Entity? Starten wir Cheat Engine und stellen den Typ auf Float. Wir markieren eine Einheit, lesen das Leben ab und verändern es, indemaok1 wir die Einheit einen Gegner angreifen lassen. Zum Glück können wir über F3 das Spiel pausieren, so ist entspanntes Suchen nach der richtigen Variable möglich ohne in die Trickkiste greifen zu müssen. Übrig bleiben sollten zwei Variablen die jeweils das aktuelle Leben anzeigen. Mit der Adresse der Variable selbst fangen wir nichts an, denn spätenstens beim nächsten Spielstart sieht diese ganz anders ist. Spannender ist aber die Funktion von Cheat Engine, über den Debugger herraus zu finden welche Instruktionen auf die Variable zugreifen. Das ist natürlich auch im normalen Debugger über einen Memory-Breakpoint möglich, allerdings bekommen wir bei den doch vielen Zugriffen eine schöne Liste von CheatEngine.

Continue Reading

0

RRT – Eine Simulationsumgebung

Warum nicht auch Themen in einem Blogpost verarbeiten, die in der Uni Beachtung fanden und das Interesse auf eine eigene Implementierung wecken? In diesem ersten von zwei Teilen geht es darum, eine Simulationsumgebung für ein Auto zu schaffen, das später diverse Wege und Einparkroutinen findet. Das ganze Funktioniert über Rapidly-Exploring Random Trees, indem man einfach losfährt und dadurch einen Suchbaum aufspannt. Keine Wegfindung, keine Heuristik oder Gradientenfelder, aber vieeele Knoten und Versuche.

Langweilig denkt Ihr? Wenn ihr kein Interesse an dem eigenlichen Thema habt, so lernt ihr doch einiges über C# und objektorientierte Programmierung, welche uns das Leben wieder mal einfacher macht. Den aktuellen Sourcecode findet ihr unten im Anhang, da doch einige „unnötige“ Sachen wie Properties und Hilfsklassen nicht gepostet werden. Hier schonmal eine kleine Vorschau, was die Simulation am Ende vom Post mit wenigen Codezeilen kann:

rotation_colilision

Los ans Coden, beginnen wir mit der abstrakten Enviroment-Klasse. Von einer abstrakten Klasse kann keine Instanz (= kein Objekt) erstellt werden, und das ist auch gut so. Denn die Environment-Klasse dient nur als grobes Schema für alle weiteren Szenarien, daher halten wir sie sehr allgemein. Zunächst reicht es zu überlegen, was eine Simulationsumgebung braucht: Eine Höhe und Breite (ohne Einheit, aber rechnen wir in Metern) , natürlich ein sich bewegendes Objekt (Auto, Lastwagen mit Anhänger, Flugzeug) und eine Liste von Hindernissen, die es zu vermeiden gilt. In Code ausgedrückt sieht es sehr ähnlich aus:

Continue Reading

0

HearthstoneCalc – Injecting

Der Werdegang von HearthstoneCalc hat einen eigenen Post verdient, in welchem dann weitere Ansätze (Monte Carlo Tree Search) vorgestellt werden. In diesem Blogeintrag geht es allerdings um das Injecten und Daten abrufen aus Hearthstone. Denn ohne Daten aus dem Spiel müssen wir HearthstoneCalc garnicht mehr weiterentwickeln.

Uns wird es zum Glück leicht gemacht. Hearthstone ist mit der Engine Unity3D geschrieben. Für Blizzard hat das den großen Vorteil, das Spiel einfach auf mobile Geräte (Tables und Smartphones, Android und iOS) portieren zu können. Für uns hat es den großen Vorteil, dass Unity .NET (genauer gesagt: Mono) verwendet. Und da die Binaries noch nicht einmal obfuscated vorliegen, haben wir ein relativ einfaches Spiel.

Der für Unity relevante Code wird in der Assembly-CSharp.dll gespeichert. Die Anzahl der Klassen überschreitet alles, was ich bisher gesehen habe. Dementsprechend fällt es am Anfang schwer, uns zurecht zu finden. Auch muss man sich zunächst an die Unity-Eigenarten gewöhnen: Jedes Objekt ist eine Entity, die wiederrum mehrere Unterentities haben kann. Oftmals haben Klassen Unterklassen, enthalten viel zu viel Renderlogik oder scheinen nie erzeugt zu werden.

GameStateDiagDaher gilt zu klären: Welche Daten müssen wir alle Abrufen? Die Daten aus dem Spiel müssen in die Strukturen von HearthstoneCalc gebracht werden. Die wichtigste und größte Struktur ist hierbei die GameState-Klasse (Links). Sie enthält das Spielfeld mit den Monstern, die Karten des Spielers und die Infos über die jeweiligen Helden. Natürlich haben die Helden weitere Unterklassen, wie z.B. die ausgerüstete Waffe oder die gesetzen Geheimnisse. Auch Monster sind inzwischen komplexer geworden, denn sie können verschiedene Buffs besitzen und auf andere umliegende Minions Einfluss ausüben.

Die Klassen aus Hearthstone können wir nicht einfach übernehmen, denn sie enthalten viel zu viele Informationen. Diese Klassen sind nicht dafür ausgelegt, Millionen möglicher Boardzustände zu speichern. Zu diesem Problem werde ich nächsten Post über HearthstoneCalc noch mehr sagen.

Der große Vorteil von Mono ist natürlich, dass wir realtiv einfach .NET Code ausführen können. .NET Code in einem Programm ausführen? Klingt doch sehr nach CLR-Hosting!? Leider ist das nicht so einfach, denn die Unity-Klassen mögen es nicht, wenn sie außerhalb von mscorlib.dll Thread aufgrufen werden. Versucht man eine Unity-Funktion direkt aufzurufen, so erhält man folgende Fehlermeldung zu gesicht:

Continue Reading

0

HearthstoneCalc – Einstieg und Abstaktion

In diesem Post werde ich etwas über mein aktuelles Freizeitprojekt „HearthstoneCalc“ berichten. Ich werde fortsetzende Posts über das Tool danach richten, wie interessiert Ihr Leser an den Artikeln seid. Schauen wir mal 😉

Ich interessiere mich schon länger für Spiele KIs und bin der Überzeugung, dass Computer bei  der Planung von Spielzügen weit effektiver sind als ein menschliches Gehirn. Dabei geht es nicht um die Kreativität die ein menschlicher Spieler an den Tag legt, sondern die reine rationale Beurteilung der Spielsituation. Schachcomputer sind inzwischen ungeschlagen, weil sie einfach Unmengen an Situationen vorraussehen und bewerten können. Seid einiger Zeit fasziniert mich das Spiel „Hearthstone„, ein Rundenbasiertes Kartenspiel ähnlich Magic oder Yu-Gi-Oh. Man kann Diener oder Zauber spielen, die eigenen Heldenfähigkeiten nutzen oder mit Waffen die Kontrolle über das Board behalten. Der Spielverlauf wird später nochmal genauer erklärt, jetzt geht es erstmal um das Programm „HearthstoneCalc“.

Ziel des Programms ist es, alle möglichen Züge zu eruieren und den besten auszuwählen. Dabei sollte das Programm den aktuellen Spielstatus auslesen, die Berechnungen durchführen und den Spielzug selbstständig ausführen. Im Gegensatz zu Spielen mit perfekten Informationen wie Schach oder Vier-Gewinnt haben wir bei Hearthstone drei große Probleme:

  1. Die gegnerischen Karten sind unbekannt. Zwar werden von den Spielern meist ähnliche und als effektiv geltende Decks gespielt, allerdings varieren auch hier die Karten. Die Karten des Gegners die er auf der Hand hat sind verdeckt und bieten daher keine perfekten Informationen über zukünftige Spielzüge
  2. Hearthstone braucht keinen Skill, sondern nur Glück„. An diesem Zitat ist leider viel wahres dran. Viele Zauber wirken auf alle Einheiten verteilt und viel Schaden (z.B. von explodierenden Bomben) ist variabel. Glück gehört einfach zum Spiel dazu, daher kann man den Ausgang eines Zuges nicht effektiv berechnen. Man muss mit Wahrscheinlichkeiten rechnen, und davon nicht wenige. Später gibt es ein Beispiel, wie komplex ein solcher Zug sein kann.
  3. Manche Decks verfolgen eine spezielle Strategie und sammeln daher Karten, um einen großen Zug zu machen. Solch eine „Strategie“ bringt man dem Computer schlecht bei, vorallem da er nebenher darauf achten muss, nicht gegen den Gegner zu verlieren.

Ihr merkt, das Projekt wird komplex. Und ein solches Projekt fängt man am besten an, indem man abstrahiert und vereinfacht. Ein solch einfaches Modell kann dann später erweitert werden. Effektiv heißt das auf die beiden oberen Punkte bezogen: Wir schauen zunächst nur den aktuellen Zug unseres Spielers an und lassen die mögliche gegnerische Reaktion außer Acht. Zudem berechnen wir nur die Züge ohne Wahrscheinlichkeiten bzw Rechnen mit dem schlimmsten Ausgang für uns.

Continue Reading

0

Sicherheit in Onlinespielen – Wichtige Grundregeln

Egal ob Browsergame oder Multiplayer PvP, Onlinespiele sind in der heutigen Zeit sehr gefragt. Es macht einfach mehr Spass, gemeinsam mit Freunden zu Spielen, statt sich mit einer pseudoklugen KI an der Seite herrum zu schlagen. Der Trend geht klar Richtung Onlinespiele, was wiederrum auch Gamehacker anlockt. In dem heutigen Artikel werden Grundlagen besprochen, auf die man beim Programmieren achten sollte. Anschaulich wird das ganze durch Beispiele erklärt.

Das Spektrum von Hacks, über Bots und Exploits ist zu groß, als dass man es alles in einem Artikel abdecken könnte. Daher werden primär nur Echtzeit-Onlinespiele betrachtet. Diese Techniken lassen sich aber beliebig auf andere Multiplayer-Spiele übertragen. Und noch kurz zu den verwendeten Begriffen in diesem Artikel:

  • Server: Dabei handelt es sich um einen zentralen (!) Server, der das eigentliche Spiel hostet. Er nimmt Daten von anderen Spielern entgegen und verteilt die „Änderungen“ im Spiel an alle verbundenen Clients. In machen Spielen wird der Server auch als „Host“ bezeichnet, was im Prinzip nichts anderes bedeutet.
  • Client: Ein Spieler, der mit dem Server verbunden ist und aktiv Stati (Schießen, Laufen) an den Server sendet

Der wohl bedeutenste Grundsatz dürfte sein: Traue nie den vom Client empfangenden Daten. Der Client schickt, wie schon oben erwähnt, in regelmäsigen Abständen Daten wie seine eigene Position und seine Attribute an den Server. Wenn ein Gamehacker die Welt-Position des Clients verändert, wird diese auch zum Server gesendet. Wenn der Server diese Daten nun ungeprüft übernimmt, haben wir einen sog. Teleport-Hack. Solche Teleport-Hacks befanden sich u.a. in großen Onlinespielen wie Metin 2.

Während sich der entstehende Vorteil durch Teleportierungen noch in Grenzen hält, hört der Spass bei sog. Masskill-Hacks auf. Dabei sendet der Client die Nachricht „Ich habe XX Schaden am Gegner Y gemacht“. Der Server übernimmt dieses ungeprüft und tötet den Gegner Y. In Battlefield 3 ist dieser Hack inzwischen gefixxt, die Kollisionserkennung ist allerdings immernoch Clientseitig. So sind „Instant Kills“ möglich, indem man einfach den Schaden, den eine Waffe verursacht, ins unendliche erhöht. Daher die Regel Nummer 2: Auf Plausibilität prüfen! Im Falle einer clientbasierten Kollisionserkennung kann man durch Wände schießen. Wenn der Server nun einmalig prüft, ob Spieler X den Spieler Y überhaupt treffen kann, wären solche Hacks schon verhindert. Warum das nicht gemacht wird? Weil solche Checks relativ viel Rechenleistung brauchen und einen Server mit 64 Spielern überfordern würde.

Continue Reading

0

Siedler 3 – Lobby Preview

Die letzen Tage habe ich wieder viel mit Siedler 3 verbracht. Allerdings nicht mit Spielen, sondern mit Reversing und Coding.

Durch einige Tricks habe ich es geschafft, einzelne UI Elemente zu „kontrollieren“ und Aktionen mit ihnen durchzuführen, die eigentlich nur nach einem Mausklick auf das jeweilige Element erfolgen. Denn die „neue“ Lobby wird über das LAN-Menu laufen, nur dass der Bildschrim komplett ersetzt wird. Um aber ein Spiel aus dem LAN-Modus zu starten, sind folgende Schritte notwendig:

  • Spieler klickt auf den Adapter in der ersten Listview (DirectPlay Adapter)
  • Spieler klickt in die Textbox und gibt die IP des Hosts ein
  • Spieler klickt auf „Suche Spiele“ -> Spiele werden angezeigt
  • Spieler wählt ein Spiel aus der Lisview aus
  • Spieler klingt auf „Mitspielen“.

Diese 5 Schritte kann ich nun per Programmcode aufrufen, auch wenn es noch nicht immer klappt (Bei einem Fehlerdialog hängt sich das Programm auf, da dieser eigentlich nicht vom UIThread aufgerufen wird etc).

Das bedeutet, dass einer neuen Lobby nun nichts mehr im Wege steht. Oder doch? Die eigentliche UI für die Lobby muss ja noch geschrieben werden. Und dabei kann (wegen des alten GDI standarts, leider nicht mal GDI+) auch keine UI Library verwendet werden. Selber schreiben heißt die Devise! In den letzten Tagen habe ich daher einige Basis UI Klassen angefertigt (TextLabel, Button, ListView) um daraus eine Lobby zu konstruieren. Das Resultat:

Settlers3Lobby_WIP

Continue Reading

0

Siedler 3 – Die GUI

Die GUI! Wofür interssierten wir uns überhaupt für die GUI? Die GUI mag zwar ein Randaspekt sein, aber 3 Gründe sind genug, dass wir eine Analyse vornehmen:

  • Wir wollen später eine eigene Lobby schreiben, und dabei wenn möglich diese GUI Elemente wie Buttons verwenden
  • Viele Werte, wie z.B. der nachher besprochene Mapname, tauchen zunächst nur in der GUI auf.
  • Die GUI ist die Brücke zwischen Benutzer und Programm. Wenn wir wissen wollen, welche Funktion aufgerufen wird wenn ein bestimmter Button gedrückt wird, müssen wir wissen wie die Eventhandler für diesen Button aussehen. Und danach landen wir genau in der gesuchten Funktion (Beispiel: Neues Spiel Button -> Direkt beim Game-Konstruktor)

Anhand der GUI kann man schön sehen, wie OOP verwendet wurde. Alle Menüs erben von einem „Grundmenü“. Die Menüs implementierren die Funktionen wie zeichnen und handeln von Benutzereingaben, so dass eine schöne Kapselung entsteht. Und zum Wechseln des Menus wird einfach der Zeiger des aktuellen Menus aktualisiert, schon wird das nächste Menu angezeigt.

Beginnen wir mit etwas Code, der das Menu wechselt:

v4 = (int)this; // v4 ist das Register EBX
this->CurrentMenuIndex = a2; // Im Argument 2 wird übergeben, welche ID das neue Menu hat
v5 = v4->lpActualScreen; // Zeiger auf das aktuelle Menu Element
if ( v5 ) if (lpActualScreen != null)
{
    v7 = (int)((char *)&v5->dword4 + *(_DWORD *)(v5->dword4 + 4)); // dynamsichen Funktionszeiger holen
    (**(void (__thiscall ***)(_DWORD, _DWORD))v7)(v7, 1); // und aufrufen
}

Auch wenn der von IDA Pro erzeugte Code schrecklich aussieht, so kann man daraus einiges rauslesen. Fangen wir mit der ersten komischen Zeile an. Wieso speichert das Programm den this-Pointer in einer lokalen Variable (bzw genauer gesagt einem Register?). Da der This-Pointer in ECX übergeben wird, aber weitere Funktionen mit einem vielleicht anderen This-Pointer aufgerufen werden, wird der This-Pointer in EBX gespeichert. Das ist für die Funktionsscope nun der gesicherte This-Pointer. Nun wird das aktuelle Menu überprüft (lpActualScreen != null). Wenn ein Menu gesetzt ist, so wird in v7 ein Funktionszeiger geladen, der sich aus Werten des aktuellen Menus zusammensetzt. Im Anschluss wird die Funktion aufgerufen, und dies passiert dynamisch. Per IDA Pro kann man solche Calls nicht zurückverfolgen, per Debugger allerdings schon. In diesem Falle wird eine „Uninitialize“-Methode aufgerufen, die ein paar Aufräumarbeiten erledigt. Da jedes Menu andere Aufräumarbeiten zu leisten hat, ist auch die Funktion jeweils anders.

Continue Reading

0

Siedler 3 – Draw Hook und GDI

Mit dem Wissen über COM Objekte aus dem letzen Beitrag gerüstet, sind wir nun in der Lage, Code vor bzw hinter die jeweiligen DirectX Funktionsaufrufe zu packen. DirectX 8 nutzt zum Zeichnen sog. Surfaces, also eine Fläche, auf die gezeichnet wird. Im normalfall wird jeweils das Backbuffer Surface beschrieben und im Anschluss mit dem primären Surface ausgetauscht (Flip). Das macht Siedler 3 im Hintergrund für uns, daher müssen wir uns nicht darum kümmern.

Wir könnten einerseits über die Funktion „Lock“ und „Unlock“ direkten Zugriff auf das Surface bekommen, um dort einzelne Pixel zu setzen. Da dieses aber nicht so effektiv ist, gibt es andere Wege. Man könnte die sog. „Blit“ (bit block transfer) Funktion aufrufen, um Teile aus einer Grafik in das Surface zu schreiben. So wird das zum Beispiel mit den Menuelementen, oder auch mit Sprite-Grafiken gemacht. Da wir aber zunächst nur Text ausgeben wollen, bietet uns DirectX 8 ein nettes Feature: GDI.

S3_GDI

GDI steht für Graphics Device Interface und bietet uns Funktionen zum Zeichnen, wie wir es z.B. von dem .NET Graphics Namespace gewöhnt sind. Über die Funktion „GetDC“ erhalten wir einen sog. „Device Context“, welcher einem Zeichenhandle entspricht. Mit diesem können wir nun alle Funktionen aufrufen, die ein solches Handle entgegen nehmen, z.B. FillRect oder auch TextOutA/W. Zum simplen Zeichnen nehmen wir also folgenden Code:

// In einer Init Methode
LPLOGFONT fontArial = new LOGFONT();
 
ZeroMemory(this->fontArial, sizeof(this->fontArial)); // Wir setzen lieber nochmal den Speicher auf 0
wcscpy(this->fontArial->lfFaceName, L"Arial"); // Wir kopieren den Fontnamen den wir haben wollen rein
this->fontArial->lfQuality = ANTIALIASED_QUALITY; // Und setzen noch ein bisschen Anti Analising
 
// In der Methode zum Textzeichen
HFONT hFont = CreateFontIndirect(font);		// Eine "richtige" Font aus unserer LOGFONT
SelectObject(this->currentHdc, hFont);		// GDIHandle, nutze für das nächste diese Font
SetBkMode(this->currentHdc, TRANSPARENT);	// Mach den Background Transparent, sonst gibts Rahmen
SetTextColor(this->currentHdc, color);		// Setze die Color (color ist eine COLORREF struct)
TextOutA(this->currentHdc, x,y, pText, strlen(pText));	// Und schreibe den Spass in unser Surface

Continue Reading

0

Seiten:12