MaxCoderz

For the signed division/multiplication routines to work, it must first fix the sign of the operands so both are positive. The S24S16 division routine divides abc by de, and the negation of de used a.

With this, and a couple of other minor fixes, I get a lot closer:



Still broken, though. :\

If you use collission detection it'd be okay right? Because it seems like it freaks out when you go THROUGH the wall, which you normally can't do in a game anyway.

Sadly, it's not that easy (or that at all). It's worst when you're near a wall, as you noticed, but also goes wonky at odd moments when you can be quite a distance from the wall. :\

Nevertheless, it looks good and it's surprisingly fast imho.

I wouldn't say surprisingly fast, expectedly fast is better

Ben, you mentioned clipping to Y=0 "first", do you clip again?

Actually, the currently rewritten code doesn't bother clipping to Y=0 first, which might be part of the bugginess.

There is a reason to clip to Y=0 first - consider the following:



When performing the clipping, I need to know which boundary - y=+x or y=-x - I need to clip to.
The easiest check is whether the X coordinate of the out-of-bounds point is > 0 or < 0. As you can see with the red and blue lines, this works fine. If you look at the green line, however, the X < 0 but you'd want to clip it as if it was > 0. Therefore, it is neccessary to clip it to Y=0 first, then check the X coordinate and clip to y=+x or y=-x as normal, based on that decision.

(Just thought of one quick optimisation - this extra clip-to-y step is only required if the sign of end[0].x != the sign of end[1].x)

What would the Y=0-clip look like? I guess it would be cheaper than the origin-test (1 mul compared to 2 ?), since the line is to be clipped anyway.

Have another screenshot - I stuck the 'check for Y < 0' code back in, tidied up a few things and optimised a few silly repeated calculations...



Note that when I walk through a wall now, rather than have a few frames of dancing junk lines, you (fairly) smoothly 'snap' through to the other side.

Here are the formulae I currently use.

I derived them by lots of scribbling and fudging the equation of a line 'y = mx + c'. They're as simple as I can make them.
m is held as signed 8.8 fixed-point value. c is held as a signed 16.8 fixed-point value.
The following hold for when the difference in X is greater than the difference in Y.

m = (Y1 - Y0) ÷ (X0 - X1) ; m is negative gradient.
c = Y0 + m Ãâ€â€

Good stuff, one of the more "inspiring" threads around here lately

Thanks. Did you ever get much done with converting your variable-height raycaster to Z80 assembly?

Something I didn't mention - in the screenshot above, sometimes there are two little dots in the left/right most column. This seems to be a bug where completely off-screen walls are clipped but both to the left or right side, rather than being discarded completely.

Only problem now is when the camera is directly 'inside' a wall, but seeing as clipping (in the collision detection sense) would stop that it isn't much of a concern.

Niiiiiiiice ben! I dont really see any problems at all. Will you be implementing some kind of line removal?

With any luck, yes. I'll probably start with some ugly brute-force thing (just transform all the walls, sort from back-to-front then draw them all) but it should be enough to start with. Then it's more a case of working out the best way to sort things - possibly BSP tree?

I see you are trying your hands on Vista?

Will you use this for anything besides "for fun" (like a game)?

Not quite, XP Visual Style

As for a game, it depends whether I can get it to be fast enough to be game-worthy. If so, a DOOM-esque shooter would be the obvious step to take.