Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #29479 > unrolled thread

nastepny punkt

Back to article view | Back to pl.comp.programming

Contents

  nastepny punkt fir <profesor.fir@gmail.com> - 2017-03-12 14:46 -0700
    Re: nastepny punkt bartekltg <bartekltg@gmail.com> - 2017-03-12 22:57 +0100
      Re: nastepny punkt fir <profesor.fir@gmail.com> - 2017-03-12 15:23 -0700
        Re: nastepny punkt fir <profesor.fir@gmail.com> - 2017-03-12 15:47 -0700
          Re: nastepny punkt fir <profesor.fir@gmail.com> - 2017-03-12 17:15 -0700
            Re: nastepny punkt bartekltg <bartekltg@gmail.com> - 2017-03-13 12:38 +0100
              Re: nastepny punkt fir <profesor.fir@gmail.com> - 2017-03-13 07:46 -0700
                Re: nastepny punkt fir <profesor.fir@gmail.com> - 2017-03-13 09:09 -0700
                  Re: nastepny punkt fir <profesor.fir@gmail.com> - 2017-03-13 09:50 -0700
                Re: nastepny punkt bartekltg <bartekltg@gmail.com> - 2017-03-13 18:10 +0100
                  Re: nastepny punkt fir <profesor.fir@gmail.com> - 2017-03-13 11:16 -0700
                    Re: nastepny punkt bartekltg <bartekltg@gmail.com> - 2017-03-13 20:30 +0100
                      Re: nastepny punkt fir <profesor.fir@gmail.com> - 2017-03-13 12:42 -0700
                        Re: nastepny punkt bartekltg <bartekltg@gmail.com> - 2017-03-13 22:29 +0100
                          Re: nastepny punkt fir <profesor.fir@gmail.com> - 2017-03-13 14:53 -0700
                            Re: nastepny punkt fir <profesor.fir@gmail.com> - 2017-03-15 08:08 -0700
                          Re: nastepny punkt gof@somewhere.invalid (Adam Wysocki) - 2017-03-14 13:24 +0000

#29479 — nastepny punkt

szukam dosyc prostego algorytmu 

mam punkt int x,y np 0,0
i chce znalezc nastepny punkt 
w kierunku jakiegos dowolnego punktu
int dist_x, dist_y, tak jak gdybym 
rysowal linie prostą

jak wzynaczyc ten przylegly punkt?

[toc] | [next] | [standalone]

#29480

On 12.03.2017 22:46, fir wrote:
> szukam dosyc prostego algorytmu
>
> mam punkt int x,y np 0,0
> i chce znalezc nastepny punkt
> w kierunku jakiegos dowolnego punktu
> int dist_x, dist_y, tak jak gdybym
> rysowal linie prostą
>
> jak wzynaczyc ten przylegly punkt?
>

Algorytm Bresenhama

pzdr
bartekltg

[toc] | [prev] | [next] | [standalone]

#29481

W dniu niedziela, 12 marca 2017 22:57:05 UTC+1 użytkownik bartekltg napisał:
> On 12.03.2017 22:46, fir wrote:
> > szukam dosyc prostego algorytmu
> >
> > mam punkt int x,y np 0,0
> > i chce znalezc nastepny punkt
> > w kierunku jakiegos dowolnego punktu
> > int dist_x, dist_y, tak jak gdybym
> > rysowal linie prostą
> >
> > jak wzynaczyc ten przylegly punkt?
> >
> 
> Algorytm Bresenhama
> 
raczej fragment bressenhama ale jaki
dokladnie?

[toc] | [prev] | [next] | [standalone]

#29482

W dniu niedziela, 12 marca 2017 23:23:35 UTC+1 użytkownik fir napisał:
> W dniu niedziela, 12 marca 2017 22:57:05 UTC+1 użytkownik bartekltg napisał:
> > On 12.03.2017 22:46, fir wrote:
> > > szukam dosyc prostego algorytmu
> > >
> > > mam punkt int x,y np 0,0
> > > i chce znalezc nastepny punkt
> > > w kierunku jakiegos dowolnego punktu
> > > int dist_x, dist_y, tak jak gdybym
> > > rysowal linie prostą
> > >
> > > jak wzynaczyc ten przylegly punkt?
> > >
> > 
> > Algorytm Bresenhama
> > 
> raczej fragment bressenhama ale jaki
> dokladnie?

w sumie to chyba bedzie cos takiego

int2 NextPointTowards(int x, int y, int dest_x, int dest_y)
{
  int2 n = {x, y};

  int dx = dest_x - x;
  int dy = dest_y - y;

  int sx = sign(dx);
  int sy = sign(dy);

       if(sx==0) n.y += sy;
  else if(sy==0) n.x += sx;
  else
  {
   float m = fabs(((float)dy)/dx);

        if( m < 0.5)   n.x += sx;
   else if( m > 2.0)   n.y += sy;
   else   { n.x += sx; n.y += sy; }
 }

 return n;

}

mozna by wywalic dzielenie zastepujac ifem ale nie wiedomo czy if szybszy

pozatym w dzialaniu to chyba nie zastpi bresenhama (trzebby sprawdzic) choc mw o to mi chodzi bo taka procedura jest jaby bardziej ogolna

[toc] | [prev] | [next] | [standalone]

#29483

