# Get blocky look on textures some textures

If I do this:

GraphicsDevice.SamplerStates[0] = SamplerState.PointWrap;

All textures I draw are blocky.

GraphicsDevice.SamplerStates[0] = SamplerState.LinearWrap;

All of my textures are blurred a bit.

What do I have to do so that only some of my textures are blocky and some are blurred?

You would need to use two separate sprite batches for each type of drawing. One for the blocky. One for the blurry.

SpriteBatch.Begin (SpriteSortMode, BlendState, SamplerState, DepthStencilState, RasterizerState, Effect)


The result should look something like this:

SpriteBatch.Begin (SpriteSortMode.Deferred, nil, SamplerState.PointWrap, nil, nil, nil);
//SpriteBatch.Draw(**blocky stuff**);
SpriteBatch.End ();

SpriteBatch.Begin (SpriteSortMode.Deferred, nil, SamplerState.LinearWrap, nil, nil, nil);
//SpriteBatch.Draw(**blurry stuff**);
SpriteBatch.End ();

• Or 1 SpriteBatch in immediate mode if you need to switch often. which is much faster then creating and destroying the SpriteBatch. – ClassicThunder Sep 13 '12 at 21:01
• @ClassicThunder I think eazimmerman means separate "batches" - not separate SpriteBatch objects. Obviously recreating the SpriteBatch object (all all its internal resources) is stupidly slow. But it's also unnecessary. You can draw multiple batches (Begin/End blocks) with the one SpriteBatch object. And SpriteSortMode.Immediate does the almost the equivalent of putting a Begin/End call around each Draw - so it certainly doesn't offer any speed improvements. (The main reason it exists at all is backwards compatibility.) – Andrew Russell Sep 14 '12 at 6:10
• @AndrewRussell I have measured significant performance improvements by changing code that required multiple batches (Begin/End sets) to immediate and changing values that would otherwise require a Begin/End set. – ClassicThunder Sep 14 '12 at 6:57
• @ClassicThunder Yeah, sorry - I should have been a lot less absolute there. Obviously Immediate will give you some improvement - because it does less work. It doesn't setup the sprite matrix each time, for example. I just measured it at a 30% improvement for unbatchable sprites (note that this is a CPU/GPU dependent measure). The point I was trying to make was that it is (almost) the same once it hits the GPU/driver. Moreover, if your sprites are batchable, then you almost immediately lose that performance edge - so ProgrammerAtWork may well be better off lazily switching batches. – Andrew Russell Sep 14 '12 at 8:05
• @AndrewRussell No problem and I agree. I was just wanting to mention the possibility for the sake of completeness. – ClassicThunder Sep 14 '12 at 23:13