Просмотр полной версии : УКНЦ brucelee скрины
В середине октября потел над этим проектом, но сейчас к сожалению некогда им заниматься, так что выложу пока скрины.
В чём собственно идея, думаю понятно -- портировать Bruce Lee с 8-разрядных Atari на УКНЦ.
Оригинал: http://www.mobygames.com/game/atari-8-bit/bruce-lee/screenshots
Игровой экран размером 160 x 176 пикселов.
Вот собственно мои скрины, полученные в процессе работы: 55491
Сделать успел немного -- подготовил часть спрайтов (не все), вывод спрайта по координатам.
Работал ещё над декомпиляцией оригинальной игры. Но поскольку опыта в Atari у меня маловато, не успел досконально разобрать.
В общем, пока просто картинки "на потрындеть".
https://img-fotki.yandex.ru/get/5207/7448436.8/0_9e49a_5e5084e1_orig.png (https://fotki.yandex.ru/next/users/nzeemin/album/84251/view/648346)
https://img-fotki.yandex.ru/get/27216/7448436.8/0_9e49b_f3481ca2_orig.png (https://fotki.yandex.ru/next/users/nzeemin/album/84251/view/648347)
https://img-fotki.yandex.ru/get/9155/7448436.8/0_9e49c_3eb7d598_orig.png (https://fotki.yandex.ru/next/users/nzeemin/album/84251/view/648348)
Ух ты шикарный проект :) это уже не клад, а куда серьезней игра. Вы в перспективе планируете продолжить работу над этим проектом?
УКНЦ по истинен не хватает "хороших" игр. Для меня как я уже где-то писал хорошие игры это нечто иное чем клад, а например любые всем любимые игры хиты с любых 8 битных платформ не учитывая простеньких игр типо клада, пакмена и подобных.
Ещё несколько мыслей на тему.
В игре есть несколько активно перемещающихся спрайтов -- Брюс, ниндзя и Зелёный Ямо. Плюс фонарики, которые нужно собрать. В некоторых комнатах есть ещё всякие "косилки" и резко вырастающие "деревья", которые убивают. Все эти объекты я думаю делать через ЦП.
Также есть статичный фон, но некоторые комнаты отличаются тем, что есть большие подвижные части фона -- и это уже я думаю делать через ПП.
Для ЦП доступно два плана из трёх. Поэтому спрайты я сделал трёхцветными -- четвёртый цвет это прозрачный.
Для ПП остаётся третий план, т.е. фон получается двуцветным.
С тем чтобы спрайты ЦП не интерферировали с фоном, три цвета спрайтов в палитре повторяются дважды -- для 0 и 1 в третьем плане.
В итоге, получается что на игровом экране будет 5 разных цветов -- 3 спрайтовых и 2 для фона.
Если захочется больше цветов, то схему отрисовки нужно менять, например, всё рисовать через ПП.
Дальше, есть проблема как хранить комнаты -- всего в игре их 20 (пока я не понял как это сделано в оригинале).
По сути, комната это огромный 4-цветный спрайт размером 160x176 пикселов, но каждую вторую строку фона можно дублировать.
Тогда для 4-цветного фона получается 40*176/2 = 3520 байт -- это довольно много, 20 комнат займут 70400 байт, а нужно ещё где-то хранить логику комнат (где как стоят стенки, где висят фонари итп.)
Выход -- либо делать простейшее сжатие (RLE), либо описывать комнату как набор расставленых спрайтов + сами спрайты.
пока я не понял как это сделано в оригинале
Судя по всему, тайлы 8х8 (принимая во внимание графику Атари, скорее 4х8, или даже 4х4, если каждая вторая строка повторяется), и блоки из тайлов (координаты, размер, номера тайлов). Ну и дефолтный номер тайла для бэкграунда (или другой тип блока, где все номера тайлов одинаковые).
DJs3000, очень прошу портированный Никитой LODE RUNNER не обзывать кладом! И уж точно в один список писать
RISE OUT, LODE RUNNER и пакмена - это как бы сказать немного не правильно.
а куда серьезней игра
На вкус и цвет, не играл, но на Атари это ещё догадаться надо, что это человечек. Но то, что на УК-НЦ не так много игр и картинки из эмулятора интересны получились спору нет.
У меня практичный вопрос - процедура вывода спрайтиков универсальная или привязана к конкретному проекту?
Я (поскольку Зеленоградский спрайтовый движок для ПАСКАЛЯ до сих пор не обнаружен) всё ещё время от времени
думаю думку о его воскрешении, это как эмулятор RT-11 для консоли окошек. Вопрос вот в чём, способна ли процедура
выводить спрайт по глобальной метке :: и координатам? Как там с режимом отрисовки, планы, цветность? В общем тех.
подробностей бы )
Пока писал - не увидел, частичный ответ выше ! Спасибо.
- - - Добавлено - - -
Таблица спрайтов ?
Неужели памяти не хватит если спрайты линкуются с основной программой?
Теперь нет задачи по сети передовать и что бы в сети школьной работало, так что программируем для РМП, что гораздо расширяет возможности
hobot,
См. https://github.com/nzeemin/uknc-brucelee/blob/master/MAIN.MAC строка 225 -- процедура для ЦП вывод 4-цветного спрайта шириной 8 пикселов и высотой R5 (хоть в высоту экрана).
Для вычисления адреса/смещения на экране из XY -- см. строка 204.
- - - Updated - - -
Таблица спрайтов ?
Неужели памяти не хватит если спрайты линкуются с основной программой?
Теперь нет задачи по сети передовать и что бы в сети школьной работало, так что программируем для РМП, что гораздо расширяет возможности
В оригинале игра занимает 30224 байт, т.е. там используется какой-то способ эффективной упаковки и описания комнат, надо только его понять и повторить.
https://youtu.be/fCAVFO4aCs0 -- игра Bruce Lee на Atari
https://youtu.be/1_wbYAL3EU8 -- на MSX
вряд ли там экраны сделаны спрайтами, вероятнее всего тайлами.
Если вся карта имеет прямоугольный вид, то расчёт в какой экран ГГ перешёл рассчитывается банально. Но если карта имеет витиеватый вид (далеко не прямоугольная) - то ещё я бы посоветовал сделать табличку на какой экран переходит ГГ при пересечении правой\верхней\левой и нижней границы соответственно, иногда приходится в этой таблице ещё и координаты появления в комнате хранить (если допустим ГГ ушёл в соседний экран снизу, а в соседнем должен появиться сверху)
- - - Добавлено - - -
В оригинале игра занимает 30224 байт, т.е. там используется какой-то способ эффективной упаковки и описания комнат, надо только его понять и повторить.Всё уже давно придумано до нас:
ТАЙЛЫ(спрайты определенного размера): если допустим игровое поле 256*192 пиксела (я буду говорить спектумовскими размерами, мне так привычнее) - то есть 32*24 знакоместа , и если размер "тайла" составляет 2на2 знакоместа (16*16 пикселей), то весь экран уместится в 16*12 байт = 192 байта
Я может снова ничего дельного не добавлю, но глядите (я ютубовское видео глянул), так или иначе
уровни (не зависимо от цветов) состоят из однообразных объектов (спрайты из таблицы), уровень может компактно храниться в виде матрицы из номеров спрайтов в таблице? Надо только отрисовывать их заранее и переключать страничку,
что бы в глазах игрока они как лампочка загорались, а не сверху вних рисовались, поскольку УК-НЦ в этом плане "тормозит"
- - - Добавлено - - -
строка 225 Спасибо! Разберу, кажется ничего сверхсложного нет и похоже то что нужно )
- - - Добавлено - - -
таблица и сами спрайты хранятся по глобальным меткам в отдельных obj и просто проект потом линкуется в 1 целое.
Все счастливы ! Как-то так?
Дальше, есть проблема как хранить комнаты -- всего в игре их 20 (пока я не понял как это сделано в оригинале).
Что мешает сделать подгружаемые?
Судя по всему, тайлы 8х8 (принимая во внимание графику Атари, скорее 4х8, или даже 4х4, если каждая вторая строка повторяется), и блоки из тайлов (координаты, размер, номера тайлов). Ну и дефолтный номер тайла для бэкграунда (или другой тип блока, где все номера тайлов одинаковые).
Вы оказались правы, там просто символьный режим, цветной шрифт размером 8x8 пикселей на символ.
Если учесть что каждая вторая строка повторяется, получается что каждый уровень это 160x88 пикселей, 20*11 = 220 байт на комнату.
На все комнаты так получается 220 * 20 = 4400 байт.
Что мешает сделать подгружаемые?
То что можно сделать неподгружаемые.
Комнаты в любом случае удобно описывать как набор октетов -- плашек 8x1 пикселей, это занимает одно слово.
Была идея сделать описание комнат в виде набора паттернов и тайлов. Паттерн -- это когда левые 4 пикселя октета такие же как правые 4 пикселя -- тогда паттерн описывается одним байтом, а вторым байтом можно указать сколько раз его повторить.
Тайлы я предполагал сделать подобным образом -- указываем номер тайла и его высоту, предполагается что тайлы будут хранится отдельно, и тайлы могут перекрываться.
Дальше я подготовил все экраны в виде набора битмапов и написал на C# программу которая раскладывает экраны на тайлы и паттерны и считает сколько все экраны и каждый в отдельности займут в памяти. Получилось в районе 35 КБ и сильно ужать этот объём уже не получалось. Напомню, нежатые комнаты занимают 70400 байт.
Потом я вернулся к анализу оригинальной программы на Atari и увидел что реально фон экрана там это "символы", т.е. тайлы размером 8x8.
Сел за переделку программы подготовки экранов, сделал так что тайлы всегда высотой 8 и начинаются только по смещениям кратным 8 -- это дало некоторое ужатие. Попробовал сделать без паттернов вообще -- ещё ужалось. Пробовал тайлы высотой 4, 12, 16 -- но это уже не дало уменьшения объёма, получается что экраны действительно оптимизированы под тайлы 8x8. После этого я уже занимался экспериментами в сторону объединения наборов тайлов между экранами.
Текущий итог -- все экраны занимают около 15 КБ -- 4400 байт на экраны в виде перечисления номеров тайлов, остальное ушло на тайлы; используется три набора тайлов.
nzeemin, случайно наткнулся на потрясающую игру (точнее на неофициальный порт для DOS), оказалось она есть везде окромя наших PDP-пишек (хотя может быть на БК0010 под другим названием???). В этом видео (что самое интересное) сравниваются версии с разных платформ
https://www.youtube.com/watch?v=5NDEWuju0o4
И DOS версия игрушки >
http://www.old-games.ru/game/screenshots/6391.html
на вкладке ФАЙЛЫ на страничке с игрой интересный комментарий к архиву
(видимо это поскольку официального порта для ПЦ не было различные "самоделы" ???)
Различные версии игры, распространявшиеся через сеть (BBS, Интернет, Фидо).
http://www.old-games.ru/game/download/6391.html
Поработал ещё над экранами.
Сделал проверку -- генерацию экрана по собраным тайлам, как на картинке ниже.
Обнаружил что некоторые элементы упустил, допилил конвертер.
Текущий итог -- все экраны занимают 17264 байт (4400 байт индексы тайлов плюс 12864 байт сами тайлы) -- это только графика, без информации об объектах.
https://img-fotki.yandex.ru/get/41340/7448436.9/0_a3470_a5439078_orig.png
nzeemin, проект остановлен?
jerri, пока не до него, совсем.
https://img-fotki.yandex.ru/get/41340/7448436.9/0_a3470_a5439078_orig.png
красиво, интереснее в градациях серого посмотреть )
- - - Добавлено - - -
http://f23.ifotki_.info/org/8d7ec90605c47694f6ef66dfacc667845a9a41292865552.pn g
- - - Добавлено - - -
Мощно! )
А стоит ли вообще надеяться и верить? )))
Lethargeek
14.04.2020, 17:44
Поработал ещё над экранами.
Сделал проверку -- генерацию экрана по собраным тайлам, как на картинке ниже.
может, стоило применять разные палитры для разных комнат?
на атари задник 4 цвета, а выглядит намного разнообразнее
А стоит ли вообще надеяться и верить? )))
Смотря на что надеяться и во что верить.
Пока движения вперёд нет совсем.
- - - Updated - - -
может, стоило применять разные палитры для разных комнат?
на атари задник 4 цвета, а выглядит намного разнообразнее
То есть первое сообщение темы вы не смотрели.
Lethargeek
15.04.2020, 16:24
То есть первое сообщение темы вы не смотрели.
а при чём тут первое сообщение? на скринах последних - палитр не видно, и причина этого непонятна
Oleg N. Cher
15.04.2020, 16:44
См. https://github.com/nzeemin/uknc-brucelee/blob/master/MAIN.MAC строка 225 -- процедура для ЦП вывод 4-цветного спрайта шириной 8 пикселов и высотой R5 (хоть в высоту экрана).
Для вычисления адреса/смещения на экране из XY -- см. строка 204.Репозиторий удалён, ссылочка битая.
Не буду оригинален и повторюсь: есть ли наработки по выводу спрайтов, не кратных по ширине восьми?
есть ли наработки по выводу спрайтов, не кратных по ширине восьми?
забудь об этом ) 8 и погнали, добро пожаловать в мир 8 кратных чисел )))
а при чём тут первое сообщение? на скринах последних - палитр не видно, и причина этого непонятна
в своём репертуаре? ничего читать не буду - я борюсь "с чем ты там борешься"???
только вот в этом разделе и уж в этой теме точно тебе место только пока как читателю )
прояви уважение разочек к автору темы, который ПКМ не языком треплет, а делает сверх затребованные многими людьми проекты и игры для УК-НЦ уже несколько зарелизил... почитай начало и тогда может и понятнее станет?
Репозиторий удалён, ссылочка битая.
Не буду оригинален и повторюсь: есть ли наработки по выводу спрайтов, не кратных по ширине восьми?
Репозиторий уведён в приватные когда гитхаб это позволил сделать. Разработка же по сути на начальной стадии.
Некратные 8 пикселов (по ширине) спрайты меня лично не интересуют, с практической точки зрения это просто не нужно.
Не буду оригинален и повторюсь: есть ли наработки по выводу спрайтов, не кратных по ширине восьми?
Спроси Manwe, в БКшной теме, он такое делал. Только спрайты придется хранить боком и при выводе поворачивать на 90 градусов :)
Oleg N. Cher
15.04.2020, 18:27
Ну, Manwe и не такое делал, он вроде даже делал монохромные спрайты, которые раскрашивались на лету. Но то БК, а мне надо УКНЦ.
Зачем поворачивать?
Lethargeek
15.04.2020, 18:37
в своём репертуаре? ничего читать не буду - я борюсь "с чем ты там борешься"???
только вот в этом разделе и уж в этой теме точно тебе место только пока как читателю )
это ты в своём репертуаре - я вопрос по теме задал, а ты офтопишь
так что уж кому-кому, а не тебе здесь указывать
почитай начало и тогда может и понятнее станет?
вот сам и прочитай сначала, а не гадай
- - - Добавлено - - -
спрайтов на экране немного, мелких, неужели даже столько комп не тянет в 8 цветах, что приходится на плоскости разбивать?
Но то БК, а мне надо УКНЦ.
В чем разница? Принцип тот же. Тебе главное понять очевидное - чтобы спрайт был не кратен байту он в памяти должен лежать на боку. Т.е. строки и столбцы меняешь местами. Медленно, поскольку вывод побитный. (но единственное преимущество этого алгоритма - экономия памяти). Если памяти не жаль можешь побитно не весь байт выводить, хоть два бита из байта.
Lethargeek
15.04.2020, 18:49
чтобы спрайт был не кратен байту он в памяти должен лежать на боку. Т.е. строки и столбцы меняешь местами. Медленно, поскольку вывод побитный.
может, а не должен, можно иначе же - спрайты рядом как одна картинка, отсекать маской (что, полагаю, всё-таки быстрее побитных выводов)
спрайты рядом как одна картинка, отсекать маской
Речь шла об алгоритме Manwe. Oleg N. Cher, забыл вам сообщить, что ему нужна универсальная процедура, для произвольного размера спрайтов. В случае с маской все же лучше если спрайты одного размера. Я вообще стараюсь даже байтовые операции использовать по минимуму. Так что мне это малоинтересно.
И вообще это не та тема где нужно обсуждать это.
Lethargeek
15.04.2020, 19:28
Речь шла об алгоритме Manwe.
там, где я прокомментировал - речь о принципе
ему нужна универсальная процедура, для произвольного размера спрайтов
ну тем более
И вообще это не та тема где нужно обсуждать это.
так почему же столько времени обсуждаете
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot