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
Related
I am drawing a scatter plot with the help of GDI.
But, when there are many lines, it takes about two seconds to draw.
I looked into using SlimDX and SharpDX and utilized their 2D.
It only decreased the time by half. Is there any better tools that I can use to speed up the drawing? I am simply utilizing g.DrawLine. I also heard that there is a tool that lets me draw a scatter on memory and put it on a screen. If you have ideas, it will be greatly appreciated. Thank you.
[Are] there any better tools that I can use to speed up the drawing?
First, use g.DrawLines instead of g.DrawLine. This means there is one transition from user code to graphics code instead of one per line.
Second, select a bitmap into the graphics object, draw into that then write the bitmap to the display. See how to draw a line on a image? for an example of drawing a line on a bitmap. This means the lines are drawn once then refreshing the display is a single fast Bit Blit.
Using DirectX ports (e.g. SharpDX, and SlimDX) is possible but probably overkill unless you are dealing with extremely complex scatter plots. These are (generally) more geared toward 3D vector or 2D Bit Blit based graphics.
How can I smooth a Graphics object in C# ? To be more precise, I need to run a smoothing at a very precise moment of my Graphics object generation, on the whole object. The image is coloured.
I am flexible in terms of input classes (Graphics, etc..). I just suggested Graphics at it is a central class for image manipulations in C#.
Graphics.SmoothingMode is out of context for what I need to do and I imagine WU's algorithm only applies to drawing lines in greyscale.
Have a look at the image processing features of AForge.Net. It is an open source framework that includes a lot of useful image processing capabilities. You will find many smoothing filters among them.
I think you used the wrong words to describe your problem. Anti aliasing refers to (as Hand mentioned) the point in time when individual objects are drawn for the first time. For instance, when drawing a diagonal line on an empty surface.
You already have an image, and you want that image to be smoothed. I suggest you detect edges in the image using a standard algorithm, then smooth those edges. I am not familiar with the exact process to do this myself, sadly.
I'm looking to make a relatively simple game using solely graphics primitives (Arcs, Lines, Polygons, etc.).
I started doing this in C# by drawing to a Panel, but right now I'm hung up on how all the scaling works in terms of keeping the proportions the same when changing resolutions. Does anyone have any advice and / or tips on how to do something like this?
There are two options:
1 - Scale everything so that it is sized at a certain percentage of the screen/window. For example, if you want your object to be 1/4 of the screen, then it's width is ScreenWidth/4 and height is ScreenHeight/4. The problem with this technique is that a screen's aspect ratio may make things short and fat or tall and wide. Usually this is addressed by determining one dimension and then using the screen's aspect ratio to determine the other dimension. Ie, Width=Height*AspectRatio.
2 - Make everything the same physical dimension. For example, you may want an object to appear exactly 1" by 1". You can use the screen's resolution (dots per inch) to scale your drawings accordingly. The problem with this is that while it may work well for 'average' sized screens, images may be too small on large screens or too large on small screens.
Most games use technique #1 (with compensation made for the aspect ratio). AR was not always a big deal, but now with widescreen monitors being so popular, it's almost required.
Also, like Richard said, WinForms is not great for games (except minesweeper!), but probably okay for teaching yourself.
Not really a helpful answer but, don't use WinForms!!
If you want a good gaming platform, use DirectX, or XNA Game Studio.
You can do this using GDI+, and transforms. For details on using Matrix to do transforms, see this article on CodeProject.
That being said, this is much, much simpler using WPF's drawing options. In addition to being a retained mode model, which is much simpler when doing simple graphics (ie: move an object instead of constantly redrawing), it has some other nice benefits. The main benefit is that everything in WPF is done using floating point values, and is completely scalable, with no extra real effort. For details on this, see Shapes and Basic Drawing with WPF, which includes both drawing and transforming of shapes.
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();
}
image http://prod.triplesign.com/map.jpg
How can I produce a similar output in C# window forms in the easiest way?
Is there a good library for this purpose?
I just needs to be pointed in the direction of which graphic library is best for this.
You should just roll your own in a 3d graphics library. You could use directx. If using WPF it is built-in, you can lookup viewport3d. http://msdn.microsoft.com/en-us/magazine/cc163449.aspx
In graphics programming what you are building is a very simple version of a heightmap. I think building your own would give your greater flexibility in the long run.
So a best library doesn't exist. There are plenty of them and some are just for different purposes. Here a small list of possibilities:
Tao: Make anything yourself with OpenGL
OpenTK: The successor of the Tao framework
Dundas: One of the best but quite expensive (lacks in real time performance)
Nevron: Quite good, but much cheaper (also has problems with real time data)
National Instruments: Expensive, not the best looking ones, but damn good in real time data.
... Probably someone else made some other experiences.
Checkout Microsoft Chart Controls library.
Here's how I'd implement this using OpenGL.
First up, you will need a wrapper to import the OpenGL API into C#. A bit of Googling led me to this:
CsGL - OpenGL .NET
There a few example programs available to demonstrate how the OpenGL interface works. Play around with them to get an idea of how the system works.
To implement the 3D map:
Create an array of vectors (that's not the std::vector/List type but x,y,z triplets) where x and y are along the horizontal plane and z is the up amount.
Set the Z compare to less-than-or-equal (so the overlaid line segments are visible).
Create a list of quads where the vertices of the quads are taken from the array in (1)
Calculate the colour of the quad. Use a dot-product of the quad's normal and a light source direction to get a value to shade value, i.e. normal.light of 1 is black and -1 is white.
Create a list of line segments, again from the array in (1).
Calculate the screen position of the various projected axes points.
Set up your camera and world->view transform (use the example programs to get an idea of how to do this).
Render the quads and lines, OpenGL will do the transformation from world co-ordinates (the list in (1)) to screen space. Draw the labels, you might not want to do this using OpenGL as the labels shouldn't scale with distance from camera, otherwise they could get too small to read.
Since the above is quite a lot of stuff, there isn't really the space (and time on my part) to post working code (but someone else might add something if you're lucky). You could break the task down and ask questions on the parts you don't quite understand.
Have you tried this... gigasoft data visualization tools (Its not free)
And you can checkout the online wireframe demo here