Рассказываю.Сообщение от newart
В 1996 году я делал воксели, они страшно тормозили, и памяти под 3D карту не было.
В 1997 стал делать столбцами, но по воксельному алгоритму. Делал долго, первые варианты были без текстуры, потом никак не мог настроить перспективную коррекцию. Плевался от GENS, но ничего другого у меня не было. Не сразу ещё допёр до группировки столбцов в стены (наш препод по компьютерной графике, например, вообще не рассматривал такой вариант).
В 1998 допёр до интерполяции результатов сканирования - тоже нетривиально: например, в Stellar Contour нет интерполяции.
В 1999 перешёл с атрибутов на чанки, до этого наивно надеялся на мультиколор.
В 2000 наконец придумал, как быстро выводить спрайты без кучи копий, правда, при этом они закрывают стены. Многие вольфы на ZX вообще не дошли до этого этапа.
Потом уже допёр, что сканирование можно делать двойными шагами, что при движении можно картинку ухудшить, перебирал всякие быстрые варианты вывода чанков. Последний вообще был в 2003 году, когда Cyberjack и JtN написали статью в Adventurer.
В 2004 году сделал первую 3D игру.
В 2005 начал вторую - уже квест. Но не хватило 128К памяти. Поэтому я перешёл на АТМ Turbo и стал писать другие игры. Пробовал, между прочим, переделать Wolf 2004 под АТМ экран, но результат выглядел ужасно. Текстуры надо было рисовать сразу под много цветов, а не 8 стандартных. Тем более что многие текстуры там вообще не цветные. Пробовал делать мипмэпинг (на 512К), но интересного результата не получилось.
Когда уже всё забросил, допёр, как быстро отрисовывать столбцы (процедура под каждый масштаб), но при этом нельзя дрыгать головой. А мне почему-то казалось, что без дрыгания головой играть неинтересно (в Wolf 2004 это дрыгание давало иллюзию лучшей детализации). Поэтому делать не стал. Только потом поиграл в оригинальный Wolfenstein 3D и понял, что дрыгание не нужно. Нужно много FPS. А их взять неоткуда. Хотя потом посчитал разблюдовку, сколько куда уходит времени в Wolf 2004, можно ускорить раза в полтора. Но всё равно мало.
Думал, как делать без текстур, стал анализировать вариант с заливкой по EOR-fill - на C-64 этот метод популярен, а на спеке его юзал только RST7, да и тот никому не говорил. И тут просёк, что так можно и с текстурами, если в чистом ч/б. Правда, таких текстур у меня не было, а те, которые в Doom beta и в Citadel, мне не нравились. Увидел Wolf на TI-83 и вдохновился. Всё это было уже в 2009 году.
В пиксельном разрешении сразу встали проблемы с точностью математики. Воксельные алгоритмы пришлось отбросить сразу. Взял классический алгоритм с умножениями-делениями. Причём нельзя сканировать сначала горизонтальные стены, потом вертикальные - получаются глюки на стыках стен. Надо сканировать и те, и другие, а это значит 8 веток по каждому из 8 основных-побочных направлений. Я эти ветки сделал макросами с параметрическими метками, чтобы не писать 8 раз одно и то же. Почему-то ни один ассемблер, кроме ALASM, не умеет параметрические метки.
Сначала я сделал все вычисления в 16 битах (чтобы хоть как-то работало, хоть и медленно), потом отбрасывал биты, переводил в логарифм и т.д., пока наконец не смог сделать полноэкранный вольф в 8-битной математике.
Потом перебирал разные способы интерполяции. Самая быстрая оказалась, как ни странно, рекурсивная. Хотя я потом думал над нерекурсивной, которая по идее будет ещё чуть быстрее, но ей надо больше памяти.
Там ещё надо было нарисовать все эти текстуры, чтобы ещё минимизировать число цветопереходов на каждом столбце, ибо чем больше, тем тормознее. А максимум 17 цветопереходов на столбец. Это ограничение очень чувствуется, когда пытаешься нарисовать надписи!
Первая версия движка (от декабря 2010 года) была в польской деме Critical Error. Вместе с картинкой, музыкой и записью кнопок она впритык заняла всю память. То есть в принципе игру сделать было нельзя, разве что тупой лабиринт типа Wolfdemo 1/2/3/3.5. И вообще, FPS был всё ещё слишком низкий для шутера, даже в окошке 24x16 знакомест (размер настраивается в исходнике). Сама картинка разваливалась в процессе рисования. Даже сделал настройку для double-buffering'а на 128К.
Стал пробовать низкое разрешение - смотрелось фигово. Потом додумался до заливки пола и потолка атрибутами. Для этого сначала пришлось собрать статистику, по которой 90% стен ниже 8 знакомест.
Потом спрайты. Чтобы их выводить поверх стен, надо сначала сделать EOR-fill не на экран, а в память. А потом перебрасывать на экран. Это лишний тормоз. Поэтому я сделал на каждом столбце флажок, что этот столбец уже залит по EOR-fill и на нём можно рисовать спрайты. При выводе на экран такие столбцы не заливаются, а просто перебрасываются. Сами спрайты выводятся по пиксельным столбикам, а не по знакоместным. То есть надо учесть флажок залитости в нужном знакоместном столбике и, если надо, залить его - с учётом того, что низкие столбцы надо ещё почистить (там кака под атрибутами), ещё с учётом того, что спрайты в lores, а фон в hires. А ещё надо учесть масштаб отрисованных стен на каждом столбике. В Wolf 2004 тупо смотрелось - спрайт ближе, чем стена на середине этого спрайта, при той графике глюки было незаметны, а в пиксельной графике ещё как заметно!
И вообще, где хранить сами спрайты? Памяти нету. Поэтому я сократил таблицу умножения, стало не 128 масштабов, а 64. Долго подбирал, какие масштабы брать, какие не брать - искал максимальный, минимальный, с каким шагом брать мелкие масштабы, с каким крупные. Там в бейсиках можно видеть формулу пересчёта из новых масштабов в старые - она получена регрессией, потом ещё на глазок подгонялась.
Потом вот сделал низкое разрешение только на близких стенах и монстрах, теперь хотя бы компромисс между качеством и скоростью.
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
