Can't seem to see the forest for the trees

Hello,

I think you're making it too complicated.
Why don't you use a simple array with size scrX*scrY*3 ?

unsigned char * rbuf = (unsigned char *)malloc(scrX*scrY*3*sizeof(unsigned char));

or use C++

std::vector rbuf;


Uncle

Quote:

Original post by UncleRemus I think you're making it too complicated. Why don't you use a simple array with size scrX*scrY*3 ?

Seconded!

Quote:

or use C++

Thirded!

Also, the debugger is your friend, here. Step through, and see what fails. The values of everything leading up to this point will be invaluable.

stepped through with the debugger quite slowly. yep it's been a good friend lol
just haven't cought anything through it so far with this one (sigh).
uncle remus this vector thing is new to me. is it part of the standard c++ ?
i'll wander around this sight toof ore more on it. thx guys.

ps: i've gone three and for dimensional arrays like this before.
i'm pretty sure it was on the same compiler. must be getting old heh

Doing it that way is making things difficult. What if you want to access the table as a whole to say write to a file or copy it or something.

Much easier to do as above. scrX*SrcY*3

Quote:

Original post by Indogo 2000 this vector thing is new to me. is it part of the standard c++ ?

Most useful tool I've ever encountered. Google for some more usage on it, like Iterating and such.

Umm... what happens if you do a multidimensional array access on a non-multidimensional-array variable?

If you wish to manually handle multidimensional arrays, do it like this:

char *a;

a[num_columns*row+col]=whatever.




or for a 3 dimensional array:

a[max_x*max_y*z+ max_x*y+x]=whatever.

ok guys. i suppose you're right about the one dimensional array method.
and you guys really have me intrigued about this std::vector deal.
was trying to resurrect some ancient (1995) voxel-terrain code I found from
one of my backup discs. very nastalgic. thanks guys for you insights!!!

Besides the tips above, in the OP's snippet there are at least 2 errors (I haven't looked furthur):

Instead of
if((rbuf=(unsigned char***)malloc(scrX*sizeof(unsigned char)))==NULL)
you have to allocate _pointers_ like here
if((rbuf=(unsigned char***)malloc(scrX*sizeof(unsigned char**)))==NULL)

And later on, instead of
if((rbuf[x]=(unsigned char**)malloc(scrY*sizeof(unsigned char)))==NULL)
you have to allocate _pointers_ like here
if((rbuf[x]=(unsigned char**)malloc(scrY*sizeof(unsigned char*)))==NULL)

The 3rd allocation is correct so far.

ah HAH!!
that was EXACTLY the embarrasingly simple oversight i was hoping it would be
yay i'm not cray lol
works like a charm


thx haegar.
you guys all rock

Quote:

Original post by Indogo 2000 ah HAH!! that was EXACTLY the embarrasingly simple oversight i was hoping it would be yay i'm not cray lol works like a charm thx haegar. you guys all rock

So now you've learned a lesson and will use std::vectors, right? [smile]

you definitely got me curious enough to check out
the std::vector mechanism Jouley! i've started poking at it.
what about performance though?

Quote:

Original post by Indogo 2000 you definitely got me curious enough to check out the std::vector mechanism Jouley! i've started poking at it. what about performance though?

In principle, identical to raw arrays.
Indexing into the array typically gets inlined by the compiler so it is as efficient as if it'd been a regular array.

If you're using MSVC 2k5 or later though, Microsoft has added a bit of overhead to it, by doing bounds-checking by default. That can be disabled by defining the right macro however, and usually the performance hit from this bounds-checking is negligible in any case.

nice to have the bounds checking at first...
nice to be able to take control of it when you start zeroing in where and when
you can use it better elsewhere.

hey how do we put our code snippets inside thoes nice scrollable boxes?

Wrap them by [ source ] and [ /source ] tags, but leave out those spaces inside the brackets.

It may sound wierd but i'm working to DEoptimize
the ray casting mechanism to just regular vector math.
Yep it'll be painfully slow. I will then be porting the
routines to run in parallel on the GPU via CUDA. Was thinking
of a way to implement the paralelism.
Ok a few ways come to mind but trying to send even just
a 512x512 heightmap to each gpu would be way too much.

So I was thinking of like a supervoxel. say 8x8x8 segments.
Using a 3d no-hit-test bresenhams-line-algorithm to make a
slice of data to pass to the gpus. they would each hit test
their own low-res supervoxel, flagging it as having data or not.
The supervoxels actually HAVING data would be sent BACK to
the gpus for voxel level hit-testing. I know it seems like a lot
of extra work but when the voxel data starts getting even bigger
it seems like it would pay off even more.

Who pays you to push the stl library vector stuff? I find a lot of people who teach it as some kind of gospel. Who here agrees with me?

IoIndigo? You thumping your chest?