Best way to store array of pixel
Author
Hi,
Im currently trying to create a 2D array to hold a pixel. the index will represent the position of the pixel so it looks like this:
ColorRGB color[width][height]
the colorRGB object only a class that hold floats r, g, b and a few set get method.
the problem is while using this method, i can not use a 600*600 array or more. it seem like a physical memory boundary. is there any better/efficient way to hold the pixel?
thank you in advance
That's how I do it, so I don't know why you would be getting an error. It works fine for me. You could always try to put it into a single dimensional array with the size width*height, but I really don't think that there should be a problem with the way you are doing it now because c actually makes multidimensional arrays single dimensional. Can you post the actual error?
Also, how are you declaring the array? Have you tried malloc?
Also, how are you declaring the array? Have you tried malloc?
ColorRGB color[600*600]may run you out of stack space if you are just directly declaring it as such.
ColorRGB *color = new ColorRGB[600*600];will allocate on the heap, and should just work, but you have to call
delete[] color;at some point to free the memory.
std::vector<ColorRGB> data;data.resize(600*600)will also work, and may be easier to work with, as it handles the memory management for you.
Note, all the c++ code above treats a width * height image as a 1D array. There a lots of benefits to this over the 2D array approach. Especially when you start allocating on the heap with new. Index into a 1D array is either data[x*height+y] or data[x+y*width] depending on if you want vertical columns or horizontal rows to be contiguous, the second being the most common.
Yes, it is most likely that you ran out of stack memory.
If you compile with standard settings on windows(I asume you're working on windows) you have about 1MB of stack memory for each thread.
You could change the compiler settings but that would only move the problem.
As KulSeran mentioned you should allocate the memory on the heap.
If you compile with standard settings on windows(I asume you're working on windows) you have about 1MB of stack memory for each thread.
You could change the compiler settings but that would only move the problem.
As KulSeran mentioned you should allocate the memory on the heap.
Author
This is the error that showed up during the runtime:
Program received signal: “EXC_BAD_ACCESS”.
Unable to restore previously selected frame:
i declared my 2D array with this call:
ColorRGB color[800][800];
for information, althought i dont think this is the real source, i also pass this 2D array to a method:
void Mesh::scanline(ColorRGB line[][800], int width, int height)
which is not a real big problem (i think) since array would be passed as a pointer right?
any idea?
Thank you in advance
Program received signal: “EXC_BAD_ACCESS”.
Unable to restore previously selected frame:
i declared my 2D array with this call:
ColorRGB color[800][800];
for information, althought i dont think this is the real source, i also pass this 2D array to a method:
void Mesh::scanline(ColorRGB line[][800], int width, int height)
which is not a real big problem (i think) since array would be passed as a pointer right?
any idea?
Thank you in advance
The problem is that you allocate to much on the stack. It doesn't matter how you pass the array to other functions: You allocate it on the stack wich doesn't like objects of that size.
Better allocate it on the heap manually or even better, use an stl container like std::vector. It'll keep away the pain of deleting the array and performs (if used correct) almost as good as an old c-style array.
Better allocate it on the heap manually or even better, use an stl container like std::vector. It'll keep away the pain of deleting the array and performs (if used correct) almost as good as an old c-style array.
Author
yes but for a performance-critical application, would it give a 'significant' effect to the performance?
Since allocating the array on the stack doesn't work for arbitrary sizes (although it will work on the heap) you're really out of alternatives.
If you really wanna fiddle around with old c-style arrays you can happily do so :).
About the performance critical part, I have never done benchmarks, because I knew I don't want to create something like a std::vector myself. However the STL has a reputation to be very fast.
But be careful: For the MSVC STL, this only goes for the fully optimized release version. Debug can be painfully slow (my old game runs with 60+ fps in release mode, whereas it runs with 2 fps in debug mode, due to my heavy use of stl containers).
If you really wanna fiddle around with old c-style arrays you can happily do so :).
About the performance critical part, I have never done benchmarks, because I knew I don't want to create something like a std::vector myself. However the STL has a reputation to be very fast.
But be careful: For the MSVC STL, this only goes for the fully optimized release version. Debug can be painfully slow (my old game runs with 60+ fps in release mode, whereas it runs with 2 fps in debug mode, due to my heavy use of stl containers).
You declared ColorRGB colors[800][800] and then try to read ColorRGB line[][800] which is out of bounds. Note that [800] means indices 0-799.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
