[Beispiel] Isomap erzeugen

Hallo,
anbei ein Beispiel wie man aus zwei schwarz/weiß 2D Bildern eine Grafische 3D Isomap gennerieren kann. Auf einen Inputgrafik Wasser/Land unterschieden. Auf der andern Grafik wird durch die Helligkeit die Höhe angeben ermittelt.
Das Script hatte ich auch schon auf Browsergames.net veröffentlicht.
Der Quellcode stammt nicht von mir sondern von einem Arbeitskollegen der mir erlaubt hat das hier zur freien Verfügung reinzustellen. Nähere Infos wie Ihr das Ding zum laufen bekommt kann ich euch somit leider nicht geben.
Wenn ihr sowas einbauen wollt denkt bitte daran das Grafikgennerierung ordentlich Rechenperformance kostet und deswegen sollte man damit sparsam umgehen. Zum ausprobieren und erweirtern läd das Ding auf jeden Fall ein.
Viel Spass Damit

sieht cool aus, nur wie sollen sich spieltechnisch solche pixelmaps verarbeiten lassen?

^^ die verarbeitung lässt sich ja nicht nur auf pixelmaps benutzen.
Die Idee Bilder als Datenquelle zu missbrauchen um so Datenbankzugriffe zu sparen wäre zumindest eine Idee die sich auf die meisten Kartensysteme übertragen lässt. Man könnte auch noch ein drittes Image nehmen und darüber die Insel zu bebauen. Auch einer der Hauptvorteile ist das man sich beim designen seiner Landschaften keinen extra Editor bauen muss sondern mit jedem Grafikprogramm vorlieb nehmen kann.
Wenn ich ein BG im Stil von Civilisation programmieren würde, dann wäre das für mich ein System auf das ich zurückgreifen würde um die Große Weltkarte zu entwerfen.

Original von fiese Moep
^^ die verarbeitung lässt sich ja nicht nur auf pixelmaps benutzen.
Die Idee Bilder als Datenquelle zu missbrauchen um so Datenbankzugriffe zu sparen wäre zumindest eine Idee die sich auf die meisten Kartensysteme übertragen lässt.

Die Idee ist irgendwie interessant,
bleibt nur die Frage, ob das denn überhaupt schneller wäre als ne Datenbank?

Ich glaube nicht, dass das schneller wäre als eine Datenbank, da Bildbearbeitung immer ziemlich langsam ist. Außerdem erzeugt so eine Karte auch etwas an Traffic, da diese immer neu geladen werden muss. Der Vorteil einzelner Tiles wäre, dass man diese cachen könnte bzw. als Image-Pack anbieten.

Zugriff auf ein Image als Datenquelle ist sehr schnell. Es muss kein Query geparst werden und nicht in mehreren hundert Megabyte Daten gesucht werden. Eine BMP ist auch nix anderes als eine Textdatei schnellere Zugriffe wirst du nicht finden.
Was das gennerieren von Grafiken angeht das ist sehr langsam. Die Grafik jedes mal neu zugennerieren wenn sie dargestellt werden ist Wahnsinn. Aber man kann die Grafiken über einen Cron aktuell halten oder nur einmal neu Gennerieren wenn sich was geändert hat.

Bilder (Bitmaps) sollten sogar am Abstand die schnellste Speichermöglichkeit sein...
Tabellen kann man nicht unendlich breit machen, und das in die Länge aufzudröseln ala x,y,höhe fürht zu riesigen Tabellen mit noch größeren Indexes.
Bei einem Bitmap liest man sich einfach die entsprechenen Bytes aus, die Position kann man sich ja einfach ausrechnen. Auf GD oder ähnliches würde ich allerdings verzichten, sondern direkt auf die Datei zugreifen. So erspart man sich u.a. das komplette Einlesen der Datei und die Konvertierung in ein internes Format...
Und ist ja nicht auf 1 oder 3 bytes pro Punkt beschränkt, sondern kann beliebig viele Bytes pro Punkt verwenden... 4 oder 8 Bytes passen auch gut zu den heutigen 32 oder 64 bit Rechnern.
Aber Daten, die man nur zu einem Prozent aller Punkte braucht, wie z.B. Gebäude oder Planeten würde ich in die DB speichern, weil sonst die Bitmap sehr viele Nullen enthalten wird...
Wobei man dass durch eine blockweise Komprimierung, wie es z.B. NTFS macht ausgleichen kann, ohne viel an Performance zu verlieren.

Aber wieso sollte ich dann überhaupt ein Bitmap verwenden. Ich kann doch dann im Prinzip auch eine ganz normale Textdatei erzeugen, in denen 0er und 1er, etc. gespeichert sind? Und im Bitmap kann ich ja im großen und ganzen auch nur die Positionen speichern, aber keine zusätzlichen Daten. Wie z. B. bei der Landschaft irgendwelche Variablen, ob die Landschaft blockiert, verlangsamt, etc. Das ist etwas mühsam.

