Да, например, Sayman говорит, что голожопые девки это возмутительно для компьютерного журнала! :) Тогда я буду фотать те же сиськи-попки, но в кроп-кадре будет только соответствующая желзяка.

у меня есть выбор? :)

Как насчет такой идеи: я зафотаю милаху с амигой. Никаких обложек :)

Никогда не умел в бейсик, и для меня RANDOMIZE USR 15619:REM всегда были какой-то хардкодовой магией. Теперь, наконец, понимаю, что это и зачем.

Для стартеров «в двух словах» самое оно :)

буду ждать кошерную амигу :)

в 2 раза не выйдет, и не мечтай)) даже в самом удобном буфере, без учёта времени переброски, без ограничений на размер кода, с рисованием set и одновременно с двух концов, с экономией проверки после ступеньки, без учёта дополнительных расходов на цикл и хвост — теоретический предел 23+ такта на пиксель (для вертикалей)

если так, то у меня сейчас (лучший случай/худший случай/среднее)
467/610/538; 774/1013/893; 1221/1609/1415
но средневзвешенное дб поменьше среднего, особенно для линий короче 9 точек
так как самый худший случай (и близкие) статистически довольно редки

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

Я не считал свою преамбулу отдельно. Я меряю просто среднюю скорость отрисовки линий фиксированной длины. Сейчас у меня в среднем 504 такта на линию из 5 точек, 983 такта на линию из 15 точек, 1703 такта на линию из 30 точек.

Пробежался бездумно по памяти и увидел :)
Короче, интересная идея. Скорее всего я пущу её в ход. Но хочется большего. Хочется линию в 2 раза быстрее, например. Вот это будет заметно.

Да, я это тоже понял. Но пока не решил для себя точно, какая схема меня привлекает больше.

И еще. Как уже говорил на форуме, если сцена сложная, из большого кол-ва коротких линий, и в 25-50 fps заведомо не уложится, может оказаться выгоднее рисовать в буфере с удобной раскладкой и стеком перебрасывать на экран, что в итоге может получиться быстрее и по памяти примерно столько же вместе с буфером (и даже меньше, если вычесть второй экран)

Ну хз-хз, может быть, такой задачи там и не ставили, но в двух других примерах от call до постановки первой точки проходит ~400 и ~490 тактов, у меня в среднем ~330 (и это не старался еще особенно). Сам алон упоминал как рекорд около 270 емнип, но там, вероятно, цикл намного проще и медленней.

Где ты там увидел 16k?? Чуть больше восьми, если точно — 8635 байт на саму процедуру линии (и даже вместе с демо-кодом нет и 9k). Из них вход 169 байт и 2k заняли таблицы, которые все можно сократить на четверть за счёт небольшого замедления входа, а на освободившееся место распихать рисующие куски. То есть можно в 8k утоптать вполне. И нет, размер не мог удвоиться хотя бы потому, что ветка без ступенек короче, а еще для хвоста часть кода можно объединить.

Кроме того, забыл написать про оптимизацию преамбулы. Да, алон прав, в большинстве случаев преамбула оптимизирована неважно. Но, если честно, сделать оптимизацию преамбулы несложно, просто уже потому, что там нечего особенно оптимизировать. Ну да, на коротких линиях это важно и коротких линий обычно большинство. Поэтому мне понятен посыл, но не очень понятно что там по этому поводу можно обсуждать — у всех кто ставит перед собой такую задачу, преамбула эффективна.

Посмотрел твой код. Да, идея развести Брезенхема в 2 независимые ветки прикольная, но непрактичная, с моей точки зрения. Жизненные реалии для меня выглядят так: если пишешь 128К демо, очень желательно иметь весь код для выкладки в экран ниже 49152 (чтобы можно было пользоваться теневым экраном). При этом, если хочется поддержать классические спектрумы, крайне нежелательно класть код ниже 32768. У тебя грубо говоря есть 16К под код; на самом деле меньше, потому что есть такие вещи как резидентное ядро, и всякие данные, и, разумеется, код для чего-то ещё кроме рисования линий. Стандартная быстрая линия, как у Рейдера, или из Эксперта, занимает около 5кб. Думаю, что за пределы 7-8 килобайт выходить нельзя, если хочется реально практичных решений.

Твоё предложение фактически удваивает размер кода за 4 такта на точку. 4 такта — это из цикла где в лучшем случае тратится 26 тактов на итерации (на самом деле, в среднем тратится больше). 4/26 — это даже не 20% выигрыша. Думаю что DDA оправдать будет проще, потому что табличное деление можно втиснуть примерно в 100-150 тактов, и это выиграет относительно стандартного подхода для (100-150)/4 ~ 25-40 точек, т.е. для достаточно длинных линий.

Конкретно в деталях, ты там явно расписал не только Брезенхема в 2 ветки, ты также расписал и что-то другое. Мне было лень разбираться в подробностях, но процедура рисования линий длиной более 16К — это просто даже уже не очень и смешно.

Новогодние интерьеры во всех студиях города! Один друг просил сфотать модель с его фамиком :) Получилось вот так!

Больше всего понравилась работа «Mermaid and Tree». Имхо, идеальное попадание в цвет и местами в форму. Автор реально шарит и в пикселарте и в эротике.

Так ведь я не спорю. И написал, что автор молодец, что попытался привнести в свою работу нечто большее, чем просто красивую форму. Да для меня это неприемлемо, но ведь зацепило!

Ты прав в том, что уровень допустимой пошлости — штука индивидуальная. Я понимаю, почему ты называешь её порнографией, так как работа предельно откровенная, но, с другой стороны, не было ли это целью конкурса? :)
Посмотрел работы предыдущих лет, там очень много крутейших сисек, но они не вызывают каких-то иных, кроме сугубо эстетических, чувств. Может быть, можно было как-то тоньше обыграть сам процесс, не так в лоб, но с задачей картинка Димы, имхо, справляется отлично.