GrabImage unreliable unless flip is called twice

BlitzMax Forums/BlitzMax Programming/GrabImage unreliable unless flip is called twice

Rambo_Bill

(Posted 2005) [#1]

sometimes grabimage is grabbing a blank image on some systems, unless after all my draw commands I do two flip commands then do a grab image. The problem with this is it looks really lame when everyone can see you drawing out your stock graphics.

Anyone know how to fix?

Oh and Noel telling me to get a new computer or video card is not the answer I want.

Dreamora

(Posted 2005) [#2]

This only happens when people define on driverside more than 1 backbuffer for the flipchain.
You can't do anything about that as draw draws to the highest backbuffer initialized while grabbing is done on the next-to-draw backbuffer.

Rambo_Bill

(Posted 2005) [#3]

So your telling me we can't pre-draw our graphics anymore? and your explanation,while it makes sense, seems to not fit as sometimes grabimage does work without flips and sometimes it doesn't (Yes even on the same system it did work on before). Youd think the behaviour would atleast always be the same on the same system. Can you specify to only use one backbuffer?

Dreamora

(Posted 2005) [#4]

hmm just tested my "idea"
was wrong sorry ...

But in that case I don't understand why it should not grab any data ...

Did you try with DirectX?
Perhaps its really your card that can't and won't work with OpenGL (SiS, S3, Intel, ATI IGP or similar cards that are useless for real 3D)

Rambo_Bill

(Posted 2005) [#5]

It's using the default driver, which is DirectX. Some graphic cards seem to have the problem almost all the time, some have the problem almost never, and yet others never fail to grab image. So the reliability of grabimage is across the board. Sometimes I miss blitzplus :P

Dreamora

(Posted 2005) [#6]

Another idea: What size are the images you grab?
Grabbed images are transfered to VRAM so if you grab too much on a little 4MB or 8MB PCI card, it will just refuse to do it (512x512x32bit is 1MB VRAM).
Don't know, perhaps that is the reason? (old blitz behaved differently at that point)

for AGP this normally isn't much of a problem as most have 32+MB VRAM located as AGP-PCI RAM in the systems RAM.

Rambo_Bill

(Posted 2005) [#7]

if the size of the image was the problem, why would calling flip twice fix that? Perhaps you forgot that after calling flip twice that grabimage always works on every test computer I have.

Try Again.

Robert Cummings

(Posted 2005) [#8]

Isn't there a set buffer command to set the buffer you're working with first?

the reason flip twice shows it is probably you're copying from the front.

Oddball

(Posted 2005) [#9]

I'm using GrabImage extensively in my current project and haven't had a single problem with it. Have you tryed it in OpenGL too, and were the results the same? What are the specs for the computer that requires the x2 flips? And have you got a small bit of code that shows the problem so that we can test it on more systems? I'm interested in solving this as if there is a problem on some systems with GrabImage that would prove troublesome for my current project. In my tests I have found OGL to be much faster than DX when using GrabImage so this may be a DX problem only.

Rambo_Bill

(Posted 2005) [#10]

@Oddbal
I don't have a problem with grabimage on my PC either, seems to be a problem with certain graphic cards. I have not tried OpenGL as my games use the DirectX driver. I'll have to get the specs, but one of them was an off-the-shelf year old Dell.

Heres the code:

' Test of Grab Image
Graphics 640,480,0
Local myImage:tImage=IB_Image2()
Cls
DrawImage myImage,10,10
Flip

WaitKey




Function IB_Image2:tImage(TXT:String="Hello World")
	Local lWidth:Int,lHeight:Int
	lWidth=TextWidth(TXT)+2
	lheight=TextHeight(TXT)+2	

	Local tWidth:Int,tHeight:Int,X:Int,Y:Int
	Local mImage:tImage=CreateImage(lWidth,lHeight)
	SetClsColor 0,0,0
	Cls
	' put in our text
	tWidth=TextWidth(TXT)/2
	tHeight=TextHeight(TXT)/2
	X=(lWidth/2)-tWidth
	Y=(lHeight/2)-tHeight
	SetColor 50,50,50
	DrawText TXT,X+2,Y+2
	SetColor 255,255,255
	DrawText TXT,X,Y
	' With the two flips below, this code would work on all pc's, not just some.
	' Flip 
	' Flip
	' now Grab the image
	GrabImage mImage,0,0
	Return mImage
End Function

This code would only works on some pcs all the time. If you take out the rems before the flip commands it works all the time, but it looks stupid seeing the drawing going on.

Oddball

(Posted 2005) [#11]

I'm confused as to why you can't test this in OGL too. Does the pc that this fails on not run OGL? The code here runs perfectly fine on my pc, so I'm gonna need to test it on a few more. If anyone else can test this code as well that would be appreciated. And lets start getting some specs of pc's it works on and ones it fails on. Would really like to get this sorted before I find out my project is gonna start failing randomly. That'd be customer support hell.

Rambo_Bill

(Posted 2005) [#12]

If I knew it worked in OpenGL what good would that do me? I would need a way to test to see if DirectX is working right or not. Having said that, I'll still test it in opengl when I next get a chance(These test pc's are not all mine). As far as giving the user the option of DirectX or OpenGL, most of my users would sooner uninstall the game then change an option in the game.

Oddball

(Posted 2005) [#13]

I was only asking if it works in OGL to help BRL track down the bug. I think this topic needs moving to the bugs forum too.