What's "cracking" ? It is finding a password value which your system will accept, i.e. one which will match whatever your system stores as hash value in its database. If the attacker finds another password, distinct from the "true" password, but which matches the hash, then the attacker wins nonetheless.
For a given hash value, there are already many matching passwords (because there are "only" 2256 possible hash values, and many more possible passwords if you accept "long" passwords, say 50 characters). By truncating the hash value, you only increase the number of passwords which, when hashed-and-truncated, will match what you stored; i.e. you only make things easier for the attacker.
Now things are not necessarily so dire. SHA-256 offers 256 bits of output because it tries to offer resistance to collisions of at least 2128, and you need 256 bits of output to get that much resistance. However, collisions are not an issue for hashed password storage; what is needed is resistance to preimages. This one requires only n bits of output for 2n resistance. In other words, if you keep only 128 bits (that's 32 hexadecimal characters) then you are still "fine", or at least not substantially worse than what you would be with the full 64 characters.
Caution: a simple hash is not good. Though you do not weaken it any further (at least not in a practically meaningful way) by truncating it, you already have two problems:
- You have no salt, which allows the attacker to apply time-wise or space-wise parallelism. Namely, attacking many passwords simultaneously, and/or using precomputed tables (rainbow tables).
- A single hash is too fast, making it easy for the attacker to try millions, possibly billions of potential passwords per second.
So you need a better password-hashing process, one which can be configured for slowness and which uses a salt (a new random salt for each password). Usual recommendation is bcrypt. Then, and only then, you might envision a truncation (but keep at least 128 bits, and homemade alterations to cryptographic algorithms are not recommended on a general basis).
Edit: to clarify things: an attacker with unlimited computing power may try to enumerate all possible passwords and keep the ones which match the stored hash values -- these are candidates for being the "true" password. By truncating the hash, you increase the number of candidates, so, in a certain light, the attacker is farther from guessing the "true password". However, the attacker is not after the "true password", but after a password which grants access. Any password which matches the stored value will grant access, since the server grants access on the basis of "the entered password matches the stored hash value". So any candidate is good enough for the attacker.