Программирование под ZX-Spectrum: 3D графика

По-любому Асм под zx попробуйте, ещё большее удовольствие получите. По сути тот же самый си, только вместо каждой одной сишной команды вам надо будет писать стандартную последовательность из нескольких ассемблерных комманд.

Как видно, в матрице присутствуют функции косинуса и синуса. Результат выполнения этих функций — вещественные числа.

Кстати, вы можете полностью отказаться от вычисления sin и cos рассчитав диапазон значений в момент запуска или просто создав массив. По примеру таблиц Брадиса только в электронном виде. Существенно ускорит работу.

И поддержу, истинное наслаждение получите только на asm ))

Вспоминаю те 1992...1995 годы со Спектрумом с теплотой. Для учебы занимался программированием радиотехнических расчетов на встроенном Basic, а как кульминация разработок - взялся делать уже на Ассемблере, зачем-то, графический редактор картинки, размером 2 х 2 полных экрана.
И только когда практически получилось через недельку возни, после ощщщщущуния кайфа от достижения цели, я вдруг понял, что ..... нахрен этот редактор никому и низачем не нужен :)

Я такое лет 15 назад под J2ME писал, там тоже вещественной нет арифметики. Только у меня камера была и текстуры. BSP по-моему не было, интерес иссяк. Текстурированный кубик примерно 64 пикселя на грань крутился на телефоне весьма бодро.

Для реализации перспективной проекции я использовал формулу, подсмотренную в книге М. Мозгового «Занимательное программирование», которую очень любил, когда начинал программировать на Delphi.

Спасибо, приятно :)

Оптимизацию надо всегда начинать с самого внутреннего цикла. Посмотрел Вашу функцию drawModel3D, и в ней внутренний цикл выглядит так:

Обратите внимание, что адрес, выделенный голубым, в каждом цикле вычисляется по 8 раз, вместо того, чтобы вычислить его один раз в начале тела цикла. Причем для такого процессора как Z80 это выражение довольно тяжелое по времени выполнения, так как у него каждая команда адресации минимум занимает 4 такта (максимум 21), а в этом выражении их скорее всего 4 (трудно сказать в какой именно код генерит компилятор). Далее можно один раз вычислить указатель на ".src" и ".dst", чтобы не вычислять их по 4 раза каждый.

SCREEN_DEPTH равен 50 как я посмотрел определение, но если его сделать 64, то можно заменить умножение (которого нет на Z80 и вы зависите от реализации библиотеки) на сдвиг (который в Z80 есть). В этой статье разобраны реализации умножения и деления на Z80, с анализом времени выполнения, и эти операции занимают от 250 до 1000 тактов процессора, в то время как сдвиг занимает 8 тактов (без учета затрат на загрузку операндов). Если глубина 64 не подходит, и надо именно 50, то умножение на 50 можно сделать так:

X*50 = X*32+X*16+X*2 = X<<5 + X<<4 + X<<1 (примерно в 10 раз быстрее умножения)

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

Аналогично функция processModel: "model3d->processedVerticies[i]" и "model3d->vertices[i]" вычисляются по шесть раз в каждой итерации цикла.

Аналогично цикл внутри функции multMatrix можно переписать, развернув внутренние циклы, и устранив повторные вычисление ссылки на строку матрицы во внутреннем цикле (пишу на условном языке без соблюдения синтаксиса С, просто чтобы смысл идеи показать):

for (int i = 0; i < 3; i++) {
		Matrix_I = matrix->values[i];
    res[i] = ((Matrix_I[0] * column[0]) >> 11) + ((Matrix_I[1] * column[1]) >> 11) + ((Matrix_I[2] * column[2]) >> 11);
    }
}

ROUND_COEFF нужно сделать 2048, вместо 2000 и все умножения и деления заменить на сдвиги.

Очень хорошая книга по оптимизации графики на компьютерах 90-х годов: Секреты программирования игр

И пока у Вас есть еще тригонометрические функции вместо таблиц, попробуйте прилинковать другую математическую библиотеку - оптимизация библиотек разная, по этой ссылке есть сравнение - похоже скорость может отличаться в разы.

На сях бесполезно. Без асма делать нечего. Даже в 2D. При этом он очень прост. Я в 3D на нем не лез, чутка в демосцену. В основном занимался геймдевом. И все же очень упоротой оптимизации, код генерации, предварительных расчётов делать там нечего. Все 3D строится строго на предсгенерированных таблицах для тригонометрии. Вылизанных до основания функциях умножения и деления.