Flickering textures in fullscreen
Blitz3D Forums/Blitz3D Programming/Flickering textures in fullscreen
| ||
Some of the textures in my game display this weird flickering behavior. See e.g.: (The left track of the tank should look like the right one.) Note that this only happens only in fullscreen mode and independently of the resolution. The flickering seems to be dependent on the camera angle, with those textures flickering more that are near the edge of the screen. It would be great if someone could help me out! |
| ||
| What is your camerarange set to? And do you have any overlapping polygons in the scene? Usually if there is two (or more) polygons, place very close together and occupying roughly the same area, they will fight with each other. The z-buffer isn't 100% accurate, so one frame one could be on top, then the next frame, the other could be on top. |
| ||
| I think he's not talking about z-fighting, are you? Unfort. flickering is hard to see on a single picture :) Maybe he's talking about a frequency interference. This happens when somebody is wearing real Silk cothes in Television - it's flickering magically. Or also sone sorts of fishbone patterns. The monitor has a certain frequency, and so has the pattern. When the both overlap - frequencywise, then there may be flickering artefacts. This may also happen on modern LCD displays, esp. when they are running in a resolution other than their physical Pixel resolution. Then again it may be something completely diffrent +_+ If it's really the Silk thing, then a simple screenshot of this scene would have to flicker the same way in fullscreen mode. (Use Savebuffer, then do the test) |
| ||
| I agree with Ross C. It looks like the tracks are too close to the tank-mesh and while rendering, one part overlaps the other, creating flickering results, due to inaccuracies in the Z-buffer. At some camera-angles, the result can look fine, but when you go further away from the tank-model, both tracks could end up flickering. try to make your tracks a little bit bigger (further away from the tank model) so they won't overlap. |
| ||
| But why does it happen only in fullscreen mode? |
| ||
| Looks like you're using orthographic projection? That's going to exaggerate the z-ordering things the other people have already mentioned. You can also get this 'sawtooth' effect on some hardware when you set the 'far' camera range too high. But why does it happen only in fullscreen mode? That's the other thing - colour depth. It may only happen in 16-bit or 32-bit. Trying to force 16-bit colour in a window on a 32-bit desktop, will also cause the game to use 32-bit colour. |
| ||
| Does setting the bit depth to 16, also cause blitz to use a 16 bit z-buffer? |
| ||
| Dunno. Maybe. |
| ||
| You're dead on, Gfk! I experimented a bit, and as Ross C suggested, there were indeed overlapping polygons in my tank model and, as a result, z-fighting. After fixing the overlap in my model, the flickering considerably decreased, but it didn't go away completely. Then I changed the color depth from 16-bit to 32-bit, et voila, the flickering was gone -- even my old models with overlapping parts didn't flicker anymore! The command reference page on WBuffer has the explanation: "a z-buffer can be slightly inaccurate in 16-bit colour mode, for which the level of precision is less than in 24-bit or 32-bit colour modes." At least on my machine, z-buffering is not "sligthly", but extremely inaccurate with 16-bit color depth. I even noticed flickering between turrent and chassis although these parts never overlapped. I have two questions left: 1. What's orthographic projection? Where do I change this? 2. Can I safely assume that 32-bit color depth will work on all machines my game will be run on? Thanks so much for your help, very appreciated! |
| ||
| 1. What's orthographic projection? Where do I change this? If you have to ask, you aren't using it as its off by default. Its basically rendering but without perspective. Gives things an isometric 2D look (like the tank in your image). See CameraProjMode(). 2. Can I safely assume that 32-bit color depth will work on all machines my game will be run on? Yes, unless somebody's trying to run your game on a 10 year old PC. |
| ||
| Ah, I didn't watch the picture closely. Now I've seen that sawtheeth - of course, z-fight. Dummy, me :] |
   |