podstawą moich procedur okienkowania okregi u jego wycinka
jest ustalenie pozycji krawędzi okna względem 2 ćwiartek do strony danej krawędzi
wtedy mam 4 zmienne decyzyjne i stanach
>=r, >=0, <0,

to pozwala na szybką pełną akceptacje okregu lub szybkie odrzucenie
i kontynuacje dalszych obliczeń w innym przypadku
początkowo porównuję kwadraty długości co skraca czas, bo nie chce liczyć sqrt
gdy to nie jest konieczne jednak póżniej z tego co pamiętam musiałem użyć srt
aby mieć mozliwość porównania drugiej współrzednej z innym zakresem dla danej
ćwiartki.

generalnie okienkowanie okregu mozna sprowadzic do kilku etapow
1 wyznaczenie zmiennych decycyjnych i szybkie pelne odrzucenie lub plena akceptacja,
2 w przypadku bardziej skaplikowanym obliczenie koniecznych punktów przeciecia
3 rysowanie kazdej cwiartki z osobna, poprzedzajace wyznaczeniem dla niej zmiennych
bedacych start, stop dla 2 prodedur midpoint, 2 procedury bo cwiartka ma 2 oktety.

pamietam ze mialem trudnosci aby za pomoca kwadratow dxp / dyp
porownywac zakresy ograniczajace dana cwiartke
aby pozniej za pomoca takich porownac wywolac odpowiednio procedure midpointa,
dlatego tez uzylem sqrt,
co sugerowala chyba ksiazka Foleya, w punkcie omawiajacym okienkowanie okregu za
pomoca prostokata

w przyppadku wycinku okregu czy koła
zastosowalem podobne podejscie ale z racji ze to wycinek musiało być one nieco
bardziej skaplikowane
1 i 2 punkt to samo jw.
3 wyznaczenie odpowiednich cwiartek obejmujacych zakres luku
4 rysowanie 1 lub 2 oktetow dla danej cwiatki podobnie jak wyzej pkt 3

do góry

>
> Przeskalować przed rysowaniem?
>
>
> Pozdrawiam

co i jak przeskalować ?

użyć wiekszego przyrostu w iteracji midpoint po za ekranem w zależnosci od r ?

do góry

On Saturday, October 10, 2015 at 7:56:33 PM UTC+2, Radoslaw Jocz wrote:
> >
> > Przeskalować przed rysowaniem?
> >
> >
> > Pozdrawiam
>
> co i jak przeskalować ?
>
> użyć wiekszego przyrostu w iteracji midpoint po za ekranem w zależnosci od r ?

Czemu iterujesz po rozmiarze obiektów a nie po pikselach monitora?

for( x=0 ; x<width ; x++ ) {
for( y=0 ; y<height ; y++ ) {
rgb = daj_kolr( zbior_obiektow_graficznych() );
set_pixel( x , y , rgb );
}}

Nigdy nie może być więcej iteracji niż width * height.

daj_rgb_kola( x , y , kolo , skala , offset_x, offset_y, etc ) {
return ( liczysz_kolor );
}

Nie rozumiem co to za miliony iteracji dla jednego obiektu.

Pozdrawiam

do góry

On Saturday, 10 October 2015 19:07:12 UTC+1, M.M. wrote:
> On Saturday, October 10, 2015 at 7:56:33 PM UTC+2, Radoslaw Jocz wrote:
> > >
> > > Przeskalować przed rysowaniem?
> > >
> > >
> > > Pozdrawiam
> >
> > co i jak przeskalować ?
> >
> > użyć wiekszego przyrostu w iteracji midpoint po za ekranem w zależnosci od r ?
>
> Czemu iterujesz po rozmiarze obiektów a nie po pikselach monitora?
>
> for( x=0 ; x<width ; x++ ) {
> for( y=0 ; y<height ; y++ ) {
> rgb = daj_kolr( zbior_obiektow_graficznych() );
> set_pixel( x , y , rgb );
> }}
>
> Nigdy nie może być więcej iteracji niż width * height.
>
> daj_rgb_kola( x , y , kolo , skala , offset_x, offset_y, etc ) {
> return ( liczysz_kolor );
> }
>
> Nie rozumiem co to za miliony iteracji dla jednego obiektu.
>
> Pozdrawiam