Das kannst du bei der Bitmap auch einfach.
Wenn du z.B. eine 24bit-BMP hast, dann hast du einmal den R-Wert (0..255), den G-Wert (0..255) und den B-Wert (0..255), welche du unabhängig mit Variablen belegen kannst. Und in einem 8bit-Wert kannst du wiederrum 8 verschiedene Ja/Nein-Informationen ablegen, indem du Bitwerte vergleichst.
z.B. hat an der Position (1|4) R den Wert 13 (also 00001101).Jetzt hast du die Option, dass das folgende Land Panzer langsamer fahren lässt. Diese Option hat den Wert 1 (also 00000001). Jetzt vergleichst du beide Werte mit dem &-Operator ($r & $option = $option) und wenn da true rauskommt, fahrne Panzer dort langsamer. Die Option Infanterie langsamer hat dann den Wert 2 (00000010) und in meinem Beispiel kommt da false raus, also gibt für Infantere normale Geschwindigkeit.
So kannst du z.B. im R-Wert speichern, welches Gebäude auf dem Flecken Land steht, im G-Wert einige andere Optionen und im B-Wert den Besitzer des Feldes.
Mit Hilfe von Bitoperatoren kannst du die Felder auch addieren, will jetzt nicht nachgucken, aber wenn du ($r<<16)+($g<<+$b) machst, solltest du eine 24Bit-Integer rasubekommen, wo immer noch alle Werte enthalten sind, es wurden einfach die Bits aneinander gehängt. (Ich bitte darum, dass mit den letzten Absatz einer bestätigt oder widerlegt, da ich mir hier jetzt nicht ganz sicher bin).
Wenn du nun eine Bitmap mit 8 Byte pro Pixel hast, kannst du dort 2^64 verschiedene Informationen speichern also mehr, als du wahrscheinlich je brauchen wirst...
Ausserdem wird die Karte dadurch auch kleiner, denn eine ASCII-null bzw. ASCII-eins verbraucht ein Byte, in einer BMP nur ein Bit...

Aber wieso sollte ich, bis auf die Lanfschaft (wie hier Highmaps) in ein Bild speichern?! Was hab ich davon? Dass ich in Paint meine Daten "malen" kann? Wenn ich die Daten so wie Du beschrieben hast speicner will, dann kann ich ja das Bild an sich nicht mehr bearbeiten. Oder ich brauch für jeden Typ eine andere Farbe. Und dann ist es irgendwie schon wieder total sinnlos? Da nehm ich doch gleich eine txt-Datei und speicher dort meine Daten ab.

Ein Bitmap muss kein Bild sein, du kannst auch alles in eine X-beliebige Datei speichern und jedes Bit von Hand schreiben/lesen.

Ein Bitmap muss kein Bild sein, du kannst auch alles in eine X-beliebige Datei speichern und jedes Bit von Hand schreiben/lesen.

Das ist mir schon klar, nur was bringt er mir? Wieso sollte ich es als Bild speichern, wenn ich doch eine Textdatei (Geschwindigkeit) oder Datenbank (denke mal, die ist etwas komfortabler, vor allem, wenn es um Änderungen und Updates geht) nehmen kann? Ich sehe da keine rechen Sinn drinnen.

Du musst einfach mal von dem gedanken loskommen das eine Bitmap ein Bild ist -.-

Eine Bitmap ist in der Informatik:
* im allgemeinen eine Folge von voneinander unabhängigen Bits, die jeweils die gleiche Bedeutung haben;
Auch wenn mir die definition auch nicht ganz passt -.-
Das bild ist ledeglich eine Interpretation der Daten.

Original von progsDas ist mir schon klar, nur was bringt er mir?

Wie oben schon geschrieben braucht eine textdatei mehr speicher als eine bitmap und ist schneller als ne datenbank.
Natürlich ists weniger komfortabel als ne Datenbank.
Und lässt sich ne Bitmap überhautp mit PHP schreiben/lesen?

Du musst einfach mal von dem gedanken loskommen das eine Bitmap ein Bild ist -.- [/qote]
Oben wurde geschrieben, "Bilder" als Datenquelle zu nehmen.

Die Idee Bilder als Datenquelle zu missbrauchen um so Datenbankzugriffe zu sparen wäre zumindest eine Idee die sich auf die meisten Kartensysteme übertragen lässt.

Ein Bild ist ein Bild. Und was bringt er mir, die Daten in einem Bild zu speicher? Es bringt mehr, es in eine Textdatei (oder Bitmap, wenn es kein Bild ist) zu speichern. Das Bild als Datenspeicher bringt meiner Meinung nichts.

