Bug with ImageBuffers?

Archives Forums/Blitz3D Bug Reports/Bug with ImageBuffers?

Marcell(Posted 2013) [#1]
I think I have found bug in Blitz3D when using ImageBuffers.

I've made a game where in the beginning of the code I have made some own images using CreateImage. Later in the code before the game is started, I have drawn some text with DrawImageRect from bitmap font (png-file) into these images so that there's first SetBuffer ImageBuffer(gfxMyBuffer) and then the DrawImageRects.

Normally everything works fine, but if the game is interrupted so that the player has been taken into operating system, the mentioned own images appear as black boxes when drawn with DrawImage.

If the content of the own images is drawn always again before DrawImage, eveything works fine again.

I have Blitz3D update 1.107, Windows 7 Home Edition Service Pack 1, graphics card is ATI Moblity Radeon HD 4570.

With this graphics card I have had following problems sometimes when starting programs from Blitz3D:

Runtime Message
Starup Error: graphics_create failed

Runtime Error
Unable to set graphics mode

The first line of code is AppTitle "Program Name", second Graphics 1024,768,32,1.

With this graphics card I sometimes have some problems when running Windows 7, so the mentioned runtime errors are probably not bugs of Blitz3D.

Edit: The bug probably is in images created with CreateImage, not in the SetBuffer Imagebuffer-command. For some reason the images created with CreateImage are cleared when the control has been taken into operating system and then returned into game again.

Yue(Posted 2013) [#2]
Sample code??

Floyd(Posted 2013) [#3]
From the versions.txt file:

***** V1.99 *****

Implemented many fixes for 'loss of graphics' type situations, eg: when user logs out,
hit's ctrl-alt-del, alt-tabs out of a full screen app etc.

A few special cases:

* 2D images that have been manually modified using WritePixel/WritePixelFast should be declared
'dirty' after you have finished modifying them. You can do this using the new
BufferDirty() command, eg: BufferDirty ImageBuffer( theImage ). If you don't care if such
images survive loss of graphics, you can skip this.

* Vidmem texture contents will not survive loss of graphics. However, the textures themseleves 
will still exist, and these are supposed to be frequently updated anyway, so this shouldn't
be a major problem.

* Blitz3D still can't survive desktop rez-mode change in windowed mode. However,
the new GraphicsLost() command can be used to detect this. The only thing you'll be
able to do after GraphicsLost() returns True is EndGraphics() (and then perhaps reload everything
back in if you can be arsed). Or, as I'd be inclined to do, just exit, eg:

If GraphicsLost() RuntimeError "Please restart Defender"

Also added 2 new windowed graphics modes: 6 and 7. These are similar to modes 2 and 3, but will
auto-suspend the application when it loses activation. These new modes are highly recommended!

Marcell(Posted 2013) [#4]
Here is little sample code demonstrating the bug I described:

RemiD(Posted 2013) [#5]
No bug here, the text seems to be drawn correctly.
However i have tried with windowed mode.

If this is an issue with fullscreen mode, what you can do is to only use windowed mode and to use the windows functions to hide the title bar so that it appears as if it is fullscreen mode.

Marcell(Posted 2013) [#6]
Yes, this problem occurs in fullscreen mode.

The code example is direct copy/paste from my Blitz3D program where I have the described problem.