Bug 1167 : frameRate vs. frameRateTarget
Last modified: 2009-02-23 05:24




Status:
ASSIGNED
Resolution:
-
Priority:
P4
Severity:
enhancement

 

Reporter:
Ira
Assigned To:
fry

Attachment Type Created Size Actions

Description:   Opened: 2009-02-21 22:09
This is more of a question than a bug perhaps, based on a specific issue in
the current chapter i'm working on:

I'd like to use the sketch frameRate as a value in a pre-animation
calculation, but of course I only get 10 back. It seems that my options are
to create a separate myFrameRate variable or access frameRateTarget. I've
resorted to the latter, but not sure if it's a good idea, pedagogically
speaking. Thoughts?
Additional Comment #1 From fry 2009-02-22 10:16
Hm, what's the larger thing that you're trying to accomplish?

From the sound of it, you perhaps should be calculating the frame rate
yourself, use millis() or System.nanoTime(). The frameRate value is meant
for printing to the screen, or as a diagnostic. It's not guaranteed to be
frame accurate (e.g. might have damping).
Additional Comment #2 From Ira 2009-02-22 10:27
(In reply to comment #1)
>
>
>
> Additional Comment #1 From
>
> fry
> 2009-02-22 10:16
>
> <!--
> addReplyLink(1); //-->[reply]
>
>
>
>
> Hm, what's the larger thing that you're trying to accomplish?
>
> From the sound of it, you perhaps should be calculating the frame rate
> yourself, use millis() or System.nanoTime(). The frameRate value is meant
> for printing to the screen, or as a diagnostic. It's not guaranteed to be
> frame accurate (e.g. might have damping).
>
>

I actually don't need precise accuracy, just a value near the set frame
rate. The example is a particle engine that generates an overall birth rate
based on particle life, particle count and frame rate. The engine keeps
replenishing the particles, which is why I wanted to encapsulate this birth
rate calculation. It's not a big deal, and I can use it as an advanced
example introducing the the dev API. I just worry that public properties on
dev may not necessarily stay that way in the future, right?
Thanks.
Additional Comment #3 From fry 2009-02-23 05:24
Ah, ok.. Yeah, I think you just need to keep a copy of what you've set the
frameRate to, until we have a better way of dealing with this.

Variables that are 'public' in PApplet should be safe to write about. The
frameRateTarget variable is protected which means subject to change (but
still accessible by subclasses for the time being).
This bug is now being tracked here.