Timer - Idee

[WPShadow]

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!

[hoessi666]

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....

[Tenorm]

Hab ich auch mal gemacht, bei erfolgreicher Umsetzung gibt sich aber ein kleines ( ) Problem: Wenn aufgrund irgendeiner cpu-Schwankung die fps einbrechen l?uft viel schief: z.B. Kollisionen werden verf?lscht (also wenn man vor der Wand steht und sich pl?tzlich 100 statt 10 Einheiten weiter darauf zubeweget k?nnte man auf der anderen Seite stehen 

[Hemlos]

Im sorry about not being able to communicate in german...
I think I know a solution for everyone(hopefully).
If you can understand this, please translate it for the others:

The problem isnt just with FPS.
The problem is a combined issue for a movement rate, relative to FPS, AND screensize.

If you want movement to be the same on any computer with your program,
you must scale and factor everything (time, screen size, movement size).

Proof of concept is in the particle system i recently created.
In order to make all the particles move on any computer, the same relative size factor as on some other computer(which may be a different screen size and different FPS), i had to create a movement size algorithm, which is factored in every frame.
No matter what i set in LIMITFPS.....all particles movement size is relavant to time and screensize.
If the FPS are low at 10, or high at 800....the particles will still travel across the screen in the same distance during the same amount of time!
The idea is this: If a particle moves across a screen, from one side to another, in one second time....it must do the same thing on any computer, using any screensize.

So i built this algorithm to cover any screensize, with any FPS:

Code (glbasic) Select Expand

MovementFactorPerFrame = ( ScreenHeight / 2) * 0.001 * GETTIMER()
(Algorithm translation: half the screen height is a relavant movement size factor of 1, divided by frame time.)

To change the real speed.....use a multiplier:

Code (glbasic) Select Expand

MovementSize = MovementFactorPerFrame * SpeedMultiplier

I have been pounding my head for years to solve this issue...this algorithm is a GOLDEN EGG.
As soon as V7 beta is full version, my particle system will be available, and you will be able to see this algorithm in action. To test...use 2 computer with the same program, and move the particles on both computers at the same time......all objects should move roughly the same relative speed, and the same relative distance compared to the screen size.

Note: And as others have said, make sure you VSYNC FORCED OFF, and set LIMITFPS 10000.
If you dont do this...your(any computer your program is on) FPS are limited to your video refresh rate.
If FPS>VSYNC is needed for your program to function properly....make sure you document this information about VSYNC in your help file, stating in it, to force vsync off!

Hopfully, someone can help properly convey the idea here.
In the event that this document is irrelavant to the topic, i blame it on my translator

[Moru]

Hemlos, why pound your head to a wall when you have but to ask? If you download my first GLBasic program you have the solution there. It's called Worms and can be found on my homepage.

[WPShadow]

Is it possible to see the timer in there???

I found the program and the source, but not the timer inside! 

[Hemlos]

Did you try this?

Code (glbasic) Select Expand

MovementFactorPerFrame = ( ScreenHeight / 2) * 0.001 * GETTIMER()

If you need help with it, let me know.

[WPShadow]

Ok for 2D! But is it useful for 3D too?

I tried to make a timer for 2D and 3D together and 3D is the biggest problem... 

[Hemlos]

Ok for 2D! But is it useful for 3D too?

I tried to make a timer for 2D and 3D together and 3D is the biggest problem... 

I dont think you need this algorithm with 3d...
..perhaps just a timer testing the last frame time is all that is needed:
Because, there is no variation in the world size from one computer to the next,
Unlike 2d where the screensize is the area that may differ in movement factors.

This should be good enough for 3d:

MovementFactorPerFrame = 0.001 * GETTIMER()

I will be testing this variation with my particle system. If i find anything unusual about movement timers in 3d, ill report back here again.

[WPShadow]

Great, thx for your help!

[Hemlos]

No problem. Cheers