W dniu niedziela, 12 marca 2017 23:47:04 UTC+1 użytkownik fir napisał:
> W dniu niedziela, 12 marca 2017 23:23:35 UTC+1 użytkownik fir napisał:
> > W dniu niedziela, 12 marca 2017 22:57:05 UTC+1 użytkownik bartekltg napisał:
> > > On 12.03.2017 22:46, fir wrote:
> > > > szukam dosyc prostego algorytmu
> > > >
> > > > mam punkt int x,y np 0,0
> > > > i chce znalezc nastepny punkt
> > > > w kierunku jakiegos dowolnego punktu
> > > > int dist_x, dist_y, tak jak gdybym
> > > > rysowal linie prostą
> > > >
> > > > jak wzynaczyc ten przylegly punkt?
> > > >
> > > 
> > > Algorytm Bresenhama
> > > 
> > raczej fragment bressenhama ale jaki
> > dokladnie?
> 
> w sumie to chyba bedzie cos takiego
> 
> int2 NextPointTowards(int x, int y, int dest_x, int dest_y)
> {
>   int2 n = {x, y};
> 
>   int dx = dest_x - x;
>   int dy = dest_y - y;
> 
>   int sx = sign(dx);
>   int sy = sign(dy);
> 
>        if(sx==0) n.y += sy;
>   else if(sy==0) n.x += sx;
>   else
>   {
>    float m = fabs(((float)dy)/dx);
> 
>         if( m < 0.5)   n.x += sx;
>    else if( m > 2.0)   n.y += sy;
>    else   { n.x += sx; n.y += sy; }
>  }
> 
>  return n;
> 
> }
> 
> mozna by wywalic dzielenie zastepujac ifem ale nie wiedomo czy if szybszy
> 
> pozatym w dzialaniu to chyba nie zastpi bresenhama (trzebby sprawdzic) choc mw o to mi chodzi bo taka procedura jest jaby bardziej ogolna

zrobilem testy i okazalo sie ze to nie dziala dobrze

http://minddetonator.htw.pl/compact.jpg

gorna linia to normalne a dolna dolna linia to wynik generowania tych punktow
wyzej

teraz pytaine czy da sie to przepisac tak by generowalo porzadna linie (tez biorac za helper tylko punkt docelowy) czy tez trzeba uzyc wersji na floatach

[toc] | [prev] | [next] | [standalone]

#29484

On 13.03.2017 01:15, fir wrote:
> W dniu niedziela, 12 marca 2017 23:47:04 UTC+1 użytkownik fir napisał:
>> W dniu niedziela, 12 marca 2017 23:23:35 UTC+1 użytkownik fir napisał:
>>> W dniu niedziela, 12 marca 2017 22:57:05 UTC+1 użytkownik bartekltg napisał:
>>>> On 12.03.2017 22:46, fir wrote:
>>>>> szukam dosyc prostego algorytmu
>>>>>
>>>>> mam punkt int x,y np 0,0
>>>>> i chce znalezc nastepny punkt
>>>>> w kierunku jakiegos dowolnego punktu
>>>>> int dist_x, dist_y, tak jak gdybym
>>>>> rysowal linie prostą
>>>>>
>>>>> jak wzynaczyc ten przylegly punkt?
>>>>>
>>>>
>>>> Algorytm Bresenhama
>>>>
>>> raczej fragment bressenhama ale jaki

Z testów wygląda, że całego.



>>
>> w sumie to chyba bedzie cos takiego
>>
>> int2 NextPointTowards(int x, int y, int dest_x, int dest_y)
>> {
>>   int2 n = {x, y};
>>
>>   int dx = dest_x - x;
>>   int dy = dest_y - y;
>>
>>   int sx = sign(dx);
>>   int sy = sign(dy);
>>
>>        if(sx==0) n.y += sy;
>>   else if(sy==0) n.x += sx;
>>   else
>>   {
>>    float m = fabs(((float)dy)/dx);

a to da się zrobić bez floatów. Choćby tak:
if ( 2*abs(dx) < abs(dy) )...
else if ( abs(dx) > 2*abs(dy) )...

>>
>>         if( m < 0.5)   n.x += sx;
>>    else if( m > 2.0)   n.y += sy;
>>    else   { n.x += sx; n.y += sy; }
>>  }
>>
>>  return n;
>>
>> }
>>
>> mozna by wywalic dzielenie zastepujac ifem ale nie wiedomo czy if szybszy
>>
>> pozatym w dzialaniu to chyba nie zastpi bresenhama (trzebby sprawdzic) choc mw o to mi chodzi bo taka procedura jest jaby bardziej ogolna
>
> zrobilem testy i okazalo sie ze to nie dziala dobrze

>
> http://minddetonator.htw.pl/compact.jpg
>
> gorna linia to normalne a dolna dolna linia to wynik generowania tych punktow
> wyzej

Nic dziwnego. Ten kod pozwala na wybór jednego z 8 kierunków.
Będzie używał 2 kierunków na zmianę tylko wtedy, gdy jest na ich
granicy.
Efektywnie będzie wiec tworzył proste jedynie w 16 różnych kierunkach.

Aby temu zapobiec, trzeba albo pamiętać linię, po której się porusza
(skomplikowane, niepotrebne i, a do tego jak się domyślam, że śledzony
punkt się porusza:) )
albo pamiętać ułamkową pozycję i robić ideowo jak u Bresenhama.


I teraz pytanie, co tak naprawdę robisz.

Jeśli rysujesz linię,
- Użyj Bresenhama.
- Twoja biblioteka graficzna nie ma rysowania linii? Muis mieć. Niech
ona to zrobi, wtedy karta graficzna narysuje linię, nie procek;-)

