spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Kannst du die Texturen nicht in kleinere Aufteilen? Ich meinte auch nicht das du alles laden sollst sondern mehr im Voraus. Ich nehme mal an das du dein Level in Quadrate/Cubes einegeteilt hast. Und sobald du das übernächste lädst kanns du das letzte wieder freigeben. Wenn sich das bis später nnicht geklärt hat kann ich ja mal ne Grafik dazu machen.

Sleep würde ich auch verwenden aber nicht beim rendern sondern nach jeder Prüfung ob geladen werden muss. Hier solltest du so viel puffern das nicht uaf das laden gewartet werden muss. Der Wechsel zum nächsten Feld sollte ohne Laden auskommen können. Und wenn dieser wechsel stattfindet kannst du das darauf folgende laden.

Zitat von »"chriss"«

@Chase Das stimmt schon das man 800fps nicht braucht aber umso mehr es sinnt (<= sind?) umso genauer läuft das Spiel. Zumindest wenn die Inputabfragen im Renderloop stecken. Zudem sind Kollisionstest genauer da sie öffters durchgeführt werden.

Nochmal: Physik-Engines laufen immer nur mit fixen Time-Steps zuverlässig! Das bringt dir also rein gar nichts! Und auch die genauere oder schnellere Reaktion auf Eingaben ist hier nicht gegeben. Die Auswirkung der Eingabe siehst du nämlich sowieso erst im nächsten gerenderten Frame, und z.B. die Dauer eines Tastendrucks kannst du auch über Time-Stamps in den Eingabe-Events herausfinden.

Zitat von »"chriss"«

Zitat von »"Chase"«

Das Nachladen geschieht in einem anderen Thread

Genau deswegen ist es sinnlos die Framerate zu begrenzen.

Das ist sehr widersprüchlich.
Man soll ja deiner Meinung nach so viel CPU-Zeit wie möglich in der Spielschleife verbringen. Dann bekommt der Lade-Thread zwangsläufig weniger CPU-Zeit zugeteilt. Und selbst bei Multicore-Systemen ist das nicht ohne negativen Einfluss!

Zitat von »"David Scherfgen"«

Zitat von »"chriss"«

Zitat von »"Chase"«

Das Nachladen geschieht in einem anderen Thread

Genau deswegen ist es sinnlos die Framerate zu begrenzen.

Das ist sehr widersprüchlich.
Man soll ja deiner Meinung nach so viel CPU-Zeit wie möglich in der Spielschleife verbringen. Dann bekommt der Lade-Thread zwangsläufig weniger CPU-Zeit zugeteilt. Und selbst bei Multicore-Systemen ist das nicht ohne negativen Einfluss!

Nein das soll heißen das beide Threads eh unterschiedlich schnell laufen und das eine Verlangsamung des Renderthreads eigentlich kein Effekt auf den Ladethread hat.

Die Argumentation, so wie ich sie verstanden habe ist: "Der Ladethread ist zu langsam also mache ich den Renderthread auch langsamer damit es wieder passt!"
Sollte das nicht die Aussage gewesen sein, reden wir hier eh vorbei und können uns das spaaren darüber zu diskutieren.

Ich wollte nur sagen das es mehr Sinn macht, da zu optimieren wo der Engpass entsteht, als die besserlaufenden Threads zu verlangsamen damit es wieder passt.

Zitat

Nein das soll heißen das beide Threads eh unterschiedlich schnell laufen und das eine Verlangsamung des Renderthreads eigentlich kein Effekt auf den Ladethread hat

dir ist aber schon klar, dass threads nicht wirklich parallel laufen!?
wenn ich jetzt mal im taskmanager schau, dann seh ich dort 485 laufende threads. ich hab aber nur 2 kerne...
das "verlangsamen" mit Sleep() hat den effekt, dass die zeit die in der renderfunktion sonst verbraten würde dem anderen thread zu gute kommt.

Zitat von »"dot"«

Zitat

Nein das soll heißen das beide Threads eh unterschiedlich schnell laufen und das eine Verlangsamung des Renderthreads eigentlich kein Effekt auf den Ladethread hat

dir ist aber schon klar, dass threads nicht wirklich parallel laufen!?
wenn ich jetzt mal im taskmanager schau, dann seh ich dort 485 laufende threads. ich hab aber nur 2 kerne...
das "verlangsamen" mit Sleep() hat den effekt, dass die zeit die in der renderfunktion sonst verbraten würde dem anderen thread zu gute kommt.

Ja weiß ich, die Frage ist nur ob das wirklich notwendig ist. Aber das muss der Entwickler wissen.

Das wird ein bisschen OT ich hoffe das ist ok.

Zitat von »"David Scherfgen"«

Nochmal: Physik-Engines laufen immer nur mit fixen Time-Steps zuverlässig!

Also in meinem aktuellen Projekt benutze ich auch ode. Nachdem ich das hier gelesen hab bin ich auch mal auf framebasiertes rendern umgestiegen, und jetzt ist die höhe der sprünge endlich immer gleich. allerdings nur solange der spieler nicht in bewegung ist. wenn ich "dauerspringe" der spieler also beim aufkommen noch schwung hat springt er wieder jedes mal zufallsmäßig unterschiedlich hoch. Gibts vielleicht ne Möglichkeit das hinzukriegen ohne die Kräfte zu verändern?

Wie lässt du ihn denn springen?
Setzt du die vertikale Geschwindigkeit?

nein die vertikale kraft