Problem with texture creation on some machine
Blitz3D Forums/Blitz3D Programming/Problem with texture creation on some machine
| ||
| Hi there, I have the following test code:
Graphics3D 640,480,32,2
t = CreateTexture(8,8,256+1)
SetBuffer(TextureBuffer(t))
Color 255,255,255
Rect 0, 0,8,8,True
SetBuffer(BackBuffer())
tb = TextureBuffer(t)
LockBuffer(tb)
p = ReadPixelFast(2,2,tb)
Print("result:"+Hex(p))
UnlockBuffer(tb)
FreeTexture t
While Not KeyDown( 1 )
RenderWorld
Flip
Wend
End
- It creates a 8x8 white texture. - Locks the texture - Pick a pixel on the middle - Display the value of the pixel On my machines, the result is, as expected, $ffffffff (white pixel), but on a user machine, the result is $ff000000 (black pixel) The user machine uses Windows Vista 32bits, DirectX10 and the hardware is an Acer Aspire 5520 with an NVIDIA GeForce 7000M/nForce 610M. Any idea? Maybe the texture flags? or something else? Any help welcome. |
| ||
| I would avoid storing the texture in VRAM perhaps, and check to see if that makes a difference. |
| ||
| I just sent a test program to my user with flags changed.. we will see. |
| ||
| You can't consistently use any 2D drawing commands other than WritePixelFast on texture buffers. They'll work on some machines and silently fail on others. So presumably the slacker here is Rect. You could try either replacing Rect with a manual-rect using WritePixelFast, or copying from a region created on the BackBuffer? |
| ||
| Or using the Blitz3D+ DLL? o.o |
| ||
| Yasha: Didn't know that. Is it documented? What is the explanation? is it a bug in Blitz3D? Using WritePixelFast everywhere is not really an option because it is far slower than just do a Rectangle in the Texture buffer. Thundros: Which DLL? Are you talking about FastExtension? |
| ||
| No... this 1... http://www.blitzbasic.com/Community/posts.php?topic=75711 |
| ||
| Is it documented? Definitely not. Anyway, CopyRect is fast enough for real-time use on most machines, so if that's the cause of the problem, you can usually just CopyRect off the BackBuffer (after all, this is how people without FastExtension do render-to-texture). As for the B3D+ DLL... that has absolutely nothing to do with this, and doesn't offer any remotely relevant features. |
| ||
| Yasha: Didn't know that. Is it documented? What is the explanation? is it a bug in Blitz3D? It's implicit from the fact that the 2D commands use DirectDraw. This component has been deprecated since DirectX 8 onward, so it's not safe. There is not enough information to say that this is the problem, however. I agree with Yasha: draw to the BackBuffer then CopyRect from there to the texture buffer. I'm sure CopyRect is much more compatible than the drawing commands. Then use the ReadPixelFast. - Use the texture on any cube or simple mesh just to see if it's working. - Setup several different tests under the same app; rules out quicker what's the problem. |
| ||
| Not sure if using print with a locked buffer causes any issues or not? |
| ||
| Well, without the 256 flag it seems to work on my user's computer. And it is also faster on my setup. In short, if I understand well, the 256 flag should be used when we do "render on texture" operations, otherwise not. Is it right? |
| ||
| Depends on what you mean by "render on texture." If you'll be drawing to a texture constantly while the game/program is running at full speed (realtime), then you will absolutely need to use flag 256 and find workarounds for its many shortcomings. I had a thread on one such issue a while ago: http://blitzbasic.com/Community/posts.php?topic=95435 |
| ||
| Flag 256 makes problems on some machines. You may use some code to test the flag for proper operation (colors...) and as well as if it actually makes something faster on a certain machine, or not, and in that case don't use it - dynamicly. I wrote some speed comparation code for reading/writing pixels and copyrecting, in context with or without flag 256, probably published it somewhere, code archives or around here, must be a few years ago. try searching for "flag 256" or alike. |
   |