You can draw a rectangle, with a Texture2D of 1 pixel width and length, with the color of your choice. No need to use SetData which can be slow with huge amounts of data (even a little cost when few data is passed)
Or create the coloring Texture2D at startup, so SetData is not called at runtime each frame for each rectangle.
Can you explain this a little more? SpriteBatch is the best way to draw rectangles. Internally it uses triangle primitives for rendering. Perhaps SpriteBatch API could be cleaned up or augmented…
I would create one texture from on load from a colorarray the size of the screen in a seperate project just to create a image or use paint.
I would straight blit parts of it without streaching at all.
(by this i mean)
The source Rectangles and destination Rectangle portions would have the same Width and Height.
(this could be multiple smaller parts of the source)
As a matter of acetic choice, the destination drawing position of the rectangle (the X Y) might be randomized just prior to drawing or evenly distributed across the screen.
It could be as many blits as desired and the duration of each blit might be longer or shorter.
i would make these all a shade of grey to white in the texture then use the color parameter in spritebatch to to either shade each blit as well as manually set the colors transparency Alpha value the A portion of the color.
e.g (something like the below for actual drawing).
// you could use the same rectangle for source and destination.
// provided its not out of bounds of the texture itself.
// just s below
Point s = new Point();
s.X = (int)Math.Random(0, sourceTexture.Width);
s.Y = (int)Math.Random(0, sourceTexture.Height);
Point d = new Point();
d.X = (int)Math.Random(0, viewport.Width - s.X);
d.Y = (int)Math.Random(0, viewport.Height - s.Y);
if you make a class that stores the parameters put that into a list or array and just keeps drawing the lists or arrays parameters till the class says a item has run out of time and should be replaced. Then you can control how often it happens how visible it is and how much processing power it uses. As well as change how the effect looks from a static effect to a sort of artifact effect you might see in a low res movie.
Transparency controls how much of a impact on the eyes the effect has in general…
LithiumToast, I’ve had problems with the enlarged pixel, or small texture and the anti-alias, that feathers the texture you draw. This is wanted for most of the textures, but not for sharp edges, and I’m trying to avoid multiple sb.Begin, sb.End as I’ve read this is expensive.
Willmotil, that is pretty much exactly what I have thought of for that approach. This also allows for extra noise by using a graphic.
Well, if you really wanted to you could use a pixel shader that doesn’t use a texture at all. But that is not really advised since it’s a lot of work to dive down into the rendering pipeline details; I think SpriteBatch can do the job for you if your requirement is just to draw rectangles. Have you tried playing around with different sampler states? SamplerState.PointClamp will make ensure sampled texels are given that aliased, blocky, retro feel.
I don’t personally see what the problem with using a pixel shader is. This is exactly the perfect use case for them and could be implemented any number of ways with little speed impact
If that’s not an option on the other hand, I would pre-render the effect if possible. Create a spriteboard of frames of static noise and play them overlayed the scren. It wouldn’t need to be high in resolution or frame count to create an effect on par with old CRT monitors. I would imagine this to be the fastest option and the picture won’t take much memory