-
X-Received: by 10.140.23.111 with SMTP id 102mr197533qgo.6.1444577294324; Sun, 11 Oct
2015 08:28:14 -0700 (PDT)
X-Received: by 10.140.23.111 with SMTP id 102mr197533qgo.6.1444577294324; Sun, 11 Oct
2015 08:28:14 -0700 (PDT)
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!news.glorb.com!
kq10no19877688igb.0!news-out.google.com!l36ni52058qgd.1!nntp.google.com!5no5027
55qgg.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: pl.comp.programming
Date: Sun, 11 Oct 2015 08:28:13 -0700 (PDT)
In-Reply-To: <mvc6qj$3nr$1@node1.news.atman.pl>
Complaints-To: g...@g...com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=80.4.98.181;
posting-account=ep55TgoAAAD3FPdT4j2MbhszjClpO1MM
NNTP-Posting-Host: 80.4.98.181
References: <f...@g...com>
<mvc6qj$3nr$1@node1.news.atman.pl>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0...@g...com>
Subject: Re: circle midpoint + windowing, reverse, REAKTYWACJA
From: Radoslaw Jocz <r...@g...com>
Injection-Date: Sun, 11 Oct 2015 15:28:14 +0000
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Xref: news-archive.icm.edu.pl pl.comp.programming:208458
[ ukryj nagłówki ]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
Następne wpisy z tego wątku
- 11.10.15 21:13 bartekltg
- 12.10.15 18:53 M.M.
- 14.10.15 16:11 firr
- 14.10.15 16:20 firr
- 14.10.15 19:40 bartekltg
- 15.10.15 09:26 firr
- 15.10.15 11:11 Radoslaw Jocz
- 15.10.15 11:22 Radoslaw Jocz
- 15.10.15 11:29 Radoslaw Jocz
- 21.10.15 09:42 firr
- 22.10.15 00:36 Radoslaw Jocz
- 22.10.15 17:11 firr
- 22.10.15 23:37 Radoslaw Jocz
Najnowsze wątki z tej grupy
- Alg. kompresji LZW
- Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
Najnowsze wątki
- 2025-02-14 Zdalne załączanie grzałki bojlera elektrycznego
- 2025-02-14 Warszawa => Kierownik ds. kluczowych Klientów <=
- 2025-02-14 Częstochowa => Product Manager - Systemy infrastruktury teleinformaty
- 2025-02-14 Warszawa => Senior Frontend Developer (React + React Native) <=
- 2025-02-14 Warszawa => Data Engineer (Tech Leader) <=
- 2025-02-14 Czy ma sens grupa news:pl.soc.polityka-prawna ? :-)
- 2025-02-14 e-paper
- 2025-02-14 Gliwice => Business Development Manager - Network and Network Security
- 2025-02-14 Warszawa => System Architect (Java background) <=
- 2025-02-14 Katowice => Senior Field Sales (system ERP) <=
- 2025-02-14 Wrocław => Specjalista ds. Sprzedaży (transport drogowy) <=
- 2025-02-14 Re: Dlaczego nie było (pełzającego) zamachu stanu? Bo minister Bodnar już "zawiesił" prokuratora Ostrowskiego
- 2025-02-14 e-paper
- 2025-02-14 Warszawa => Architekt rozwiązań (doświadczenie w obszarze Java, AWS
- 2025-02-14 Warszawa => International Freight Forwarder <=