Wenn du haufenweise Text abspeicherst, bringt dir ne Bitmap nichts, das ist richtig, aber ein Integer ist als Bitfolge abgelegt deutlich kleiner als eine ASCII-Folge. Das ist der einzige Nutzen der Sache.
Wie schon vorher gesagt, ist eine Bitmap nicht unbedingt ein Bild, das ist nur eine Art, das zu interpretieren. Eine Bitmap ist einfach eine lange Reihe von nahezu beliebig vielen binären Einsen und Nullen. Ob dein Programm nun 24 aufeinander folgende Bits als einen Bildpunkt interpretieren soll oder meinetwegen 100 Bits als ein Feld auf deiner Landkarte, ist Definitionssache. EINE BITMAP IST KEIN BILD.
Dass du diese Bitmap wie ein Bild behandelst, liegt nur daran, dass du mit PHP so am einfachsten an die einzelnen Bits bzw. Bytes ran kommst, mehr nicht.
Eine Textdatei ist auch nichts anderes als eine Bitmap, nur dass eben 8 aufeinander folgende Bits als ein ASCII-zeichen interpretiert werden (zumindest bei ASCII-Codierung).
Der Vorteil ist einfach, dass du auf weniger Speicherplatz mehr Informationen unterkriegst und das ist sowohl für die Platte aber wichtiger auch für den Arbeitsspeicher entlastend, UND du kannst mit der Bildbearbeitungsbibliothek von PHP einfach auf ganz bestimmte Positionen zugreifen.

Ob du Daten in einem Bitmap oder in einer Textdatei speicherst ist
erstmal egal, denn ein Bitmap speichert genauso wie eine Textdatei.
Der Einzige unterschied ist ein geringer Overhead für Bitmapfileheader ( 14 Byte ) und den so genannten Bitmapinfoheader ( 40 Byte )
Danach fangen bei einer Bitmap schon die Bilddaten an.
Man sieht also, dass das Speichern in einer Bitmap nicht wesentlich mehr Speicher nutzt als eine textdatei.
Natürlich ist eine Bitmap datei kein Bild, aber es ist eine Art ein Bild abzuspeichern...

Eine Textdatei ist auch nichts anderes als eine Bitmap, nur dass eben 8 aufeinander folgende Bits als ein ASCII-zeichen interpretiert werden (zumindest bei ASCII-Codierung).

Das stimmt natürlich nur auf der binären ebene, da der Bitmapinfoheader und der Bitmapfileheader fehlen.

schon mal überlegt was eigentlich passieren muss... dass eine Software die Farbe des Pixels X/Y auslesen kann?
Richtig, zuerst muss (GIF oder JPG sei Dank) mehr oder weniger die komplette Datei / das komplette Bild geladen werden.
Fazit: Es ist grotten schlecht und ressourcenfressend.
Entweder BMP ohne Kompression (dann fällt das weg) oder gleich binäre Files.
Gruss

Bei gif und oder jpeg muss man zuerst die ganze datei laden, damit
man an die daten rankommt, da erstmal das Bild decodiert werden muss.
Wenn es wirklich schnell sein soll, dann muss es bmp sein, vorrausgesetzt es wird aus dem chace geladen. Ob das aber schneller als eine Datenbank ist würde ich in Frage stellen.
Bei bmp kann man wenigstens noch hingehen uns sagen:
ich möchte bei einem 640 * 480 Bild x = 30, y = 12 haben, dann
muss ich nur bis pixel nummer 7710 lesen und kann die restliche Datei liegen lassen. Aus diesem Grund denke ich, dass Datei im RAW Format am schnellsten ist.
aber das sind nur vermutungen, wie gesagt, dass müßte wirklich mal gemessen werden, wie schnell datei bmp oder jpg bzw wie schnell Datenbank ist.

bzgl des Topic möchte ich mal auf meine Lösung hinweisen, die ich im Blog hier mal vorgestellt hatte:
www.galaxy-news.de/mypage/33_theundeadable/blog/

Original von TheUndeadable
www.galaxy-news.de/mypage/33_theundeadable/blog/

Wieso GZip???
10'000 x 10'000 x 8Bit => 100 MByte.
Wen stört schon 100 MByte?
Ists zu viel? Dann machs einfach. Beide Achsen durch einen Wert teilen (beispielsweise 10).
gibt also eine 10 x 10 matrix; Diese hat Pointer auf wiederum ein Feld mit 1000 x 1000 Feldern.
Nun möglichkeit 1:
- Alle Felder haben 1 Wert
- Das Segment hat ein spezifisches Pattern
- Der gleiche Algo nochmals durchgeführt
Der Clou?
- Einzelne, sich wiederholende Pattern, werden nur einmal gespeichert
- Leere Felder brauchen absolut kein Platz
- Suche erfolgt äusserst speditif. Mittels maximal 4 Zugriffen hast das Zielfeld erreicht. Wenn dir das zu viel ist, nimm anstelle von 10er Teilung eine 20er
Für die HiSpeed geilen. Den Index (also nicht die Daten nur der Index) im Ram halten. Indexgrösse dürfte max. ca 1 MByte sein.
Somit benötigst du maximal 1 MByte ram und 5 bis 10 MByte hd.
50 % der Zugriffe haben 0 HD Zugriff
50 % der Zugriffe genau einen Block-Read
Machst einen Block Cache darüber; Schon hast du einen HD Zugriff jeden 100ten read.
100'000 x 100'000 Kartensystem probehalber in C++ umgesetzt (vor 4 Jahren).
Gruss