Arthropleura

Hi guys.

I'm working in a little experiment with colours. I created an array of colours, with 800x600 dimensions.
I was able to paint the colors using spriteBatch and texture2D of 1 pixel, but the yield is terrible.

There is noway to draw a Point or a Vector2D not using SpriteBatch or textures Primitive ways to draw in screen
I see something in the example project inside XNA, RetroAsteroids, but It draw with VertexPositionColor, and it isn't what i'm searching

thanks a lot

(sorry for my english, i know)

PD: I hope the solution won't be a Matrix of Proyection... =S



Re: XNA Game Studio Express Trying to draw a pixel

killfr0g

Check out the How to: Draw Points, Lines, and Other 3D Primitives example in XNA Help, it's under Programming Guide > 3D Graphics. You have to use something like VertexPositionColor which is perfect if you want to draw a coloured pixel on screen.




Re: XNA Game Studio Express Trying to draw a pixel

Arthropleura

I'm trying to do that out of 3D. In 2D primitives, but thanks



Re: XNA Game Studio Express Trying to draw a pixel

gvigelet

I may be wrong but the only way to draw a single point is to use the pointlist, there is an example in the documentation.

I did previously create a scrolling starfield in the beta 2 of XNA Game Studio with a single pixel sprite, though I had the same issue with performance.

i am sure i can re-write the scrolling starfield using pointlists to get much better performance if anyone is interested.

Thanks






Re: XNA Game Studio Express Trying to draw a pixel

manders

How about creating a screen-sized texture, creating a 800x600 array of Colors, set whatever pixels you want in the array, using SetData to send the data to the texture, then use the Sprite code to draw the texture

You could turn on alpha blending and initialize the array to transparency, if you have other stuff already drawn that you don't want to obliterate with your texture...

That's probably the best approach if you are setting a whole lot of pixels. If you're only touching a few, then 1x1 pixel sprites should be okay perf-wise.

-Mike





Re: XNA Game Studio Express Trying to draw a pixel

Arthropleura

First method you say is sending information to a texture it's possible changue el color of one pixel I'll try it. The problem is that it'snt resizable.

The problem of method of 1x1 px texture is the number of texture2D that the program can process. 800x600 is 480.000 textures processed per second. Changing inner color it's so much overload for processor.

I'll see the best solution, thank's all for the interest. But please if someone have another point of view, put it here.





Re: XNA Game Studio Express Trying to draw a pixel

Jim Perry

Arthropleura wrote:
I'm trying to do that out of 3D. In 2D primitives, but thanks

Why

There's isn't really a such thing as 2D on today's video cards. 2D is just 3D with a 0 z axis value.






Re: XNA Game Studio Express Trying to draw a pixel

Shawn Hargreaves - MSFT

At a higher level, what exactly are you trying to achieve

Modern graphics cards are very bad at drawing single pixels. They are optimised for rendering larger objects in a single draw call, using programmable shaders to control the details of the output.

Trying to build up a complex scene through many individual pixels will be incredibly slow no matter how you do it, because that's just not how the hardware is designed, but if you describe more about your final goal, someone might be able to suggest an alternative way of doing this that would fit better onto how shader hardware works.





Re: XNA Game Studio Express Trying to draw a pixel

parlance

Shawn Hargreaves - MSFT wrote:
At a higher level, what exactly are you trying to achieve

Modern graphics cards are very bad at drawing single pixels. They are optimised for rendering larger objects in a single draw call, using programmable shaders to control the details of the output.

Trying to build up a complex scene through many individual pixels will be incredibly slow no matter how you do it, because that's just not how the hardware is designed, but if you describe more about your final goal, someone might be able to suggest an alternative way of doing this that would fit better onto how shader hardware works.

Shawn is right. There are a number of reasons that drawing pixels individually with SpriteBatch will be slow. Modern graphics cards gain most of their speed through the parellelization of the task at hand, ie. breaking a job into smaller identical parts, and accomplish those parts simultaneously. In the graphical analogy, this means when transforming vertices, the graphics card (depending on the card and number of pipelines) will try to transform as many of those vertices as it can at the same time. When a complete triangle has been transformed, the graphics card will use as many pixel pipelines as it can to simultaneously render many pixels of the same triangle as the same time. Additionally, there is a lot of overhead (both for the gpu and cpu) associated with beginning and ending a primitive drawing batch (in this case your primitives are triangles, and you are rendering 2 of them in a single batch). So, the reasons why this is slow is 1) You are transforming only 4 vertices in every batch, this only allows 4 vertex units to operate, regardless of how many are present. Additionally, since you are drawing points, all 4 vertices end up having the same output screenspace position and the UV coordinates are irrelevant for a texture with a solid color. 2) You are drawing 1 pixel in every batch, allowing only 1 pixel unit to operate, regardless of how many are present. Additionally you are needlessly reading the color of this pixel from a texture, wasting efficiency on un-needed interpolators for UV coordinates, and un-needed memory bandwidth to fetch and filter the texels from video memory. 3) You are dealing with a very very large number of tiny batch sizes, if 1 and 2 weren't enough, this is basically like throwing sticky tar down on the pavement.

