А, ну просто из граф. функций пока выбросил все лишнее (все равно переделывать), и вообще... спрайт рисую вот так:

Т.е. циклы идут в топку. Это еще в 90-м году понял, когда 2-ю Ягу делал. Если вот именно так отрисовывать, выигрыш по скорости очень приличный. Это тот случай, когда память жалеть не надо, надо жалеть скорость))

Правильное решение. Тоже после многочисленных экспериментов в те годы пришел к тому, что лучше потратить десятки тактов, динамически генерируя и пропатчивая без условных/безусловных переходов процедуру, зато потом сэкономить тонну процессорного времени, выполняя такой "развернутый" упрощенный цикл. Если удастся восстановить мои игровые проекты ~1995 года, Вам интересно будет взглянуть на мои способы решения.

Потрясающая инициатива с Norton подобной оболочкой! Какой текущий статус?

Ну это я так, просто как мысли.

А кажется и это совсем не плохо, а если на два экрана разделить то вообще жир.

На два экрана разделить, это как? я чет не понял. Это коробка размером в 2 экрана? Боюсь тогда слишком много сдвигать придется... скорости не хватит боюсь.

Я не художник, но пока вот зарисовка уже в современном Топазе...

Ворота маленькие вышли))

Идея новой игры для системы "ТОПАЗ", аналог вашего же футбола но хоккей, с золотым кубком на заставке!!!!
http://agatcomp.ru/Gamez/Futbol.shtml

..пойду прилягу, аж давление поднялось...

Да, я тоже финал смотрел сегодня)) Валидол сплошной.

В 92-м, я пытался нарисовать в Топазе хоккей, вот картинка. Но тогда не поддерживалась цветная графика 256х256. Сейчас можно что-то и получше сделать...

..пойду прилягу, аж давление поднялось...

Теперь возможно переключать граф. страницы через NMI достигая как бы плавности движения объектов. Но увы, я толком это не вижу)) В эмуляторе нельзя синхронизировать 50Гц развертки Агата и 60-80Гц моего монитора. Но тем не менее качество изображения стало лучше. Нет мерцаний объектов.

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

Ну  и главное: по команде background восстанавливается фон экрана под всеми спрайтами, которые были занесены в буфер фона. Очень удобно. Т.е. теперь при движении объектов нет нужды стирать их по отдельности. Т.е. теперь просто рисуешь объекты, инфа о них попадает в буфер и в след. итерацию скопом стираешь одной командой. Запись в буфер можно включать/выключать, а также есть команда очистки буфера.

О скорости: если без лагов, то:
При переключении графики на i-e таймерное NMI (fps=50/i), рисовал движущиеся спрайты поверх фона, т.е. спрайты с наложением по маске (фон естественно не портится):

Результаты такие: fps/количество объектов/размер объектов

fps=50     3шт.  16х16
fps=25     7шт.  16х16
fps=17     11шт. 16х16
fps=12.5  14шт. 16х16

fps=50     11шт.  8х8
fps=25     22шт.  8х8
fps=17     33шт.  8х8
fps=12.5  44шт.  8х8

fps=50     6шт.    8х16 или 16х8
fps=25     12шт.  8х16 или 16х8
fps=17     19шт.  8х16 или 16х8
fps=12.5   25шт.  8х16 или 16х8

Это все для цветной графики 256х256. Шаг движения спрайтов 4 точки. Результаты конечно не очень. Оптимизировать отрисовку конечно можно еще чуть-чуть, но принципиальных улучшений ждать не приходится. В других граф. режимах, думаю будет получше.

А вот и пример программы, 10 спрайтов 16 на 16 бегают по экрану на фоне лабиринта.

Что пока есть. Пока только цветной режим 256 на 256
В системе существует страница спрайтов 16Кб и страница с лабиринтами тоже 16Кб. И еще экран (будет две страницы по 16Кб)
Лабиринт с элементами может иметь размеры 256х64 или 128х128 или 64х256.
Размер элемента в лабиринте (для этого граф. режима) либо 8x8 точек, либо 16x16.

Функции:

display x,y,n              выводит спрайт элемента лабиринта с кодом n по координатам x*4, y*4

sprite c,d                  задает размер спрайта 8*с на 8*d точек

draw x,y,a,b,             выводит спрайт на экран по координатам х*4,y*4. a*8 и b*8 координаты верхнего левого угла спрайта
                                на странице со спрайтами. размер спрайта задается командой sprite.

xdraw x,y,a,b,e,f        выводит спрайт с маской на экран по коорд. х*4, y*4. a*8,b*8, координаты верхнего левого угла
                                спрайта на странице спрайтов, e*8, f*8 координаты левого верхнего угла маски. Размер спрайта
                                задается командой sprite.

