bilder pro sekunde, scolling logik(verständnis)problem ?

Guck dir doch mal den Catch Block an und überleg dir was passiert, wenn 2 Bilder in einer ms gerendet werden?
Für sowas nimmt man nano-Sekunden. Da gibts auch eine Methode für.

Das Thread.sleep ist doch aber auskommentiert.

Ansonsten: google -> java nanoseconds -> 1. Treffer

Bevor du dich hier in was versteigst, solltest du mal überlegen, ob du die Framerate wirklich vorgeben willst. Schau doch einfach, wie viel Zeit seit dem letzten Durchgang vergangen ist, rechne aus, wie weit das Objekt sich in deiner Spielewelt bewegt hat und zeichne es dann am neuen Ort - das bringt dir auf allen Devices immer die optimale Geschwindigkeit.

Wenn du OpenGL machen willst guck dir mal die Andengine an.
Ist eine freie OpenGL 2D Grafikengine, die echt einfach zu bedienen ist.

Also korrigiert mich wenn ich falsch liege, aber im Moment schaut das doch bei dir so aus.

Du willst eine FPS von 30 Sekunden. D.h. ein Schleifendurchlauf darf max 1000/30 = 33.33333 Millisekunden dauern. Du lässt deinen Thread aber schon für 33.33333 Millisekunden schlafen und hast dann aber noch nichts gezeichnet und die FPS berechnet. Dafür brauchst du ja auch Zeit. Somit kannst du nie auf die 30 FPS kommen.

Ja irgendwie gehst du das komisch an. Irgendwie hab ich den Eindruck du hast das mit den FPS noch nicht so ganz verstanden. Sorry falls ich mich täusche aber irgendwie scheint mir das so.

FPS heisst Frames per second und gibt an, wie oft pro Sekunde der Inhalt des Bildschirms neu gezeichnet wird. Das ist letztendlich nur dafür wichtig, dass Objekte die sich bewegen, für das menschliche Auge flüssig erscheinen und nicht ruckeln. Mit der Geschwindigkeit wie schnell sich das Objekt von Punkt A nach B bewegt, hat das gar nix zu tun.

Wie Thomas M gesagt hat, ist es für den Anfang am einfachsten, die FPSs FPSs sein zu lassen und sich nicht darum zu kümmern, dass man eine bestimmte Anzahl schafft oder nur eine bestimmte Anzahl hat.


Probier das mal. Ich hab es jetzt nicht getestet, sondern aus dem Kopf zusammen geschrieben. Du lässt die Loop so schnell laufen wie es geht und misst bei jedem Durchgang wie viel Zeit vergangen ist, seit dem du das letzte mal die Position des Rechtecks aktualisiert hast. Dann wird berechnet wie viele Pixel sich das Rechteck in dieser Zeit bewegt hat und diese Anzahl wird auf die x-Position drauf gezählt.

Dann wird das Rechteck gezeichnet und der Frame Zähler eins hochgezählt. Am Ende wir dann noch überprüft ob eine Sekunde vergangen ist, wenn ja, dann wird der Counter ausgelesen und an die FPS übergeben und alles wieder zurück gesetzt.


// Position des Rechtecks
private int xPos = 0;
private int yPos = 0;

// Geschwindigkeit mit dem sich das Rechteck bewegt in Pixel pro Sekunde
private float xSpeed = 200;

// Variablen zum Brechnen der vom Rechteck zurückgelegten Strecke.
private long lastUpdate;
private long deltaTime;

// Variablen zum Berechnen von FPS
private int counter = 0;
private int fps = 0;
long startTime;

public void run() {
startTime = System.currentTimeMillis();
lastUpdate = System.currentTimeMillis();

while (running) {
if (!holder.getSurface().isValid()){

Canvas canvas = holder.lockCanvas();
deltaTime = System.currentTimeMillis() - lastUpdate;
updateModel(deltaTime);
draw(canvas);
holder.unlockCanvasAndPost(canvas);
counter++;

if(System.currentTimeMillis() - startTime > 1000){
// eine Sekunde ist rum
fps = counter;
counter = 0;
startTime = System.currentTimeMillis();
}
}
}
}

private void updateModel(long deltaTime) {
xPos += (deltaTime/1000f) * xSpeed;
lastUpdate = System.currentTimeMillis();
}

private void draw(Canvas canvas) {
canvas.drawColor(Color.BLUE);
canvas.drawRect(xPos, yPos, xPos + 10, yPos + 10, paint);
canvas.drawText("FPS: " + fps, 50, 50, paint);
}

— geändert am 16.02.2012, 20:36:03

Ich sagte ja, dass ich das aus dem Kopf zusammen geschrieben habe. Das sollte dir ja auch nur eine Idee davon geben, wie du das umsetzen kannst. Ich will dir ja hier auch nicht alles vorkauen.

Hier werden unterschiedliche Arten von Game Loops vorgestellt. http://www.koonsolo.com/news/dewitters-gameloop/

der original emulator emuliert ja auch das GESAMTE device exact .. das braucht schon ziemlich rechenleistung .. auf nem Q6600 ist aber für normale activites erträglich, muss aber zugeben, dass das starten am emulator auch wirklich schneller geht als gleich am handy zu starten .. :-)

für games gibts ja dank libgdx bessere möglichkeiten ... nutze den original emulator aber gerne um zu sehen wie ein spiel performed haha

aber mal im ernst: mit dem eigentlichen thread hat das nichts zu tun oder?

Moment einmal - Games entwickeln in einem EMULATOR?

Du hast es immer noch nicht richtig verstanden. Du gibst nicht vor: Ich will 30 Frames pro Sekunde und will bei gegebener Objektgeschwindigkeit pro Bild eine Verschiebung um x Pixel haben. Das Prinzip heisst Frame-independent-Movement oder manchmal auch Time-based-Movement. Heisst: Du durchläufst jede Iteration des Game-Loop so oft es geht, berechnest die neuen Positionen deiner Objekte in deiner Spielwelt und zeichnest sie dort. Auf einem schnellen Handy schaffst du das 40 Mal in der Sekunde und hast dann 40 Frames, auf einem langsamen vielleicht nur 20 Mail und im Emulator 3 Mal. Und wenn du dann - egal wo ausser dem Emulator - zu wenig Frames für deinen Geschmack hast, musst du schauen, wo du beim Berechnen der Welt und beim Zeichnen (oder Simulieren und Rendern, wie die Freaks sagen) optimieren kannst, um dein FPS-Ziel zu erreichen.

Dieses Verfahren ist genau das, womit Ruckeln von Games auf langsamen Rechnern zu erklären ist: Die Zeit für einen Durchlauf des Game-Loop ist so lang, dass sich die Welt in der Zeit bis zum nächsten Durchlauf so weit verändert hat, dass der User keine flüssige Bewegung mehr wahrnimmt. Dennoch ist es das einzige Verfahren, dass eine Echtzeit-Darstellung von Bewegung ermöglicht - das was da versuchst, ist genau der umgekehrte Ansatz: Du willst auf jeden Fall erzwingen, dass alle Bewegungsphasen dargestellt werden, das hiesse im Ergebnis: Die Bewegung wäre flüssig im Sinne von "es fehlt keine dargestellte Position", würde aber wirken wie in Zeitlupe, je langsamer das Device, je mehr... Oder verstehe ich deine Vorgehensweise falsch?

— geändert am 09.03.2012, 16:21:24