So, how do you fix this 1) Increase batch sizes. This will use less work for the host CPU and GPU to accomplish the exactly same task. If it IS important to you to be able to explicitly and arbitrarily set the position of every pixel you are rendering, try using a very large vertex buffer and rendering using the POINT_LIST primtive type instead. This will transform only 1 vertex per pixel. If at all possible, setting the positions using the vertex shader instead of using the CPU would also go a long ways towards increasing performance. 2) Disable textures and add a diffuse color component to your vertex definition. Because each pixel is only 1 color anyway, it's unecessary to read that data from an array of colors, with filtering nonetheless. Doing this you could trim your pixel shader down to only 2 (ALU) instructions.

That said, if you're trying to fill al the pixels in an 800x600 screen every frame, you probably still won't find the perform you're looking for. There are other ways to render an entire screen that take better advantage of parellelization. Right now you are trying to ask yourself the following question: If I had a pixel of a given color, where should it be A better question to ask is this: If I had a pixel of a given position (0-800, 0-600), what color should it be If you think it's possible to answer the last question then you're better off writing a single shader to fill the screen as a 2 dimensional function with parameters U and V (representing the pixel's location from 0-800 and 0-600). This is definately the most efficiently way to solve the problem although it won't always be possible depending on what you are trying to do (what Shawn was getting at, I believe). If you decide that it is possible and you want more information, please let me know.

The other option, storing a system local framebuffer and using the CPU to do the drawing and uploading the final texture doesn't leave you in a lot better shape, although you'd probably still get better effiency than with SpriteBatches. The problem with this system is that ultimately, modern CPUs aren't designed to do work related to graphics or multimedia processing, at least, not to the extent that GPUs are. CPUs are far better at handling a task that requires that a series of specified steps be executed in order. Depending on the complexity of the operation, rendering a single pixel is something that is going to need to be handled 28.8 million times per second. Besides the immense CPU-load, you're also looking transferring ~109.86 MB worth of texture data to the GPU every second. This isn't a HUGE deal, because at the very least you'd be trasferring it in very large batches, but you have to ask yourself if the memory bandwidth couldn't have been better used for something else.





Re: XNA Game Studio Express Trying to draw a pixel

Jonas Beckeman

If you're drawing retro vector graphics, like Vectrex or the original Asteroids (I got that impression from your first post although your main focus is pixels), a good way is to use a small texture and draw rotated/streched quad sprites. If your texture looks like this:

oxxo   (o = transparent, x = color)
oxxo

you get nice anti-aliased lines (thanks to texture interpolation) that are still well-defined at the ends.

If you're only using this method, you can use a *lot* of lines, since you won't have any state changes - everything can be rendered with one single draw call. Use dimmed colors and an additive blend mode to get a more realistic effect.





Re: XNA Game Studio Express Trying to draw a pixel

jcoatney

I can actually think of some reasons for wanting finer control. For instance I am working on a map building program for a game project. Currently I must render each tile of the map that is on screen individually, creating a lot of reduntant draws and taking up processes because I can't draw to a reusable texture once then blit that one texture to the screen, changing it as necessary. If I could blit textures to other textures, or draw to them in some way I could dynamically create 2D information which can be recycled efficiently for drawing to the screen.

Also with a more dynamic action base you could take a bitmap and save a rotated version of it when loading instead of having to rotate it repeatidly at runtime. While this only matters to 2D programmers most likely, it is important to remember a lot of people will use 2D as their starting base for learning to program games and the 2D interface for XNA is either currently sort of clunky or simply not known well enough to implement a lot of useful graphics manipulations.

Of course I'm sort of spoiled on this because I started out in 2D programming with the Allegro library, which has a ton of different functions in it for their graphics objects and moving to this system was a step down in the options department by a lot. On the other hand it doesn't crash half as much, so I figure it's still better in that respect.






Re: XNA Game Studio Express Trying to draw a pixel

parlance

 jcoatney wrote:

I can actually think of some reasons for wanting finer control. For instance I am working on a map building program for a game project. Currently I must render each tile of the map that is on screen individually, creating a lot of reduntant draws and taking up processes because I can't draw to a reusable texture once then blit that one texture to the screen, changing it as necessary. If I could blit textures to other textures, or draw to them in some way I could dynamically create 2D information which can be recycled efficiently for drawing to the screen.

Also with a more dynamic action base you could take a bitmap and save a rotated version of it when loading instead of having to rotate it repeatidly at runtime. While this only matters to 2D programmers most likely, it is important to remember a lot of people will use 2D as their starting base for learning to program games and the 2D interface for XNA is either currently sort of clunky or simply not known well enough to implement a lot of useful graphics manipulations.