gdraw x,y,i,j              восстанавливает фон, отрисовывая элементы лабиринта. x*4,y*4 координаты левого верхнего угла
                                восстанавливаемой области, i*4,j*4 размер восстанавливаемой области экрана.

window a1,b1,a2,b2  задает координаты окна (умноженные на 4) в котором отрисовывается лабиринт (спрайты можно выводить по всему экрану).

loke k,p                     отрисовывает часть лабиринта в окне. k,p координаты элемента в лабиринте, который будет отрисован
                                в вехнем левом углу окна, заданно командой window...

typelab r,t                 r-задает тип элементов лабиринта(r=0 соответствует 8 на 8 точек; r=1 соответствует 16х16),
                                t- тип лабиринта (t=0 256х64; t=1 128x128; t=2 64x256).

clrscr                        очистка экрана.

Есть еще функции вывода текста и переменных, но они еще не закончены:

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

??                            вывод значения переменной в 16-ричной системе

???                         вывод значения переменной в 16-ричной системе (выводит один символ, если значение меньше 16)

htab a; vtab b         задает координаты вывода a*4, b*4 (пока не доделано)

color c,f                  c-цвет текста, f-цвет фона

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

Так вот, со спрайтами, какие функции обработки спрайтов еще в языках программирования есть? Я особо то ни на чем не программировал никогда)) ну кроме ассемблера.

Пока результаты такие, если fps=17 то на экране успевает восстановить фон и нарисовать с маской 11-12 объектов размером 16 на 16 точек каждый. Если fps=25, то 8 таких объектов. Но поскольку шаг движения спрайта 4 точки, то всего выходит 61 отрисовка объекта при движении от края до края экрана. Для fps=25 это слишком быстро))

ЗЫ. Нигде не ставлю проверок на границы экрана, дабы не уменьшать скорость отрисовки. Т.е. проверка на косяки - на совести программиста)))

FAT на агате - всё таки решение не очень хорошее. Именно сама таблица. Скорость поиска свободных блоков падает. Таблица занимает большое фиксированное пространство - при сбое в одном секторе теряется информация сразу о группе файлов + диск становится не доступен (если читать всю таблицу сразу, а не по запросу, но тогда возрастает время на позиционирование головок). Невозможно отформатировать диск если хоть один сектор таблицы имеет физический сбой (ну то есть диск царапанный). На FAT32 ведь вернулись к отдельной маске свободных блоков - то, что в эпле было сразу (VTOC).

Да согласен, минусы есть и серьезные... В MS-DOS кажется копия FAT хранилась или могла сохраняться...

Есть у меня свой ДОС, 92-го или 93-го года. Даже исходники есть благодаря вам. Вот там как раз FAT  реализована. Я тогда просто копию делал с какой-о книжки о MS-DOS.

В любом случае, сейчас я дисковую систему трогать не буду, сейчас надо компилятор переделывать. Граф. операторы улучшать.

А вот еще вопрос, в конечном итоге можно будет готовые игры запускать автономно или только через Топаз?

Изначально конечно хотелось автономно. Но есть две проблемы.

Первая-это необходимо вместе с бинарником записывать необходимые функции (библиотеки), шрифты, функции Дос. Это сделать при желании можно. Хотя общий объем получается приличным.

Вторая проблема заключается в том, что у меня свой ДОС. По сути как стандартный, но с ограничениями и различиями: другой каталог файлов, формат записи файла в каталог и т.п. Я еще и переделать хотел под ДОС, в котором будут уже полноценные подкаталоги, FAT и т.п. ... И тут сложность в том, что в процессе игры надо будет подгружать спрайты, лабиринты или как планируется, записывать данные о игре (таблица рекордов, например).

Выход пока вижу только один, это создание загрузочных дисков для конкретной игры (лодерунер кажись так сделан был, нет?). Ибо боюсь стандартный ДОС все это не потянет... Хотя конечно надо подумать...
------------------------------------------------------------------------------------------------------------
Сейчас занимаюсь переделкой под систему с доп. ОЗУ. Размер бинарного файла игры будет до  44-46КБ (это только код, без спрайтов, лабиринтов  и прочего), размер текстового буфера 32Кб, возможность связывать текстовые файлы, наличие двух переключаемых экранных страниц (для плавности отображения))) и т.д. Бинарник, кстати, макс. размера в 46Кб это текст программы более 64КБ))

Собственно, доп. ОЗУ уже поддерживается, сейчас делаю поддержку файлов размером до 188 блоков. На скрине, компиляция игры, что выше выложена. Свободной памяти осталось 29КБ, а будет еще лучше, после введения новых граф. функций.