What Input Layer Will People Look To Use?

[nimnimnim]

I'm going to start hacking a project in some crossplatform manner and I'm wondering which input system I should abstract on, thinking the community might settle on a favorite or even an official (as per sdk?) eventually. (not that I can't start with anything and then just change it but I'm curious too )

So which library/layer do you use, plan on using or would you like to be using in the end?

I guess SDL is the main candidate for people right now?

As for me I'd like to consider OIS allthough I haven't used SDL input recently enough to know of the limitations so I'm not saying I'm sure OIS is better or anything...

 

[Squidge]

Yes, SDL is the main candidate. It will work for frame buffer and X. People are expected to use it unless they require extreme performance. Basically, if you don't use SDL, you will have to do everything that SDL does for you, yourself (and why waste that time reinventing everything?).

Maybe you can use OIS via SDL?

 

[Tinnus]

I'm pretty sure OIS has an SDL backend

 

[senquack]

Rlyeh has briefly discussed a new object-oriented evolution of his minlib and I believe I recall him mentioning Pandora somewhere alongside it. Don't quote me on that.

 

[Squidge]

I don't see the point of Minilib on Pandora when the default environment is X, and SDL is dynamically linked. Rlyeh would have to implement a lot of code into his library that is already written for SDL.

It only really makes sense on Gp2X and Wiz - the sdl is typically statically linked (bloating the binary) and accessing the hardware directly is the best way of writing apps.

 

[Pickle]

It only really makes sense on Gp2X and Wiz - the sdl is typically statically linked (bloating the binary) and accessing the hardware directly is the best way of writing apps.

With open2x isnt dynamic libs possible?

 

[Squidge]

With open2x isnt dynamic libs possible?

Yes, but it makes sense to make your app compatible with a larger user base, so typically, statically linked is the only option.

 

[javaJake]

I'm planning to stick with SDL as well. Like the others have said, SDL does most of the work for you. (The only thing I'd personally worry about would be the speed of SDL - for some reason I have the notion in my head that SDL is slower than anything else, but also easier than anything else. )

 

[nimnimnim]

iirc from the code (may have changed) OIS uses SDL backend on some unprioritised platforms (was it Mac?) but dinput on win etc.

well seems SDL is what will be served. makes it all very easy anyways

 

[senquack]

I'm planning to stick with SDL as well. Like the others have said, SDL does most of the work for you. (The only thing I'd personally worry about would be the speed of SDL - for some reason I have the notion in my head that SDL is slower than anything else, but also easier than anything else. )

SDL is fast as long as it has accelerated support on your platform. It's fastest if you use it in its native language, C.

Even unaccelerated is fast. I've benchmarked 32-bit to 16-bit large surface blits, first in SDL, then using a crappy ARM assembly loop. SDL beat the crappy ARM assembly loop. Using straightforward ASM optimizations (no "tricks") I was only able to improve on SDL by 5% or so. A clever hacker (Photon I believe) improved the same ASM routine by something like >30% but it involved lots of tricks and added restrictions on the blit unsuitable for a general-purpose library.