View Single Post
22 October 2015, 07:07   #36
Code Kitten

Join Date: Aug 2015
Age: 47
Posts: 1,090
To mods: please do not merge my posts, they really have completely different topics. Thanks.

Quote:
Originally Posted by Mrs Beanbag
Quote:
 Originally Posted by ReadOnlyCat The right wall on the image below illustrates pretty nicely the range of possible distortions on a single 16 pixels wide strip depending on Z, X and Y.
Yes i know, but i don't know what is the problem here... maybe there is something you miss.

On each line you distort the previously distorted strip, you don't redraw the entire thing for every line. So as long as you are only "stretching" the columns, each pixel column of the 16-pixel tall strip need move upwards only 0 or 1 pixels.
Holy kangaroo!
I had to let this post of yours mature peacefully for quite some time before it finally made sense when re-reading it today.

I previously understood that you would do 4 blits for each line of the source texture strip, but your plan was to factorize several lines at the same time and re-blit from the destination rather than the original texture strip.

So essentially you would:
1. "sine scroll" an initial block of say 16 rows x 16 lines, with "scroll" parameters defined by Y, Z and theta (angle between view vector and wall).
The whole block is distorted per the parameters computed for the highest Y (lowest projected line on screen).
2. Then starting from the second highest Y (or lower depending on the desired granularity), you re-distort again that same block, but using itself as a source.
With new parameters recomputed for this distortion.
3. Redo step 2 with lower Y until a new block from source is needed at which point go to step 1 (with different parameters though).
Is that what you meant? I am not sure I am explaining it very well.

I think this does indeed make sense. What you would obtain is essentially a function which Y-scales a source texture as a function of (Z, wall-angle).

For a super simple case, with:
- wall texture start coincides with left screen border
- ignoring perspective projection on x for now

You essentially need to compute the smallest set of texture-to-screen and screen-to-screen blits which ends up moving each pixel of the source texture at the proper y positions (because you possibly have to scale up). This for a given Z (distance wall-screen) and theta (angle wall-to-view-direction).

Damn, this might work.
Now, this doesn't obviously deal with x-axis perspective projection but this could indeed could be a very efficient way to Y/Z scale a texture.
I am not too sure if this handles scaling up well though, but at least it deals well with scaling down. Also, this would require mip maps otherwise you would do too many blits for far walls.

Quote:
 Originally Posted by MrsBeanBag In fact we can do better than that, because the stretch is symmetrical (even if the texture is not), so we only need to do half the number of blits really.
It is symmetrical only if the eye is at exactly half the wall's height.
But even then, I am not sure this halves the number of blits? This certainly makes the top-half/bottom-half Y-shifts symmetrical though and thus easy to compute.

Quote:
 Originally Posted by MrsBeanBag And i have thought about how to calculate the masks more efficiently, basically you need to draw lines along the walls onto a buffer, with 1 pixel per x-coordinate. When a set pixel is encountered in the mask image, it shifts the corresponding column of the texture strip upwards.
That I completely do not understand.
Can you try explaining it in a different way?

Last edited by ReadOnlyCat; 22 October 2015 at 07:19. Reason: Rephrased.

Page generated in 0.04158 seconds with 11 queries