Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

A bug in the code is worth two in the documentation.


programming / comp.lang.asm.x86 / Line clipping w. Cohen-Sutherland - causes more work & time instead of less ?

SubjectAuthor
* Line clipping w. Cohen-Sutherland - causes more work & time instead ofR.Wieser
`* Re: Line clipping w. Cohen-Sutherland - causes more work & timeTerje Mathisen
 `* Re: Line clipping w. Cohen-Sutherland - causes more work & timeR.Wieser
  +* Re: Line clipping w. Cohen-Sutherland - causes more work & timewolfgang kern
  |`* Re: Line clipping w. Cohen-Sutherland - causes more work & timeR.Wieser
  | `* Re: Line clipping w. Cohen-Sutherland - causes more work & timewolfgang kern
  |  `- Re: Line clipping w. Cohen-Sutherland - causes more work & timeR.Wieser
  `* Re: Line clipping w. Cohen-Sutherland - causes more work & timeTerje Mathisen
   `- Re: Line clipping w. Cohen-Sutherland - causes more work & timeR.Wieser

1
Subject: Line clipping w. Cohen-Sutherland - causes more work & time instead of less ?
From: R.Wieser
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Thu, 8 Oct 2020 16:37 UTC
Path: i2pn2.org!i2pn.org!news.swapon.de!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: addr...@nospicedham.not.available (R.Wieser)
Newsgroups: comp.lang.asm.x86
Subject: Line clipping w. Cohen-Sutherland - causes more work & time instead of less ?
Date: Thu, 8 Oct 2020 18:37:11 +0200
Organization: Aioe.org NNTP Server
Lines: 66
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rlnf80$kvp$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="499a86c47ac7906ad060ec4d92f29921";
logging-data="27148"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18f0Kp+kxYnHVUCLmohpfSE2WP2oFsdJFE="
Cancel-Lock: sha1:f05PvhsWkwtMaggwT6zCL55g6ZI=
View all headers
Hello all,

I need someone to eyeball what I think I've found, and tell me where I went
hopelesly off-track.  At least, I think I must have, as several
implementations and/or examples of the Cohen-Sutherland algoritm all seem to
do the exact same thing - which is different from what I ended up with.


The Cohen-Sutherland algorithm is explained here :

http://www.cc.gatech.edu/grads/h/Hao-wei.Hsieh/Haowei.Hsieh/mm.html

with its pseudo-code(?) implementation here :

https://www.cc.gatech.edu/grads/h/Hao-wei.Hsieh/Haowei.Hsieh/code1.html


While implementing it for a 16-bit DOS environment (and having problems
understanding what exactly should be happening in the
"CohenSutherlandLineClipAndDraw"s "main" block) I suddenly realized that the
"CompOutCode" function (to determine the "zone" a coordinate is in) gets
called each time a lines clipping is actually done - which can happen upto
four times.

Like when a line is drawn from the lower part of the top-left zone to the
upper part of the bottom-right zone (it would pass, in order, the top, left,
bottom and right boundaries)

https://www.cc.gatech.edu/grads/h/Hao-wei.Hsieh/Haowei.Hsieh/pic1.gif

Thats 16 comparisions and associated bitmask settings - which I think are
unnneeded.


Replacing a line like "if TOP in outcodeOut then" with a simple
coordinate-against-boundary check (like "if y1 < TOP then") does away with
having to call "CompOutCode".

Also, I do not see any reason to loop thru those checks until a zero "zone"
mask is generated - a simple checking for all four boundaries in (no
particular) order looks to be enough ...


IOW, my current program first does an "if (x1 <left and x2 < left) or (..."
check to determine a "trivial discarding" of a line, and if not continues to
clip the first coordinate against all boundaries in succession ( "if x1 <
left {update x1,y1}; if x1 > right {update x1,y1}; if y1 < bottom {update
x1,y1}; if y1 > top {update x1,y1};" ), than swaps the coordinates and does
it again so the enpoint is clipped too.

tl;dr:
Can someone explain to me how the Cohen-Sutherland algoritm speeds up and/or
simplifies basic line clipping ?

Regards,
Rudy Wieser

P.s.
A few of the webpages effectivily all doing the same thing :
https://en.wikipedia.org/wiki/Cohen%E2%80%93Sutherland_algorithm
https://www.geeksforgeeks.org/line-clipping-set-1-cohen-sutherland-algorithm/
https://iq.opengenus.org/cohen-sutherland-line-clipping-algorithm/
https://sighack.com/post/cohen-sutherland-line-clipping-algorithm





Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
From: Terje Mathisen
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Thu, 8 Oct 2020 19:52 UTC
References: 1
Path: i2pn2.org!i2pn.org!news.swapon.de!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: terje.ma...@nospicedham.tmsw.no (Terje Mathisen)
Newsgroups: comp.lang.asm.x86
Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
Date: Thu, 8 Oct 2020 21:52:47 +0200
Organization: Aioe.org NNTP Server
Lines: 96
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rlnqm8$1i8$1@gioia.aioe.org>
References: <rlnf80$kvp$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="499a86c47ac7906ad060ec4d92f29921";
logging-data="14680"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/BBUui6QJTk1YRyh10qViVDiPL1C4L2IY="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.4
Cancel-Lock: sha1:96T1bYuN08dVq3HQZPcrbEj+0TA=
View all headers
I never studied or read up on any textbook algorithms for line clipping against a frustrum, but in my own code I had the special case that frustrum would always be rectangular with aligned vertical/horizontal edges, so the code was simple enough:

Check left vertical edge, if the x coordinates cross it, clip
Check right vertical edge, ditto
Check bottom horizontal edge, clip if needed
Check top edge, ditto.

An alternative is to classify each coordinate into one of 9 bins, and then use the resulting product for classify(x0,y0)*classify(x1,y1) to very quickly detect both all inside and most of the discard cases, i.e. both end points either above or below, left or right of the clipping (visible) area.

For the remaining cases apply the parts of the first algorithm that makes sense for each case, i.e. only the full diagonals (from 0 to 8 or 2 to 6) need all the clipping operations, and at that point there is no need to re-calculate the bin number.

Terje

R.Wieser wrote:
Hello all,

I need someone to eyeball what I think I've found, and tell me where I went
hopelesly off-track.  At least, I think I must have, as several
implementations and/or examples of the Cohen-Sutherland algoritm all seem to
do the exact same thing - which is different from what I ended up with.


The Cohen-Sutherland algorithm is explained here :

http://www.cc.gatech.edu/grads/h/Hao-wei.Hsieh/Haowei.Hsieh/mm.html

with its pseudo-code(?) implementation here :

https://www.cc.gatech.edu/grads/h/Hao-wei.Hsieh/Haowei.Hsieh/code1.html


While implementing it for a 16-bit DOS environment (and having problems
understanding what exactly should be happening in the
"CohenSutherlandLineClipAndDraw"s "main" block) I suddenly realized that the
"CompOutCode" function (to determine the "zone" a coordinate is in) gets
called each time a lines clipping is actually done - which can happen upto
four times.

Like when a line is drawn from the lower part of the top-left zone to the
upper part of the bottom-right zone (it would pass, in order, the top, left,
bottom and right boundaries)

https://www.cc.gatech.edu/grads/h/Hao-wei.Hsieh/Haowei.Hsieh/pic1.gif

Thats 16 comparisions and associated bitmask settings - which I think are
unnneeded.


Replacing a line like "if TOP in outcodeOut then" with a simple
coordinate-against-boundary check (like "if y1 < TOP then") does away with
having to call "CompOutCode".

Also, I do not see any reason to loop thru those checks until a zero "zone"
mask is generated - a simple checking for all four boundaries in (no
particular) order looks to be enough ...


IOW, my current program first does an "if (x1 <left and x2 < left) or (..."
check to determine a "trivial discarding" of a line, and if not continues to
clip the first coordinate against all boundaries in succession ( "if x1 <
left {update x1,y1}; if x1 > right {update x1,y1}; if y1 < bottom {update
x1,y1}; if y1 > top {update x1,y1};" ), than swaps the coordinates and does
it again so the enpoint is clipped too.

tl;dr:
Can someone explain to me how the Cohen-Sutherland algoritm speeds up and/or
simplifies basic line clipping ?

Regards,
Rudy Wieser

P.s.
A few of the webpages effectivily all doing the same thing :
https://en.wikipedia.org/wiki/Cohen%E2%80%93Sutherland_algorithm
https://www.geeksforgeeks.org/line-clipping-set-1-cohen-sutherland-algorithm/
https://iq.opengenus.org/cohen-sutherland-line-clipping-algorithm/
https://sighack.com/post/cohen-sutherland-line-clipping-algorithm





--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
From: R.Wieser
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Fri, 9 Oct 2020 07:53 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!news.swapon.de!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: addr...@nospicedham.not.available (R.Wieser)
Newsgroups: comp.lang.asm.x86
Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
Date: Fri, 9 Oct 2020 09:53:33 +0200
Organization: Aioe.org NNTP Server
Lines: 46
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rlp4u7$bp0$1@gioia.aioe.org>
References: <rlnf80$kvp$1@gioia.aioe.org> <rlnqm8$1i8$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="0fcd6347c956a003ba32d3281a2ccd7a";
logging-data="6042"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+bjcfX4SECiDLEnQLwS4ykWhZWE5/GXDE="
Cancel-Lock: sha1:7hQJJL7CkA3hY81IJ9BnumjzGUA=
View all headers
Terje,

but in my own code I had the special case that frustrum would always be
rectangular

Thats what I'm having.

so the code was simple enough:
[snip]

Which is pretty-much what I ended up with too.

An alternative is to classify each coordinate into one of 9 bins,

And thats pretty-much the problem : what does it give that a simple "if (x1
< Left and x2 < Left) or (x1 > Right and ....") comparision doesn't provide.

For the remaining cases apply the parts of the first algorithm that makes
sense for each case, i.e. only the full diagonals (from 0 to 8 or 2 to 6)
need all the clipping operations

So, trying to skip certain checks depending on which zones the start and
endpoints are in ?   AFAICS that won't work, as the exact clipping action is
dependant on where, in those corner zones, the start and endpoints are.

Assuming a diagonal line than if it starts above the clipwindow diagonal the
top-boundary clip should be taken.  If it starts below the diagonal the
left-boundary should be taken.    It gets complicated when a line is not at
a diagonal angle, or when only the start or endpoints are in those corner
zones ...

I have got zero proof, but somehow I get the feeling that such checks could
easily become more expensive than a duplicated clipping or two.


tl;dr:
The thing is that the Cohen-Sutherland algorithm seems to make the whole
thing more complicated (and costly in the sense of total instructions - even
in pseudo-code) than what you and I ended up with. And that does not make
any sense.  As such I came to the conclusion I must be missing something in
that algorithm.  The question is, what ?

Regards,
Rudy Wieser




Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
From: wolfgang kern
Newsgroups: comp.lang.asm.x86
Organization: KESYS-development
Date: Fri, 9 Oct 2020 10:34 UTC
References: 1 2 3
Path: i2pn2.org!i2pn.org!news.swapon.de!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: nowh...@nospicedham.never.at (wolfgang kern)
Newsgroups: comp.lang.asm.x86
Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
Date: Fri, 9 Oct 2020 12:34:51 +0200
Organization: KESYS-development
Lines: 15
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rlpeho$rbs$1@gioia.aioe.org>
References: <rlnf80$kvp$1@gioia.aioe.org> <rlnqm8$1i8$1@gioia.aioe.org>
<rlp4u7$bp0$1@gioia.aioe.org>
Reply-To: nowhere@never.at
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="0fcd6347c956a003ba32d3281a2ccd7a";
logging-data="17825"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19u0M4O2XAj9+AQIO9eC/OR4KpNasSzXsM="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.3.1
Cancel-Lock: sha1:Fl560SiV6yemPWTu6VZCDOJjvFI=
View all headers
On 09.10.2020 09:53, R.Wieser wrote:
[...]
The thing is that the Cohen-Sutherland algorithm seems to make the whole
thing more complicated (and costly in the sense of total instructions - even
in pseudo-code) than what you and I ended up with. And that does not make
any sense.  As such I came to the conclusion I must be missing something in
that algorithm.  The question is, what ?

cannot see any sense in it either, perhaps just to explain what clipping is to non-aware folks.
my clip is in the final dot-drawer, so what's outside become ignored but may delay the whole story.
__
wolfgang



Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
From: R.Wieser
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Fri, 9 Oct 2020 11:16 UTC
References: 1 2 3 4
Path: i2pn2.org!i2pn.org!news.swapon.de!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: addr...@nospicedham.not.available (R.Wieser)
Newsgroups: comp.lang.asm.x86
Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
Date: Fri, 9 Oct 2020 13:16:12 +0200
Organization: Aioe.org NNTP Server
Lines: 20
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rlpgq4$1u83$1@gioia.aioe.org>
References: <rlnf80$kvp$1@gioia.aioe.org> <rlnqm8$1i8$1@gioia.aioe.org> <rlp4u7$bp0$1@gioia.aioe.org> <rlpeho$rbs$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="0fcd6347c956a003ba32d3281a2ccd7a";
logging-data="9175"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+2jYQvSyO1DmKD7TnLE4xtd82rZkayFNU="
Cancel-Lock: sha1:mPVVqggBx29eB/MyJo60xqVfd0M=
View all headers
Wolfgang,

cannot see any sense in it either, perhaps just to explain what clipping
is to non-aware folks.

Understanding what clipping is was the easy part.

my clip is in the final dot-drawer, so what's outside become ignored but
may delay the whole story.

Thats what I've beein doing too.   But at some point I saw sense in not
going thru slews of dots that are not going to be displayed anyway, likely
speeding up the drawing process itself.    Especially as I wanted to be able
to draw in a full 16-bit signed int range, while only actually viewing a
small part of it.

Regards,
Rudy Wieser




Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
From: Terje Mathisen
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Fri, 9 Oct 2020 13:01 UTC
References: 1 2 3
Path: i2pn2.org!i2pn.org!news.swapon.de!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: terje.ma...@nospicedham.tmsw.no (Terje Mathisen)
Newsgroups: comp.lang.asm.x86
Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
Date: Fri, 9 Oct 2020 15:01:10 +0200
Organization: Aioe.org NNTP Server
Lines: 75
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rlpmua$pnb$1@gioia.aioe.org>
References: <rlnf80$kvp$1@gioia.aioe.org> <rlnqm8$1i8$1@gioia.aioe.org>
<rlp4u7$bp0$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="0fcd6347c956a003ba32d3281a2ccd7a";
logging-data="1506"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18OyyQnWXmpEJpdTY3wMnnsgoKncc3VUMo="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.4
Cancel-Lock: sha1:Cfqg+wlefhZ0EtjZfIwRV6lDIq4=
View all headers
R.Wieser wrote:
Terje,

but in my own code I had the special case that frustrum would always be
rectangular

Thats what I'm having.

so the code was simple enough:
[snip]

Which is pretty-much what I ended up with too.

An alternative is to classify each coordinate into one of 9 bins,

And thats pretty-much the problem : what does it give that a simple "if (x1
< Left and x2 < Left) or (x1 > Right and ....") comparision doesn't provide.

One key issue is that you can generate all those classifications in parallel, so it could all be done in a cycle or two, replacing a bunch of distributed/replicated if (a <= b) tests.

For the remaining cases apply the parts of the first algorithm that makes
sense for each case, i.e. only the full diagonals (from 0 to 8 or 2 to 6)
need all the clipping operations

So, trying to skip certain checks depending on which zones the start and
endpoints are in ?   AFAICS that won't work, as the exact clipping action is
dependant on where, in those corner zones, the start and endpoints are.

Absolutely right, but it still helps: If we number the zones from 0 to 8, top left to bottom right, and neither end point is in the first (0..2) row, then we can skip all clip tests against the top of the frustrum. Similarly with any other side of the target zone.

When both end points are in the same row or column we get to either trivially discard, or limit clipping to one dimension.

Assuming a diagonal line than if it starts above the clipwindow diagonal the
top-boundary clip should be taken.  If it starts below the diagonal the
left-boundary should be taken.    It gets complicated when a line is not at
a diagonal angle, or when only the start or endpoints are in those corner
zones ...

I believe my own code ignores the order clips should occur in, i.e. a diagonal line passing the top and right boundaries can be clipped against those two lines in arbitrary order and still come out correct, we don't need to figure out up front if anything will be visible or not.

I have got zero proof, but somehow I get the feeling that such checks could
easily become more expensive than a duplicated clipping or two.

I agree.


tl;dr:
The thing is that the Cohen-Sutherland algorithm seems to make the whole
thing more complicated (and costly in the sense of total instructions - even
in pseudo-code) than what you and I ended up with. And that does not make
any sense.  As such I came to the conclusion I must be missing something in
that algorithm.  The question is, what ?

I'm assuming this was intended for HW implementation where it is easy to have enough parallel resources to perform all those operations more or less at the same time.

With modern SIMD hardware we also want as many of the comparisons to happen at the same time as we can manage.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
From: R.Wieser
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Fri, 9 Oct 2020 16:36 UTC
References: 1 2 3 4
Path: i2pn2.org!i2pn.org!news.swapon.de!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: addr...@nospicedham.not.available (R.Wieser)
Newsgroups: comp.lang.asm.x86
Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
Date: Fri, 9 Oct 2020 18:36:33 +0200
Organization: Aioe.org NNTP Server
Lines: 56
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rlq3ik$11pf$1@gioia.aioe.org>
References: <rlnf80$kvp$1@gioia.aioe.org> <rlnqm8$1i8$1@gioia.aioe.org> <rlp4u7$bp0$1@gioia.aioe.org> <rlpmua$pnb$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="0fcd6347c956a003ba32d3281a2ccd7a";
logging-data="30146"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+MdPjZp7wLyv0SZNV2GNUtwXgDkegdtAU="
Cancel-Lock: sha1:j0aKmxhj1uL4e/odyDjcqGbTg4g=
View all headers
Terje,

One key issue is that you can generate all those classifications in
parallel, so it could all be done in a cycle or two, replacing a bunch of
distributed/replicated if (a <= b) tests.

I did not think of that, but that is indeed a case in which it could/would
matter (clipping both endpoints in parallel would than be another big
speed-up).

I do not see anything in/to the algorithm about such an intention though.
Also, AFAIC most environments upto rather recently where single-core (and
the algorithm was created back in 1967).

Absolutely right, but it still helps: If we number the zones from 0 to 8,
top left to bottom right, and neither end point is in the first (0..2)
row, then we can skip all clip tests against the top of the frustrum.

Yes, thats the method used in the pseudo-code.   I don't think that that
bit-test will be much, if any shorter than the comparision of two values
though (assuming that the coordinates fit in the processors registers) .

In short, only the first creation of that zone bitmask (instead of four
times two coordinate-against-boundary comparisions) seem to weigh positivily
against the total time spend.  In the other cases a comparision of two
values could well be shorter than a regeneration of that zone bitmask and
the subsequently needed bit-test.

Hmm... Just thought of using the gathered zone bits as an index in a
jumptable to different boundary-compare sequences. As you said, a line which
starts in zone 0 (and is not trivially rejected) only needs to compare with
the top and left boundaries.     On the other hand, thats a lot of
duplicated code just to remove (the opposite) two boundary checks ....

I believe my own code ignores the order clips should occur in

So does mine.  And as you said, it works ok that way (test have not shown
any glaring problems with it).

I'm assuming this was intended for HW implementation where it is easy to
have enough parallel resources to perform all those operations more or
less at the same time.

Yes, thats is an explanation that makes sense.  Thanks for that.   I thought
I was going mad here. :-|

With modern SIMD hardware we also want as many of the
comparisons to happen at the same time as we can manage.

With modern hardware there is a good chance I can just tell the GPU what I
want to have happen and than leave the rest upto it. :-)

Regards,
Rudy Wieser




Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
From: wolfgang kern
Newsgroups: comp.lang.asm.x86
Organization: KESYS-development
Date: Sat, 10 Oct 2020 10:16 UTC
References: 1 2 3 4 5
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: nowh...@nospicedham.never.at (wolfgang kern)
Newsgroups: comp.lang.asm.x86
Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
Date: Sat, 10 Oct 2020 12:16:35 +0200
Organization: KESYS-development
Lines: 23
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rls1rh$fg4$1@gioia.aioe.org>
References: <rlnf80$kvp$1@gioia.aioe.org> <rlnqm8$1i8$1@gioia.aioe.org>
<rlp4u7$bp0$1@gioia.aioe.org> <rlpeho$rbs$1@gioia.aioe.org>
<rlpgq4$1u83$1@gioia.aioe.org>
Reply-To: nowhere@never.at
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="9911126c7f410ee7624ae2f5da90d4e7";
logging-data="3864"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/OKz9emaQhmK2vZRk5XAE8iziZ3kBH+R4="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.3.1
Cancel-Lock: sha1:mYftfHDdZrLmKwTkE631e6pDRO0=
View all headers
On 09.10.2020 13:16, R.Wieser wrote:
Wolfgang,

cannot see any sense in it either, perhaps just to explain what clipping
is to non-aware folks.

Understanding what clipping is was the easy part.

my clip is in the final dot-drawer, so what's outside become ignored but
may delay the whole story.

Thats what I've beein doing too.   But at some point I saw sense in not
going thru slews of dots that are not going to be displayed anyway, likely
speeding up the drawing process itself.    Especially as I wanted to be able
to draw in a full 16-bit signed int range, while only actually viewing a
small part of it.

Yes, me too once tried to gain speed by clipping before the draw, but the additional checks took more time than a few not written dots.
My draw functions use 16 bit unsigned (left,top screen == 0,0).
__
wolfgang



Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
From: R.Wieser
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Sat, 10 Oct 2020 14:47 UTC
References: 1 2 3 4 5 6
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: addr...@nospicedham.not.available (R.Wieser)
Newsgroups: comp.lang.asm.x86
Subject: Re: Line clipping w. Cohen-Sutherland - causes more work & time
Date: Sat, 10 Oct 2020 16:47:01 +0200
Organization: Aioe.org NNTP Server
Lines: 13
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rlshhc$11ae$1@gioia.aioe.org>
References: <rlnf80$kvp$1@gioia.aioe.org> <rlnqm8$1i8$1@gioia.aioe.org> <rlp4u7$bp0$1@gioia.aioe.org> <rlpeho$rbs$1@gioia.aioe.org> <rlpgq4$1u83$1@gioia.aioe.org> <rls1rh$fg4$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="9911126c7f410ee7624ae2f5da90d4e7";
logging-data="12739"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+mOXdjjg54wzqv8CKlxzfKOX8aShgraE0="
Cancel-Lock: sha1:Q725Pf9ToHIGOeeJ8hBwZRApaOY=
View all headers
Wolfgang,

My draw functions use 16 bit unsigned (left,top screen == 0,0).

In hindsight I should maybe have done that too, as mixing signed and
unsigned values together (coordinates and distances between them) (while
staying within the 16-bit realm of instructions) took me a while to wrap my
head round.

Regards,
Rudy Wieser




1
rocksolid light 0.7.2
clearneti2ptor