Question about screen memory
Blitz3D Forums/Blitz3D Beginners Area/Question about screen memory
| ||
| Hi, I'm new to BlitzPlus and have a question about the way it handles screens. I've realised that SetBuffer FrontBuffer() does nothing, even though the documentation says otherwise. I think it double buffers as a rule now. I only have 8Mb graphics card, so I thought if I did a screensize of 1280x1024x32 I could force it to just have one visible screen. (i.e. not enough memory for 2 buffers). Using this code. ;---------------------------------------------------------- If GfxModeExists(1280,1024,32) Graphics 1280,1024,32 Else Print "Could not open graphics mode (1280x1024x32)" Repeat Until GetKey() End EndIf Color 255, 255, 255 Rect 0,0,1024,768,0 ;Flip Repeat Until GetKey() ;---------------------------------------------------------- But no, it still double buffers. (Needs the Flip) What is going on? I suspect it has used 1280x1024x16 but not sure. Anyone? |
| ||
| Is the program running in fullscreen (Graphics <width>, <height>,<depth>,1)? If not then it's possible Windows is handling the buffering itself. |
| ||
| Hi, It is working in full screen using 0 or 1. I imagine it must be switching down to 16 bits to allow double buffers. Thanks |
| ||
| Hi Marg, You can test if it's a 16/32 bit colour screen visually: Show a gradient in shades of grey on screen. You can use something like the code underneath. If it's a 32 bit screen the transition from white to black should be smooth. In 16 bit it's stepped due to a lack of shades of grey. for x=0 to 255 colour x,x,x line 200+x,100,200+x,500 next greetinx, Rowdy. (excuse my poor english) |
| ||
| Hi Rowdy, Did what you said and it is smooth in 1280x1024x32. Do you think BlitzPlus is using 24 bits? This would allow what is happening to happen as only 7.5Mb video needed. Thanks Marg |
| ||
| Can't you just use the GraphicsDepth() function? |
| ||
| Hi, I tried GraphicsDepth() and was told it was 32 bit but my question is how can I double buffer 1280x1024x32 in only 8Mb Video memory? Marg |
| ||
| I replied on the other thread by you on a similar problem. SetBuffer() is used to select which buffer you are drawing to, but that is not the same as turning dubble buffering on/off. Dubble buffering is a combination of selecting the back buffer, and using flip to flip the contents of the backbuffer to the front buffer (screen). At least that is what I think. To use the frontbuffer you should do SetBuffer(FrontBuffer()). Then draw things, and do not use flip (flip is not needed as you are already drawing directly to the screen). This way, you would only be using one buffer. What I *don't* know is what Blitz does with the other buffer. I think it is still there. I mean, there is no command to say "hey Blitz, I don't need the backbuffer so you don't have to reserve the needed memory". When I run your program I see the rectangle *without* using flip. And this is expected, as you don't make a call to SetBuffer(), and the default then is to use the frontbuffer. So what you are doing above is "not buffering", drawing straight to the screen. Well that might not have been of much help. Oh, I am not using Blitz Plus but normal Blitz Basic 2D, I don't know if the default buffer for SetBuffer() was changed in Blitz Plus? |
| ||
| The question is, is the BackBuffer using video memory, or is it using main memory? Some PCs actually "steal" main memory to provide additional storage for video when needed, so this is partly a hardware question as well. The fact is, regardless of what appears on the screen, the size and color depth of the current video setting is going to control how much memory is required. If you select a graphics size up to the limits of your current system settings, you will get a full screen result. If you specify a graphic screen larger than your system settings, you will only be able to see a part of it at a time on the screen, and have the problem of trying to scroll around it. Think about what happens when you change your screen settings, and how the desktop and opened applications appear to you. That is where the control of your graphical memory requirements are determined. |
   |