Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

11

16.06.2004, 12:05

Quellcode

1
2
3
4
5
6
7
8
9
10
//Die Indexdaten kopieren und umrechnen
      for(int i2=0; i2<(*m_PartIt)->GetNumIndices(); i2++)
      {
         pIndices[i2]=pIndex[i2];
      }
      for(i2=0; i2<(*m_PartIt)->GetNumIndices(); i2++)
      {
         pIndices[i2]+=(unsigned short)iTempNumIndices;
      }
      iTempNumIndices+=(*m_PartIt)->GetNumVertices(); 

Was soll das bringen? Ich seh da irgendwie keinen Sinn drin. Vieleicht überseh ich da ja auch was. Die erste ist in Ordnung. Aber mit der zweiten Überschreibst du doch alle Werte wieder im Temporären Puffer.

Quellcode

1
pIndices[i2]+=(unsigned short)iTempNumIndices;
Die Type Konvertierung nach (unsigned short) ist nicht notwendig. Es gilt der Typ des Zeigers nicht des zu Addierenden Wertes.

Was ich auch nicht so ganz verstehe ist, wieso Arbeitest du hier mit einem Temporären Puffer? Warum schreibst du die Indizes nicht direkt in die Datei? So wie du es auch mit den Vertice gemacht hast.


Noch ein kleiner Tipp:

Quellcode

1
2
3
4
5
6
   m_PartIt=m_Partliste.begin();
   for(i=0; i<m_Partliste.size(); i++)
   {
      // Mache was
      m_PartIt++;
   } 

Du kannst die schleife auf anders Definieren. Nämlich mit den STL komponenten.

Quellcode

1
2
3
4
for(m_PartIt = m_Partlist.begin(); m_PartIt != m_Partlist.end(); ++m_PartIt)
{
   // Mache was
}
Ist das selbe. Nur das du keinen extra Speicher für den Zähler brauchst ;)
Wichtig! Ich übernehme keinerlei Verantwortung für eventl. Datenverlust oder Schäden am Rechner ;D

12

16.06.2004, 13:20

Das ich die Indices in nen Extrabuffer schreib hat damit zu tun, das ich sie ja alle noch Umrechnen muss. Die sind ja jeweils relatov zur Gruppe. Im Editor hab ich für jede Gruppe einen Index und einen Vertex Buffer (ich weiß, das ist eigentlich blöd, aber ein Editor muss nicht so performanceoptimeirt wie ein Spiel sein).

Ich hatte erst alles in einer Schleife:

Quellcode

1
pIndices[i2]=pIndex[i2]+(unsigned short)iTempnumIndices;

habs dann aber mal in 2 Schleifen gemacht. Sletsam ist auch wennich die zweite Schleife weglasse, funktionierts einwandfrei. Auch komisch ist, das es nur bei komplexeren Modellen nicht geht. Ich hab eins, da funktionierte es nicht, da hab ich ein paar Gruppen gelöscht, dann gings auf einmal wieder.
Sehr seltsam.

13

17.06.2004, 11:39

Ah...sorry jetzt hatte ich einen Denkfehler ;D Stimmt hast natürlich recht. Aber dennoch ist es nicht nötig einen Speicherbereich anzulegen. Die Reservierung von Speicher ist immer mit dem Risiko verbunden das man über ihn hinausschreibt.

Darum sollte man wen möglich und wenn dadurch keine Performance verluste entstehen weglassen. Du kannst dieses Teilstück auch so schreiben

Quellcode

1
2
3
4
5
6
7
8
9
10
11
unsigned short offset = 0;  // Offset für die Index-Werte
for(m_PartIt = m_Partlist.begin(); m_PartIt != m_Partlist.end(); ++m_PartIt)
{
  for(int c = 0; c < (*m_PartIt)->GetNumIndices(); ++c)
  {
     unsigned short index = (*m_PartIt)->GetIndices()[c] + offset;
     fwrite(&index, sizeof(unsigned short), 1, Datei);
  }

  offset += (*m_PartIt)->GetNumIndices();
}

So jetzt schreibst zwar jeden Index einzeln, dafür ist der Code übersichtlicher und du brauchst keinen Speicehr reservieren. Zumal ist es nun auch einfacher zu kontrollieren ob auch alle Werte stimmen.

Noch ein Hinweis:
Da du anscheinend nur 16Bit große Indizes verwendest must du vorher kontrollieren ob die Gesamtanzahl der Indizes die 16Bit nicht überschreiten. Sonst ist der Index 2^16 == 0 und (2^16)+1 == 1, etc. ;)
Entweder du schreibst nur 32Bit Indizes oder zu fügst einen Wert hinzu, der sagt wie groß ein Index ist 16 oder 32Bit.
Wichtig! Ich übernehme keinerlei Verantwortung für eventl. Datenverlust oder Schäden am Rechner ;D

14

17.06.2004, 14:15

Danke für die Antwort ich werds gleich mal ausprobieren.
Das mit dere Indexgröße: Also wenn ich zu viele hab, fängt er dann wieder vorne an zu zählen? Naja, ich könnte noch ne Abfrage reinbauen, die dann notfalls ne Fehlermeldung ausgibt,. Außerdem könnte ich in das Modellformat noch einen Eintrag für Index, bzw. Vertexformat machen. Allerdings reichen 16 Bit doch glaub ich schon für 64.000 Indices aus, oder?