Jeśli jets to ludzik goniący za być możę ruchomym punktem,
idea jest ta sama (błąd-korekcja) - ludzik ma pozycję znaną
dokałdniej niż 'ten piksel'. Nie da się sprowadzić do wspolnego 
mianownika jak dla stałej linii, więc albo float (najwygdniej) albo
'stały przecinek', czyli np pozycja z to int z dokłądnosćią do 1/1024
piksela.

BTW, jesli to ludzik i pogoń, to tak, jak to opisałeś, ma jeszcze jedną
wadę. Ruch pionowy i poziomy jest wolniejszy niż po przekątnych
o sqrt(2).

pzdr
bartekltg

[toc] | [prev] | [next] | [standalone]

#29486

W dniu poniedziałek, 13 marca 2017 12:38:15 UTC+1 użytkownik bartekltg napisał:
> On 13.03.2017 01:15, fir wrote:
> > W dniu niedziela, 12 marca 2017 23:47:04 UTC+1 użytkownik fir napisał:
> >> W dniu niedziela, 12 marca 2017 23:23:35 UTC+1 użytkownik fir napisał:
> >>> W dniu niedziela, 12 marca 2017 22:57:05 UTC+1 użytkownik bartekltg napisał:
> >>>> On 12.03.2017 22:46, fir wrote:
> >>>>> szukam dosyc prostego algorytmu
> >>>>>
> >>>>> mam punkt int x,y np 0,0
> >>>>> i chce znalezc nastepny punkt
> >>>>> w kierunku jakiegos dowolnego punktu
> >>>>> int dist_x, dist_y, tak jak gdybym
> >>>>> rysowal linie prostą
> >>>>>
> >>>>> jak wzynaczyc ten przylegly punkt?
> >>>>>
> >>>>
> >>>> Algorytm Bresenhama
> >>>>
> >>> raczej fragment bressenhama ale jaki
> 
> Z testów wygląda, że całego.
> 
> 
> 
> >>
> >> w sumie to chyba bedzie cos takiego
> >>
> >> int2 NextPointTowards(int x, int y, int dest_x, int dest_y)
> >> {
> >>   int2 n = {x, y};
> >>
> >>   int dx = dest_x - x;
> >>   int dy = dest_y - y;
> >>
> >>   int sx = sign(dx);
> >>   int sy = sign(dy);
> >>
> >>        if(sx==0) n.y += sy;
> >>   else if(sy==0) n.x += sx;
> >>   else
> >>   {
> >>    float m = fabs(((float)dy)/dx);
> 
> a to da się zrobić bez floatów. Choćby tak:
> if ( 2*abs(dx) < abs(dy) )...
> else if ( abs(dx) > 2*abs(dy) )...
> 
> >>
> >>         if( m < 0.5)   n.x += sx;
> >>    else if( m > 2.0)   n.y += sy;
> >>    else   { n.x += sx; n.y += sy; }
> >>  }
> >>
> >>  return n;
> >>
> >> }
> >>
> >> mozna by wywalic dzielenie zastepujac ifem ale nie wiedomo czy if szybszy
> >>
> >> pozatym w dzialaniu to chyba nie zastpi bresenhama (trzebby sprawdzic) choc mw o to mi chodzi bo taka procedura jest jaby bardziej ogolna
> >
> > zrobilem testy i okazalo sie ze to nie dziala dobrze
> 
> >
> > http://minddetonator.htw.pl/compact.jpg
> >
> > gorna linia to normalne a dolna dolna linia to wynik generowania tych punktow
> > wyzej
> 
> Nic dziwnego. Ten kod pozwala na wybór jednego z 8 kierunków.
> Będzie używał 2 kierunków na zmianę tylko wtedy, gdy jest na ich
> granicy.
> Efektywnie będzie wiec tworzył proste jedynie w 16 różnych kierunkach.
> 

chyba sluszna uwaga raczej nie przemyslalem tego

> Aby temu zapobiec, trzeba albo pamiętać linię, po której się porusza
> (skomplikowane, niepotrebne i, a do tego jak się domyślam, że śledzony
> punkt się porusza:) )
> albo pamiętać ułamkową pozycję i robić ideowo jak u Bresenhama.
> 
> 
> I teraz pytanie, co tak naprawdę robisz.
> 
> Jeśli rysujesz linię,
> - Użyj Bresenhama.
> - Twoja biblioteka graficzna nie ma rysowania linii? Muis mieć. Niech
> ona to zrobi, wtedy karta graficzna narysuje linię, nie procek;-)
> 
> Jeśli jets to ludzik goniący za być możę ruchomym punktem,
> idea jest ta sama (błąd-korekcja) - ludzik ma pozycję znaną
> dokałdniej niż 'ten piksel'. Nie da się sprowadzić do wspolnego 
> mianownika jak dla stałej linii, więc albo float (najwygdniej) albo
> 'stały przecinek', czyli np pozycja z to int z dokłądnosćią do 1/1024
> piksela.
> 

a masz jakis matematyczny/logiczny dowód 
ze tego sie nie da zrobic?

dla mnie nie jest to takie pewne (nie mam zdania) 

tego co uzywam raczej uzywalbym do rysowania lini - taka forma jest bardziej 'ogolna' np latwo z tego zrobic rysowanie lini przerywanej, w dwu kolorach -- no i mozna tez uogolnic na nielinie (ale przypadek o ktory pytam to rysowanie lini)

