• avatar sq
  • 1
голожопые девки это возмутительно для компьютерного журнала

Не вижу никаких противоречий, у вас же не компьютерный журнал
Надо дописывать, уже требуется :)
Редактор specscii почти есть)
  • avatar Vinnny
  • 0
ты главное твори, а мы оценим :)
и ракурсы/одежды можно по разному экспериментировать.
Да, например, Sayman говорит, что голожопые девки это возмутительно для компьютерного журнала! :) Тогда я буду фотать те же сиськи-попки, но в кроп-кадре будет только соответствующая желзяка.
  • avatar Vinnny
  • 0
у меня есть выбор? :)
Как насчет такой идеи: я зафотаю милаху с амигой. Никаких обложек :)
Никогда не умел в бейсик, и для меня RANDOMIZE USR 15619:REM всегда были какой-то хардкодовой магией. Теперь, наконец, понимаю, что это и зачем.
  • avatar idxi
  • 0
Для стартеров «в двух словах» самое оно :)
  • avatar Vinnny
  • 0
буду ждать кошерную амигу :)
в 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К — это просто даже уже не очень и смешно.