Messages

Deshalb wird die L?sung wohl folgenderma?en sein:

LIMITFPS 100 

Ich ?berlegen wegen einem Systemcheck, der beim ersten Start des Programmes die max. m?glichen FPS messen kann und aufgrund dessen die Rate automatisch anpassen kann!

Du bindest die Bewegung wieder an die Frames. Das ist nicht frameunabh?ngig und wird zwangsl?ufig zu verf?lschten Bewegungen auf bei sehr verschiedenen Systemen f?hren!
Du testet mit Deiner Methode am Anfang die max. Fps f?r eine bestimmte Situation. Im richtigen Spiel kommen dann aber wahrscheinlich noch Berechungen f?r Bewegungen, Verhalten, Level?berwachung (Gameover, Bonusleben etc) dazu. Das erg?be eine andere max. FpS.

Ausserdem steigt der Berechungsaufwand pro Sprite nicht linear an (1Sprite=max. 500 Fps, 2 Sprites= max. 250 Fps usw.).
Wenn Du also einen "Stresstest" mit 10000 Sprites (zoomend und rotierend) durchf?hrst, hei?t das nicht, dass Du mit nur 1000 Sprites auch entsprechend 10x schnellere Fps kriegst.
Zus?tzlich m?sste der Test am Anfang jeder Spielsession durchgef?hrt werden, da ja durchaus auf einem PC auch andere Progs im Hintergrund laufen k?nnen und bei der n?chsten Spielsession dann wieder nicht...

Einen Test mit einer "gestellten" Spielsituation etc halte ich daher f?r eher kontraproduktiv.

Die Limitierung der Fps per Befehl ist im Bezug auf eine Geschwindigkeit angegeben in Pixel pro Frame (wovon ich ausgehe, sonst w?rdest Du ja ?ber die Zeit verkn?pfen und das ganze anders aufziehen) nur sinnvoll, wenn klar ist, dass die maximal eingestellten Frames auch immer erreicht werden. Zu niedrige Framerate bedeutet dann zu langsame Bewegungen. Man sichert also nur gegen zu schnelle Bewegungen ab.

Ich glaube, Du machst es dir zu kompliziert. Aber vielleicht verstehe ich Deinen Ansatz auch nur falsch....

I would check to make sure the file can be written to - assuming it can is a bit dodgy

Usually, You start a Game loading the Hiscore-Table.
The "LoadHicores"-Function checks if a hiscore-File exists, if not it creates one.
Datas can then later be saved to it.

But,yes... A check could also be implented in "SaveHiscores"...

Code (glbasic) Select Expand

FUNCTION SaveHiscores: amount%

OPENFILE(0,"Hiscores.dat",0)

FOR i=0 TO amount-1

WRITELONG 0,hiscores[i].score
WRITELINE 0,hiscores[i].name$
WRITEWORD 0,hiscores[i].level

NEXT

CLOSEFILE 0

ENDFUNCTION

FUNCTION LoadHiscores: amount%

IF OPENFILE(0,"Hiscores.dat",1)=TRUE

FOR i=0 TO amount-1

READLONG 0,hiscores[i].score
  READLINE 0,hiscores[i].name$
  READWORD 0,hiscores[i].level

NEXT

CLOSEFILE 0

SORTARRAY hiscores[],0

ELSE

OPENFILE(0,"Hiscores.dat",0)
CLOSEFILE 0
SaveHiscores(amount)

ENDIF

ENDFUNCTION

These Functions work like a charm for me...maybe it?ll be a help for you.
They work on the Wiz, too (I used them in TetWiz).

Of course, you?ll have to declare a typed array hiscores[] (or just replace it with your variables).
Amount% in the functions ist the number of entries in the List (10,5,100,...)

F?r eine plattform-unabh?ngige Darstellung solltest Du die physikalische Geschwindigkeiten der einzelnen Objekte in deiner virtuellen Welt binden an die Framerate...

Wieso an die Framerate binden? Ist doch quatsch.
Es soll doch Frameunabh?ngig laufen, damit es ?berall gleichschnell ist.

Da hast Du recht, aber wir benutzen nur zwei Wege zum gleichen Ziel:
- Du bindest die Bewegung direkt an die Zeitachse
- Ich mache das gleiche, in dem ich die genaue Dauer einer jeden Display-Schleife messe

Um eine frameunabh?ngige Bewegung zu erhalten muss man zwangsl?ufig ?ber die Zeit gehen (Punkt 1). Die genaue Dauer eines Schelifendurchlaufs messe ich ja auch - mit Gettimer().

