@Thomas

also ich habe hier ein Dutzend 2048x2048 DDS files die ich in Modellen (die Textur ist extern verlinkt!) über die WMB lade. Wenn ich kein ent_preload ausführe, dann ladet das level und wenn ich einmal die Kamera drehe, dauert der nächste Frame entsprechend lange, weil die engine da erst die Texturen läd (also das dauert schon recht lange..)

Ich benutze nur die folgende function, die den entities zugewiesen ist (also die ist den entities direkt im WED zugeteilt):

Code:

---

void veg_meshLndscChunk ()
{
	setMATERIAL(my, mat_landscape);
	set(my, PASSABLE);
	ent_preload(my);
}

---

Und wenn das level geladen wird, wird sofort preloaded. Und ich hab kein Ruckeln mehr.

Harry: Handbuch lesen! http://manual.conitec.net/aent_preload.htm. Von Ihrer Kamera-Methode rate ich ab.

- Ich koennte eine globale Variable level_preload implementieren, die bei ent_create automatisch ein ent_preload durchfuehrt. Dies wuerde solche problemloesungen vereinfachen.

Ausgezeichnet! Kommt bestimmt noch mit dem nächsten stable A6 release...oder?

@JCL: Ich habe gestern Abend noch ein wenig mit dem "Ruckler"-Problem experimentiert, und habe dabei ein paar interessante Dinge herausgefunden.


Beschreibung der Testumgebung:
Im Testlevel gab es 3 Entities: den Player (mit Movement-Skript), ein Boden-Model mit einer eher kleinen Skin, und ein Test-Model mit einer sehr großen Skin (4096x4096).

Meine Grafikkarte unterstützt 512 MB, also gab es im Testlevel keinen Grund warum z.B. Grafikspeicher ausgelagert werden sollte (der Speicherbedarf von meinem Level lag bei höchstens 20 MB).

Im Level blickte die Kamera (der Player) zunächst nicht in Richtung des Test-Models. Erst durch Drehen des Players mit der Maus in Richtung des Test-Models wird das Test-Model im Spiel sichtbar. Dadurch konnte ich testen, ob es im laufenden Spiel zu einem "Ruckler" kommt, wenn das Test-Model erstmals sichtbar wird.

Alle Entities wurden direkt im WED plaziert - also nicht per ENT_CREATE erstellt.




1. Testlauf:
Das Test-Model hatte KEINE Mipmaps. Und es war auch keine Action für das Model hinterlegt.

Ergebnis: Sobald das Test-Model sichtbar wurde, kam es zu einem "einfrieren" des Spieles für die Dauer von ca. 4 Sekunden. Also eine extrem lange Ruckel-Zeitdauer.

Schlussfolgerung: Das was im Handbuch steht kann nicht ganz stimmen ("Video memory is automatically preallocated for entities placed in the current level") - also dass für alle Entities im Level auch Videospeicher reserviert wird. Offensichtlich wird der Videospeicher auch bei Entities, die mit dem Level mitgeladen wurden, erst dann reserviert/zugewiesen wenn die Entity zum ersten mal sichtbar wird.




2. Testlauf:
Diesmal wurde beim Model eine Action hinterlegt, welche direkt auf die Textur zugreift.
Code:

---

font_bmp_src = bmap_for_entity(my,0);
font_format_src = bmap_lock(font_bmp_src,0);
if (font_format_src >= 565) { bmap_unlock(font_bmp_src); }

---

Ergebnis: Wie ich erwartet hatte, wurde jetzt die Textur in den Videospeicher übertragen. Somit gab es jetzt auch kein Einfrieren mehr.
Allerdings gab es immer noch einen sehr kurzen "Ruckler" (für die Dauer von ca. 1/10 Sekunde). Auch diesen kurzen Ruckler gab es allerdings nur dann, wenn das Model zum ERSTEN MAL sichtbar wurde.




3. Testlauf:
Diesmal wurde in der Model-Action ein ENT_PRELOAD gemacht:
Code:

---

 ent_preload(my);

---

Ergebnis: Das Ergebnis sah genauso aus wie bei Test 2. Es gab nur einen ganz kurzer Ruckler für die Dauer von ca. 1/10 Sekunde.




4. Testlauf:
Um herauszufinden, ob diese kurze Verzögerung etwas mit den Mesh-Daten zu tun haben könnte, habe ich nun in der Action zusätzlich noch eine Vertex-Position verändert:
Code:

---

ent_preload(my);
wait(1); //Nur zur Sicherheit

vec_for_mesh(temp,my,1);  //Vertexposition ermitteln
vec_scale(temp,2);        //Neue Position berechnen
vec_to_mesh(temp,my,1);   //Vertex an neue Position verschieben

---

Ergebnis: Das Ergebnis sah genauso aus wie bei Test 2 oder 3. Es gab immer noch den kurzen Ruckler für die Dauer von ca. 1/10 Sekunde.




5. Testlauf:
Diesmal habe ich ein Test-Model benutzt welches auch Mipmaps hat. Das Ergebnis war jedoch das gleiche.




6. Testlauf: - jetzt wird es spannend
Diesmal habe ich wieder ein Model ohne Mipmaps benutzt. Aber ich erstelle die MIPMAPS im LAUFENDEN SPIEL.
Und genau das dürfte auch der Grund sein, warum das ENT_PRELOAD bei mir NIE funktioniert.
Damit mein Demospiel nicht so viel Platz auf der Festplatte benötigt, erstelle ich nämlich die Mipmaps erst im laufenden Spiel.

