   Loading updated images @ 30+ FPS
  hi all. i created a simple random number generator that stores an array of values between 0 and 65535(unsigned shorts). the size of the array is dynamically allocated depending on the w,d and h sent to it from the main function, in this case an OpenGL application. this applications goal is to update the image @ 30 FPS however there is some lag time because of the size of the array which is 640x640x4, with 4 being there because the image needs an alpha. the FPS right now is about 10 - 12 FPS. As of now every time my function in the class is called(every frame) it generates random numbers using the rand() function to repopulate the array. i dont know how much computational time rand() takes up but maybe it is more than i thought. would there be a better solution for populating the array and returning it to the main function? any questions please ask.. thanks!   
  If it is indeed the RNG that's slowing you down (and not the texture pushes across the CPU->GPU bus), you could always try either Mersenne Twister or the Microsoft Crypto API. Both have functions that allow you to fill an array in one call, rather than obtaining a single random number per call.One other optimization is to ensure that you are not duplicating the results when returning them.ex: Bad:vector<int> func(void){ vector<int> temp; // do stuff  return temp;}ex: Good:void func(vector<int> &temp){ temp.clear(); // do stuff}I believe this should work with SIMD-oriented Mersenne Twister:void func(vector<int> &temp, size_t num_ints){ temp.clear(); temp.resize(num_ints); // Pass array in as 32-bit ints, regardless of size // Note only works if you are filling an integer array (not floats) // If int is 16-bit, then the array must be at least 2 large fill_array32(reinterpret_cast<uint_32_t *>(&temp[0]), num_ints/(sizeof(uint_32_t)/sizeof(int)));};  Just like taby said, if your hardware bus is AGP or PCI-e, I can't imagine pushing that texture across being a problem. So I'd look into the other code. rand() isn't fast, and the Mersenne Twister is a much improved solution. That is what I'd try next.   ;Quote:Original post by Jason PetraskoJust like taby said, if your hardware bus is AGP or PCI-e, I can't imagine pushing that texture across being a problem. So I'd look into the other code. rand() isn't fast, and the Mersenne Twister is a much improved solution. That is what I'd try next.thanks all for your input - i am not the only one working on this project and the guy doing the actual opengl part is calling my public class function that returns a pointer to the array..and i believe he uses that to fill the area with pixels instead of a texture. i will go back and make sure of this though. at any rate lets assume this is true.. not that it might not make any difference. here is my code: unsigned short * myclass::get_image(int w, int h, int d){ if(image != NULL)   delete [] image; image = NULL; image = new unsigned short[w * h * d]; srand(std::time(NULL)); for(int i = 0; i < w * h * d; i++)   image = (rand() % 65535) + 1; return image;}so from his main he would say something like: unsigned short *image = c->get_image(640,640,4);but i will have to check to see what he is doing after that to make sure there is nothing on his end. also he is using FLTK instead of just win32 so i dont know what, if any, stipulations that might have. any thoughts about this code? obviously i will be looking more into the solution that taby gave me.. thanks!   ;  "and i believe he uses that to fill the area with pixels instead of a texture"Gee, uh, I hope that isn't as bad as it sounds. Because putting it all into a texture and pushing it over to the video card in a single GL call is far more efficient than making 640 /TIMES/ 640 calls for the pixels...   ;Quote:Original post by Jason Petrasko"and i believe he uses that to fill the area with pixels instead of a texture"Gee, uh, I hope that isn't as bad as it sounds. Because putting it all into a texture and pushing it over to the video card in a single GL call is far more efficient than making 640 /TIMES/ 640 calls for the pixels...i asked him and he said that when he gets the pointer to my array that i fill up with values using the code above, he uses glDrawPixels() using that pointer to fill up the draw area. is a texture less time consuming? thanks for your input. ill admit i havent worked that much personally with just pixels so thats why i am asking. thanks Jason..;  glDrawPixels() is a raster operation. Which most likely won't be accelerated on a lot of hardware.Is there a reason you wouldn't want an Ortho mode and Simple texture blitting?   ;  If the person working on the rendering part hasn't done this already, tell him to look into using the GL_ARB_pixel_buffer_object (PBO) extension to get asynchronous transfers.  Doing this will let your application start to send the pixel data to the card and then start calculating the next image without needing to wait for the transfer to complete.   