|There are a lot of approaches to different problems, but which is the best?|
There's hardly ever a hands-down "best" solution for a given problem. One may be better than others in some circumstances, but might be worse in other circumstances.
In programming, there is never a one-size-fits-all.
That said.... here are my personal thoughts on the above mentioned topics
Passing window identifiers around to parts of the program that only need input is rather strange, so I would probably bind to a Input reference.
However, the real question here should be "do I use sf::Input or should I use events?"
Events have the perk of being less likely that they'll be missed. For example say the user presses and releases a button really fast while your program is stalled. If you poll the realtime status with sf::Input, you can miss the button press entirely. However if you work with events, you'll still catch it.
Of course most things in games are based on real-time states and not one-time events, so I tend to favor using sf::Input directly for in-game play. Although I try to use events for things like when the user is customizing their controls.
I tend to prefer having a manager with a unique identifier for each image (typically the identifier is the filename). The advantage to this is that you don't have to concern yourself with preloading the image. The manager can just load the image as it's needed.
This works well with other resources as well.. like sound effects and BGM.
IMO it's best not to derive from sf::Sprite, since:
1) it doesn't really make logical sense to do so
2) it means you can only have 1 sprite per object.
What if you want a complex drawn object... like having the arms drawn separately from the torso so that they could be rotated. Or if you draw the face separately so you can have different expressions. Or if you draw different pieces of armor based on what equipment the player is wearing, etc, etc.
There is definitely no one-size-fits-all or even a one-size-fits-most for this problem. This is definately something that needs to be carefully examined and decided on a per project basis.
I do vaguely recall recommending NGen stay away from callbacks because they're unnecessary, confusing, error prone, and have difficult syntax. IIRC, he could just as easily have had a virtual function... but wanted to simulate virtual functions with callbacks for whatever reason. I don't recall the details that well.
For my latest project I'm trying to KISS with hard coded (but rationally organized) objects. That is, enemies and whatnot's logic will all be coded in C++, but will be organized into different classes in a logical hierarchy.
Objects are created dynamically when the map is loaded (which object is where is all stored in the map file) and each object will have different functions called upon different events. Like when they are hit, when they die, etc.
In previous projects I tried to go a step further and have a mini scripting language with which I would code all my object AI and things. The game would then run it all through an interpretter/VM. The problem is coming up with an effective model for that is rather difficult. On the plus side... it makes your game incredibly dynamic, and the possibilities for user mods expands dramatically, since they can just write their own enemies and things.
I'm not a fan of letting the framerate determine the logic speed. An alternative that I'm currently experimenting and working with is to run your logic at a fixed speed based on a clock (not the framerate). Then interpolate the drawing between logic updates.
For example, if the player moves from x=0 to x=10 on an update, and the screen is drawn 60% of the way between those two updates, you would draw the player at x=6.
There's are pros and cons to each though.
pro: smoothest graphics possible when vsyncing
con: if user has mismatching refresh rate, you either can't vsync (which means your graphics aren't smooth anymore) or you'll run at incorrect speed
time based with interpolated graphics
pro: can always vsync
pro: consistent game logic rate no matter what
con: much more difficult to implement correctly
I don't really have any thoughts on the subject, as I have yet to find a way to work multi-threading into my game projects.