I have an unsigned int array which contains the image data. I wonder if it seem unusual to use an Fibonacci heap Data structure to handle what collection of pixels were written to the array. Also, I thought about using the heap to map out the collection of pixel to be overwrite with the background data that it had previously written over.
Any suggestions ?
Last edited by Darkinyuasha1; 05-01-2010 at 03:39 PM.
My one word answer is yes. Unless you have to find a particular pixel quickly.I wonder if it seem unusual to use an Fibonacci heap Data structure to handle what pixels what collection of pixels were written to the array.
But more often than not you'll want to perform operations on all the pixels, so an array works just as well.
You what?Also, I thought about using the heap to map out the collection of pixel to be overwrite with the background data that it had previously written over.
Consider this post signed
Well I wanted the heap to use the array.. so that it could track the individual elements that were changed.. and would need to be overwritten later on... lol without going through the array element by element...
@Darkinyuasha1: I think if you try and read this thread pretending to be someone who is not you, you'll notice you never bothered to really explain what you are doing, and too much is left to inference. Why/how are elements in the array changing over time? I could guess, but I'm not going to bother.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
I initially build a class to rendering data from an array of pixels. There are three layered arrays, which are the same as the blank buffer. Each layer will be specific for certain drawings... like layer 0 for the back ground, layer 1 sprites, layer 2 particle effects. I made a function to draw on one of the specific layers. When you update the class, the data on the layers are drawn onto the buffer, then the buffer is copy to direct video memory. I made a loop to run through the arrays in parallel. I thought if i could use a fast data structure to get the specific written pixel to write to the buffer would of been better .Originally Posted by MK27
data structures that provide O(log(n)) access are only faster than data structures that provide O(n) when n is not too small. If n is less than about 8, then it will most likely only be slower.
Well for N I'm worry with pixel array data that is most likely going to be over 250 by 250 . I know for Binomial heap is exactly like binary heap for Big O insertion. The merging property, of combining two binomial trees into one heap. Thus, I could write all the elements from a single heap correct?
I don't think anyone, myself included, understands what you are thinking of.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
Alright, so what data structure would work for rendering a written set of pixels on an array?
Keep it simple. Maintain a bounding box of all the pixels in each layer which have been drawn on. Tracking it to the single pixel is going to be far too slow. Just the mere existence of such a data structure means that the raster and the data structure will compete with each other to be in cache.
Accessing pixels sequentially is BLAZINGLY fast.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Thanks, I did go over board with the idea lol. I'll incorporate the bounding box into my render. I just thought it would be slow if the render constantly scroll through an array. In example, An array of 500 x 500 elements.
It's definitely worthwhile to limit your access to pixels as much as possible, but a complicated technique that keeps a large data structure in memory will probably have the opposite effect that you intend. The processor is really quite fast, unless you screw up the caches, which is likely to happen as your code gets more and more complicated.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
