W dniu sobota, 10 października 2015 18:30:44 UTC+2 użytkownik firr napisał:
> W dniu sobota, 10 października 2015 17:48:51 UTC+2 użytkownik Radoslaw Jocz
napisał:
> > > wszystko jest super proste, po prostu jest to regula na na x dla danego y oraz
r,
> > > cale przyspieszenie wynika z tego ze nie trzeba liczyc pierwiastka wystarczy
porownac
> > > kwadraty (i ew z rozwiniecia tych paru mnozonek i dodawan by zaoszczedzic z
jedno lub ze dwa, juz w to nie che mi sie wczytywac)
> >
> > wiem to doskonale,
> > problem z orginalnym midpointem jest taki ze jest dobry dla pelnych kół,
> > w całości lub w większości wyswietlanych, przec co mają mały promień.
> >
> > wyobraź sobie promien 1,000,000 pikseli w oknie 640x480 czy chcesz iterowac te
miliony niewidocznych punktów ???
> >
> > mia mam zamiaru obliczać sqrt, dla porownan potegi dlugosci wystarcza,
> > I na tym polega midpoint,
> > ponadto zakłada dzialania na intach wiec jest przenosny w 100%
> > problem polega na tym ze ja chce okienkowac koła lub wycinki koła o dużym
promieniu, z maksymalnym błędem +- 1 piksel na całym obwodzie co już dawno mi się
udało,
> >
> > teraz tylko się zastanawiałem czy mogłbym idealnie to rysować co do piksela,
> > oczywiście orginalny midpoint odpada
>
> moze spróbuj napisac midpoint ktory bedzie
> rysowac łuk od punktu A do punktu B, chyba
> nie powinno byc takie trudne - pozniej zostanie wyznaczyc A i B

Ps na grupie zagranicznej (comp.lang.c) padla idea rysowanie tego inaczej - tj wogole
nie midpointem - cos w stylu logo
- bierzesz punk startowy liczysz styczną
( a sytyczna do promienia to cos w stylu
{tx, ty} = {-ry, rx} ) i idziesz po prostu piksel do przodu - trzebaby to przemyslec
ale jest to ogolnie dobra idea, nie ma tych wiadomych problemow na jakie cierpi
midpoint bo jest 'direction-agnostic' - w przypadku malych lukow to moze sie oplacac)