moge przerobic na floaty ale troche szkoda ze nie kojarze poprawnej wersji 
na intach - ew mozna kombinowac z zapamietywaniem tego subpixelowego przesuniecia jako wewnetrznej zmiennej statycznej - temat niby prosty a wymaga troche przemyslania



> BTW, jesli to ludzik i pogoń, to tak, jak to opisałeś, ma jeszcze jedną
> wadę. Ruch pionowy i poziomy jest wolniejszy niż po przekątnych
> o sqrt(2).
> 


> pzdr
> bartekltg

[toc] | [prev] | [next] | [standalone]

#29487

W dniu poniedziałek, 13 marca 2017 15:46:29 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 13 marca 2017 12:38:15 UTC+1 użytkownik bartekltg napisał:
> > On 13.03.2017 01:15, fir wrote:
> > > W dniu niedziela, 12 marca 2017 23:47:04 UTC+1 użytkownik fir napisał:
> > >> W dniu niedziela, 12 marca 2017 23:23:35 UTC+1 użytkownik fir napisał:
> > >>> W dniu niedziela, 12 marca 2017 22:57:05 UTC+1 użytkownik bartekltg napisał:
> > >>>> On 12.03.2017 22:46, fir wrote:
> > >>>>> szukam dosyc prostego algorytmu
> > >>>>>
> > >>>>> mam punkt int x,y np 0,0
> > >>>>> i chce znalezc nastepny punkt
> > >>>>> w kierunku jakiegos dowolnego punktu
> > >>>>> int dist_x, dist_y, tak jak gdybym
> > >>>>> rysowal linie prostą
> > >>>>>
> > >>>>> jak wzynaczyc ten przylegly punkt?
> > >>>>>
> > >>>>
> > >>>> Algorytm Bresenhama
> > >>>>
> > >>> raczej fragment bressenhama ale jaki
> > 
> > Z testów wygląda, że całego.
> > 
> > 
> > 
> > >>
> > >> w sumie to chyba bedzie cos takiego
> > >>
> > >> int2 NextPointTowards(int x, int y, int dest_x, int dest_y)
> > >> {
> > >>   int2 n = {x, y};
> > >>
> > >>   int dx = dest_x - x;
> > >>   int dy = dest_y - y;
> > >>
> > >>   int sx = sign(dx);
> > >>   int sy = sign(dy);
> > >>
> > >>        if(sx==0) n.y += sy;
> > >>   else if(sy==0) n.x += sx;
> > >>   else
> > >>   {
> > >>    float m = fabs(((float)dy)/dx);
> > 
> > a to da się zrobić bez floatów. Choćby tak:
> > if ( 2*abs(dx) < abs(dy) )...
> > else if ( abs(dx) > 2*abs(dy) )...
> > 
> > >>
> > >>         if( m < 0.5)   n.x += sx;
> > >>    else if( m > 2.0)   n.y += sy;
> > >>    else   { n.x += sx; n.y += sy; }
> > >>  }
> > >>
> > >>  return n;
> > >>
> > >> }
> > >>
> > >> mozna by wywalic dzielenie zastepujac ifem ale nie wiedomo czy if szybszy
> > >>
> > >> pozatym w dzialaniu to chyba nie zastpi bresenhama (trzebby sprawdzic) choc mw o to mi chodzi bo taka procedura jest jaby bardziej ogolna
> > >
> > > zrobilem testy i okazalo sie ze to nie dziala dobrze
> > 
> > >
> > > http://minddetonator.htw.pl/compact.jpg
> > >
> > > gorna linia to normalne a dolna dolna linia to wynik generowania tych punktow
> > > wyzej
> > 
> > Nic dziwnego. Ten kod pozwala na wybór jednego z 8 kierunków.
> > Będzie używał 2 kierunków na zmianę tylko wtedy, gdy jest na ich
> > granicy.
> > Efektywnie będzie wiec tworzył proste jedynie w 16 różnych kierunkach.
> > 
> 
> chyba sluszna uwaga raczej nie przemyslalem tego
> 
> > Aby temu zapobiec, trzeba albo pamiętać linię, po której się porusza
> > (skomplikowane, niepotrebne i, a do tego jak się domyślam, że śledzony
> > punkt się porusza:) )
> > albo pamiętać ułamkową pozycję i robić ideowo jak u Bresenhama.
> > 
> > 
> > I teraz pytanie, co tak naprawdę robisz.
> > 
> > Jeśli rysujesz linię,
> > - Użyj Bresenhama.
> > - Twoja biblioteka graficzna nie ma rysowania linii? Muis mieć. Niech
> > ona to zrobi, wtedy karta graficzna narysuje linię, nie procek;-)
> > 
> > Jeśli jets to ludzik goniący za być możę ruchomym punktem,
> > idea jest ta sama (błąd-korekcja) - ludzik ma pozycję znaną
> > dokałdniej niż 'ten piksel'. Nie da się sprowadzić do wspolnego 
> > mianownika jak dla stałej linii, więc albo float (najwygdniej) albo
> > 'stały przecinek', czyli np pozycja z to int z dokłądnosćią do 1/1024
> > piksela.
> > 
> 
> a masz jakis matematyczny/logiczny dowód 
> ze tego sie nie da zrobic?
> 
> dla mnie nie jest to takie pewne (nie mam zdania) 
> 
> tego co uzywam raczej uzywalbym do rysowania lini - taka forma jest bardziej 'ogolna' np latwo z tego zrobic rysowanie lini przerywanej, w dwu kolorach -- no i mozna tez uogolnic na nielinie (ale przypadek o ktory pytam to rysowanie lini)
> 
> moge przerobic na floaty ale troche szkoda ze nie kojarze poprawnej wersji 
> na intach - ew mozna kombinowac z zapamietywaniem tego subpixelowego przesuniecia jako wewnetrznej zmiennej statycznej - temat niby prosty a wymaga troche przemyslania
> 
> 
> 
> > BTW, jesli to ludzik i pogoń, to tak, jak to opisałeś, ma jeszcze jedną
> > wadę. Ruch pionowy i poziomy jest wolniejszy niż po przekątnych
> > o sqrt(2).
> > 
> 
> 
przykladowa wersja float 

