So I've been trying to wrap my head around shaders in 2D in XNA.
http://msdn.microsoft.com/en-us/library/bb313868(v=xnagamestudio.31).aspx
This link above stated that I needed to use SpriteSortMode.Immediate, which is a problem for me because I have developed a parallax system that relies on deferred rendering (SpriteSortMode.BackToFront).
Can someone explain to me the significance of SpriteSortMode in shaders, if Immediate is mandatory, anything I can do to maintain my current system, and anything else in general to help me understand this better?
In addition, my game runs off of multiple SpriteBatch.Begin()/End() calls (for drawing background, then the game, then the foreground and HUD and etc). I've noticed that the Bloom example does not work in that case, and I am guessing it has something to do with this.
In general, I've been having some trouble understanding these concepts. I know what a shader is and how it works, but I don't know how it interacts with XNA and what goes on there. I would really appreciate some enlightenment. :)
Thanks SO!
The sort mode will matter if you are attempting to do something non-trivial like render layered transparency or make use of a depth buffer. I'm going to assume you want to do something non-trivial since you want to use a pixel shader to accomplish it.
SpriteSortMode.Immediate will draw things in exactly the order of the draw calls. If you use another mode, SpriteBatch will group the draw calls to the video card by texture if it can. This is for performance reasons.
Keep in mind that every time you call SpriteBatch.Begin you are applying a new pixel shader and discarding the one previously set. (Even if the new one is just SpriteBatch's standard pixel shader that applies a Tint color.) Additionally, remember that by calling SpriteBatch.End you are telling the video card to execute all of the current SpriteBatch commands.
This means that you could potentially keep your existing sorting method, if your fancy pixel shaders are of limited scope. In other words, draw your background with one Effect and then your foreground and characters with another. Each Begin/End call to SpriteBatch can be treated separately.
If your goal is to apply one Effect (such as heat waves or bloom) to everything on the screen you have another option. You could choose to render all of your graphics onto a RenderTarget that you create instead of directly to the video card's backbuffer. If you do this, at the end of your rendering section you can call GraphicsDevice.SetRenderTarget(null) and paint your completed image to the backbuffer with a custom shader that applies to the entire scene.
I'm not one hundred percent sure on how much the sprite sorting mode effects shaders, i would think it would vary depending on what you were using the shader for.
as for bloom if you're using multiple begin and ends (which you really want to minimise if you can). you can create a render target the size of the screen, draw everything as you are now. then at the very end, take that render target back (using graphicsdevice.SetRenderTarget(null);) then draw your full screen render target (at 0,0 position) with the bloom shader, that way you will bloom the entire scene, regardless of the components of the scene using various sort modes.
Related
I have a really peculiar question. I want to deteriorate the graphics in Unity of just a part of the screen. For example, if I'm playing a game with the screen split in two, one player can be playing with ultra graphics and the other, low ones. Is there a simple way of doing this, like setting the graphics quality on each camera? Thank you so much for your help!
I don't imagine and easy way to do that.
Graphics are the conglomerate of multiple things (at least for me); the number of polygons of an object, the size of the textures, etc.
So the only thing I know you can do, is to duplicate the scene (like if you are making and on-line game) and load this duplicate scene with different materials, models and textures on one player scene. Then synchronize the rest of the scene, so both players are looking the "same" scene.
Also you can "deform" the image, with shaders or camera filters, like a Blurr effect! But this won't really affect the "graphics".
I don't think that's currently possible. The game would have to render the same objects on 2 different ways, but that's just not possible in a good-performance scenario. You could very simple use prefabs with a lower quality on one of the screens or images with a lower resolution in the UI.
Do you really need this for your game? If u do some changes in the quality settings or change your game core mechanics, maybe the performance becomes good enough to skip this.
Hello: I am trying to create an app which will display a moving sphere. App will vary speed and direction. I've tried Adobe Flash but cannot get it smooth. Smoothness is essential in this case. So I am trying C#.
Initially, I can see that this can be implemented by:
1) Creating a PictureBox of a sphere, and using a Timer, change its coordinates. or
2) Using the this.paint function to draw a filled circle, and somehow, with a timer, erasing and redrawing it.
Can someone recommend the best path to take? I'll have a main menu where the user will chose speed/direction/how many etc... and then simply show the "game window" with the moving spheres. Any guidance would be much appreciated.
This is to be displayed on a PC only.
Thanks
-Ed
I just answered a similar question here.
NOTE: Depending on your needs, it is possible to achieve smooth animations under winforms (under certain conditions) though you are responsible for everything. wpf provides an animation framework but wpf is perhaps a milestone harder.
It probably does not matter should you pursue winforms first or WPF. You arguably could learn the basics under winforms then move over to wpf. wpf may require you to learn quite a bit before you can do anything.
Summary
Essentially what this does is to create an offscreen bitmap that we will draw into first. It is the same size as the UserControl. The control's OnPaint calls DrawOffscreen passing in the Graphics that is attached to the offscreen bitmap. Here we loop around just rendering the tiles/sky that are visible and ignoring others so as to improve performance.
Once it's all done we zap the entire offscreen bitmap to the display in one operation. This serves to eliminate:
Flicker
Tearing effects (typically associated with lateral movement)
There is a Timer that is scheduled to update the positions of all the tiles based on the time since the last update. This allows for a more realistic movement and avoids speed-ups and slow-downs under load. Tiles are moved in the OnUpdate method.
If you note in the code for Timer1OnTick I call Invalidate(Bounds); after animating everything. This does not cause an immediate paint rather Windows will queue a paint operation to be done at a later time. Consecutive pending operations will be fused into one. This means that we can be animating positions more frequently than painting during heavy load. Animation mechanic is independent of paint. That's a good thing, you don't want to be waiting for paints to occur. xna does a similar thing
Please refer to my full SO answer complete with sample code
Here are a few hints to get you going:
First you will need to come to a decision about which platform to target: WPF or Winforms.
Then you should know what to move across what; a nice Bitmap or just a circle across an empty background or a Bitmap or a Form with controls on it.
In Winforms both your approaches will work, esp. if you set a circular region see here for an example of that. (The part in the fun comment!)
And yes, a Timer is the way to animate the sphere. Btw, a Panel or even a Label can display an Bitmap just as well as a PictureBox.
For smooth movements make sure to set the Form.Doublebuffered=true, if you move across a Form. If you move across any other control (except a PictureBox or a Label) you will need to subclass it to get access to the DoubleBuffered property!
It is often also a good idea to keep the Location of a moving item in a variable as a PointF and use floats for its speed because this way you can fine grain the speed and Location changes and also the Timer Intervals!
Im developing a game like "bubble-bobble". So far I have done physics and collision detection.
Now I want to make my Hero (Rectangle Sprite) animated. I would be glad if someone could explain simple scripting for simple animated characters or some nice links for animation.
The XNA Documentation includes an entire article on Animating a Sprite. The basic technique is to use an AnimatedTexture class, which is included within the Animated sprite sample code.
The high level idea is that you load a texture into memory using a graphics API. Since you're using C#, this is most likely done through XNA.
This texture you have loaded contains each frame of animation that is required, and may span across multiple textures. When you go and render your 'sprite' object, you pass the XNA API the texture you want to use, and a source rectangle coordinates that surround the specific frame of animation you want within that texture.
It's up to you to manage this process. I create tools that assemble these source rectangles and stores meta data about each specific animation each sprite has; like which rectangles, and the duration of each frame, etc.
I am writing a program to imitate Natural Physics. I want to know whether there is a better way to draw an object other than overriding the OnDraw method, and FillRectangle(x,y,1,1) for each pixel.
Is there a way to do a similar action using DirectX or OpenGL? Because to my knowledge the Graphics does not utilize the video card of ones computer (please correct me if I am wrong).
Saying this I would like some thoughts in relation to creating a 3D environment using mathematical calculations to work out the relative quadrant sizes so that objects appear to be farther away then in reality (as a monitor is only 2D), or closer.
Yes. Drawing pixel by pixel with FillRectangle will be very inefficient and slow things down a huge amount. As you say, you should use a graphics rendering system such as DirectX or OpenGL. The choice of which is up to you. If you do a simple search on the web you will find many tutorials on how to get started with 3d graphics.
OpenGL focuses on "Draw me this object in space", and it will take care of rendering it, taking advantage of your graphics card if possible. You do not worry about the pixels, you specify dimensions, camera angles, shaders etc.
You can draw pixels with OpenGL, but that is not the 'correct' way to draw 3d graphics with it.
EDIT in response to Vasa's questions:
I believe OpenGL does what's best based on your graphics card capabilities and drivers. In general OpenGL isn't going to be your best option for drawing direct pixels. BUT remember that
Pixels are different sizes on different machines. Are you expecting to just live with this? Or live with a big display on low-res screens and a tiny one on high-res screens? There may be multiplications involved. If you use literal pixels then once you start multiplying for different screens you are going to get artefacts and inaccuracies.
You want a direct mapping of X to pixels. OpenGL uses float values. They aren't integer 1 to 1 mappings, but they do use a direct proportion. If you choose a scale then OpenGL is not going to suddenly start distorting ratios.
The important thing is proportions not absolute pixels. Although I accept that it's possible for your case to be different.
See this for 2d drawing:
http://basic4gl.wikispaces.com/2D+Drawing+in+OpenGL
I'm writing a 2d tile-based engine. Currently, my drawing routine uses the C# Drawing library to redraw every visible tile every time the screen refreshes. I got scrolling and zooming to work, and everything looks the way I want it to. But the routine is slow. Now I'm trying to improve it. I've a couple of questions:
First, I think redrawing the tiles at every refresh is unnecessary (since they never change). Right now I'm trying to change the algorithm so that it writes the whole map to a single bitmap at initialization, and then cuts the correct portion of the bitmap when it's time to draw. Do you think this is the right way to go?
(I also considered leaving the image in the background and just scrolling over it. But then I decided that I don't want to draw stuff that's outside of the field-of-view. However, perhaps that is cheaper than cutting/pasting? A memory vs time issue?)
Second, as far as I understand the C# Drawing routines do not use the full power of the GPU. I think I should try to do the drawing in OpenGL (or DirectX, but I prefer the former, since it is multiplatform). Will that help? Do you know any tiling (or general pixel-drawing) tutorial for OpenGL? A book reference could also help.
I also don't do multi-threading at the moment (in fact I only have a vague idea of what that is). Should I try to multi-thread the drawer? Or would OpenGL make multi-threading for graphics redundant?
Thanks.
What application framework are you planning to use? Techniques for efficient drawing are very different between WinForms (Win32) and WPF.
You are correct that .NET drawing routines do not take full advantage of the GPU. Using DirectX or OpenGL, one immediate optimization would be to preload all of your image tiles (or at least, all of the tiles you need for the immediate view area plus a little more) into GPU memory using image lists or display lists. You would then draw the tiles on a surface by index - draw tile N at x,y. This is usually much faster than drawing on a GPU surface using bitmaps stored in main system memory, since the bitmap pixels have to be copied to the GPU for each tile drawn and that uses up a lot of time. Drawing by index also uses a lot less GPU memory whenever you can use the same image tile in multiple places in the output.
OpenGL vs DirectX is your choice, but IMO DirectX has been evolving at a faster rate providing more hardware accelerated functions than OpenGL. OpenGL drivers on Windows also have a reputation for being neglected by hardware vendors. Their primary focus is on their DirectX drivers.
Give some thought to whether you really need OpenGL or DirectX for your 2D tile application. Requiring OpenGL or DirectX will reduce the number of machines, particularly older machines, that can run your app. OpenGL and DirectX may be overkill. You can do a lot with plain old GDI if you're smart about it.
Stay away from multithreading until you have a really good reason to go there and you have some experience with threading. Multithreading offers the reward of some performance boosts for some computing situations, but also brings with it new headaches and new performance problems. Make sure the benefit is significant before you sign up for all these new headaches.
In general, moving pixels around on the screen is usually not a good match for multithreading. You've got only one display device (in most cases) so hitting it with multiple threads trying to change pixels at the same time doesn't work well. To borrow an expression from project management: If a woman can create a baby in 9 months, can you use 9 women to create 1 baby in 1 month? ;>
Work on identifying parts of your system that do not need to access the same resources or devices. Those are better candidates for running in parallel threads than blitting tiles to the screen.
The best optimization is to discover work that does not need to be done - reducing the number of times tiles are redrawn for example, or changing to an indexed model so the tiles can be drawn from GPU memory instead of system memory.
If you want to use OpenGL your best bet for 2d would be SDL.
Using OpenGL with C# will never be that portable simply due to the fact it would use .NET wrappers.
XNA is a great tool for writing games in C#, it should provide a lot more speed and flexibility then SDL does (especially the .net port) plus more features (however more bulk).
For your cutting or scrolling question, the best route would be scrolling.
Memory is much less of an issue than CPU when you're drawing using GDI+ (what System.Drawing uses). You could always split the map up into sections and scroll those then load when necessary if it's that big.
I'm not familiar with OpenGL, but I've written a tile based engine in ManagedDX (later ported to XNA). ManagedDX is depricated, but there's the SlimDX project which is still under active development.
With DX, you can load each individual tile into a Texture. (Using Texture.FromFile() or Texture.FromStream() for example), and have a single Sprite instance draw them. This performs pretty well. I group the textures in a simple class with a Point or Vector2 for their locations, set them only when the location changes rather than every time the draw method is called. I cache tiles in memory only for the immediate screen and one or two tiles beyond, there's no need for more than that as the file IO is quick enough to fetch new tiles as it's scrolled.
struct Tile
{
public Point Location;
public Texture Texture;
}
Device device;
Sprite sprite;
List<Tile> tiles = new List<Tile>();
.ctor() {
this.device = new Device(...)
this.sprite = new Sprite(this.device);
}
void Draw() {
this.device.Clear(ClearFlags.Target, Color.CornflowerBlue, 1.0f, 0);
this.device.BeginScene();
this.sprite.Begin(SpriteFlags.AlphaBlend);
foreach (Tile tile in this.tiles) {
this.sprite.Draw2D(tile.Texture,
new Point(0, 0), 0.0f, tile.Location, Color.White);
}
this.sprite.End();
this.device.EndScene();
this.device.Present();
}