On Sat, Aug 4, 2012 at 4:24 AM, Olli Pettay <olli.pet...@helsinki.fi> wrote:
> 5ms is quite low when the aim is 60Hz updates... but with > incremental/generational GCs 5ms sounds very much possible. > 5ms is an *eternity* when you're aiming for 60 FPS, where you only have 16.6ms per frame to play with. That's 30% of your CPU budget just for memory management. It doesn't matter if it's 5ms every 100 frames, since it's the worst case you have to optimize for. (I've spent a lot of time optimizing non-web games to stay at 60 FPS, and it's a battle of microseconds, optimizing away .1ms here and .2ms there, so calling 5ms "quite low" is a bit troubling.) But like I said, I think we should punt on this for now; if it turns out to be needed, a GC-friendly abstraction can always be thinly layered on top of this one. (I have a partially-formed mental picture of how that could work, but I really don't want to sidetrack the thread with that. I'm not convinced that playing GC whack-a-mole is a practical solution to this, though.) On Sat, Aug 4, 2012 at 12:25 PM, Florian Bösch <pya...@gmail.com> wrote: > - A mixed model is where an axis is used with tresholds (like say a weapon > trigger with the index finger). A miss is not bad, but response accuracy > will improve from getting the event as close to the threshold as possible. > So this would inform the API of its thresholds for this axis, so events can > be issued when the high frequency polling detects the axis going over the > it. > I'd suggest also putting this off until later--it can be added if it turns out to be needed in practice. (You're describing using analog inputs as binary inputs, and there are a few ways to do that, but I'd lean towards not complicating the API with it at the start.) (I think we should let the thread sit for a while until Scott gets back around to it, so the discussion doesn't get too far ahead of itself.) -- Glenn Maynard