Der einzige Unterschied ist, dass Du , soweit ich deinen ersten Thread richtig verstehe, die Zeiten mehrerer vergangener Schleifen speicherst und einen Durchschnittswert daraus bildest.
Ich habe ?ber diese Idee fr?her auch nachgedacht, es aber verworfen, da eventuelle Framerate-Spitzen nach oben oder unten einem "nachlaufen" und das Bewegungs-Ergebnis sp?terer Durchl?ufe zu sehr verf?lschen...selbst wenn Du das mathematisch versuchst zu gl?tten...
Vielleicht habe ich Deinen Post aber auch nur missverstanden?!

Mein Beispiel verfolgt in dem Fall den 2. Weg! In dem Fall nehme ich an, da? die maximalen FPS einfach 100% sind und alles darunter erh?ht sich um den entsprechenden Prozentsatz hoch 2!

Woher wei?t Du, welche maximale Framerate es gibt? Auf meinem PC schmei?t mir GLBasic teilweise Ausrutscher auf 1000FpS aus. Dauern zwar nur den Bruchteil einer Sekunde, w?rden aber deine Bewegungen doch ziemlich verf?lschen.
GLBasic limitiert zwar von Haus aus auf 500FpS, aber 100%ig einhalten kann man es eben nie...
Oder meinst Du die max. Framerate, die auf dem Zielsystem m?glich ist? Die kannst Du aber doch gar nicht kennen...

Code (glbasic) Select Expand

while true

x=x+0.02*fpstime

drawsprite 4711,x,y

fpstime=int(gettimer())
showscreen
wend


Ist jetzt mal eben zwischen T?r und Angel...
Der Sinn dahinter ist folgender: Du kannst mit dem Befehl Gettimer() die abgelaufene Zeit zwischen zwei Showscreens ermitteln (in millisekunden). Wenn Du deinen Speed in Pixel pro Millisekunden angibst (hier 0.02), wei?t Du dass das Sprite 4711 in dem Beispiel sich in einer Sekunde 20 Pixel auf der x-Achse bewegen w?rde (1000ms * 0.02)
Dass Problem, auf dass Du ja hinauswillst, ist, dass Du nicht weisst wieviele Frames pro Skunde auf dem Zielsystem laufen. Da wir aber jetzt Timerabh?ngig bewegen (pro ms) statt pro Frame, hast Du mit dem obigen Beispiel immer eine Strecke von 20 Px pro Sekunde, denn: Sind auf dem Zeilsystem nur 2 FpS m?glich, w?rde das bedeuten, dass ein Frame 500 ms zur Berchnung brauchte. Diesen Wert gibt Gettimer() uns zur?ck. 500*0.02 sind 10. Also 10 Pixel Bewegung + 10 Pixel f?r den zweiten berechneten Frame in der Sekunde und Du bist wieder bei den 20.

