Problem

[Wilhelm von Preußen]

Edle Herren, unsere MAp bereitet mir grösste Sorgen. ICh erwarb diese karte für viel Geld und erhielt eine exzellente MAP in photorealistic qualität.
Problem ist, indiziert(256Farben) wird diese MAP ca. 180 mb platz einnehmen. Weiteres, viel grösseres Problem ist, dass man ein P8 Surface nicht in ein "normales" backbuffer format blitten sollte, da DX diese konversion nicht unterstützt. Es sei denn Formate der DXT1-5 könnten uns da helfen, da die DXT`s Konversation in backbuffer von DX noch unterstützt wird. Leider wiess ich nicht genau, was diese DXTs sind, in der dx doc ist von komprimierten 8 bit surfaces die Rede.
Als Alternative könnten wir einen Algho schreiben, der 8 bit surfaces in backbuffer formate blittet, da habe ich allerdings keine lust drauf.
Nächste Alternative, die Bilder einfach in 16 bit surfaces laden, welhe allesamt Konversationsfähig sind. GROSSES Problem, die Bildgrösse in MB erhöht sich IMMENS!!! (400 mb ca)
Als letzte Alternative: CreateTextureFromFile, dann Kartenteile als Sprites auf die Oberfläche zeichnen. Sprites können in fast beliebigen formaten dargestellt werden, auch P8. Nur las ich von irgendwelchen Restriktionen auf so manchen Grafikkarten, dass z.b. eine textur max 256x256 Pix gross sein darf und dass DX nur 8 texturen gleichzueitig bearbeiten kann. Aber das scheint eine sehr alte Aussage zu sein, ich testete bereits mit einem Kartenausschnitt P8 Fromat 3048x1800, zeichnete diesen und es lief einwandfrei.
Meine Frage nun, was wisst ihr über sprites und deren texturen in bezug auf resourcen von grafikkarten.
Würden wir alles als sprites im indizes 256 mode laden, hätten wir ca. 180 mb NUR an kartenmaterial für die textur der Karte!
Ich habe die karte im absoluiten Rohzustand, also knallweiss nur mit gewässern in Blau. diese 180 mb wäre die normale Ansicht auf die karte(grün, gebirge etc), dann wird es noch eine tectur geben wo nur Provinznamen eingezeichnet sind, in die ROHmap werden nur die Provinzgrenzen eingezeichnet. Wirtschaftskarte wird im SPiel erst generiert, je nachdem was ein land wo anbaut. Die Rohkarten werden nur minimal platz einnehmen und im SCRATch gespeichert.

[Wilhelm von Preußen]

hmm keine Reaktion obwohl es sehr ernst ist!! Ich komme im Moment nich weiter. Es handelt sich bei der Weltkarte um Satelitenphotos. Einzige klar ersichtliche Regelmässigkeit ist Wasser. Unsere Spielewelt beträgt ca 26000x 14000 Pixel, jeder kann sich selbst ausrechnen was das an Speicher kosten würde wenn ich diese komplett in ein 16 bit surface lade(ca. 800 mb ram). Also müssen wir eine andere Möglichkeit finden. Ich dachte bereits daran, nur Festland in 8 bit Surfaces zu packen, und alle surfaces haben eine palette(was jedoch sehr sehr schwer wird das mit einer einzigen palette zu machen.) Das dürfte ganz grob geschätzt 200 mb werden. Andere Spiele verwenden in 2d Spielen nur ganz wenige Landschaften, Gebirge, Flachland und diese werden dann an die betreffenden Stellen eionfach kopiert. Das geht leider bei der Sat karte nciht, da jeder Pixel anders ist.
Enweder wir überlegen uns was um diesem Problem zu entgehen, oder wir brauchen einen grafiker der uns bsp 5 Landschaftstexturen erstellt(gebirge, wald, Wüste, Steppe usw), wobei jede Textur sehr klein sein kann.
Noch eine mlögöichkeit ist die Karte komplett in 3D zu erstellen mit heightmaps und dem ganzen Zeugs, jedoch bin ich dort noch nicht so bewandert.

Was tun edle herren?

[Wilhelm von Preußen]

ach und nicht vergessen werden sollte die colorkeying map, mit welcher provinzen erkannt werden können etc. Müsste ebenfalls in 16 bit format sein

[Wilhelm von Preußen]

kann dieses forum niemand sehen-???

[TheEvilForce]

Hier ein kleiner Lösungsvorschlag :
Unterteilt die Karte in einzelne Teile der Grösse 1600x860 Pixel. Der Trick ist ganz einfach ...

1-1600 1601-3200
xxxxxxxxzzzzzzzz
yyyyyyyy

Wie ihr seht braucht ihr mehr als 100 Teile. Der grosse Vorteil aber ist, dass ihr mit 9 Teilen die gesamte für den Spieler sichtbare Welt zusammen mit einem grossen Puffer habt. Nehmen wir an der Spieler befindet sich an der x-Koordinate 1500 bei einer Auflösung von 1024x768. Dann braucht ihr die Teile x und y (für die x-Achse) und habt, wenn er scrollt, die Möglichkeit das innerhalb dieses Bereiches zu machen.
Was passiert, wenn der Spieler an den Rand kommt?
Nehmen wir an, der Spieler befindet sich an der x-Stelle 2000...
1-1600 1601-3200-4800
xxxxxxxxzzzzzzzzbbbbbbbb
yyyyyyyyaaaaaaa
Nun ganz einfach. Ihr braucht in diesem Falle den Teil x nicht mehr und braucht ihn auch nicht laden. Dafür ladet ihr einfach a.

Ich hoffe, das war jetzt einigermassen verständlich. Ihr müsstet dies in x und y Richtung machen. Und diese kleinen Teile in den Speicher zu laden sollte kein Problem darstellen.
Der andere Vorteil ist, dass man dieses System an die Auflösung anpassen kann und somit bei geringere Auflösung die Leistung verbessert wird.

[Wilhelm von Preußen]

hmm so ganz hab ichs nicht verstanden hehe. Da ich noch kein Spiel mit so einer grossen gamemap programmierte weiss ich leider nicht, inwiefern streaming bei einer scrollbaren karte dieser grösse funktioniert. Ich denke mal ihr meintet streaming, woran ich auch schon dachte aber wie gesagt ich weiss nicht wie die performance dann aussieht.Ganz grob gesagt, lade Grafik wo Spieler an xy pos ist, lösche Karte an alter x,y pos des Spielers AUS DEM SPEICHER. Da könnte man sicher noch etwas dra herumfeilen, das z.b. auch die nachbargrafiken der grafik an xy pos geladen werden.
Bevor ich losleg die karte in soviele Teile zu unterteilen(übrigens sind kartenausschnitte im 2er komplement portabler! 512x512, 1024x1024 etc) muss ich genau wissen ob man dann nciht eher eine flackerkarte zu Gesicht bekommt, wenn man stets von den bitmaps liest und nicht vom ram, agp oder direkt im vram. Ich meine ok, man könnte halt wie gesagt alle nachbargrafiken in den videoram direkt mit reinladen und so die perormance stark verbessern. Aber ob folgendes so schnell funktioniert das der Spieler kein flackern sieht: xy in NOrdamerika, nun klickt er Spieler auf der mini map auf australien. Grafik australien wird neu initialisiert, von Bitmap in den SPeicher geladen(createsurfacefromfile) und sichtbar gemacht, amerika danach gelöscht. Bei solchen Sprüngen weiss ich nicht ob flackern entsteht. Aber auch hier kann man optimieren, linksklick gedrückt auf map löst bereits den ladevorgang aus, linke maus losgelassen präsentiert die grafik.

edler evil, könntet ihr nicht mal euren grandiosen prof fragen welche erfahrungen er gemacht hat oder was er von diser idee hält?

Sollte ich euch nicht verstanden ghaben, bitte um erneute eräuterung.

[TheEvilForce]

Das mit den Nachbargrafiken ist drin. Wenn ihr zum Beispiel in der Minimap auf einen Punkt klickt, so läuft der gesamte Prozess an der neuen Stelle ab, das sollte also kein Problem sein, notfalls kann man 1 Sekunde laden, das sollte reichen... Zur Performance kann ich nicht viel sagen, dass müsste man mit einer Testmap mal ausprobieren...

PS : Hat sich jemand schon mal ein Victoria-Savegame angesehen? Ich hab eines da und es ist richtig grausig, will gar nicht wissen, wie lange dort der Ladevorgang dauert...

[Wilhelm von Preußen]

oh ja ein vic savegame = 10mb. auf meinem Rechner(3ghz, 1024DDR) geht speichern + laden ja noch. Mit schlechterem RAM und PRozessor siehsts böse aus.

nochmal zur grafik, bei einem Wechsel auf der MAp in eine ungeladene Region müssten ca. 1.5 Mb von einem file in ein Surface geladen und geblittet werden... ka ob das gutgeht. Ich harre eures Tests.

[Bismarck]

vielleicht könntet ihr die Wasser-Grafik vereinfachen und dort eine einfache Textur verändern. Da die Erde ja größtenteils von Wasser bedeckt ist senkt dies die Ladezeit und die Größe der Map beträchtlich (habe leider nicht viel Ahnung von DirectX). Außerdem könntet ihr die Größe des Grafikkarten-Rams überprüfen und je größer er ist, umso mehr angrenzende Map-Stücken reinladen. Falls ihr, wie zuletzt von euch gesagt, die Größe des Files auf 1.5 reduziert habet, so könnet ihr die Daten auch in normalen Ram laden um die Ladezeit zu verkürzen und somit das Flackern verhindern!

[Wilhelm von Preußen]

vielleicht könntet ihr die Wasser-Grafik vereinfachen und dort eine einfache Textur verändern. Da die Erde ja größtenteils von Wasser bedeckt ist senkt dies die Ladezeit und die Größe der Map beträchtlich (habe leider nicht viel Ahnung von DirectX). Außerdem könntet ihr die Größe des Grafikkarten-Rams überprüfen und je größer er ist, umso mehr angrenzende Map-Stücken reinladen. Falls ihr, wie zuletzt von euch gesagt, die Größe des Files auf 1.5 reduziert habet, so könnet ihr die Daten auch in normalen Ram laden um die Ladezeit zu verkürzen und somit das Flackern verhindern!

Der Jammer ist, die Grösse der Files ist ja eigentlich egal herr. Es kommt auf das Surface bzw die Textur an, in welchem Format diese ist. Bsp ein 32 bit Surface 300x300 wird immer pro Pixel 4 byte benötigen, also 300x300x4 bytes wird mit diesem surface geladen. Nun haben wir eine 36000x20000 map, im 16 bit modus wären das 36000*20000*2 Bytes, grob geschätzt wären das 500 mb die in den Speicher zu laden wären, also ein Ding der Unmöglichkiet.
Das mit dem Wasser dachte ich auch schon. In DirectX wird vor jeder Darstellung einer Szene der Backbuffer mit einer Bestimmten Farbe "Gesäubert", so plante ich bereits, die Farbe des Wassers als ClearColor zu nehmen und somit nur Erdtteile verwenden zu müssen. ABER!! Auch die See verfügt über Grenzen wie Provinzen, und diese wären wiederum am einfachsten darstellbar wenn sie in einer fertigen Map bereits vorhanden sind. Oder, wir machen sehr einfache Seegrenzen und jemand extrahiert die Grenzen Pixel für Pixel an PosXY, was mit sicherheit einige Zeit brauchen würde aber , wie ihr schon sagt, mind 50 % des gesamten Speicherplatzes sparen würde. (Immerhin besteht die Erde aus 70 % wasser).
ot: Herr, wo ist der Programmierer

[Bismarck]

ot: Herr, wo ist der Programmierer

Der hat leider zur Zeit keine Zeit!

[Wilhelm von Preußen]

Der hat leider zur Zeit keine Zeit!

Ok dann lassen wir das mi dem ehrenwerten herrn. Seit 2 Monaten keine Zeit, ich glaube nicht dass er das Projekt vorwärts bringen kann.
So lasset uns weitersuchen....

[Bismarck]

nun, sobald nur irgendwelche Funktionen, die nichts mit DirectX oder ähnlichem zu tun haben, zu programmieren sind, kann ich das auch machen! Bin einigermaßen in C++ inzwischen bewandert (durch Selbststudium und PHP-Programmierung)

[TheEvilForce]

Ich habe eine weitere Lösung erdacht.
Wir erstellen im Arbeits-/Systemspeicher die gesamte Map. So im Speicher der Grafikkarte wird nun ein Ausschnitt reingeladen, den man sieht (zumindest ganz am Anfang). Wenn man nun die Mausposition ändert, so braucht man rechts ein kleines Stück abschneiden, links nur ein kleines Stück dazu. Dieses kleine Stück holt man sich vom Arbeitsspeicher, hält somit also den Datenverkehr und den RAM-Verbrauch der Grafikkarte niedrig.