Lot's of folks here have answered the questions well but I thought I'd throw my hat into the ring as well:
Singleton as a "one and only one" instance enforcement
This is better handled with standard object construction / destruction; if there should only be one instance of an object in your program, instantiate only one.
If your code would break because more than one object has been instantiated that is a big problem that should be solved.
In theory properly designed code should not care about instances created in isolation, instances only become useful when associated with other instances or directly acted upon.
Singleton as a global point of access
Many people use singletons for the ability to access features from various points in their program; this is a huge design flaw.
By making a direct reference to say "TextureManager::getInstance()" you have failed to properly declare your collaborators from the accessing class.
Collaborators should be explicitly declared either via constructor parameters (for required objects for normal baseline functionality) or via setters for optional functionality.
This explicit declaration and requiring to pass instances to other instances, forms your object graph, the ability to construct and destroy your object graph without any residual state, is hugely important for testing, and avoiding flaky behavior.
"I can't go around passing instances into objects, that's too tedious and I don't know all the places I want to use my object"
First off, the excuse of not wanting to explicitly declare what objects can operate on other objects is laziness; and will lead to bugs, hard refactoring, "spaghetti" code smell, and will make it harder to see and understand good design choices from poor ones.
Many developers provide the scenario that, when creating an object from within another object, they may not have the instance they need to construct that object.
The problem with this scenario is deeper than the problem suggested however, if you have objects deep in your object graph creating other objects; you've already lost the battle.
You should take steps to have top-level code, such as a Factory, build and construct objects according to a design specification (such as loaded game data), these objects then work when assembled properly and have no concern about how they were joined together.
Consider the example of a Car object, within its constructor it creates an Engine, and four Wheel objects.
You would rightly assume that the Car constructor would need all the parameters that the Engine and Wheel objects require, putting a considerable number of confusing parameters into the Car constructor.
e.g: Car(color, horsePower, rpmRedLine, whiteWalls, treadPattern);
If instead you have a CarFactory object, take in such information, it can then create Car, Engine and Wheel objects in isolation, and join them together based on specification in CarFactory.
This keeps specification and implementation of Car, Engine and Wheel light; and allows for Substituting of subclasses if required; which would not be possible if Car's constructor were doing the 'new' ing.