15

17.06.2004, 19:55

Tja ein kleiner Fehler war im Codebeispiel, wollt nur mal drauf hinweisen: Es muss:

Quellcode

1
offdset+=(*m_PartIt)->GetNumVertices();

heißen, da Indices ja relative angaben von Vertices sind.
Ansosnten ist die Idee ja ganz pfiffig, führt abr zu dem selben Ergebnis. Wenn die Modelle zu komplex werden steht in den letzten Indices nur noch 0 und der Texturname kann nicht gelesen werden! Und wie immer, wenn ich die Addition von "offset" weglasse, funktionierts einwandfrei!
Ich bin echt am verzweifeln!

16

17.06.2004, 23:35

Zitat

Das mit dere Indexgröße: Also wenn ich zu viele hab, fängt er dann wieder vorne an zu zählen? Naja, ich könnte noch ne Abfrage reinbauen, die dann notfalls ne Fehlermeldung ausgibt,. Außerdem könnte ich in das Modellformat noch einen Eintrag für Index, bzw. Vertexformat machen. Allerdings reichen 16 Bit doch glaub ich schon für 64.000 Indices aus, oder?
Ja klar ein 16Bit Wert reicht für genau 65.536 Index-Werte. Das sollte im Normalfall reichen. Wenn man allerdings mehrere Modell zusammenkopiert sollte man möglichst darauf achten das man diesen Wert nicht überschreitet. Denn tatsächlich fängt er dann wieder bei NULL an zu Zählen. Aber nicht D3D sondern nur der Wert der Indizes ;)

Kurze erklärung:
1 Byte == 8Bit: Max-Wert: 255

255 + 1 = 0 klinkt unlogisch, aber es passen ja nur 8Bit rein und 256 brauch 9Bit. Wobei die unteren 8Bit == NULL sind und Bit 8 == 1

Zu deinem Fehler:
Ja da weis ich auch nicht weiter. Ist alles recht eigenartig. Mir fällt da nur eine Sache ein. Prüfe mal ob du vor besagter Funktion einen Fehler hast. Prüf vor allem deine Schleifen wo du in Speicher hineinschreibst.
Wichtig! Ich übernehme keinerlei Verantwortung für eventl. Datenverlust oder Schäden am Rechner ;D

17

27.06.2004, 17:05

Ich bin beim Dateisystem jetz auf Chunks umgestiegen, aber es hilft alles nix. Es will einfach nicht funzen (natürlich wieder nur bei zu komplexen Modellen. Eines hat 5 Gruppen, es geht, wenn ich eine sechste Hinzufüg, gehts nicht mehr)

18

27.06.2004, 19:37

Ich denke mal es könnte am Ladecode liegen:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
case CT_INDICES://Die Indices laden
            dwChunkSizeTest+=fread(&iNumIndices, sizeof(int), 1, Datei)*sizeof(int);
            dwChunkSizeTest+=fread(&dwIndexFormat, sizeof(DWORD), 1, Datei)*sizeof(DWORD);
            if(dwIndexFormat==sizeof(unsigned short))//Testen ob die Indices dads richtigeFormat haben!
            {
                Indices=new unsigned short[iNumIndices];
                dwChunkSizeTest+=fread(Indices, sizeof(unsigned short), iNumIndices, Datei)*sizeof(unsigned short);
            }
            else
            {
                Error("Modell::Laden");
                Error(Dateiname);
                Error("CT_INDICES speichert Indices im falschen Format!");
            }

            //ChunkSizeTest
            if(dwChunkSizeTest!=ChunkHeader.dwChunkSize)
            {
                Error("Falsche Chunkgröße: CT_INDICES");
                Error("angegeben:");
                Error(ChunkHeader.dwChunkSize);
                Error("gelesen:");
                Error(dwChunkSizeTest);
                Error("Anzahl Indices angegeben:");
                Error(iNumIndices);
            }
            break;

Die ausgabe in der Errordatei:

Quellcode

1
2
3
4
5
6
7
Falsche Chunkgröße: CT_INDICES
angegeben:
104.000000
gelesen:
98.000000
Anzahl Indices angegeben:
48.000000

Also: Die Funktion fread liest 6 Byte weniger als angegeben. Warum???

Osram

Alter Hase

Beiträge: 889

Wohnort: Weissenthurm

Beruf: SW Entwickler

  • Private Nachricht senden

19

27.06.2004, 20:08

Hast Du Dir mal die Datei in nem Hex editor angesehen? Vielleicht ist die kaput und hört tatsächlich an der Stelle (98 statt 104) auf? Oder vielleicht ist gerade an der Stelle ein Ctrl-Z :-D
"Games are algorithmic entertainment."

20

27.06.2004, 20:54

tja ich nutze zum speichern die oben gepostete Funktion. Zu ende ist die Datei auf keinen Fall, da noch die teturangabe folgt. Ich hab auch mal

Quellcode

1
if(ferror(datei)

nach dem fread-Aufruf geschrieben, aber die Abfrage war offensichtlich false.

Werbeanzeige