int MovePointTowards(float* x, float* y, float dest_x, float dest_y) 
{ 
  float nx = *x; 
  float ny = *y; 

  float dx = dest_x - nx; 
  float dy = dest_y - ny; 

  if(fabs(dx)<0.1 && fabs(dy)<0.1) return 0; 

  float sx = fsign(dx); 
  float sy = fsign(dy); 


       if(sx==0) ny += sy; 
  else if(sy==0) nx += sx; 
  else 
  if (dy<dx) 
  { 
   float m = fabs(dy/dx); 

           nx += sx; 
           ny += m*sy; 
 } 
 else 
 { 
   float m = fabs(dx/dy); 

           ny += sy; 
           nx += m*sx; 
 } 

 *x=nx; 
 *y=ny; 
 return 1; 

} 

void foo()
{


float x = 100; 
float y = 100; 

 do SetPixel(x,y, 0xffffff); 
 while(MovePointTowards(&x, &y, 234, 337)); 

}

dziala pytanie o ile to jest wolniejsze i
o ile by bylo po maksymalnym wyoptymalizowaniu

inne pytanie co mozna tym np ciekawego narysowac

[toc] | [prev] | [next] | [standalone]

#29488

W dniu poniedziałek, 13 marca 2017 17:09:32 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 13 marca 2017 15:46:29 UTC+1 użytkownik fir napisał:
> > W dniu poniedziałek, 13 marca 2017 12:38:15 UTC+1 użytkownik bartekltg napisał:
> > > On 13.03.2017 01:15, fir wrote:
> > > > W dniu niedziela, 12 marca 2017 23:47:04 UTC+1 użytkownik fir napisał:
> > > >> W dniu niedziela, 12 marca 2017 23:23:35 UTC+1 użytkownik fir napisał:
> > > >>> W dniu niedziela, 12 marca 2017 22:57:05 UTC+1 użytkownik bartekltg napisał:
> > > >>>> On 12.03.2017 22:46, fir wrote:
> > > >>>>> szukam dosyc prostego algorytmu
> > > >>>>>
> > > >>>>> mam punkt int x,y np 0,0
> > > >>>>> i chce znalezc nastepny punkt
> > > >>>>> w kierunku jakiegos dowolnego punktu
> > > >>>>> int dist_x, dist_y, tak jak gdybym
> > > >>>>> rysowal linie prostą
> > > >>>>>
> > > >>>>> jak wzynaczyc ten przylegly punkt?
> > > >>>>>
> > > >>>>
> > > >>>> Algorytm Bresenhama
> > > >>>>
> > > >>> raczej fragment bressenhama ale jaki
> > > 
> > > Z testów wygląda, że całego.
> > > 
> > > 
> > > 
> > > >>
> > > >> w sumie to chyba bedzie cos takiego
> > > >>
> > > >> int2 NextPointTowards(int x, int y, int dest_x, int dest_y)
> > > >> {
> > > >>   int2 n = {x, y};
> > > >>
> > > >>   int dx = dest_x - x;
> > > >>   int dy = dest_y - y;
> > > >>
> > > >>   int sx = sign(dx);
> > > >>   int sy = sign(dy);
> > > >>
> > > >>        if(sx==0) n.y += sy;
> > > >>   else if(sy==0) n.x += sx;
> > > >>   else
> > > >>   {
> > > >>    float m = fabs(((float)dy)/dx);
> > > 
> > > a to da się zrobić bez floatów. Choćby tak:
> > > if ( 2*abs(dx) < abs(dy) )...
> > > else if ( abs(dx) > 2*abs(dy) )...
> > > 
> > > >>
> > > >>         if( m < 0.5)   n.x += sx;
> > > >>    else if( m > 2.0)   n.y += sy;
> > > >>    else   { n.x += sx; n.y += sy; }
> > > >>  }
> > > >>
> > > >>  return n;
> > > >>
> > > >> }
> > > >>
> > > >> mozna by wywalic dzielenie zastepujac ifem ale nie wiedomo czy if szybszy
> > > >>
> > > >> pozatym w dzialaniu to chyba nie zastpi bresenhama (trzebby sprawdzic) choc mw o to mi chodzi bo taka procedura jest jaby bardziej ogolna
> > > >
> > > > zrobilem testy i okazalo sie ze to nie dziala dobrze
> > > 
> > > >
> > > > http://minddetonator.htw.pl/compact.jpg
> > > >
> > > > gorna linia to normalne a dolna dolna linia to wynik generowania tych punktow
> > > > wyzej
> > > 
> > > Nic dziwnego. Ten kod pozwala na wybór jednego z 8 kierunków.
> > > Będzie używał 2 kierunków na zmianę tylko wtedy, gdy jest na ich
> > > granicy.
> > > Efektywnie będzie wiec tworzył proste jedynie w 16 różnych kierunkach.
> > > 
> > 
> > chyba sluszna uwaga raczej nie przemyslalem tego
> > 
> > > Aby temu zapobiec, trzeba albo pamiętać linię, po której się porusza
> > > (skomplikowane, niepotrebne i, a do tego jak się domyślam, że śledzony
> > > punkt się porusza:) )
> > > albo pamiętać ułamkową pozycję i robić ideowo jak u Bresenhama.
> > > 
> > > 
> > > I teraz pytanie, co tak naprawdę robisz.
> > > 
> > > Jeśli rysujesz linię,
> > > - Użyj Bresenhama.
> > > - Twoja biblioteka graficzna nie ma rysowania linii? Muis mieć. Niech
> > > ona to zrobi, wtedy karta graficzna narysuje linię, nie procek;-)
> > > 
> > > Jeśli jets to ludzik goniący za być możę ruchomym punktem,
> > > idea jest ta sama (błąd-korekcja) - ludzik ma pozycję znaną
> > > dokałdniej niż 'ten piksel'. Nie da się sprowadzić do wspolnego 
> > > mianownika jak dla stałej linii, więc albo float (najwygdniej) albo
> > > 'stały przecinek', czyli np pozycja z to int z dokłądnosćią do 1/1024
> > > piksela.
> > > 
> > 
> > a masz jakis matematyczny/logiczny dowód 
> > ze tego sie nie da zrobic?
> > 
> > dla mnie nie jest to takie pewne (nie mam zdania) 
> > 
> > tego co uzywam raczej uzywalbym do rysowania lini - taka forma jest bardziej 'ogolna' np latwo z tego zrobic rysowanie lini przerywanej, w dwu kolorach -- no i mozna tez uogolnic na nielinie (ale przypadek o ktory pytam to rysowanie lini)
> > 
> > moge przerobic na floaty ale troche szkoda ze nie kojarze poprawnej wersji 
> > na intach - ew mozna kombinowac z zapamietywaniem tego subpixelowego przesuniecia jako wewnetrznej zmiennej statycznej - temat niby prosty a wymaga troche przemyslania
> > 
> > 
> > 
> > > BTW, jesli to ludzik i pogoń, to tak, jak to opisałeś, ma jeszcze jedną
> > > wadę. Ruch pionowy i poziomy jest wolniejszy niż po przekątnych
> > > o sqrt(2).
> > > 
> > 
> > 
> przykladowa wersja float 
> 
> int MovePointTowards(float* x, float* y, float dest_x, float dest_y) 
> { 
>   float nx = *x; 
>   float ny = *y; 
> 
>   float dx = dest_x - nx; 
>   float dy = dest_y - ny; 
> 
>   if(fabs(dx)<0.1 && fabs(dy)<0.1) return 0; 
> 
>   float sx = fsign(dx); 
>   float sy = fsign(dy); 
> 
> 
>        if(sx==0) ny += sy; 
>   else if(sy==0) nx += sx; 
>   else 
>   if (dy<dx)

powinno byc if(fabs(dy)<fabs(dx))
 
>   { 
>    float m = fabs(dy/dx); 
> 
>            nx += sx; 
>            ny += m*sy; 
>  } 
>  else 
>  { 
>    float m = fabs(dx/dy); 
> 
>            ny += sy; 
>            nx += m*sx; 
>  } 
> 
>  *x=nx; 
>  *y=ny; 
>  return 1; 
> 
> } 
> 
> void foo()
> {
> 
> 
> float x = 100; 
> float y = 100; 
> 
>  do SetPixel(x,y, 0xffffff); 
>  while(MovePointTowards(&x, &y, 234, 337)); 
> 
> }
> 
> dziala pytanie o ile to jest wolniejsze i
> o ile by bylo po maksymalnym wyoptymalizowaniu
> 
> inne pytanie co mozna tym np ciekawego narysowac

