DrawPoint or DrawRect with a size of 1,1?
Monkey Forums/Monkey Programming/DrawPoint or DrawRect with a size of 1,1?
| ||
| I've created a box that is essentially an 50 x 50 diddy arrayList of pixel coordinates. The reason I did this was because I want to be able to check collision with each pixel of this box and destroy each pixel after collision and thus not draw those particular pixels in the box anymore. I realize I could do this with an Image, but I'm trying to work without Images at the moment for other "non coding" reasons. My question is; is it better to use DrawPoint() at each coordinate in the arrayList, or use DrawRect() at each coordinate, with a size of one? I've currently set it up to use DrawRect(), but I did this mostly because of the Champagne example program that seems to have commented out the 'DrawPoint() and chose to DrawRect() instead. I assumed this was because it would render faster, because there was some issue with DrawPoint(). Is that true or is there something I'm missing here? |
| ||
| Performance issues will vary depending on target and your overall rendering strategy. Some targets use the native rectangle drawing to do point drawing anyway. OGL targets switch to GL_POINT rendering, which may or may not be faster in actually drawing but also has implications due to changing the rendering state. Short answer, do some timings yourself. |
| ||
| Thanks. I tried both and it seems to have no difference in for HTML5 in Chrome on either Mac or Windows. I'll try some of the other browsers too, but I won't get a chance to test the other platforms because I'm not translating and compiling for those in this product, for the future in sight at least. |
| ||
| I know you mentioned not using images, but I think that's the best way to handle drawing on per pixel basis. Your back buffer (image) is an array of integers and all sorts of techniques exist for manipulating buffers like that even good enough for real time manipulation. Read/Write Pixels are awesome for what they do. |
| ||
| I completely agree with you Dima, and eventually this will morph into that for a 2.0 version. However, external requirements preclude the use of ANY images, at this point. It must be all procedurally generated. The drop in performance seems to be acceptable at this point, as it still runs at 35 to 40 fps in the browser because the game is relatively simple. Still, given the simplicity, it should be running at 60, but unfortunately doing this pixel array setup is slowing it down. |
| ||
| CreateImage(w, h) is technically procedural, then you can simply WritePixels(intArray[w*h]) or something like that and DrawImage(). In this case Image is just an intermediate buffer for getting your integer array of pixels onto the screen under all targets. edit: with access to hardware accelerated graphics one could build a 2d mesh (grid) in a vertex buffer, then set vertex colors to the pixel colors and draw whole mesh as one. Cool thing here is that mesh can be scaled and hardware will take care of blending colors between the vertices, making result filtered and not pixelated. |
| ||
| Try using some sort of binning or recursive data structure for this, you will find it gigantically faster. If box is undamaged, draw whole box. Else Divide into quadrants Treat each quadrant as a whole box |
| ||
| Thanks for the input guys, it is certainly helpful short and long term. I was thinking of doing that zoqfotpik, it's a good idea. I'm already doing similar with the collision object(s) because the direction from which they approach the 50 x 50 boxes is very predictable, so I'm only looking for collisions on each box, and each part of each box, when it's necessary to do so. I'll try out some of the other methods too as I optimize it, but at this point I'm just trying to get all the basic features up and running, only with procedurally generated objects, with a limited set of data structures. I'll optimize and clean up the code when I have that part done, and as the project moves forward I'll create different and/or more efficient ways of doing each thing. |
   |