Hier das Coding:
Code:

---

ent_preload(my);
wait(1); //Nur zur Sicherheit

bmap_to_mipmap(bmap_for_entity(my,0)); //Jetzt wird die Mipmap erstellt

---

Und siehe da: plötzlich habe ich wieder die lange Wartezeit von 4 Sekunden, sobald das Model zum ersten mal sichtbar wird.
Und egal ob ich das ENT_PRELOAD vor oder nach dem Erstellen der Mipmaps mache ... das Ergebnis ist immer das gleiche.
Sobald im laufenden Spiel eine Mipmap erstellt wird, gibt es danach eine lange Verzögerung, sobald das Model zum ersten mal sichtbar wird.

Das sieht mir irgendwie nach einem Fehler aus, oder?


Und warum ich in ALLEN meinen Testfällen JEDESMAL zumindest eine sehr kurze Verzögerung habe, ist mir auch ein Rätsel. Eventuell liegt es ja auch an der Grafikkarte?!?!

Schön wäre es jedenfalls, wenn man auch die kurzen Ruckler wegbekommen könnte. Solange das nicht geht, muss ich weiterhin meinen Kamera/Panel-Trick anwenden, auch wenn das keine sehr schöne Lösung ist.


Liebe Grüße,
Thomas

Für den kurzen Ruckler gibt es eine moegliche Erklärung: Nicht nur die Textur, sondern auch das Mesh muss allociert werden - das geht allerdings normalerweise viel schneller als die Texture. Probieren Sie aber ent_mesh() vor oder nach ent_preload.

Fuer das Mipmap-Problem hingegen habe ich keine rechte Erklaerung. Es ist aber klar, dass Ihr Code oben nichts bringt - Sie muessen ent_preload _nach_ und nicht vor der Mipmap-Erzeugung aufrufen, denn die Textur hat sich ja jetzt geaendert.

Auch beim Aendern von Texturformaten, Alphakanal usw. muss ent_preload nach und nicht vor der jeweiligen Aenderung aufgerufen werden.

@JCL: Danke für die Antwort. Mittlerweile glaube ich, dass ich das Problem eingrenzen konnte.

Es dürfte etwas mit den MIPMAPS zu tun haben. Kann es sein, dass der Speicher für die Mipmaps immer erst dann allociert wird, wenn das Model zum ersten mal sichtbar ist?
Dass also ENT_PRELOAD beim Speicher-Zuordnen sozusagen nur die Haupt-Textur berücksichtigt, jedoch auf die Mipmaps "vergisst"?!

(Anmerkung: Da der Ruckler nur sehr kurz ist, kann ich mir auch vorstellen, dass aufgrund eines Programmfehlers z.B. auch einfach nur die letzte/kleinste Mipmap nicht allociert wird.)


Ich hatte nämlich am Wochenende ein paar Tests mit unterschiedlichen Models und unterschiedlichen Skin-Grafikformaten gemacht (Bitmap-Skins, TGA-Skins und DDS-Skins).
Und dabei ist mir aufgefallen, dass es den kurzen Ruckler NICHT GAB, wenn das Model keine Mipmaps hatte. Vorausgesetzt dass man zuvor ein ENT_PRELOAD verwendet hat.

Also kurz zusammengefasst:
- Bei ENT_PRELOAD mit Models OHNE Mipmap gibt es keine Ruckler.

- Bei ENT_PRELOAD mit Models welche eine Mipmap haben (oder bei externen DDS-Texturen, bei denen ja offensichtlich automatisch eine Mipmap erstellt wird?!) gibt es jedoch immer einen kurzen Ruckler, wenn das Model erstmals sichtbar wird.

Quote:

---

Für den kurzen Ruckler gibt es eine moegliche Erklärung: Nicht nur die Textur, sondern auch das Mesh muss allociert werden - das geht allerdings normalerweise viel schneller als die Texture

---

Bei meinem Testlevel kann das Mesh jedoch nicht das Problem gewesen sein - mein Test-Model hatte nämlich nur 2 Polygone.
Außerdem (siehe oben) gibt es KEINEN Ruckler, wenn das Model keine Mipmaps besitzt.

Quote:

---

Es ist aber klar, dass Ihr Code oben nichts bringt - Sie muessen ent_preload _nach_ und nicht vor der Mipmap-Erzeugung aufrufen, denn die Textur hat sich ja jetzt geaendert.

---

Ich hatte BEIDES ausprobiert (also ENT_PRELOAD vor und nach der Erstellung der Mipmaps) - das KURZE "Ruckel"-Problem hatte ich aber in BEIDEN Fällen.



Mit freundlichen Grüßen,
Thomas

Ent_preload allociert definitiv auch alle Mipmaps. Moeglicherweise aber passiert innerhalb der DirectX-Bibliothek oder des Videotreibers irgendetwas mit den Mipmaps, das von ent_preload nicht beeinflusst wird. Das wuerde den Rucker erklaeren, dann aber muesste er eigentlich bei saemtlichen DirectX-Andwendungen auftreten. Oder es gibt doch irgendeinen Trick, ihn zu vermeiden.

Ich werde mal in der Richtung nachforschen und nachfragen.

Okay, danke.