[toc] | [prev] | [next] | [standalone]

#29489

On 13.03.2017 15:46, fir wrote:

>
> dla mnie nie jest to takie pewne (nie mam zdania)
>
> tego co uzywam raczej uzywalbym do rysowania lini - taka forma jest
> bardziej 'ogolna' np latwo z tego zrobic rysowanie lini przerywanej,
> w dwu kolorach -- no i mozna tez uogolnic na nielinie (ale przypadek
> o ktory pytam to rysowanie lini)


No to gdzie problem, żby zastosować algorytm gościa na B?
Żadnych floatów, tyle iteracji ile pikseli, same zalety.
To naprawdę dopieszczony algorytm.


pzdr
bartekltg

[toc] | [prev] | [next] | [standalone]

#29490

W dniu poniedziałek, 13 marca 2017 18:10:28 UTC+1 użytkownik bartekltg napisał:
> On 13.03.2017 15:46, fir wrote:
> 
> >
> > dla mnie nie jest to takie pewne (nie mam zdania)
> >
> > tego co uzywam raczej uzywalbym do rysowania lini - taka forma jest
> > bardziej 'ogolna' np latwo z tego zrobic rysowanie lini przerywanej,
> > w dwu kolorach -- no i mozna tez uogolnic na nielinie (ale przypadek
> > o ktory pytam to rysowanie lini)
> 
> 
> No to gdzie problem, żby zastosować algorytm gościa na B?
> Żadnych floatów, tyle iteracji ile pikseli, same zalety.
> To naprawdę dopieszczony algorytm.
> 
> 
a kto mowi ze jest problem? 

