ReadPixel speed?
Blitz3D Forums/Blitz3D Programming/ReadPixel speed?
| ||
| Hey everyone, I was just wondering how fast ReadPixel actually is? I mean, would say 50 entities each reading the pixel located at the x/y position in front of them at the same time be possible without being to slow? |
| ||
| Well, how long does it take for RenderWorld to perform what it needs to do, and then how much longer does it take when ReadPixel is added to the operation? Multiply that by 50 and you have an approximation (which could be severely off). In any case, I'd say the answer is no. Chances are it would be horrifically slow- even if you were using ReadPixelFast- if I understand the proposed situation correctly. |
| ||
| cool, thanks for your reply :-) Umm could you make it so that one entity reads the pixels of the bitmap of a certain distance around it, and places things depending on the colour of the pixel read, and then updates and removes/places them as the entity moves around and gets a certain distance away, like say you had a bitmap spread over a terrain and wanted grass placed on the green and rocks on the brown, and them to dissapear/appear as you move so you dont have to create 10,000,000,000 objects? |
| ||
| But he seems to be talking about reading 50 pixels, which takes virtually no time. |
| ||
| ab: I'd suggest creating an array for the positions of those spots then a smaller array that contains the entities that would be visible. Just reposition/fade them based on the information you have at hand at that point (probably fade them based upon 2D distance though). Keep in mind, that could be highly inefficient, but this is the first thing that comes to mind for me. Floyd: My take on the proposed situation was that he wanted to get the colors of whatever was in front of an entity in 3d space, which would probably require re-rendering the scene from the entity's point of view, which in turn would probably be slow if you did it 50 times. |
| ||
| I'd recommend using ReadPixelFast. |
| ||
| I'd recommend telling us what you're trying to achieve rather than giving us the solution. There might be a much simpler and more elegant way that you haven't seen yet. |
| ||
| What Im trying to do is make a massive landscape that incorporates an invisible bitmap, and the camera reads all the pixels in that bitmap a certain x/y distance away from itself, and depending on the colour of the pixel read, places a certain object there. When the camera moves a certain distance away from the object, the object itself is destroyed but its data (perhaps r/g/b levels, ie. the intensity of the red (0-255) decides what object to put there, the blue decides the objects size for example etc.) remains. This way, theoretically, you could have tremendous numbers of objects that can be constantly updated through WritePixelFast easily (for example, the data (x/y values, object type and size as mentioned before)) for 1048576 objects within a simple 1024 x 1024 bitmap, all placed/destroyed through Read/WritePixelFast. |
| ||
| Would you not be better off using a bank? Then you can hold as much or little information as you want. Peeks and Pokes are much faster than readpixelfasts as you don't have to arse around with locking buffers... and of course you could use an array. Of course if we're talking about saving memory it's a hugely ineffieciant way of going about it as you're storing information on objects that don't exist. The other problem you've got is that objects will have to fall on the exact grid that depending on the size of your terrain will look clunky as hell. If you're planning on having 1,000,000 objects then they way you're going about it is probably alright however, if you're only talking a few thousand objects quite frankly I think you're better off storing your objects in a type. This way the x,y,z is accurate and you're only holding information on the objects you have rather than what you don't have to. |
| ||
| Cool, thanks for your answer. Im not to keen on arrays etc., and I thought this might be a pretty unique and relatively very simple way of creating a lot of possibilities, especially if you are looking at really, really big numbers of entities (ie. 4 million or so by using only 4 1024 x 1024 bitmaps)...I will start writing something, hopefully this could be quite useful, as you could even be able to create a map of a whole country for example, one set of bitmaps is the visible map and the other stores the data via r/g/b levels. Does locking/unlocking buffers take up much power? |
| ||
| I would suggest that if you're not using the images as images as such use a bank. Use an image to create the initial load into the bank but steer clear of using an image for just reading and writing data. |
   |