search

libretro-mirrors / libretro-arb

For proposed improvements to libretro API.
8 stars 2 forks source link

Do we need retro_input_poll_t? #11

Closed Alcaro closed 9 years ago

Alcaro commented 9 years ago

Blocks: #8 retro_input_poll_t seems completely pointless to me. Can we declare that polling is the frontend's job, just before entering retro_run? I've left it blank in minir and haven't seen any weird results from that. The only possible reason I see for letting the core poll is if it wants to poll after rendering half of its frame, or something crazy like that, which seems too unusual to warrant an extra function. If we need it, let's at least demote it to an env callback.

Druage commented 9 years ago

We currently don't use it on Phoenix either.

Themaister commented 9 years ago

The rationale of input_poll_t is to let cores defer input polling for as long as possible/sensible (decreases latency).

Alcaro commented 9 years ago

Yes, that is indeed the only possible meaning behind that function. Yet, to my knowledge, none of them use that ability; they all call it as soon as they enter retro_run. I don't mind a RETRO_ENVIRONMENT_POLL_INPUT for the cores that need it, but for cores that don't do anything fancy, I want it to default to the simplest possible method - that is, remove retro_set_input_poll() and let the front poll before retro_run(). Or maybe we want RETRO_ENVIRONMENT_GET_POLL, which returns a retro_input_poll_t and makes the front disable its auto polling; we don't want to poll twice per frame. I'm sure there is a way to satisfy everyone on this topic.