buffer/debug question
Blitz3D Forums/Blitz3D Beginners Area/buffer/debug question
| ||
| I ran into some odd (to me) behavior while experimenting with a program to generate random abstract art to the screen. The part I don't understand is that when I run the code with debug enabled and hit spacebar a few times, everything seems to go directly to the foreground (which is what I want), but if I run it without debug enabled it seems like output is alternating between foreground and background. If I take out the flip command, and run with debug NOT enabled, I'll see the output only after I hit the escape key. With debug enabled, I'll NEVER see the output. -------------------------------------- Graphics 1024,768 SetBuffer FrontBuffer() Cls While Not KeyHit(1) Color Rand(1,255),Rand(1,255),Rand(1,255) For I= 1 To 100 Step 10 Oval 200,350+Rand(1,50), I,I,0 Next Flip WaitKey Wend -------------------------------------- Any thoughts? |
| ||
| change SetBuffer FrontBuffer() to SetBuffer BackBuffer(). YOu are always writing to the frontbuffer and then copying the empty backbuffer over it when you call flip. You should 'almost always' write to the backbuffer, and then flip swaps the backbuffer to the front, thus showing what you have drawn. Good Luck, MK |
| ||
| Thanks for the suggestion, MK, but oddly enough it seems to behave exactly the same even after changing SetBuffer FrontBuffer to SetBuffer BackBuffer(). It still works fine with debug on, but as soon as I set debug off, it seems to be switching back and forth. Just to be clear what I mean by that, I took out the for next loop and adjusted the oval statement (see code below) and got the following sequence: (1) I run it - a small filled circle is displayed. (2) I press spacebar to loop again - The first circle disappears, and a different circle is displayed. (3) Spacebar again - The 2nd circle dissappears, the 1st one comes back, and a 3rd (new) one comes on (for a total of 2 on screen now) (4) Spacebar again - Circles 1 and 3 dissappear, 2 comes back, and new once comes on (still two on screen). (5) "" - circles 2 and 4 gone, 1 and 3 come back joined by 5 for total of 3 circles ... and so on ad infinitum. -------------------------------------- Graphics 1024,768 SetBuffer BackBuffer() Cls While Not KeyHit(1) Color Rand(1,255),Rand(1,255),Rand(1,255) Oval 200+Rand(1,50),350+Rand(1,50), 5,5,1 Delay 100 Flip WaitKey Wend -------------------------------------- So I don't know - Does the above code work for someone else running with debug on? Could it be a Windows XP problem? My video card? (64mb NVidea GeForce2 MX with TV Out). Frustrated but not discouraged, Ted |
| ||
| put the cls inside the loop |
| ||
| Thanks for the idea skidracer, but I'm afraid putting the cls inside the loop would defeat my purpose (I tried it just to be sure and yes, it does). The program I am creating generates various effects on the screen. With each press of the spacebar (or key other than Esc), the user can ADD to the previous effects. Putting the cls inside the loop just erases everything to a clean slate. Ted |
| ||
| In windowed mode there isn't really a seperate front and back buffer. To solve your problem just remove the Flip command. |
| ||
| OH! I think I just came up with a solution. If I add a second Flip AFTER the WaitKey like so ... ----------------------------------- Graphics 1024,768 SetBuffer FrontBuffer() Cls While Not KeyHit(1) Color Rand(1,255),Rand(1,255),Rand(1,255) Oval 200+Rand(1,50),350+Rand(1,50), 5,5,1 Delay 100 Flip WaitKey Flip Wend ----------------------------------- ... then it works fine with or without debug on. The only difference is that it does blank the screen and then bring it back with debug off, but I can live with that. For this particular application, it might even be a good thing. I'm still curious about the hows and whys (and this behaviour is particular to Windows XP) - Supposedly one can draw directly to the frontbuffer, but I haven't seen it so far. Oh well, I'm learning. Ted |
| ||
| >> In windowed mode there isn't really a seperate front and back buffer. To solve your problem just remove the Flip command. << Doesn't work for me, MasterBeaker - If I do that I don't see anything but a blank screen until I hit the Esc key (and not even then if debug is on). Fortunately, adding the second Flip command solved the problem. |
| ||
| AhHa, from the blitzplus user guide (migrating to blitzplus section): All graphics are now double buffered, so you must use Flip or FlipCanvas to show any rendering. Sorry, this has been a waste of time for you, the FrontBuffer() command should have been more obviously deprecated. Also, your double flip cludge is not guaranteed to work on all machines as many 3D cards are set to triple buffering by default. |
| ||
| Augh!!! Well, thanks Skidracer. Better to find out about the potential triple buffering problem now than (the hard way) later. I guess I could try grabbing the whole screen after each update and then copying it to the backbuffer prior to the next drawing operation - Seems like it should be possible to just incrementally update the backbuffer somehow though. And not a waste of time for me, just a "Learning Experience" :) |
| ||
| Ok, here's solution #2: ------------------------------------- Graphics 1024,768 ScreenHolderHandle=CreateImage(1024,768) While Not KeyHit(1) SetBuffer ImageBuffer(ScreenHolderHandle) Color Rand(1,255),Rand(1,255),Rand(1,255) Oval 200+Rand(1,50),350+Rand(1,50), 5,5,1 SetBuffer BackBuffer() Cls TileImage ScreenHolderHandle,0,0 Delay 100 Flip WaitKey Wend ------------------------------------- This seems to work with or without debug, doesn't produce any flicker, and (I presume) will not be a problem for those with #D cards set to triple buffering. |
| ||
| @PT, I think that solution is going to be dog-slow. It really should work by writing to the backbuffer and using flip. Do the example programs work for you? What version of BB are you using? Are you running windowed or fullscreen? If the example programs work on your machine, I would start from there. If not, then you need to check your graphic drivers or test it on another machine. Something's not right. Good luck, MK |
| ||
| No, the frontbuffer in BlitzPlus is definately not usable. |
| ||
| Well, MK, speed is not much of a problem for that particular application, at least not on my machine (1.7 ghz), but of course I am concerned with speed for other programs (as well as potential other users of this one on slower machines). I am running BlitzPlus ver 1.11, which I believe is the current version. Most of my test programs start with "Graphics 1024, 768" which I presume is considered running in full screen mode (it's what I have my screen res set to anyway). As for the example programs, they work more or less with two caveats: (1) They usually seem geared towards getting something on the screen and that's it, whereas what I have been doing is drawing some graphics on the screen, pausing for the user to press a key, and then adding more graphics WITHOUT erasing the first graphics, etc. (2) As Skidracer was kind enough to point out: "All graphics are now double buffered, so you must use Flip or FlipCanvas to show any rendering." - I think some of the examples were created prior to that being true and thus do not work the same way they once did. All of the games that came with Blitz Plus seem to work fine for me, so I don't think my drivers are too bad. Thanks for the idea of trying it on another machine though. I'll try a small exe on my mom's computer (which used to be mine) this weekend. In the meantime if you (or anyone) would be kind enough to paste the following into BlitzPlus and try to run it (with debug NOT enabled), I would be very interested to see if you get the same results as me. What I would be AIMING for would be for the first line to display, then after the user hits a key the second line displays (without the first one disappearing!) What DOES happen is that when the second line displays, the first one disappears. ---------------------------------- Graphics 800,600 Cls SetBuffer BackBuffer() Line 100,50,500,55 Flip Delay 200 WaitKey Line 100,70,500,55 Delay 200 Flip WaitKey |
| ||
| I just had exactly the same kind of problem like you : a character is walking in my game, and when the level is won, my character stops and look at the player... in debug mode. I "real" mode, the level stopped as the character was walking still (one frame behind ?)... THAT was a real fight before I have the idea to look here and finaly find your post!... It seems to work now, but I am not completely satisfied, because I haven't understood the reason of this different behaviour in debug and real mode... :-( So my questions to the Blitz-experts : - what is the best thing to do to avoid those discrepancies between debug and real modes - is this problem XP related (I use XP pro) and/or graphic cards related - I use Blitz2D now, but I will buy Blitz3D : is it the same for Blitz3D ? Thanks a lot in advance ! |
| ||
| Debug mode has error-trapping engaged. It runs the code slower, but is more likely to catch a bug so that your cpu doesn't crash. "Real" mode does not have this "safety net", so it runs faster; it throws the requirement to have crash-free code on you, the programmer. Maybe you can work out a compromise: try new code in debug mode. If it does not crash your computer, then switch off the debug so you can run your prog in "real" mode. |
   |