New swShader Demo
- Thread starter Nick
- Start date
All of that window style and resize code was obsolete. 
It's the task of the application, not the renderer, to initialize that correctly. Thanks again for noting this Hyp-X!
The fixed-function pipeline should be feature-complete, except that it has no separate alpha channel. Texture sampling is, obviously, also limited to bilinear, and there's some texture mirroring hacking. Other than that, things like z-compare modes, blending operations, stencil operations, etc. are all implemented. I'm running more apps every day...
It's the task of the application, not the renderer, to initialize that correctly. Thanks again for noting this Hyp-X!The fixed-function pipeline should be feature-complete, except that it has no separate alpha channel. Texture sampling is, obviously, also limited to bilinear, and there's some texture mirroring hacking. Other than that, things like z-compare modes, blending operations, stencil operations, etc. are all implemented. I'm running more apps every day...
Regarding the 'bad pixels'... I noticed something really strange just now...
If you look at the shadow, you'll see pixels flashing on and off, even when you are not moving anything at all.
I suppose every frame should be rendered exactly the same if nothing moves, so it seems like there is something that isn't reset every frame, but is left at a random value? Perhaps FPU rounding control or something nasty like that.
If you look at the shadow, you'll see pixels flashing on and off, even when you are not moving anything at all.
I suppose every frame should be rendered exactly the same if nothing moves, so it seems like there is something that isn't reset every frame, but is left at a random value? Perhaps FPU rounding control or something nasty like that.
In the sample application's FrameMove function, the position and rotation of the plane gets updated. The camera system builds a view matrix using quaternions and matrix inversions and such. But even when there's no movement, it updates these parameters. Because of floating-point precision issues, the actual view matrix jitters.Scali said:
So, the 'bad pixels' is a real bug, the flashing pixels are just a bad side-effect of it with the slightly instable view matrix.
Nick said:
Hum, I suppose I should look at the source to see what is really going on then... Floating-point precision issues should be deterministic... I mean, given the same input, the same set of calculations should always give the exact same answer, whether this answer is stable or not.
If I remove the camera update the flashing pixels dissapear...Scali said:
I had a situation like this before. I was orthonormalizing my camera matrix every frame. This caused a jitter when using point sampling. The reason turned out to be that a matrix which is already orthonormal (the matrix from the last frame, when not touching keys or mouse) does not remain exactly the same when applying the orthonormalization algorithm. There was a tiny difference in the last bits of the floating-point format.
I'm entirely sure something very similar is happening in this demo.
Bummer. This pretty much means that it will only be available to developers with enough money to spend on such a frill. I guess from an end user POV it will only be available on these specific games.Nick said:
But again, only available to people who pay a lot. Enthusiasts won't be able to play with it.
(Sorry, I'm just disappointed. I'm not angry with you, since the product does deserve such money, but it would have been nice to have it without paying that.)
I think I figured out why there are dark pixels in the middle of the shadow volume, and pixels on the ground that are not shadowed correctly. The rasterizer does find the correct pixels to fill, it's the z interpolation that has precision issues. I interpolate z along the edges, so it accumulates a small error. For thin polygons like this, the gradient is a little less accurate, and because these polygons are quite long the accumulated error is bigger. So in the polygon spaghetti of the shadow volume some errors are made about which pixels are in front of the other. Hence the stencil algorithm wrongly marks some pixels as in shadow, and others as unshadowed.
My new rasterizer won't have this problem, since it recomputes the accurate interpolants every 8x8 pixel block. That's a very small cost for added precision. I could do something similar for the current scanline-based rasterizer, but I don't think it's worth bothering about that now. I'm really busy implementing optimizations for SoftWire...
My new rasterizer won't have this problem, since it recomputes the accurate interpolants every 8x8 pixel block. That's a very small cost for added precision. I could do something similar for the current scanline-based rasterizer, but I don't think it's worth bothering about that now. I'm really busy implementing optimizations for SoftWire...
Unfortunately, no. First priority is the SoftWire optimizations. Copy propagation, load and spill elimination. You can read more about it here: Copy propagation without allocating registers. Will take some extra days to get it implemented correctly.Scali said:
After that I can generate code dynamically using C++ syntax. That will be extremely useful for writing new fixed-function pipelines, shader compilers, rasterizers and clippers. All in a fraction of the time it usually took me to implement new things. The optimizer will make sure that performance will be just as optimal, or even better, than the assembly implementations.
I expect these things to be completely done in two months. After that I can fully concentrate again on the DirectX interface...