to jest ciekawe podejscie ale znacznie wolniejsze od mojego ktore obecnie stosuję,

zastanawialem sie przed chwilą ze mogłbym przeanalizowac takie podejscie

1. opisac kwadratem okrag wtedy mamy maksymalne zakresy +-dx, +-dy
2. cześć wspolna kwadrat z oknem - prostakatem.

uruchomic midpoint tylko w tych przedzialach ale z odbiciami aby nie bylo tych
niekorzystnych 1 pikselowych przesuniec w ramach jednego okregu

byc moze bylo by to rozwiazanie,
poczatek juz mam bo moja procedura sie do tego samego sprowadza,

innymi słowy trzeba by ustalic wystarczajacy zakres procedury midpoint potrzebny do
narysowania okregu,
wystarczacy to nie znaczy minimalny optymalny
wtedy za pomoca 1 procedury mozna wykorzystac odbicia oraz sprawdzic zakres luku w
przydpadku wycinka

do góry

> Nie rozumiem co to za miliony iteracji dla jednego obiektu.
>
> Pozdrawiam

w przypadku orginalnego algorytmu midpoint iterowana jest 1/8 obwodu okregu
gdy np r = 1,000,000
to jest juz sporo iteracji, przy ekranie np 640x480 wiekszosc punktow zostanie
odrzucona ale mimo to bedzie to powolne dla duzych promieni

do góry

On Saturday, October 10, 2015 at 8:38:16 PM UTC+2, Radoslaw Jocz wrote:
> to jest ciekawe podejscie ale znacznie wolniejsze od mojego ktore obecnie stosuję,

Nie wiem co dokładnie robisz, z góry przepraszam, nie mam też czasu
się wczytać w Twój problem. Zwykle przed odrysowaniem czyści się
ekran poprzez wypełnienie każdego pixela jednolitym kolorem. Nie
wiem czy też czyścisz, czy nie, ale jeśli tak, to Twoja metoda wcale
nie jest szybsza.

Pozdrawiam

do góry

> Nie wiem co dokładnie robisz, z góry przepraszam, nie mam też czasu
> się wczytać w Twój problem. Zwykle przed odrysowaniem czyści się
> ekran poprzez wypełnienie każdego pixela jednolitym kolorem. Nie
> wiem czy też czyścisz, czy nie, ale jeśli tak, to Twoja metoda wcale
> nie jest szybsza.
>
> Pozdrawiam


nie musi byc najlepsze czy najszybsze tylko nadajace sie do konkretnego zastosowania,

nie robie animacji tylko wyswietlanie statycznych elementow, dodatkowo jest
zoom i scroll.

poczatkowo zalezalo mi aby funkcja byla szybka i dokladne co do +-1 piksel.
Opracowalem algorytm ktory pozniej zaimplementowalem.
Chcialem to zmodyfikowac bo pojawialy sie niekiedy przesuniecia +-1 piksel
pomiedzy oktetami w ramach tego samego okregu


jak opracuje kolejny lepszy algorytm to napisze tutaj o tym

do góry

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.

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ść.

Zgadujue, ze z tego 'innego' startu bierze się problem
z niedopasowaniem.

pzdr
bartekltg.

do góry

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

>
> 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.


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

mysle za dalo by rade wyprowadzic zmodyfikowana procedcure na intach
aby obslugiwala inny krok niz 1 w celu tylko wszyskiej i poprawnej inicjalizacji
wartosci calkowitych d,x,y dla orginalnego midpointa

do góry

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

do góry