I just have a one quick question on Timer and TimerEvent (flash.events.TimerEvent & flash.utils.Timer) of Adobe Flex.
I am currently working on a project wherein I need to occasionally change speed, stop and play an swf animation (loaded to a loader and instantiated as a ByteArray).
Example, I have a moving car (swf animation) running at 40kph. Then I have a button which will change the speed by increments of 40kph. SO basically, whenever I hit the button, the playing car should change speed by the increment. The difficult part is, I already had this working in Adobe Flex but it doesn't change the speed yet. I mean, it only moves by the keyframe interval I set when I created the swf file on flash (which is, to say, 30 frame interval per keyframe).
So in short, I just need to make the speed change depending on how many increments I asked it to change. A colleague told me to use Timer and TimeEvent of Flex but I can't seem to quite get the hang of it since I'm still new to the ActionScript world.
I hope someone can help me. Thanks :)
You need to animate the car from the code. The following code speeds up wheels until 120 km/h:
private var car:MovieClip;
private var speed:Number; // from 0 to 120
private function enterFrameHandler(event:Event):void
{
if (speed < 120)
speed++;
car.wheel1.rotation += speed;
car.wheel2.rotation += speed;
}
The idea is to calculate animation parameters for every new frame "on the fly".
Related
Getting the monitor's refresh rate with AWT/Swing:
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment()
.getDefaultScreenDevice()
.getDisplayMode()
.getRefreshRate()
Question: Is there a similar method/procedure in getting the refresh rate with JavaFX? And if there is one, how to do it?
No equivalent public API in JavaFX
This is the DisplayMode.getRefreshRate() javadoc for the awt API you are currently using:
Returns the refresh rate of the display, in hertz.
There is no equivalent public JavaFX API.
If the public api existed in JavaFX, it would probably be accessible via the Screen class, but there is no accessor for such functionality defined there.
There is an undocumented, unsupported, private API which would appear to offer similar functionality:
com.sun.javafx.tk.Toolkit.getToolkit().getRefreshRate()
JavaFX pulse processing
Related information on how JavaFX works can be found in the pulse documentation for the JavaFX architecture description.
A pulse is an event that indicates to the JavaFX scene graph that it is time to synchronize the state of the elements on the scene graph with Prism. A pulse is throttled at 60 frames per second (fps) maximum and is fired whenever animations are running on the scene graph. Even when animation is not running, a pulse is scheduled when something in the scene graph is changed. For example, if a position of a button is changed, a pulse is scheduled.
When a pulse is fired, the state of the elements on the scene graph is synchronized down to the rendering layer.
The screen hardware refresh rate is different from JavaFX internal pulse processing rate. Though I guess it is technically possible that these could be synchronized in the internal implementation (and that may happen in some cases), there is nothing in the public documentation which mentions whether that actually occurs.
A note on adaptive refresh technologies
Also note, with the advent of technologies such as gsync and free sync the refresh rate can be adapted to the content.
Vertical synchronization is an option in most systems in which the video card is prevented from doing anything visible to the display memory until after the monitor finishes its current refresh cycle . . . technologies like FreeSync and G-Sync reverse the concept and adapts the display's refresh rate to the content coming from the computer. Such technologies require specific support from both the video adapter and the display.
Such technologies make the notion of relying on a hardware refresh rate in the monitor a bit blurry at best.
Answers to FAQs
You state that your intention for querying the display refresh rate is:
Like drawing anything as fast, as long as it's still achievable by the monitor...
JavaFX is, by default intentionally capped at a 60fps frame-rate, regardless of the monitor specifications.
This cap can be overridden using undocumented system properties, as outlined here:
How to ignore the 60fps limit in javafx?
You could use the undocumented feature to remove the frame rate cap in JavaFX and then rely on the underlying video card driver and hardware to render at the maximum rate available within the underlying hardware and software capability for the screen.
Here is the code which deals with that in the openjfx source.
/*
* Called to set the value of PULSE_DURATION or PULSE_DURATION_NS based on
* the refresh rate of the primary screen (unless overridden by the
* FRAMERATE_PROP Setting). If the refresh rate can not be determined the
* default of 60hz is used.
*
* #param precision - precision in (1000 for ms or 1000000000 for ns)
*
* #return pulse duration value, either in ms or ns depending on the
* parameter.
*/
protected int getPulseDuration(int precision) {
int retVal = precision / 60;
// Allow Setting to override monitor refresh
if (Settings.get(FRAMERATE_PROP) != null) {
int overrideHz = Settings.getInt(FRAMERATE_PROP, 60);
if (overrideHz > 0) {
retVal = precision / overrideHz;
}
} else if (Settings.get(PULSE_PROP) != null) {
int overrideHz = Settings.getInt(PULSE_PROP, 60);
if (overrideHz > 0) {
retVal = precision / overrideHz;
}
} else {
// If not explicitly set in Settings, try to set based on
// refresh rate of display
int rate = Toolkit.getToolkit().getRefreshRate();
if (rate > 0) {
retVal = precision / rate;
}
// if unknown, use default
}
return retVal;
}
In the source, the framerate is governed by the undocumented property javafx.animation.framerate, which corresponds to the setting FRAMERATE_PROP in the above source and javafx.animation.pulse which corresponds to the setting PULSE_PROP.
The internal Toolkit class provides a fallback API to use the refresh rate of the display.
So perhaps you could achieve what you want by setting the the system property javafx.animation.framerate, to the value of com.sun.javafx.tk.Toolkit.getToolkit().getRefreshRate() or by setting both javafx.animation.framerate and javafx.animation.pulse to null. I have not tried this, so I do not know. Care would need to be taken to ensure that the values that you set are correctly maintained and not overridden by defaults.
You need to be aware that, if you do this, you are making use of undocumented APIs so this would require opening appropriate module exports so that the APIs are accessible and also may be removed or become incompatible without notice in future versions of the platform (though these settings have been unchanged for many years currently).
So I have been reading the link you provided, and to me, it seems JavaFX is simply stuck at 60fps because it prefers to?
By default, yes, it is a tradeoff.
For the types of applications generally developed using JavaFX 60fps refresh max within the pulse rendering mechanism is generally sufficient regardless of the underlying hardware capabilities of the device. Increasing the rate cap above that level is usually not a good tradeoff for most JavaFX applications as it means use of higher resources (CPU and Video processing capacity and power draw), for gains in refresh updates which are generally undetectable to most users and often not supported by underlying hardware.
That said, if you want to override this default limit, there are undocumented ways of doing so, as mentioned above.
Why not use the same method?
Using the AWT method may be a reasonable alternative in this case.
The hardware refresh won't change depending on the chosen UI toolkit.
Currently (JavaFX 17), the JavaFX system depends on the java.awt package (javafx.base module requires the java.desktop module which contains all of the awt classes). So if JavaFX is available, so is the java.awt.DisplayMode class.
So if the goal is to determine the hardware refresh rate, you can do that using the existing awt API.
The refresh rate won't change when using Swing or JavaFX right?
Hardware refresh rate will not change depending on the UI toolkit used.
The definition of the scene graph pulse rate in JavaFX for updating rendering of the scene graph is somewhat related to refresh rate, but is a JavaFX only concept because Swing does not make use of a scene graph during its rendering phase.
I have a QGraphicsSvgItem that I need to rotate a certain amount based on an external variable coming into my application. Currently I'm directly setting the rotation property of the item, but this appears to significantly drop my frame rate. (117.0 fps -> 98.0 fps) is this normal? Is this the correct way to animate a QGraphicsItem? I realize that the framerate sounds plenty high, but I'm concerned that as more items in the view are animated, that the performance will become a problem.
The code below is being called via a QTimer timeout signal at an interval of 0.
Note that I have also tried using a QGraphicsItem with a custom QPainterPath to draw the item rather than an SVG and it made no noticeable performance difference.
qreal diff = m_rope_length_ft[0] - m_rope_length_ft_prev[0];
qreal angle = diff * 5.0;
m_rope_reel[0]->setRotation(m_rope_reel[0]->rotation() + angle);
m_rope_reel[1]->setRotation(m_rope_reel[1]->rotation() + angle);
m_rope_reel[0]->update();
m_rope_reel[1]->update();
A more proper way to animate in Qt is to use QPropertyAnimation. It requires that:
your graphics item is inherited from both QObject and QGraphicsSvgItem;
rotation is registered as property with Q_PROPERTY (getters and setters already exist so there is no need to implement them).
Also you should try to tune graphics item's cache mode. ItemCoordinateCache seems to be suitable for your case. There is also view cache mode, but it's hard to say which is better in your case.
Note that performance optimization should be done using average amount of items your program should be able to process. Optimizing a single item rendering may be pointless.
I have been developing a game using Flex, and used the Timer class to keep the main loop going.
However, when I tried using the enterFrame event to do the main loop, there were a few problems.
First of all, physics simulation seemed way too fast. Is the enterFrame event called more than once per frame? I set the application's global frame rate to 24, so shouldn't the application set off the event every 1/24 of a second?
And the second problem is that when the game runs like this, some MXML components that are added are not shown. I have absolutely no idea why this happens.
Help me please?!?
Thanks.
Don't count on the framerate to be even, or that the enterframe is called at a fixed interval. Even the timer-class isn't 100% accurate.
When doing timings, always use the delta between frame-updates and use that delta for your calculations. Also be sure to put in a safe-guard that the delta never exceeds some value to avoid strange behavior when the flash application freezes up for some unexpected reason.
This article explains it all perfectly:
http://gafferongames.com/game-physics/fix-your-timestep/
The framerate is a desired value. If a user runs it on a slow machine, you might experience their output to be too slow. How about reverting to the good old
setInterval?
I'm in the process of making a game (a shmup) and I've started to question the accuracy of the timers in ActionScript. Sure, they're accurate enough when you want to time things on the order of a few seconds or deciseconds, but it seems to perform pretty poorly when you get to finer ranges. This makes it pretty tough to do things like have a spaceship firing a hundred lasers per second.
In the following sample, I tested how long (on average) the intervals were between 1000 timer ticks intended for 30ms. Time and time again, the results are ~35-36ms. Decreasing the time, I found the floor on the timer delay to be ~16-17ms. This gives me a max fps of ~60, which is great visually but also means I can't possibly fire more than 60 lasers per second :-(. I ran this test a few times at 100 and 1000 loops, but for both the 30ms test and the 1ms test the results didn't change. I print to a textField at the end because using trace() and launching the swf in debug mode seems to negatively affect the test. So what I'm wondering is:
Is this test a decent measure of the Timer class's performance, or are my results questionable?
Will these results change dramatically on other machines?
I understand this is dependent on the getTimer() method's accuracy, but the discussions I find on this topic usually center around getTimer()'s accuracy on larger intervals.
package
{
import flash.display.Sprite;
import flash.events.TimerEvent;
import flash.text.TextField;
import flash.utils.getTimer;
import flash.utils.Timer;
public class testTimerClass extends Sprite
{
private var testTimer:Timer = new Timer(30, 1000);
private var testTimes:Array = new Array();
private var testSum:int = 0;
private var testAvg:Number;
private var lastTime:int;
private var thisTime:int;
public function testTimerClass()
{
testTimer.addEventListener(TimerEvent.TIMER, step);
testTimer.addEventListener(TimerEvent.TIMER_COMPLETE, printResults);
lastTime = getTimer();
testTimer.start();
}
private function step(event:TimerEvent):void
{
thisTime = getTimer();
testTimes.push(thisTime - lastTime);
lastTime = thisTime;
}
private function printResults(event:TimerEvent):void
{
while (testTimes.length > 0)
{
testSum += testTimes.pop();
}
testAvg = testSum / Number(testTimer.repeatCount);
var txtTestResults:TextField = new TextField();
txtTestResults.text = testAvg.toString();
this.addChild(txtTestResults);
}
}
}
I guess the best route to take would be to just draw multiple lasers in the same frame with different positions and avoid having more than one Timer object.
edit: I used stage.frameRate to change the render frameRate and ran the test on several framerates but there was no change.
Tinic Uro (Flash Player engineer) has written an interesting blog post about this issue some time ago.
Intead of using the timer class at all, I would put my update code in and enterframe eventlistener.
Then use getTimer(), to find out how much time has passed since last update, and then a bit of bit of math to calculate movement, laser "spawning" etc. This way the game should perform the same no matter if you getting 60FPS or 10FPS.
This also prevents weird game behavior if the the FPS drop temporary, or if the game is running on a slow machine.
For the most part the math is pretty simple, and when it is not, you can usually "cut corners" and still get a result good enough for a game.
For simple movement you can simply multiply movement offset with time since last update. For acceleration, you need a second degree equation, but could simplify be multiplying again.
In response to jorelli comment below:
The collision detection problem can be solved by better code, that does not just check the current state, but also what happened between the previous state and the current.
I've never had problems with the keyboard. Maybe you should try this nifty little class:
http://www.bigroom.co.uk/blog/polling-the-keyboard-in-actionscript-3
I just tried running your sample code, exactly as-is except as a frame script, and where I'm sitting Timer works exactly as you'd expect. With a 30ms timer, the average comes out about 33-34, and with a 3ms timer it comes out around 3.4 or 3.5. With a 1 ms timer I get between 1.4 and 1.6 over a thousand trials. It works that way in Flash and in the browser.
So as for the accuracy, see Tinic's blog post in Luke's answer. But for the upper limit on frequency, if you're getting events no faster than 16ms apart with only the sample code you posted, either something's weird, or maybe that's the upper limit on how fast your browser is giving Flash timing messages. If you're getting those results in your actual game, I think you simply have synchronous code that blocking the timer events.
One more thing - I know it's not what you asked, but it would really be wiser to handle your game logic in an ENTER_FRAME handler. It doesn't matter whether the code to spawn lasers runs every 30ms or every 3ms, the screen only gets redrawn once per frame (unless you're forcing it to update more often, which you probably shouldn't be). So whatever happens between screen refreshes is just overhead that lowers your overall framerate, since with a little cleverness it ought to be possible to achieve the exact same results as you'd get from a timer that executed more frequently. For example, instead of spawning a laser every 3ms, you could spawn 10 lasers every 30ms, and move each one a certain distance along its flight path, as if it had been created 3 or 6 or 9ms earlier.
Another natural way to run your logic off frame events would be to make a game loop that "theoretically" runs every T milliseconds. Then, in your ENTER_FRAME handler, simply iterate that loop F/T times, where F is the number of ms that have elapsed since the last frame event. Thus if you want the game to theoretically update every 5ms, and you want the screen to update at 30FPS, you'd simply publish at 30FPS, and in your ENTER_FRAME handler you'd call your main game loop 5-7 times consecutively, depending on how long it had been since the last frame. Onscreen, this will give you the same results as if you had used a 5ms timer event, and it will dispense with much of the overhead.
BitmapData.scroll and BitmapData.copyPixels are the fastest way to render in flash right now, although on a few systems, using movieclips with gpu acceleration is slightly faster. Each quad is rendered as a separate texture in OpenGL, so its not what you'd expect from an ordinary GPU accelerated application. I know, because I profiled both ways in my game. One thing that you can do to improve response time is to call your game update from the input event handlers. That way, you hear correctly timed sounds even when your game's framerate is lower, and the application will feel more responsive.
This gives me a max fps of ~60, which is great visually but also means I can't possibly fire more than 60 lasers per second :-(
I would say you are very lucky to be getting that kind of FPS as it is, and the majority of your users (assuming your audience is the internet at large) will more than likely not be achieving that kind of framerate.
I would agree that the abilities of the flash player are probably not sufficient for what you are trying to achieve.
In our game project we did have a timer loop set to fire about 20 times a second (the same as the application framerate). We use this to move some sprites around.
I'm wondering if this could cause problems and we should instead do our updates using an EnterFrame event handler?
I get the impression that having a timer loop run faster than the application framerate is likely to cause problems... is this the case?
As an update, trying to do it on EnterFrame caused very weird problems. Instead of a frame every 75ms, suddenly it jumped to 25ms. Note, it wasn't just our calculation claimed the framerate was different, suddenly the animations sped up to a crazy rate.
I'd go for the Enter frame, in some special cases it can be useful to have two "loops" one for logic and one for the visuals, but for most games I make I stick to the Enter frame-event listener. Having a separate timer for moving your stuff around is a bit unnecessary since having it set to anything except the framerate would make the motion either jerky or just not visible (since the frame is not redrawn).
One thing to consider however is to decouple your logic from the framerate, this is most easily accomplished by using getTimer (available in both as2 and as3) to calculate the time that has expired since the last frame and adjusting the motions or whatever accordingly.
A timer is no more reliable than the enter frame event, flash will try to keep up with whatever rate you've set, but if you're doing heavy processing or complex graphics it will slow down, both timers and framerate.
Here's a rundown of how Flash handles framerates and why you saw your content play faster.
At the deepest level, whatever host application that Flash is running in (the browser usually) polls flash at some interval. That interval might be every 10ms in one browser, or 50ms in another. Every time time that poll occurs, Flash does something like this:
Have (1000/framerate) miliseconds passed since the last frame update?
If no: do nothing and return
If yes: Execute a frame update:
Advance all (playing) timelines one frame
Dispatch all events (including an ENTER_FRAME event
Execute all frame scripts and event handlers with pending events
Draw screen updates
return
However, certain kinds of external events (such as keypresses, mouse events, and timer events) are handled asynchronously to the above process. So if you have an event handler that fires when a key is pressed, the code in that handler might be executed several times between frame updates. The screen will still only be redrawn once per frame update, unless you use the updateAfterEvent() method (global in AS2, attached to events in AS3).
Note that the asynchronous behavior of these events does not affect the timing of frame updates. Even if you use timer events to, for example, redraw the screen 50 times per second, frame animations will still occur at the published framerate, and scripted animations will not execute any faster if they're driven by the enterFrame event (rather than the timer).
The nice thing about using enter frame events, is your processing will degrade at the same pace as the rendering and you'll get a screen update right after the code block finishes.
Either method isn't guaranteed to occur at a specific time interval. So your event handler should be determining how long it's been since it last executed, and making decisions off of that instead of purely how many times it's run.
I think timerEvent and Enter Frame are both good options, I have used both of them in my games. ( Did you mean timerEvent by timer loop? )
PS: notice that in slow machines the timer may not refresh quick enough, so you may need to adjust your code to make game work "faster" in slow machines.
I would suggest using a class such as TweenLite ( http://blog.greensock.com/tweenliteas3/ ) which is lightweight at about 3kb or if you need more power you can use TweenMax, which i believe is 11kb. There are many advantages here. First off, this "engine" has been thoroughly tested and benchmarked and is well known as one of the most resource friendly ways to animate few or even many things. I have seen a benchmark, where in AS3, 1,500 sprites are being animated with TweenLite and it holds a strong 20 fps, as where competitors like Tweener would bog down to 9 fps http://blog.greensock.com/tweening-speed-test/. The next advantage is the ease of use as I will demonstrate below.
//Make sure you have a class path pointed at a folder that contains the following.
import gs.TweenLite;
import gs.easing.*;
var ball_mc:MovieClip = new MovieClip();
var g:Graphics = ball_mc.graphics;
g.beginFill(0xFF0000,1);
g.drawCircle(0,0,10);
g.endFill();
//Now we animate ball_mc
//Example: TweenLite.to(displayObjectName, totalTweeningTime, {someProperty:someValue,anotherProperty:anotherValue,onComplete:aFunctionCalledWhenComplete});
TweenLite.to(ball_mc, 1,{x:400,alpha:0.5});
So this takes ball_mc and moves it to 400 from its current position on the x axis and during that same Tween it reduces or increases the alpha from its current value to 0.5.
After importing the needed class, it is really only 1 line of code to animate each object, which is really nice. We can a also affect the ease, which I believe by default is Expo.easeOut(Strong easeOut). If you wanted it to bounce or be elastic such effects are available just by adding a property to the object as follows.
TweenLite.to(ball_mc, 1,{x:400,alpha:0.5,ease:Bounce.easeOut});
TweenLite.to(ball_mc, 1,{x:400,alpha:0.5,ease:Elastic.easeOut});
The easing all comes from the gs.easing.* import which I believe is Penner's Easing Equations utilized through TweenLite.
In the end we have no polling (Open loops) to manage such as Timer and we have very readable code that can be amended or removed with ease.
It is also important to note that TweenLite and TweenMax offer far more than I have displayed here and it is safe to say that I use one of the two classes in every single project. The animations are custom, they have functionality attached to them (onComplete: functionCall), and again, they are optimal and resource friendly.