Of course I'm sort of spoiled on this because I started out in 2D programming with the Allegro library, which has a ton of different functions in it for their graphics objects and moving to this system was a step down in the options department by a lot. On the other hand it doesn't crash half as much, so I figure it's still better in that respect.

I'm not sure you understand how 2D graphics operate in XNA, or at all, with modern graphics cards. The age of actually 'blitting' surfaces is over, thus the deprecation of DirectDraw many years ago. 2D graphics in DirectX9 and beyond (including XNA) work by using the graphics processor to render (usually) textured polygons with masking being accomplished through certain render states, such as the alpha testing functions. There is absolutely no penalty for 'repeatedly rotating' a sprite at run-time, because the exactly same process is executed by the GPU which is drawing it regardless of it's orientation. You really really shouldn't be concerned about the overhead of rendering a 2D tile map individually tile by tile. Assuming you're smart enough to draw only tiles that overlap the screen, you're talking about maybe 400 textured quads here. I can't even imagine that the earliest graphics cards I can think of that operate correctly with DirectX9 would have any problem doing this 5 times over at a full frame rate.

Case in point: http://members.shaw.ca/cfriesen5/PileOBabies.rar

Thousands of rotated and masked sprites in real-time at full frames.





Re: XNA Game Studio Express Trying to draw a pixel

A1Programmer

parlance

Wow, that is a very cool demo. What method of collision detection are you using for that I noticed from the source code you were using some type of binary tree, is this a bsp tree

thanks,
Derrick





Re: XNA Game Studio Express Trying to draw a pixel

parlance

 A1Programmer wrote:
parlance

Wow, that is a very cool demo.  What method of collision detection are you using for that   I noticed from the source code you were using some type of binary tree, is this a bsp tree

thanks,
  Derrick

Actually, it's a Quad Tree, which is the analog of a 3D Octree in 2D. The collision detection scheme works between moving spheres which end up being thick 2D lines with rounded ends, if you can picture it. The general algorithm first resolves each object to one or more leaf nodes depending on whether or not it's position, path, or destination intersects them. The collision detection algorithm then uses this information to avoid testing objects for collisions against anything that won't collide with them. The result is the ability to detection collision between thousands of objects (with each other even!) quickly and efficiently.

It's important to note that the same structure could've just as easily been implemented with a binary tree instead of a quad tree, you would just end up with double the intermediate nodes although the implementation would be almost identically efficient. I just used a quad tree for the sake of clarity.





Re: XNA Game Studio Express Trying to draw a pixel

jcoatney

<quote>I'm not sure you understand how 2D graphics operate in XNA, or at all, with modern graphics cards. The age of actually 'blitting' surfaces is over, thus the deprecation of DirectDraw many years ago. 2D graphics in DirectX9 and beyond (including XNA) work by using the graphics processor to render (usually) textured polygons with masking being accomplished through certain render states, such as the alpha testing functions. There is absolutely no penalty for 'repeatedly rotating' a sprite at run-time, because the exactly same process is executed by the GPU which is drawing it regardless of it's orientation. You really really shouldn't be concerned about the overhead of rendering a 2D tile map individually tile by tile. Assuming you're smart enough to draw only tiles that overlap the screen, you're talking about maybe 400 textured quads here. I can't even imagine that the earliest graphics cards I can think of that operate correctly with DirectX9 would have any problem doing this 5 times over at a full frame rate.

Case in point: http://members.shaw.ca/cfriesen5/PileOBabies.rar

Thousands of rotated and masked sprites in real-time at full frames.</quote>


Perhaps this is true, my knowledge of internal graphics functions is limited. However just because something doesn't slow down your overall program doesn't mean you shouldn't avoid adding more processes than necessary. Anyways, what if you are creating a program which is supposed to allow for art generation The inability to draw to major graphics objects prevents you from doing so.

Now I admit that this may not be very important for XNA, because the primary idea is to develope games, but it was just a simple example. Anyhow, what if you want to dynamically generate a screen shot of an entire map-scape Unless I missed something you are only able to save screen shots and the individual texture images (which doesn't even make sense unless you can edit them) neither of which accomplishes this task. This task is potentially important for showcasing a product if it is primarily 2D.

Perhaps there is some system of working in 3D which allows you to just create a plane object and dump a heap of textures on it to use it in a fashion that allows for such things, but I wouldn't know because I can't personally use the 3D functionality of XNA Studio Express (I could in Beta, which sort of annoys me a bit) and sort of ignored it as a result.

Besides it's not as though 2D functionalities are really dead, certain people just stopped focusing on them so much. No matter how you slice it, modern screens are still just 2D images, unless of course I missed a really big leap in technology. Anyhow, a lot of people still enjoy 2D games and programs, the fact that the 2D functionality is falling below the orignal standards is just sloppy as long as it is still used.

That's my opinion anyway. Maybe I'm just too old fashioned or something :)