On 11.10.2015 17:28, Radoslaw Jocz wrote:
> On Sunday, 11 October 2015 00:26:12 UTC+1, bartekltg wrote:
>> On 08.10.2015 13:51, Radoslaw Jocz wrote:
>>
>> Tam jest jakaś pomocnicza rzeczywista zmienna (kwadrat odległości
>> piksela minus kwadrat zadanego promienia), od której znaku
>> decydujesz, czy iść po płaskim, czy pod kątem. Uaktualniasz ją w
>> każdym kroku.
>
> tak tez robie.
>
>>
>> Nie da się jej wyliczyć, jaką powinna mieć wartość dla zadanego
>> kąta startowego? Wygląda, jakby się dało. Wtedy możesz zastartować
>> algorytm dla dowolnego kąta, ale jego stan będzie taki sam, jakbyś
>> przeiterował niepotrzebną cześć.
>
> taki sam ale z pewna dokladnoscia, bo przy obliczeniu sqrt to juz sa
> liczby double a nie int czy long wiec w tym problem

W wersji, którą znam, ta pomocnicza zmienna i tak jest double.



>> Zgadujue, ze z tego 'innego' startu bierze się problem z
>> niedopasowaniem.
>>
>> pzdr bartekltg.
>
> tak problem polega na tym ze obliczony jest nowy punkt i w
> konsekwencji sa drobne niedokladnosci przy warunkach poczatkowych dla
> procedury midpoint w ramach 1 oktetu, problemem nie jest sama
> dokladnosc co ta drobna roznica w danych oktetach, problemem moze byc
> dokladnosc obliczonego punktu lub dokladnosc wyliczenia zmiennej d
> jego podstawie itp. moze byc parzystosc lub nieparzystosc promienia
> itp.

Daj konkretny przykład, co (i jak) rysujesz, i gdzie jest
niedokładność.


> moje algortmy (dla okregu i wycinka) sa optymalne w takim sensie ze
> rysuja tylko to co jest konieczne, obliczaja sqrt (maksymalnie 4) ale
> jesli jest to konieczne jest kilka zagniezdzonych sprawdzen aby
> okreslic zakresy dla kazdej z cwiartek i oktetow, oktety sa rysowane
> osobno, (bo zakresy dla nich sa rozne jesli sa one w ogole aktywne) ,
> co w przypadku duzego promienia i tak jest optymalne bo wtedy
> widoczny jest przewaznie tylko 1 lub 2 oktety.
>
> mysle aby sprobowac ustalic gorny i dolny przedzial X (x>=0, x<=y)
> dla midpoint a pierwszy Y obliczyc, taki przedzial byl by
> wystarczajacy dla wszystkich oktetow wtedy byly by rysowane na raz 8
> oktetow kazdy z punktow musial by byc sprawdzany czy jest w oknie czy
> nie, w przypadku wcinka tez czy jest w zakresie katow łuku. to bylo
> by proste i rozwiazywalo by problem o ktorym mowilem przynajmniej w
> zakresie 1 okregu. mozna by jeszcze uzywac zmiennych okreslajacych
> czy w ogole dany oktet jest aktywny czy nie, ale to chyba zbedne

> zastanawialem sie tez nad tym aby rozwinac orginalna procedure
> midpoint tak aby startowac od dowolnego punktu i jednoczesnie uzywac
> licza calkowitych


> mozna by to rozwiazac to w taki sposob aby poczatkowy krok procedury
> nie byl co 1 piksel ale co 10 lub 100, 1000 itd, pozniej gdy jest
> blisko krawedzi okna zmienic krok do 1 rysowac w oknie juz normalnie


Ale po co, skoro dopiero co powiedziałeś, że _potrafisz_ dojść
do krawędzi w jednym ruchu.


pzdr
bartekltg