Very good point about frame rate... it's always a contentious issue, but I've been very happy targeting 30FPS on an E-125. I've been able to do everything I want to thus far at that rate and it remains solid (the only thing I've observed slowdowns with is when I'm making use of alpha blending over a large area, but that's to be expected).
I admit I'm not writing a 3-D engine for a first-person shooter, but if I was I probably would be writing my own library anyway!
Again, my own opinion which you are of course welcome to disagree with, is that using PF with sound extensions, if your set as your goal a solid 30FPS on an older MIPS device, you will find that you have plenty of overhead for relatively complex games on any modern device.
Further, I would limit the frame rate as per the various posts floating around here on the topic and then use multi-pixel moves for variable speed. Naturally with that you have to keep in mind that a sprite moving more than a few pixels a frame will appear jumpy... I think I've observed that five or less pixels per frame looks OK, anything more starts to look jumpy.
One last point, again more a matter of opinion than anything else... when your dealing with large chunks of data that is unchanging, like map data, the coding required to deal with it out of a resource tends to be a little less in terms of lines of code, and I think somewhat less error prone (no need to worry about missing files for instance). To me, unless you have real reasons for wanting it in a file, resources are the way to go. I suspect that will be a little better performing as well, but I've done no testing to prove or disprove that, so I could be entirely wrong. Either way, you can deal with it as a stream of byte (or larger types) data, as I do with my cut scene scripts, or as structs, as adde pointed out, which is very powerful when your data is more complexly structured.
and I don't know a real fps speed on other devices, so where can I find results of Gapi testing on different devices or something. 
