This doesnot work right!
Blitz3D Forums/Blitz3D Beginners Area/This doesnot work right!
| ||
| Try this; Graphics 800,600,16 SetBuffer BackBuffer() For x=0 To 9 ;Cls Rect 0,0,800-10*x,600-10*x,0 Flip VWait 20 Next It should have 5 rectangles on each bank, right? Why can I see all 10 at the same time? Marg |
| ||
| Well if I try your code I see only 5. When you use Flip, I think the frontbuffer and backbuffer are swapped: what is on back will be on front and what was on front will be on back. Therefore, like you say, there should be 5 on each bank, and this is also what I see. Hmm... By the way, also in reference to your other post: if I use SetBuffer FrontBuffer() in this program instead of backbuffer, and remove the flip, I see all 10 rectangles (also adding a Waitkey() at the end so you can see it, or a Delay(1000) in the loop). I think that the SetBuffer() command is not a way to select between double buffering, or no double buffering. There are always the two buffers; with SetBuffer() you just select the buffer you are drawing to. It only actually becomes "double buffering" when you 1) choose the backbuffer to draw to and 2) use Flip to flip what you have drawn to the frontbuffer. If you don't want double buffering you should select the frontbuffer, and NOT use flip. I think this is how it works. |
| ||
I see 10, but it's for the same reason as this program "drawing" a yellow line instead of just a box at the mouse pointer:Graphics 800,600,16 Global mouseimage = CreateImage (10,10) SetBuffer ImageBuffer(mouseimage) Color 255,255,0 Rect 0,0,10,10,1 SetBuffer BackBuffer() While Not KeyHit(1) ;Cls DrawImage mouseimage,MouseX(), MouseY() Flip Wend End Notice that the Cls is commented out as yours is in your example. The problem is that even though you are flipping the buffer, you're not clearing the flipped buffer. So the buffer flips to the back with whatever was on it to begin with. In your loop, the buffer is carrying the rectangles with it that have already been drawn on the buffer. You have to cls the buffer. I'm not sure if the clearing is dependent on video card or not.. Maybe some clear automatically when flipped to the back buffer, and other's don't. |
| ||
| But if you clear the buffer (using Cls), in the end you will only see the last rectangle that was drawn. I see 5 rectangles because you draw one, flip it to front, and flip front to back. Front was empty so back is now empty. You draw one, and so on: of every two rectangles you draw, each of them will end up on a different buffer. (Or, on one of the two images that you are flipping between back and front.) When you see 10 rectangles, this means that when you do flip, the back is flipped to the front *but the front is not flipped to the back*. So you draw a rectangle, flip it to front. You draw a second rectangle next to the first one and flip the result, two rectangles, to front. This way, you will have all 10 rectangles in the end. So with respect to dependency on video card, I think the difference between two cards would be in the effect of the Flip command, with these two possibilities: a) Flip has the effect of *interchanging* the contents of back and front b) Flip has the effect of copying back to front My video card (5 rectangles) would be doing "a" while your video cards (10 rectangles) would be doing "b". Or could it be a difference between the way Flip is operating in Blitz 2D versus Blitz Plus? (As I am using Blitz 2d.) |
| ||
| I think the flip function is video card dependent... I've seen this in a couple of my games that use the flip command without clearing a screen.. I've tested on a TNT, NVidia TI 4200, Radeon 9000 Pro, and Radeon Mobility.. ATI definitely handles the Flip routine differently than NVidia. |
| ||
| I have a Radeon 7000. So to be certain we should always use Cls (or another full screen redraw) after Flipping, as you can't be sure the Backbuffer still contains what it contained before OR that it contains what was previously on the Frontbuffer. (In most practical cases you would want to clear the buffer anyway to get proper animation, but I guess it is the theory here that counts.) (Or instead of Cls you could of course make sure you redraw the entire buffer in another way, like in typical single-screen 2D game where you redraw a background image each frame.) |
| ||
| a) Flip has the effect of *interchanging* the contents of back and front b) Flip has the effect of copying back to front FYI - Flip does neither (Unless I've missed something somewhere). It only changes the REFERENCE to the drawing buffer. On each screen refresh of the monitor the video card will transfer information to the monitor STARTING at the memory location referenced in either FrontBuffer() or BackBuffer(). No information is ever copied from one buffer to the other. This way, ABSOLUTELY no time is lost transferring any data anywhere. This is the fastest possible screen update available. This phenomenon you are talking about where any data is being moved around doesn't sound correct. If it is a video card 'feature', it sounds like a stupid one. Two buffers have to co-exist anyways (to allow you to draw to one while displaying the other) so why bother transferring any data? |
| ||
| Well it was only a (bad) theory... Just to see if I got it right: using Flip, the *addresses* in FrontBuffer() and BackBuffer() are interchanged? |
| ||
| I don't think it even does that. Flip just changes which of the two buffers is used for the display. |
| ||
| But that would mean that after an odd number of Flips you are drawing to the same buffer that is used for display. |
| ||
| No. You ALWAYS draw to backbuffer (or whatever is set by SetBuffer command). When you 'flip' the reference is changed, so the front buffer 'becomes' the backbuffer and vice versa. |
| ||
| Hi, thanks everyone. I think it should draw rectangles alternately on each buffer. How it manages to get all 10 on both is a mystery. I think the fact it works with Foppy (using Blitz2D) tells me there is a bug somewhere with B+. Thanks |
   |