Its a shame that you are restricted by the library... you can at least avoid this trap in your own code though. :)

memcpy is not /that/ fast in most implementations (you can almost always use mmx/sse2 to write a faster one if you want) consider for one thing that the details of the copy are passed as parameters, it must at least do some work to use them, this is a waste if you already know what they are (the for loop tells the compiler for you) also when operating on memory some instructions do not need an additional mov, which means they can be as fast, or faster, than a memory copy, others force you to do two movs (mul and div for instance)

There are two things I think you could be wanting to do here. I assume you don't want to draw a rotated black rectangle over the image, but want to get a rotated bit of the image This is quite drawn out to explain if you don't have much experience with graphics already... What you want to do is take the rectangle you want to cut and work out coordinates for the pixels, translate and rotate them (rotation matrix - google) and interpolate (bilinear interpolation - google it) between the neighbouring pixels in the original image to find the new pixel values. I would give a full explanation, but if you are a graphics programmer you should already be familiar with these ideas. Hope this helps.

GDI+ is probably too naive to handle the image size on its own, or much too slow. There is no reason why it couldn't deal with it, in theory. OpenGL is limited by your texture memory. No textures bigger than the texture memory can be loaded. You will want to load the file into memory (regular) and split it up, swapping out sections as needed. Setting up a texture in OpenGL moves data from RAM to VRAM and freeing the texture id will release it from VRAM so that you have space to load another etc... 4GB of RAM (page file) should be plenty enough for a 400M image. This kind of resolution is enormous, if you are going to put it all on screen at once I would recommend downsizing it first, i.e. pre-build files which are downsized, otherwise you will have the same memory problems, not to mention the ugly aliasing effects. Hope this helps.

You probably want to try using ray intersection tests (3d) or point in polygon tests. If drawing is slow then drawing related methods would be least appropriate. Sounds like they are causing your problem already...

Why do you need a pointer? e.g. if Key has a constructor Key(int) then instead of "return new Key(10)" with return type Key* you should be doing "return Key(10)" with return type Key. This way the compiler handles the allocations and frees for you. The only time I ended up keeping track of pointers as you described is when generating strings for an object, and only that one time because I didn't think hard enough about a solution. You can always avoid these situations with better design.

The problem with templates is that you can't have the definition in a .h and the implementation in .cpp Templates are like macros in that they are processed before the compilaton proper. There is a reason that I can't remember why that causes the problem... something to do with operating at the file scope rather than program scope There are a few ways around it, one is to write everything into the class defintion in the .h file. Contrary to popular belief this will not stop your code from working, but it is generally not good practice. There are some more elaborate workarounds out there if you look on Google... Hope this helps.

Your illegal access is where j is reaching 90 when i is 30, the array bounds are 120*30, not 120*30 + 90 for pDib1, so "+ j" is taking you outside of the array. Is this code doing what you want? The k variable here is redundant. ... int k=0; // k = 0 for(int j=0;j<90; ) // k not modified { pDib1[i*120+j+k]=pDib2[i*92+j++]; // k not modified pDib1[i*120+j+k]=pDib2[i*92+j++]; // etc... pDib1[i*120+j+k]=pDib2[i*92+j++]; pDib1[i*120+j+k]=0; } Also, a much better way to access an array like this is to increment to vars by 120 and 92 for each loop with i, saves the continual multiplication by constants, a slow down which dwarfs any speed benefit you gain from putting your increment inside the index. Consider: int a=0, b=0; for(int i=0;i<30;++i) { for(int j=0;j<90;j+=3) { pDib1[a+j]=pDib2[b+j]; pDib1[a+j]=pDib2[b+j+1]; pDib1[a+j]=pDib2[b+j+2]; pDib1[a+j]=0; } a+=120; b+=92; } This is faster and more legible (and still broken!). Hope this helps.

Winamp comes with AVS which lets you make visualisation with a simple scripting language http://www.winamp.com Its quite good as a soft introduction into graphics programming