does CopyRect clip?
BlitzPlus Forums/BlitzPlus Programming/does CopyRect clip?
| ||
| For example, if the source rect is bigger than the destination rect. Or do I have to do the clipping in-code, myself? Cheers |
| ||
| You dont pass a size for the destination. |
| ||
| I know you dont pass a size for the destination buffer but what if the destination buffer isn't big enough to hold a complete copy of the source buffer, e.g. ... tex = CreateTexture(128,128) ... CopyRect 0,0,800,600,0,0,FrontBuffer(),TextureBuffer(tex) ... Or, what I'm more interested in is what happens if you offset source rect in the dest rect, e.g. ... tex = CreateTexture(800,600) ... CopyRect 0,0,800,600,10,10,FrontBuffer(),TextureBuffer(tex) ... Does the copy get clipped to the confines of the dest buffer or not. Anyone know? Thanks |
| ||
| Yes, it should be clipped automatically... Of course, I'm not 100% sure but when I wrote something like your example here above some days ago I didn't come up against any error! Bye! |
| ||
| When in doubt, try it out......... |
| ||
| Dabbede: No, I haven't come across any probs with it either but I just think it's better to be safe rather than sorry. :) Sir Gak: That's the problem: how do you check to see if clipping is taking place or not? |
| ||
| Good question. What happens when you try to copy more data into an area of memory than allowed for it? The answer is, either you check for limits in both the source and destination, so that you only copy as much as permitted, or you don't and in copying too much you cause a buffer overflow/overwrite condition. Since array structures are usually organized in consecutive memory areas, it is sometimes possible to write to one element and detect if other elements adjacent to that one are altered. But you also have an issue as to which order the information is being copied in - if copying from a lower memory area to a higher one, some routines copy from the high order byte backwards, and from the low order byte upwards when copying to a lower area of memory. The idea is to allow the data to not overwrite itself incorrectly if the upper and lower bounds of the two areas overlap. In order to achieve the expected effect, some copy routines adjust the end of the copy area offsets beforehand to maintain a trailing edge clipping effect, while others may actually cause a leading edge clipping effect if the copy process ran from high end downwards. Of course if you use a really large source, and attempted to copy to a really small destination, you might induce a memory access violation situation if the underlying code attempts this without checking limits. you could in effect be trying to write outside the area permitted to the program. But to see if clipping does occur without necessarily running to those extremes, you should be able to try and copy from a large buffer to s small one, then copy from the small buffer back to the large one, but for each copy you specify the size of the large buffer, and you clear it beforehand. You would then get one of three results: (1) All the information from the large buffer is returned to it. This indicates that the information was not clipped when you copied it to the small buffer, in which case you were probably just lucky that you did not encounter a major problem. (2) Only the information from the small buffer is copied back, and the rest of the large buffer is still set to nil data (all zeros, for instance). This indicates that the copy process is pretty smart, and not only clipped in writing to the small buffer, but equally adept in not copying back information outside its area. (3) You get back the contents of the small buffer, followed by garbage data or data that does not reflect what was in that same area previously in the large buffer. This is a probable result, and means that the information was clipped properly when copied to the smaller buffer, but that the copy process had no issues with copying over data outside the scope of the small buffer when it's upper limit was exceeded. |
   |