У меня возник вопрос: Есть ли алгоритм рисования окружности строго по\против часовой стрелки. Т. е. чтобы прорисовка шла последовательно, не по частям.
Или самому писать?

А то чего-то не найду никак...

Не понял. Какой именно алгоритм тебе нужен?

Для твоего случая (по/против часовой стрелки) лучше всего использовать такую формулу:
x = x0 + r*cos(alpha)
y = y0 + r*sin(alpha)
(x0,y0) -- центр окружности, r -- ее радиус. alpha -- угол, от 0 до 2*pi.

Если хочешь нарисовать окружность по часовой стрелке начиная с pi/2, например, то агоритм будет 
такой:
1) ставишь точку для alpha = pi/2
2) уменьшаешь alpha на нужный шаг. Ставишь точку.
3) повторяешь п2 до тех пор пока alpha > -3pi/2 (один оборот назад от точки pi/2)

Что-то в этом роде   

нет это не лучше всего да и вообще посредственный алгоритм.

esperant0, Если чуть вспомнить тригонометрию, то этот алгоритм можно свести к простому прибавлению и умножению. Надо только воспользоваться разложению формул sin(a+b); cos(a+b). Где b равна 1 градусу или 1 минуте в зависимости от желаний.

esperant0, чем тебе он не понравился  

В любом случае для рисования фигуры нужны ее точки. Мой способ очень прост, элементарно кодируется. Лишних затрат процессора не требует. Универсален (можно нарисовать любую чать окружности).

А твой, пока, вообще ничего не умеет   

P.S. Если ты такой спец, то предложи свой. Просто обос..ть любой может. Ты обоснуй  

Есть известный алгоритм рисования окружности, который не использует не синусов не косинов. Очень быстр и прост. Эффективней вашего. Алгоритм имеется в любом хорошем учебнике по комп. графике.

Добавлено @ 22:17 
тут есть ответ на ваши вопросы http://www.codenet.ru/progr/video/alg/alg4.php


с уважением

esperant0, зачет   
Но этот алгоритм не соответствует одному из требований задачи:

Ребята! Вы меня не поняли.
ivashkanet, мне нужен целочисленный алгоритм, оптимизированный для прорисовки по экрану (нет вычисления лишних точек). Т. е. типа Брезенхема, но ,esperant0, он рисует окружность частями, а я говорю про последовательность точек. Каждая следующая точка продолжает кривую, формируя окружность.

AlexST, так ведь можно сделать 8 проходов метода Брезенхема и будет тебе окружность
P.S. Надо было сразу все условия задачи давать  

Да. Придётся делать самому.
Спасибо!

Это сообщение отредактировал(а) AlexST - 15.8.2006, 14:24

AlexST, ты переходил по ссылке esperant0?

В кратце идея (она конечно в лоб, но ничего умнее на вскидку не приходит  ):
Метод Брезенхема по сути рисует только 1/8 часть окружности (верхнюю половину I четверти). А остальное дорисовывает исходя из симметрии окружности.
Получается, что эти части рисуются одновременно (почти). Тебя это не устраивает. Так? Поэтому, вместо одновременного рисования ставим последовательное. Алгоритм будет работать медленнее (7 лишних раз нужно координаты точек окружности вычислять), но зато так как надо. 
Еще один минус: отправной точкой рисования может быть только лубая их начальных точек этих восьмушек.

Что нить такое. Не проверял, но должно работать 

Это как тебе захочется.

Зачем вычислять? Можно хранить координаты точек и всё!

Минуса не вижу.   


Это сообщение отредактировал(а) AlexST - 15.8.2006, 14:29

Я не понял кому это хочется? Мне или тебе    
То что немного изменив этот алгоритм можно получить рисование любой 1/8 окружности? Так это очевидно  

Ты хоть представляешь сколько точек придется хранить?
Тебе какой алгоритм нужен? Быстрый, но конкретно жрущий память или немного медленный, но не требующий ресурсы машины?

Уточни: В твоей конкретно задаче это не минус? или не минус вообще?

 Немного. А что, ты думаешь что в любом случае лучше вычислять?

Это навряд ли.

Уточняю: ИМХО не минус вообще. А в моей задаче тем более.

AlexST, понимаешь, окружность это примитив, который должен рисоваться быстро.
Не будет же у тебя все прилложение состоять из одной окружности. Нет.

Давай посчитаем сколько примерно понадобится точек для окружности радиусом 100 пикселей:
Так как мы на каждом шаге идем либо вниз либо вправо, то для рисования четверти круга нам понадобится около 150 точек (чтобы попасть из точки (0, 100) в (100, 0) нужно в любом случае "прошагать" 100 пикселей вправо и 100 вниз, но так как мы иногда идем одновременно и вниз и вправо, то  будем считать, что вниз мы прошагали всего 50 пикселей). 
Поэтому для нашей 1/8 придеться хранить координаты 75 точек = 75*2 точки* 2 байта (в один не влезем никак) = 300 байт на одну окружность.

А если нам их нужно тысячи нарисовать (это ведь примитив, он обычно тучами рисуется  )

Короче вопросы есть 
Ясно что нужно выбирать в каждой конкретной ситуации свое решение.

Например если ты хочешь чтобы точка просто бегала по окружности фиксированого радиуса, то ясно что лучше всего сохранять точки. 
А если радиус окружности меняется, то, ИМХО, лучше пересчитывать 

Добавлено @ 15:42 
В общем бири алгоритм и пользуйся 
Если потом тебя не устроит его скорость, то приходи сюда. Всесте подумаем