NoNaMe RTS - "за неделю на изичах"

[Biland]

Проект NoNaMe.

Концепция

1. Ориентир процессор Z80, 1МБ, KMouse, NeoGS, в т.ч. периферия SD, Mp3
2. Вспомогательные модули кода без привязки к адресу.
3. Простота их загрузки - обёртка для SD-Card, TR-Dos и т.п.
4. Работа с NeoGS. Проигрывание mp3.
5. Простая работа с памятью, куча, аллокатор.
6. Использовать RAM0 в cpu0.
7. Стандартный граф. движок для менеджера памяти ATM подобных, с избавлением от промежуточных буферов.

[свернуть]

Заметки

Генерация фона:
1. Для генерации фона используется нулевая страница ОЗУ (RAM0), подключённая вместо ПЗУ. В ней генерируется код типа ld bc,NNNN: push bc;, где далее в NNNN по методу "змейка" подставляются данные фона.

2. Добавлено в генерацию фона, отображение атрибутов (опционально). После вывода фона с атрибутами, можно обновлять только экран, если не было скролла.

Минусы:
- фон заранее подготовленный статичный (ничего там не крутится, не вертится);
- в cpu0 подставлять RAM0 не много ZX умеют;
- почти целая страница кода;
- только на весь экран (full screen)

[свернуть]

Файлы (27.02.2025)

NeoPlayerLightR165.zip - NeoGS r165, для SJAsm
FAT ImageEmpty1Gb.zip - Образ раздела FAT, пустой, 1ГБ

[свернуть]

to be continue...

[Advertiser]

[Deadly]

Ку, посмотрел код, не во всё вникал, но неплохо, не плохо..
Если, я правильно понял, там таблица жирная из минусов, но скорость нормас )

[Biland]

Это меня NEO SPECTRUMAN наставил на путь истинный, ссылаясь на Алона. Про таблицу минусы не догнал немного, если LD, PUSH, то 12288кБ, без атрибутов, плюс байты восстановления стека и прыжок обратно в код программы. Скорость отрисовки фона самая быстрая выбиралась, но минус в том, что к RAM7 вывод спрайтов без буфера не подвязать. Вот если бы в cpu0 можно было разные страницы подключать, один какой-то клон подобное умеет, не помню какой.

[Deadly]

Про таблицу минусы не догнал немного, если LD, PUSH, то 12288кБ, без атрибутов, плюс байты восстановления стека и прыжок обратно в код программы.

Я про этот минус и говорю, правда, насчитал поменьше, таблицу, в 192 тайла * 4 (LD & PUSH) = 768 байт.
У меня на тайл уходит 674 такта, и нет такой таблицы жирной в 13кб + можно рисовать в 2 экрана. В любом случае, каждый подход имеет право на жизнь, для каждого своего случая.

[Biland]

У тебя фон около 130000 тактов занимает. В данном случае, подготовка фона столько же занимает. Но потом за фрейм (в половину быстрее) кидает фон в экран, но за счёт 13кБ. Кидать фон могу в любую страницу, только адрес в стек установить. Больше всего раздражает, что нужно страницы щёлкать со спрайтами и тайлами. Этот способ специфичен, бесспорно, используется магия Медноногова.) Но с уровнем развития ZX (камень в огород "Повелителю"), считаю, что нужно использовать 1024кБ, Turbo - 7 или 14Мгц, страницы в cpu0.

[Deadly]

В данном случае, подготовка фона столько же занимает

Не каждый фрейм обновляется всё. Имеется буфер в 192 байта, отвечающие за каждый тайл, в который меняются биты, отвечающие что обновлять (бэкграунд, туман и т.п.)
т.е. ~ 15к уходит, если ни чего не меняется в кадре. если тайл требуется перерисовать, тогда плюсуй к 15к на тайл 674 тактов на его обновление и т.д. и т.п.

[^m00h^]

Интересны алгоритмы ИИ.

[Biland]

Deadly, правильно ли понял? Фон рисуется в экран, когда спрайт бежит, то буфер в 192 байта обрабатывается и на основании его идёт рефреш фона, не всего фона? Типа, как у Лорда?

[Deadly]

Аблосютли, не знаю как там у великого "Лорда Драгона" сделано, но это нормальная практика, зачем рисовать, то, что не нужно?

[Biland]

У Повелителя похоже тоже самое. Я по удалёнке последние видео смотрел, на 3,5МгЦ видно, что при прокручивании экрана, когда на спрайты возвращается происходит торможение, сразу jackal вспомнился с его лесом. А там ещё снаряды, стрелы нужно прикрутить. Как у Медноногова стрелы центрованы по тайлам, либо как в jackal без привязок. Там тоже рефреш долбить будет.

И, вообще, я посчитал, что более 200к тактов нужно будет, для 50 fps.

^m00h^, это совсем интересная тема. Особенно про волновой метод в RTS. ) Кто-то Повелителя подколол на начальном этапе. Думаю, что можно воспользоваться алгоритмом с олимпиады по программированию. Найти все маршруты, из одного города в другой. Типа двумерный массив ((3,6),(7,3),(6,4),(x1,x2)), где x1 - это город с которого выходим, x2 - это город куда приходим. Найти все маршрут по городам задачка на несколько строк, города (checkpoint) можно установить сразу, либо в процессе игры генерировать. Как бы виртуальные дороги, юниту немного времени уйдёт досчитать маршрут от ближайшей точки дороги к пункту назначения. В warcraft для этого есть дороги, они и приводят куда нужно. Здесь можно сделать, также дороги невидимые от checkpoint до checkpoint (если их нет в анимации). Этот приём в играх используется, в Settler совсем явно. Но это только набросок для ZX.