Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » VC++ / MFC » Brauche Idee zu einem Spiel mit der Kartengröße 6000x4000

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 < [ 2 ]
000
09.10.2002, 13:36 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


Hallo,
wie gesagt ich hab ein Spiel, dessen Karte besteht aus Feldern:


Code:
00 [b]000[/b] 000 [b]00[/b] 000 [b]000[/b] (Ein Feld, sind verbunden ohne leerzeichen)
höhe [b]obj[/b] rot [b]höhe2[/b] obj2 [b]rot2[/b]



Nur, das bei einer Kartengröße von 6000x4000 in "Klartext" reinzuschreiben wird ein bischen groß.

Ich bräuchte eine Idee wie ich das oben möglichst klein machen kann, muss nicht klartext sein, kann auch ne odbcdatenbank sein, nur eben muss es möglichst klein sein ... (und die daten muss ich auch irgendwie lesen & schreiben können, ohne erst 3std zu encodieren bzw zum decodieren.

Hat da einer ne Idee???
--
class God : public ChuckNorris { };

Dieser Post wurde am 09.10.2002 um 13:38 Uhr von FloSoft editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
09.10.2002, 14:54 Uhr
virtual
Sexiest Bit alive
(Operator)


Wie viel Bit hat denn nun das Feld? 16? ist mir nicht klargeworden, ob die einzelnen 0en Bits oder Bytes or whatever repräsentieren
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)

Dieser Post wurde am 09.10.2002 um 14:54 Uhr von virtual editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
09.10.2002, 16:43 Uhr
Bruder Leif
dances with systems
(Operator)


Bastelt da jemand an Ultima 28? ;-)

Wie wärs mit einer binären Datei mit 24 Mio Einträgen (huiuiui), die jeweils aus einer struct bestehen? Wäre per fseek/fread/fwrite relativ einfach zu handhaben...
Statt einer struct kannst Du natürlich die Felder auch direkt codieren, denke mal, das ist es, was virtual vorschlagen wollte: Nach dem Motto "2 Bit Höhe, 3 Bit obj, 3 bit rot etc.", und dann einen unsigned long entsprechend belegen...
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
09.10.2002, 17:18 Uhr
virtual
Sexiest Bit alive
(Operator)


@leif
Naja, selbst dann: 16 Bit * 24Mio Einträge = 48 MB...
ALso ich denk, wenn das eine Landkarte sein soll, dann sollte man nur die Topographischen Daten in einer Art array speichern, es sei denn, man kennt einen halbwegs effizienten algorithmus, mit denen man nur Höhenlinien speichert und dann zu einem beliebigen Punkt berechnen kann, auf welcher höhe das teil liegt.
Gebäude usw würde ich aber nicht in einem Array speichern, eher in einer map, mit deren Hilfe man von Koordinaten auf das Objekt mappt.
...

Ups, ich merk grad daß mein Rechenknecht 512MB hat, ist mir garnicht so aufgefallen (Denke noch in 386er Kategorien). Also von daher: was sind schon 48MB!?
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
09.10.2002, 17:41 Uhr
FloSoft
Medialer Over-Flow
(Administrator)



Zitat:
Leif postete
Bastelt da jemand an Ultima 28? ;-)


So ungefähr www.middleages.de.vu

Das mit 48MB ist ok, so ungefähr hab ich mir das auch ausgerechnet ... nur irgendwie wenn ich per Hexedit die Datei anlege und 0er reinschreib, dann wird die datei größer als 300MB ...

Wie hast du das gemeint? Ein kleines Bsp wär echt Klasse ...

Danke für eure Vorschläge, vielleicht ham ja noch ein paar einige ideen dazu ...

Achja was ich beinahe vergessen habe:

Die Werte sind von 00 bis 99 bzw von 000 bis 999
und immer

0000000000000000

ergeben ein Feld ...
--
class God : public ChuckNorris { };

Dieser Post wurde am 09.10.2002 um 19:21 Uhr von FloSoft editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
09.10.2002, 20:21 Uhr
Bruder Leif
dances with systems
(Operator)


Aaaaalso: Ein Feld besteht aus sechs Datenobjekten, "Höhe1/2", "Obj1/2" und "Rot1/2". Zweimal zwei

Dezimalstellen, also mit 7 Bit darstellbar, und viermal drei Stellen, also mit je zehn Bit darstellbar.

Zusammen 2*7+4*10=54 Bit, aufgefüllt auf 64 Bit = 8 Bytes / Feld. Eigentlich nur 7, aber so ist die Verarbeitung einfacher.


Beispiel:
(Bit 63) AAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDDDEEEEEEEEEEFFFFFFFFFFGGGGGGGGGG /Bit 0)

Mit A = "Höhe", B = "Obj", C = "Rot", D = "Höhe2", E = "Obj2", F = "Rot2", G = reserviert für spätere Erweiterungen...


Es sind 4000*6000 Felder in der Datei, also 24 Mio. Insgesamt kommst Du also auf eine 24*8 = 192 MB-Datei (!). Also doch "etwas" größer als 48 MB. Wenn Du "nur" 7 Bytes pro Feld verwendest, sind es immer noch 168 MB.



Alternative Möglichkeit: BCD-codierte Zahlen, also je 4 Bit pro Ziffer. Jedes Feld besteht aus 16 Ziffern

-> 64 Bit pro Feld. Platzbedarf wie oben, dafür wesentlich leichter zu (de-)codieren, aber kein Raum mehr

für Erweiterungen...

Das ganze könnte man natürlich noch komprimieren, aber dann wäre der Zugriff nicht gerade schnell...


