VRAM textures blacking out? Whaaaaat

Blitz3D Forums/Blitz3D Programming/VRAM textures blacking out? Whaaaaat

Adam Novagen

(Posted 2011) [#1]

Alright, so. I'm guessing this is a DX issue as usual, but I'd like to be sure, and know if there's anything I can do to prevent it.

Thanks to my beta testers, I discovered recently that when a texture is loaded with flag 256 to store in VRAM for fast access, it blacks out if the player alt+tabs out of the game while it's in fullscreen. The textures are still THERE, and they're perfectly usable and able to be drawn to; it's just that all their existing pixel data has been "zeroed."

Have some code:

Graphics3D 800,600,0,1


SetBuffer BackBuffer()


Global RAMtex = CreateTexture(64,64,16 + 32)
	SetBuffer TextureBuffer(RAMtex)
		Color 255,255,255
		Rect 0,0,64,64
		Color 255,0,0
		Rect 8,24,48,16
		Rect 24,8,16,48

Global VRAMtex = CreateTexture(64,64,16 + 32 + 256)
	SetBuffer TextureBuffer(VRAMtex)
		Color 255,255,255
		Rect 0,0,64,64
		Color 0,255,0
		Oval 8,24,48,16
		Oval 24,8,16,48


Global Cubes[1]
	Cubes[0] = CreateCube()
		PositionEntity Cubes[0],-5,0,10
		EntityTexture Cubes[0],RAMtex
	Cubes[1] = CreateCube()
		PositionEntity Cubes[1],5,0,10
		EntityTexture Cubes[1],VRAMtex


Global Light = CreateLight()


Global MainCam = CreateCamera()
	CameraClsColor MainCam,0,0,255
	CameraViewport MainCam,0,0,800,600


SetBuffer BackBuffer()


While Not KeyHit(1)


;Cls


TurnEntity Cubes[0],.2,.4,.6
TurnEntity Cubes[1],-.2,-.4,-.6


UpdateWorld : RenderWorld


Flip


If KeyHit(28)
	Repeat
		num = num + 1
	Until FileType("scrn" + num + ".bmp") <> 1
	SaveBuffer FrontBuffer(),"scrn" + num + ".bmp"
	num = num + 1
EndIf


Wend


End

The above program is entirely self-contained. Here's what happens when I run it:

The cube on the left, with the red cross, is painted with a normal texture stored in RAM (or wherever Blitz puts textures by default). The cube on the right, with the green ovoid star, is given a flag 256 texture stored in VRAM. The textures' flags are otherwise identical, 16 and 32 to lock prevent their UV from wrapping around. Now here's what happens after alt+tabbing out of the program, and back in again:

So, obviously, there are ways to SOLVE this, especially since the textures can still be used and draw to. For my own reasons, however, I would like to know first WHY this happens, and if there is a simple way to prevent it happening at all.

Last edited 2011

Last edited 2011

Last edited 2011

Ross C

(Posted 2011) [#2]

It's probably because your forcing the texture to stay in VRAM and VRAM is being wiped, or unallocated. Everything you load in blitz, is also stored in RAM, according to my tests I did a while back.

Adam Novagen

(Posted 2011) [#3]

Thing is, VRAM storage is necessary if you're going to draw to a texture from time to time, at least if you want it happening in realtime. There are a few textures in my game that get drawn to in this way, and WHEN they're drawn to it's fine, but I need them to NOT black out if the player alt-tabs.

GfK	(Posted 2011) [#4]

This has always been the case with Blitz3D for as long as I remember. As far as I know there is nothing you can do about it - a problem which rules Blitz3D games out of getting on most portals, as they normally insist that the game continues to work after alt/tab.

As a long shot, that FastExt thing people keep going on about might help. It seems to solve every other Blitz3D shortfall.

Yasha

(Posted 2011) [#5]

You could redesign your game so that all of your texture fit into one of two clearly-separated groups: static textures, which are considered "safe", and dynamic textures, used for drawing and copying (I have the feeling that this clear separation was intended or at least expected by Mark, hence the bug). Most dynamic textures will be being updated every frame, so this bug should hopefully not be noticeable.

In those cases where a texture is updated sometimes-but-not-often, consider having two; a VRAM texture to use while the texture is in the process of changing, and a regular texture to copy the frozen buffer to once the image has stopped moving. Assuming that while the image is changing it will be immune to Alt+Tab (simply by virtue of being refilled next frame), this should solve most of the problem if it's not a major speed hit to occasionally do a CopyRect to a non-VRAM texture - if this only happens every few seconds and you have tweening enabled, the player won't notice.

You'd need to have some kind of extra state flags attached to your game props to signify which texture is in use and when to change them... shouldn't be too complicated.

Rroff

(Posted 2011) [#6]

Not sure if the BufferDirty command is at all useful here, think its really for 2D images stored in system RAM.

You can probably use the GraphicsLost command tho to reload the engine when this happens.

Adam Novagen

(Posted 2011) [#7]

Alright, good to know it's just there, period; Yasha's solution is more or less what I was thinking of doing, so I'll just go ahead and fiddle it in. I'm mildly surprised about the Alt+Tab business, tbh; I always game in fullscreen, and had to learn the hard way not to Alt+Tab out of it since about half of my games from Valve themselves would crash if I did so. I believe L4D was one of 'em. Might have just been an issue with my graphics drivers though, I dunno.

Anyway, thanks for clearing this up, guys!

Rroff

(Posted 2011) [#8]

Quite a lot of games don't like alt-tab even in this day and age.

Source games will eventually have problems, sometimes a solid or tiled purple stage on certain shaders, sometimes crashes.

Test Drive Unlimited 2 will randomly stall on a blackscreen (sometimes recovering after 30 seconds).

And so on.

Last edited 2011

Adam Novagen

(Posted 2011) [#9]

Yeah, that's what I've experienced... Still, quality control is quality control. Honestly I'm mildly disgusted with myself for trying to brush off the Alt+Tab business without looking into other, clever (or more laborious) solutions; "good enough" should never be good enough!