(pominawszy to algorytm bressenhama nie jest az taki dobry na codzien raczej uzywam wersji na fixedpointach i o ile pamietam byla chyba szybsza)

to o czym mowie to pewne zagadnienie teoretyczne ktore ma wiele stron i nie sprowadza sie w calosci do 'uzyj bressenhama' (i takie sprowadzanie jest troche glupie)

[toc] | [prev] | [next] | [standalone]

#29491

On 13.03.2017 19:16, fir wrote:
> W dniu poniedziałek, 13 marca 2017 18:10:28 UTC+1 użytkownik bartekltg napisał:
>> On 13.03.2017 15:46, fir wrote:
>>
>>>
>>> dla mnie nie jest to takie pewne (nie mam zdania)
>>>
>>> tego co uzywam raczej uzywalbym do rysowania lini - taka forma jest
>>> bardziej 'ogolna' np latwo z tego zrobic rysowanie lini przerywanej,
>>> w dwu kolorach -- no i mozna tez uogolnic na nielinie (ale przypadek
>>> o ktory pytam to rysowanie lini)
>>
>>
>> No to gdzie problem, żby zastosować algorytm gościa na B?
>> Żadnych floatów, tyle iteracji ile pikseli, same zalety.
>> To naprawdę dopieszczony algorytm.
>>
>>
> a kto mowi ze jest problem?

Ty.
Jak nie ma problemu, to zastosuj.

> (pominawszy to algorytm bressenhama nie jest az taki dobry na codzien raczej uzywam wersji na fixedpointach i o ile pamietam byla chyba szybsza)

NIe pamiętasz.
Przeczytaj moze najpeirw, co to jest ten algorytm.

>
> to o czym mowie to pewne zagadnienie teoretyczne ktore ma wiele stron i nie sprowadza sie w calosci do 'uzyj bressenhama' (i takie sprowadzanie jest troche glupie)

Jeśli hccesz odkrywac na nowo koło, musisz powiedzieć po co.
Choćby 'bo się chcę pobawić'.
Jeśli tego nie zrobisz, dostaniesz (jeśli dostaniesz, bo odpowiadanie
wydaje się trochę głupie) rozwiązanie problemu.

Chcesz analizę algorytmu rysowania linii? Poszperaj w ksiazkach
do grafiki komputerowej. Tam bedziesz mial ich 10 roznych rodzaju,
coraz to lepszych.

pzdr
bartekltg

[toc] | [prev] | [next] | [standalone]

#29492

W dniu poniedziałek, 13 marca 2017 20:30:04 UTC+1 użytkownik bartekltg napisał:


nie mow co mam robic bo uswiadamiam sobie ze rozmawiam z idiota a to nie jest chyba cos czego bysmy tu chcieli ;c

watki sa nie po to by jak idiota mowic komus co ma robic tyko by odpowiadac na pytania , rozwijac tematy.. kolega nieststy woli wytwarzac ciezkie glupoty


> >>>
> >>> dla mnie nie jest to takie pewne (nie mam zdania)
> >>>
> >>> tego co uzywam raczej uzywalbym do rysowania lini - taka forma jest
> >>> bardziej 'ogolna' np latwo z tego zrobic rysowanie lini przerywanej,
> >>> w dwu kolorach -- no i mozna tez uogolnic na nielinie (ale przypadek
> >>> o ktory pytam to rysowanie lini)
> >>
> >>
> >> No to gdzie problem, żby zastosować algorytm gościa na B?
> >> Żadnych floatów, tyle iteracji ile pikseli, same zalety.
> >> To naprawdę dopieszczony algorytm.
> >>
> >>
> > a kto mowi ze jest problem?
> 
> Ty.
> Jak nie ma problemu, to zastosuj.
> 

kolega zaprzecza samemu sobie, twierdzi ze ja mowie ze mam problem z zastosowaniem bressenhama nic takiego nie mowilem.. chwile potem dorzuca "jak nie ma porblemu to zastosuj" przeczac samemu sobie - to nie jest grupa dla baranow, pewien poziom by sie przydal

> > (pominawszy to algorytm bressenhama nie jest az taki dobry na codzien raczej uzywam wersji na fixedpointach i o ile pamietam byla chyba szybsza)
> 
> NIe pamiętasz.
> Przeczytaj moze najpeirw, co to jest ten algorytm.
> 

dobrze wiem co to za algorytm, o ile pamietam wersja na fixedpointach jest szybsza i nie w tym nic dziwnego



> >
> > to o czym mowie to pewne zagadnienie teoretyczne ktore ma wiele stron i nie sprowadza sie w calosci do 'uzyj bressenhama' (i takie sprowadzanie jest troche glupie)
> 
> Jeśli hccesz odkrywac na nowo koło, musisz powiedzieć po co.
> Choćby 'bo się chcę pobawić'.
> Jeśli tego nie zrobisz, dostaniesz (jeśli dostaniesz, bo odpowiadanie
> wydaje się trochę głupie) rozwiązanie problemu.
> 
> Chcesz analizę algorytmu rysowania linii? Poszperaj w ksiazkach
> do grafiki komputerowej. Tam bedziesz mial ich 10 roznych rodzaju,
> coraz to lepszych.
> 
i co jeszcze

