The simple approach is to just make the thing that used to be
Singleton<T> a global
T instead. Globals have problems too, but they don't represent a bunch of extra work and boilerplate code to enforce a trivial constraint. This is basically the only solution that won't involve (potentially) touching the entity constructor.
The more-difficult, but possibly better approach is to pass your dependencies to where you need them. Yes, this might involve passing a
Window * to a bunch of objects (like your entity) in a fashion that looks gross. The fact that it looks gross should tell you something: your design might be gross.
The reason this is more difficult (beyond involving more typing) is that this often leads to refactoring your interfaces so that the thing you "need" to pass is needed by fewer leaf-level classes. This makes a lot of the ugliness inherent in passing your renderer to everything go away, and it also improves the general maintainability of your code by reducing the amount of dependencies and coupling, the extent of which you made very obvious by taking the dependencies as parameters. When the dependencies were singletons or globals, it was less obvious how interconnected your systems were.
But it is potentially a major undertaking. Doing it to a system after the fact can be downright painful. It may be far more pragmatic for you to simply leave your system alone, with the singleton, for now (especially if you're trying to actually ship a game that otherwise works just fine; players aren't generally going to care if you have a singleton or four in there).
If you do want to try doing this with your existing design, you may need to post a lot more details about your current implementation as there isn't really a general checklist for making these changes. Or come discuss it in chat.
From what you've posted, I think a big step in the "no singleton" direction would be to avoid the need for your entities to have access to the window or view. It suggests that they draw themselves, and you don't have to have entities draw themselves. You can adopt a methodology where the entities just contain the information that would allow them to be drawn by some external system (which has the window and view references). The entity just exposes its position, and the sprite it should use (or some kind of reference to said sprite, if you want to cache the actual sprites in the renderer itself to avoid having duplicate instances). The renderer is simply told to draw a particular list of entities, which it loops through, reads the data from, and uses its internally-held window object to call
draw with the sprite looked up for the entity.