Was soll denn in den Feldern an Daten gespeichert werden? Vielleicht kann man das ja noch ein bißchen

optimieren... wenn z.B. viele Felder "leer" sind oder den gleichen "Inhalt" haben...
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.

Dieser Post wurde am 09.10.2002 um 20:23 Uhr von Leif editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
11.10.2002, 08:40 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


Hallo,

wenn möglich sollte die Datei unter 100MB liegen (die 56k/ISDN Spieler werdens mir danken )

In den Feldern wird eben gespeichert wie die Lnadschaft ausschauen soll ...

Jedes Feld besteht eben aus 2Texturen, falls es das Obj auf 0 steht, ist es transparent ...

Die Rotation geht von 0-360 (theoretisch könnte man auch 1-4 nehmen, ich dreh eh immer nur um 90°, wären dann schon mal 2Ziffern weniger)

Die Höhe geht von 0-99 da brauch ich 2 Ziffern,
Die Objekte gehen von 0-999 (hab zwar noch nicht ganz so viele...), z.B. 0 = Nix, 1 = Gras, 2 = Moor, usw ...

Wenn z.B. die Höhe von Obj1 0 ist und die Höhe von Obj2 (in diesem Feld) 1 ist, dann wird es eben "schief" geht es nach oben (das Spiel ist 3D)

Wenn ich die Rotation auf 1-4 beschränke, krieg ich immerhin pro Feld 4Ziffern weniger ...
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
007
11.10.2002, 09:55 Uhr
Bruder Leif
dances with systems
(Operator)


OK, sagen wir Rotation 0-3, also nur eine Ziffer, genauer gesagt, nur noch zwei Bit. Höhe bis 99, also sieben Bit, Objekte bis 999, also 10 Bit. Das ganze verdoppeln wir, insgesamt also 2*(2+7+10) = 2*19 = 38 Bit pro Feld, also 5 Bytes. Bei 24 Mio. Feldern immer noch 120 MB... wenn Du die Objekte auf 0..127 runterschrauben könntest, wären's nur noch 2*16=32 Bit -> 4 Bytes / Feld -> 96 Mio Bytes = 91,5 MB.

Alternative: Du schränkst Dich im Aufbau des Spielfelds etwas ein. Die Daten für den Aufbau werden auf ein Viertel reduziert, also nur halbe Höhe und Breite, die Größe des Spielfeldes bleibt aber gleich. Die Anzahl der möglichen Objekte vergrößert sich: Jetzt gibt es ein Objekt "Alles Gras", ein anderes heißt "Linke Hälfte Gras, rechte Hälfte Moor", das nächste "Links Gras, rechts Felsen" etc. Dafür sagen wir, es gibt jetzt 4096 mögliche Objekte = 12 Bit. Zwei Objekte pro Feld -> 24 Bit. Dazu wieder die Rotation (2*2 Bit = 4 Bit) und die Höhe (2*6 Bit [wir gehen nur von 0 bis 63, sollte eigentlich reichen] = 12 Bit), zusammen 24 + 4 + 12 = 40 Bit / Feld = 5 Bytes. ABER da immer vier Felder zusammenhängen, sind nur noch 6 Mio. Felder zu speichern -> 30 Mio. Bytes = 29 MB.
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
008
11.10.2002, 12:54 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


noja 127 objekte müssten theoretisch langen

Das mit den Objekten usw wollt ich eigentlich extra so machen, da ich eben sonst tausende von texturen laden muss, so nur ähm 4 pro typ ...

Etz nur mal so: wie kann ich das dann speichern bzw laden (cppbsp wär nett)?
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
009
12.10.2002, 15:39 Uhr
Bruder Leif
dances with systems
(Operator)


OK, ich hab mal was gebastelt, hier die Version mit 10 Bit pro Objekt:

Byte 1-5: RRrrHHHH HHHhhhhh hhOOOOOO OOOOoooo oooooo--
R/r = Rot1/2
H/h = Höhe1/2
O/o = Objekt1/2
- = ungenutzt


C++:
// Daten EINER Zelle decodieren.
// Eingabe: ucSource[5] -> Die 5 Bytes, die die Zelle beschreiben
// Ausgabe: Rot1, Rot2, Hoehe1, Hoehe2, Obj1, Obj2 -> Die decodierten Daten
void DecodeCellData(unsigned char ucSource[5], int &Rot1, int &Rot2, int &Hoehe1, int &Hoehe2, int &Obj1, int &Obj2)
{
   Rot1 = (ucSource[0] & 192) >> 6;
   Rot2 = (ucSource[0] & 48) >> 4;
   Hoehe1 = ((ucSource[0] & 15) << 3) + ((ucSource[1] & 224) >> 5);
   Hoehe2 = ((ucSource[1] & 31) << 2) + ((ucSource[2] & 192) >> 6);
   Obj1 = ((ucSource[2] & 63) << 4) + ((ucSource[3] & 240) >> 4);
   Obj2 = ((ucSource[3] & 15) << 6) + ((ucSource[4] & 252) >> 2);
}


Die Codierung läuft genauso, nur in die andere Richtung... hab's noch nicht getestet, sollte aber funzen!
Und dann hängst Du immer eine "Zeile" nach der anderen in die Datei, also 6000 solcher 5-Bytes-Datensätze für die erste Zeile, dann 6000 für die zweite usw. Über fseek positionierst Du auf den gesuchten Record, Daten per fread auslesen, decodieren, fertig!
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 < [ 2 ]     [ VC++ / MFC ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: