Sebastian Biały wrote:
> Ale ja mam taki problem, że przecież odcinek może przeciąć krawędź okna
> w miejscu, które matematycznie wypada _pomiedzy_ pikselami. oznacza to
> że musze teraz zaokraglić w gore lub w dół do najbliższego piksela i z
> tego miejsca rozpocząć rysowanie odcinka standardowymi algorytmami.
>
> No wlasnie: narysowanie odcinka bez obcięcia przebiega przez inne
> piksele niż narysowanie odcinka dociętego do okna. Ze względu na
> zaokraglenia punktów przecięcia do pełnych pikseli.

Tak, jest to podstawowy problem przy tego typu rasteryzacji.

> Czy ktos może wie czy jest jakieś rozsadne rozwiązanie tego problemu?
> Oglądam sobie pare implementacji tu i tam i widzę, że autorzy po prostu
> olewaja ten problem zakładając, że tych drobnych niedokładności i tak
> nikt nie zobaczy.

Potwierdzam, że też w większości implementacji jakie widziałem
błąd pomiędzy matematycznym segmentem/pikselem a faktycznie rysowanym
jest po prostu ignorowany.

> Ale zanim tez przyjme taką koncepcję wole zapytać co
> poczytać i gdzie aby mieć lepszy wgląd w problem.

http://portal.acm.org/citation.cfm?id=607963

oraz podana tam referencja do

Steven Eker, Faster linear interpolation, Graphics gems IV

oraz niepodana do

Steven Eker "Faster Pixel-Perfect Line Clipping" z Graphics gems V

Ten ostatni tekst podaje rozwiązanie dokładnie problemu o który pytasz,
klip linia/prostokąt w miejscy pomiędzy pixelami.

> Tak naprawde wydaje mi się, że powinienem posiadac w tym wypadku
> algorytm Bresenhama ktory startuje nie od piksela tylko z prawidlowo
> ustalonymi przyrostami. Ale nie potrafie znaleźć implementacji tego typu
> więc nie mam pewności czy to prawidłowa droga.

AFAICT, jest prawidłowa, tzn. startujesz z x i określasz y na podstawie
wcześniej wyznaczonego nachylenia.

Pozdrawiam
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org