ты половину линии отражаешь что ли?

ты половину линии отражаешь что ли?

ПОРОГ

что порог

забей

наверное ты не понял мою гениальную идею - так ведь можно ускорить растеризацию в двое (ну или почти) почему не рендерить линию с двух концов? фактически это размотка цикла будет

сорян не успел, но тебе бы все равно не понравилось, там деление. на самом деле довольно тупой алг (пропорциональности) за dy надо сместиться на dx шаг = dx/dy

Ты считаешь неправильно

да производительность будет зависить от того на сколько медленен IF

но если ты деление за циклом экономишь, почему бы и на IF'ах не съэкономить

наверное ты не понял мою гениальную идею - так ведь можно ускорить растеризацию в двое (ну или почти) почему не рендерить линию с двух концов? фактически это размотка цикла будет

Во-первых, только если у тебя ПОРОГ выбран правильно Во-вторых, значение порога вконце линии не будет равно DX/2, а значит ты не попадешь в исходную точку. В третьих, растеризация треугольника идет сверху вниз. Если я буду растеризовать с середины, то мне нужна координата секущей длинного ребра. А целочисленно я ее получить не смогу, только приближением, а это уже погрешность.

Ты считаешь неправильно

там не мой алг, это "классическая" растеризация треугольника с DAA

но если ты деление за циклом экономишь, почему бы и на IF'ах не съэкономить

да блеть, вот подели 38 на 5

НАЦЕЛО

согласен про секущую, но это скорее всего будет быстрее

ты проебал 3/5

ты понимаешь что это пиздец дохуя?

пожалуйста: (38«16) / (5«16) //при чтении значения брать из старшего регистра

да нету старшего разряда блять

8 бит архитектура

и сдвиг на 1 бит онли

хм, тогда ясно

и твоя операция разворачивается уже в портянку

и по тактам - больше 32

+ деление

тактов 100

для 16 бит

+ по коду байт 200

и твоя операция разворачивается уже в портянку

это разворачивается только вначале на приведении в статическуюТочку (а если есть старший регистр, то можно вообще просто в него класть) //но все это не имеет значения если его нет. так что это просто не подходящий для 8бит алг

наконец-то

А теперь давай тут посчитаем

я тебе сразу сказал что я не знаю архитектуры спеки, так что "наконец то" это ты сказал что там нет возможности оперировать слово

11 загрузок в ините, 2 сложения, 1 сдвиг цикл: 4 сложения, 2 условия

сложения - за такт, загрузка - два, сдвиг - такт, условия - 2-3

отлично это наверное лучший алг для спеки, с этим я и не спорил

я тебе сразу сказал что я не знаю архитектуры спеки, так что "наконец то" это ты сказал что там нет возможности оперировать слово

а там вобще пиздос, загрузка до 6 тактов, сложение - 4 такта, условие 8 тактов!

и твое деление там будет вобще вечным

~360 тактов

прийдется делить умножением =)

по табличке констант

ладно я шучу

в таком случае за деление под спекой надо руки отрубать

отлично это наверное лучший алг для спеки, с этим я и не спорил

для любой! архитектуры, этот алгоритм будет быстрее любого другого.

ладно я шучу

про линию с двух сторон еще

идея понятна, но смысл?

вычислительная сложность - та же

возможно это быстрее (я пока только предположил)

IF'ов меньше

ммм

ну я сказал что фактически это размотка цикла

суть понял.... типа если начало падает по Y, то и конец поднимаем (не сравнивая)

да, лучше согласен

но с треугольниками не пойдет

ну да как то так (в принципе можно даже не проверять перезапись средней точки)

ща проверю

XOR'ом

но с треугольниками не пойдет

с треугольниками это потребует модификации с определением секущей (которую если деление не юзать не наждешь) - но на архитектурах с быстрым делением возможно будет рентабельно

а ни чего что мы тут общий чат всеми этими тактами заваливаем? (меня немного смущает когда я смотрю сколько тут народу)

или тут всем норм

работает

а что за красная зона?

пауза - остановил

красная - аппаратная линия

зеленая - XOR синим

может не совпасть центральный отрезок, попробуй например нарисуй линию длиной в весь экран и высотой в 3\4\5\6

ERROR: S client not available

в принципе с учетом деления на константу можно сказать, что подход повторяется рекурсивно (и до какой то вложенности на определенной длинне линии будет ускоряться, пока оверхед не съест)

может не совпасть центральный отрезок, попробуй например нарисуй линию длиной в весь экран и высотой в 3\4\5\6

ща цикл с шагом сделаю

может не совпасть центральный отрезок, попробуй например нарисуй линию длиной в весь экран и высотой в 3\4\5\6

сомнительно... угол то одинаковый если и не совпадет, то на один пиксель

может появиться нерегулярность алиасинга в середине

сомнительно... угол то одинаковый если и не совпадет, то на один пиксель

угол одинаковый, а начало смещения отрезков может быть разное

вообще если координатам делать правку на пол пикселя, то и этот эфект уйдет гарантированно

работает )

хех... все и так совпало, расслабляемся =)

стопэ

ща

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

не все гладко

при переходе 45

простреливает погрешность

и до 45 тоже

думаю там просто махнуть координаты надо

не суть

выше смотри

там не надо а точки не попали

а знаешь почему?

Во-первых, только если у тебя ПОРОГ выбран правильно Во-вторых, значение порога вконце линии не будет равно DX/2, а значит ты не попадешь в исходную точку. В третьих, растеризация треугольника идет сверху вниз. Если я буду растеризовать с середины, то мне нужна координата секущей длинного ребра. А целочисленно я ее получить не смогу, только приближением, а это уже погрешность.

?

потому что ПОРОГ в конце линии не равен DX/2

А чему равен ты не узнаешь, пока линию не добежишь до конца

попробуй вывести до 90гр

не получится

свап писать надо

не хочу

я это все за последнюю неделю написал раз 30 уже

с нуля

ладно, все равно это для треугольников нельзя а прирост для линий будет только от экономии половины IF'ов (короче по такту на точку макс)