256 tex flag crash
Blitz3D Forums/Blitz3D Programming/256 tex flag crash
| ||
| Need some advice. I have a number of beta testers going through my 3d tank game at the moment. However One of the testers has a Nvidia 5200fx Ultra and is reporting a nasty crash. I have a radar routine that copies the backbuffer (after a render) to a texture created with the 256 flag enabled (load texture into vidmem) and it seems this is causing the crash. JFK has a code archive entry that tests 256flag functionality, but it needs to be updated (readpixel behaviour has changed I seem to recall). http://www.blitzbasic.com/codearcs/codearcs.php?code=618 But I'm thinking that if I use JFK's code to test for 256 flag functionality, may that not cause a crash in itself? Has anyone else come up against the issue and how have you resolved it? Is it something a DLL such as Tom's dx7test could test for? |
| ||
| readpixel behavious chanched?? That's new to me. Although, the mentioned test routine, AFAIK, is really a dirty hack. It can't prevent a crash. It will only detect if a texture is working correctly and if it's faster (to copy to it) than a texture without the 256 flag. Basicly, if a loaded or created texture has a valid handle then it should work. If the 5200 can't handle it then it may be a driver issue (did the guy update the drivers?) Is the crash really reproducable? Do other 5200s act the same way? If copyrect crashes, then try to emulate it using readpixelfast and writepixelfast. Probably it's only the copyrect function that doesn't work. |
| ||
| jfk 'readpixel behavious chanched?? That's new to me' I think I was recalling the B3d changelog; 'To get the old behaviour of ReadPixel/ReadPixelFast, use the following:rgb=ReadPixel( x,y ) And $FFFFFF.' But looking at your code, I see you've already done that ;-) 'If the 5200 can't handle it then it may be a driver issue (did the guy update the drivers?) Is the crash really reproducable? Do other 5200s act the same way?' Don't know if he's updated his drivers. Looking around on the net, I see that the card's about 4 years old and was only a moderately medium spec card back then. The crash is certainly reproduceable on his machine - don't know if other 5200's act this way. Sent him an updated exe with all loadtexture 256 flags turned off and it at least stopped this particular crash. Still, I'd like to be able to do a check and set a global flag not to load textures with the 256 flag - and be fairly confident that the check itself won't cause a crash. 'If copyrect crashes, then try to emulate it using readpixelfast and writepixelfast. Probably it's only the copyrect function that doesn't work' Could be - but it's for the radar and so needs to be as speedy as possible. Suspect readpixelfast/writepixelfast are going to be too slow. |
| ||
| It is much faster with flag 256. Although presumably still slower than copyrect. |
| ||
| I wonder if Tom's dx7test.dll could check for this; From his decls; GetDeviceGUID$():"_GetDeviceGUID@0" SupportsAllStencilOPs%():"_SupportsAllStencilOPs@0" SupportsRangeFog%():"_SupportsRangeFog@0" SupportsMipMapLODBias%():"_SupportsMipMapLODBias@0" SupportsAllZCmpCaps%():"_SupportsAllZCmpCaps@0" SupportsCullCCW%():"_SupportsCullCCW@0" SupportsAntiAliasing%():"_SupportsAntiAliasing@0" SupportsDXT1%():"_SupportsDXT1@0" SupportsDXT3%():"_SupportsDXT3@0" SupportsDXT5%():"_SupportsDXT5@0" SupportsRenderTexture%():"_SupportsRenderTexture@0" I have no idea here, but perhaps if the card doesn't support render to texture, perhaps it could be assumed the 256 flag would cause a prob as well? Or is there a specific cap that could be checked for this (flag256 compatibility). |
| ||
| So any ideas anyone? I actually thought this issue would be of more interest to the community in that I suspect a lot of games produced with blitz use the 256 flag. And so a compatibility check would be very useful... |
| ||
| It's the first time I heared of a crash due to flag 256. Is it only his machine, or does it happen on all machines with the same card? At some point (eg. < 3%) you have to live with a small number of incompatible machines, it's the way it is. |
| ||
| 'you have to live with a small number of incompatible machines, it's the way it is. Maybe - I still reckon some DX guru could whip up a DLL to test this. In the meantime, perhaps the simplest solution is to provide a 'safe mode' - as many commercial games do ('XX did not exit properly last time, press OK to run in safe mode'). |
   |