W?ren auf dem Zielsystem 50 Frames pro Sekunde m?glich, w?rde berechnet 20 Millisekunden (1000 ms=1 Sek geteilt durch 50 Frames=20 ms pro Frame (das w?re der R?ckgabewert von gettimer() in diesem Fall) multipliziert mit 0.02 =0.4 Pixel pro berchnetem Frame. da insgesamt 50 Frames pro sekunde m?glich sind: 50 *0.4= 20 Pixel pro Sekunde Bewegung.

Egal wieviele Frames pro Sekunde m?glich sind, das Sprite wird sich pro Sekunde imer gleich weit bewegen.
Ermittle einfach mit gettimer() die Berechnungsdauer des letzten Frames, lege den Wert in einer Variablen ab und multilpliziere bei jedem bewegten Objekt den Speed mit der Framezeit (hier: fpstime)

P.S.Es kann sein, dass die Frameberechnung weniger als 1 ms dauert, dann w?re fpstime immer 0 und nichts w?rde sich bewegen, also sollte man die fpstime immer aufrunden, falls man weiss dass das Zielsystem dermassen schenll ist...

Habe Deinen Thread jetzt nur ?berflogen..aber w?re es nicht einfacher nur mit Gettimer() die Anzahl der vergangenen Millisekunden seit dem letzten Showscreen zu erhalten und diese Zeit mit einer Geschwindigkeit zu multiplizieren (die dann in Pixel pro Millisekunde angegeben ist?)

also zb. x=x+0.01*fpstime

wobei x die Position ist, 0.01 die gegebene Geschwindigkeit pro ms und fpstime die Zeit, die f?r die letzte Frameberechnung gebraucht wurde...

Aaaaaahh... Es lebt!!!

Habe eine Tabelle mit 360 Cosinus und Sinus-Werten erstellt und greife ?ber meine neuen Funktionen CosEx und SinEx darauf zu.
Jetzt habe ich bei vollem Sternenfeld & Co auch ?ber 100 Frames pro Sek.!!!

My TetWiz-Game exits from the Main-Prog (ie. not in a Function) via the End-Command. No use of the Vol-Keys to exit here...

Does it work a 2nd time then?

It works a 2nd time but freezes while trying to exit again...

My TetWiz-Game exits from the Main-Prog (ie. not in a Function) via the End-Command. No use of the Vol-Keys to exit here...

Habe mal ein paar Tests gemacht:

In meinem Sternenfeld im Hintergrund sollen sich 300 Sterne (als Sprites) bewegen. Dazu kommen zur Zeit ca. 30 Sch?sse und ein paar Sprites f?r das HUD. (knapp 20 FpS, auch gerne darunter)

Verringere ich die Anzahl auf 100 Sterne, bekomme ich wackelige 50 Frames, sobald ich anfange "volles Rohr" zu schiessen wird die Rate auf teilweise unter 40 gedr?ckt.

Werden die 300 Sterne nur angezeigt und nicht bewegt, bekomme ich 100 Fps und leicht dar?ber. Sobald die Sch?sse dazukommen geht es auch unter 100 FpS.

Ohne Sterne ?berhaupt zu zeichnen und berechnen, bleibt die Rate so wie im Test mit der reinen Anzeige der Sterne ohne Bewegung (also 100fps und darunter mit Ballerei)

Also muss das Problem nicht in Anzeigegeschwindigkeit von hunderten Sprites liegen, sondern in der Berechung der neuen Positionen...

Folgende Formeln verwende ich zur Bewegung der Sterne und Sch?sse:

x=x+COS(angle-90)*speed
y=y+SIN(angle-90)*speed

x,y,angle,speed sind Floats.

Dazu kommt noch die Berechnung von Punkten zwischen vorgegebnen Wegpunkten mittels Bezier-Splines (koordinaten auch in floats)

Im 2D-Bereich: Die Roto-/Zoom- Befehle (vor allem die Roto-Befehle) zum Spritezeichnen haben bei mir beim GP2X programmieren immer die Performance runtergerissen. Der Rest l?uft eigentlich normal.

Das hatte ich schon mal irgendwo hier gelesen. Benutze stattdessen vorgezeichnete Anims f?r sowas...
Daran liegt?s also nicht...
Trotzdem Danke!

Ich wollte nochmal nachfragen, wie es mit der Programmierung f?r den Wiz grunds?tzlich aussieht.

Ich habe bei meinen Spielen n?mlich immer heftige Framerate-Einbr?che; selbst ein eher anspruchsloses Game wie TetWiz kann keine vollen voreingestellten maximalen 60 FpS darstellen (ich hab?s dann auf 30 runtergedreht).
Einen 2D-Shooter, an dem ich im Moment sitze, kriege ich auf 20 Fps statt max 60 (Sternenfeld im Hintergrund,...)

Muss bei der Umsetzung f?r den Wiz irgendetwas speziell beachtet werden? M?ssen zus?tzliche Libraries in das Spieleverzeichnis? Unter Windows auf meinen "Entwicklungs-PC" l?uft alles flott....

Machen alphablending-Effekte (alphamode...) dem Wiz Probleme?
Was ist mit der fehlenden Fliesskomma-Einheit? Bremst es den Kleinen aus, wenn viele sin/cos-Berechnungen stattfinden; oder auch Bezier-Kurven-Berechnungen f?r die Interpolation zwischen Wegpunkten?

Ich w?sste n?mlich nicht wie ich solche Sachen umgehen k?nnte...

Do you want me to convert the .MP3 to .OGG for you and see if that makes a difference?

Not necessary anymore...I released the Game a little while ago...
But it would be nice to clear that music-problem in nearer future 

In my Program TetWiz, I must use mp3 as music-Format; ogg won?t play properly. (FW 1.0.0)
So, it?s just the other way round...
Maybe you?ll need the music in a special format (8/16 bits, bitrate...)?

Yeah, this is strange. Happens even if you have started another program in the meantime...