typowego barana z netu latwo poznac po tym ze znienacka nieproszony przelacza sie w tryb uzywania swoich yimaginowanych polecen, a to nieststy nie jest grupa dla knajakow

[toc] | [prev] | [next] | [standalone]

#29493

On 13.03.2017 20:42, fir wrote:
>> NIe pamiętasz.
>> Przeczytaj moze najpeirw, co to jest ten algorytm.
>>
> dobrze wiem co to za algorytm, o ile pamietam wersja na fixedpointach jest szybsza i nie w tym nic dziwnego

A ja Ci mnówię, że nie pamiętasz albo nigdy go nie poznałeś,
bo ten algorytm _jest_ na intach.

bartekltg

[toc] | [prev] | [next] | [standalone]

#29494

W dniu poniedziałek, 13 marca 2017 22:29:49 UTC+1 użytkownik bartekltg napisał:
> On 13.03.2017 20:42, fir wrote:
> >> NIe pamiętasz.
> >> Przeczytaj moze najpeirw, co to jest ten algorytm.
> >>
> > dobrze wiem co to za algorytm, o ile pamietam wersja na fixedpointach jest szybsza i nie w tym nic dziwnego
> 
> A ja Ci mnówię, że nie pamiętasz albo nigdy go nie poznałeś,
> bo ten algorytm _jest_ na intach.
> 

i co z tego wciskaczu glupot? bedziesz teraz twierdzic ze mowie ze nie jest? a moze jakies inne nowe insynuacje? 



bressenham ma ifa per pixel

   for(int i=0; i<how_many_segments; i++)
     {
      SetPixel(x,y, color);
 
      temp-=deltaY;

      if(temp<=0) {
          y+=dy; temp +=deltaX;  }

      x+=dx;
     }

a fixedpointy to 

   for(int i=0; i<how_many_segments; i++)
   {
      x += dx ;
      y += dy ;

      SetPixel(x>>16, y>>16, color);

   }

proponuje sie podciagnac w rozmowie,

[toc] | [prev] | [next] | [standalone]

#29496

W dniu poniedziałek, 13 marca 2017 22:53:23 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 13 marca 2017 22:29:49 UTC+1 użytkownik bartekltg napisał:
> > On 13.03.2017 20:42, fir wrote:
> > >> NIe pamiętasz.
> > >> Przeczytaj moze najpeirw, co to jest ten algorytm.
> > >>
> > > dobrze wiem co to za algorytm, o ile pamietam wersja na fixedpointach jest szybsza i nie w tym nic dziwnego
> > 
> > A ja Ci mnówię, że nie pamiętasz albo nigdy go nie poznałeś,
> > bo ten algorytm _jest_ na intach.
> > 
> 
> i co z tego wciskaczu glupot? bedziesz teraz twierdzic ze mowie ze nie jest? a moze jakies inne nowe insynuacje? 
> 
> 
> 
> bressenham ma ifa per pixel
> 
>    for(int i=0; i<how_many_segments; i++)
>      {
>       SetPixel(x,y, color);
>  
>       temp-=deltaY;
> 
>       if(temp<=0) {
>           y+=dy; temp +=deltaX;  }
> 
>       x+=dx;
>      }
> 
> a fixedpointy to 
> 
>    for(int i=0; i<how_many_segments; i++)
>    {
>       x += dx ;
>       y += dy ;
> 
>       SetPixel(x>>16, y>>16, color);
> 
>    }
> 
> proponuje sie podciagnac w rozmowie,

odnosnie pytania to przypominam brzmi ono, 
czy istnieje jakas rozwiazanie tego problemu ktore da sie zawrzec w formie tej funkcji dla liczb calkowitych

czyli cos w stylu:

 MovePointTowards(int* current_x, 
                  int* current_y, 
                  int dest_x,
                  int dest_y ) 

nejlepiej bez wewnetrznych danych statycznych ale jak sie nie da rowniez w
tej wersji *

z jednej strony wydaje mi sie byc moze dziwne gdyby czegos takiego nie dalo sie zrobic, z drugiej nic nie przychodzi mi 
do glowy

* problemem z danymi statycznymi chyba jest nie tyle to ze trzeba ich uzywac ale
raczej to ze chyba wplywalyby one blednie na zachowanie funkcji gdyby ktos chcial 
np zaczac jej uzywac do rysowanie drugiej niezwiazanej kreski (powiedzmy ze narysowal 50 pikseli jednej po czym chcialby zakonczyc jej rysowanie i skoczyl punktem w zupelnie inne miejsce by rysowac
nową - w sumie chyba jednak daloby sie to
(czyli zapewne taki skok o wiele pikseli)
zdetektowac i zrobic brancha

dlaczego pytam? pytam dlatego ze taka specyficzne dziwnie-ogolna forma funkcji wydaje mi sie teoretycznie wyjatkowo 
ciekawa (tj ciekawa z punktu widzenia informatyki teoretycznej)

[toc] | [prev] | [next] | [standalone]

#29495

bartekltg <bartekltg@gmail.com> wrote:

>> dobrze wiem co to za algorytm, o ile pamietam wersja na fixedpointach jest szybsza i nie w tym nic dziwnego
> 
> A ja Ci mnówię, że nie pamiętasz albo nigdy go nie poznałeś,
> bo ten algorytm _jest_ na intach.

Podziwiam, że Ci się chce...

-- 
http://www.chmurka.net/

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web