Не очень понятно. Что делает обработчик? Какой размер буфера? Что в нем хранится?
Вид для печати
Не очень понятно. Что делает обработчик? Какой размер буфера? Что в нем хранится?
размер буфера = высоте экрана в тайлах т.е 10 байт
но сам буфер намного больше
потому как с шагом в 10 в нем будут хранится ID обьектов
т.е если у тебя нарисован спрайт по адресу 0,0 и имеет размер 16 на 16
то прибавляешь 1 к первому байту
и в ячейку буфера с номером (1)*10 сохраняешь ID
кстати по поводу карты
берем такую вот карту
0 0 0 0 0 0 0 1 2 2 2 2 3 0 0 0
0 0 0 0 0 0 1 2 2 2 2 2 2 3 0 0
0 0 0 0 0 1 2 2 2 2 2 2 2 2 3 0
0 - вода
1 - склон
2 - земля
3 - склон2
когда выводишь на экран
есть смысл поменять вот так
4 0 0 0 0 0 0 1 2 0 0 2 3 4 0 0
4 0 0 0 0 0 1 2 0 0 0 0 2 3 4 0
4 0 0 0 0 1 2 0 0 0 0 0 0 2 3 4
игнорируем вывод 0 - совсем игнорируем
а 4 будет водой, т.е для коррекции цвета
Сделай все-таки в своем варианте нормальный ландшафт с нормальными тайлами. Чтобы видно было очертания ландшафта нормально.
А то так непонятно, как все же переходы будут выводится.
Если будешь приводить исходники, то, пожалуйста, ставь побольше комментариев.
Их же делать нада ;)
Комментирую свой последний вариант (ревизия 15)
Я ландшафт храню в виде:
0-й байт - номер тайла (младший байт адреса)
1-й байт - резерв
2,3-й байты - уже расчитанный адрес в экране.
...
...
Еще отдельно к ландшафту хранится отдельно массив, каждый байт которого - есть количество тайлов в столбце.
0-й байт - это младший байт адреса данных тайла уже расчитанный опять же. Старший берется уже при выводе. Я назвал его Bank тайлов, и вычисляется в зависимости от сдвига на 0,2,4,6 пикселей.
Печать ландшафта осуществляется быстро, т.к. адреса экрана уже расчитаны и хранятся с самом ландшафте. Если ландшафт сдвигается на 1 знакоместо, то уменьшается 2-й байт(это малдший байт адреса экрана) у всех тайлов в видимой части ландшафта.
Вот, народ, я и думаю. Как нужно хранить ландшафт? Как я придумал, или как Jerri, т.е. просто классическая байтовая матрица?
---------- Post added at 14:52 ---------- Previous post was at 14:45 ----------
Да, что-то я сомневаюсь в сдвигах тайлов. А где там маска для вывода? Нужны серьезные доработки.Цитата:
Сообщение от jerri
Должно работать хз - я не тестил
смотрим любуемся :)
цвет грунта наверное имеет смысл сделать песчано-желтый :) а то черный страшно выглядит
Вложение 14317
Без маски не обойтись если нужно изобразить пологий спуск, а не резкий обрыв.
Желтый не плох, но тогда атмосфера таинственности, думаю, будет нарушена. Ведь тут как? плывешь в неизвестном лабиринте-пещере, не знаешь какая мина всплывет, всё в тени...
А с желтым получиться, что ты на веселом солнечном пляже.
во первых зачем и здесь маска это раз?
все делается тайлами
во вторых как именно ты ее собираешься использовать?
изобрази ландщафт как я сфотал 2 тайла рядом, всё и увидишь.
---------- Post added at 17:06 ---------- Previous post was at 17:03 ----------
В общем, ты поясни на пальцах свой алгоритм еще раз. Как я понял есть байтовая матрица размером 16 на 10. Каждый байт означает номер тайла. Пробегаемся по матрице слева-направо, сверху вниз. Для каждого тайла вычисляем адрес его данных и выводим в экран. Адрес в экране не вычисляется, а "бежит" по ячейкам 2x2 знакоместа. Так?
что-то вродеЦитата:
Сообщение от ace210
но есть нюансы
ты не очень хорошо понял тайловую концепцию
в аттаче твои 2 тайла находятся по центру вверху
у тебя есть 4 тайловых набора сверху вниз проскролленые вправо
А если таким будет ландшафт? Вложение 14320
Т.е. первый тайл тот же, а правый уже другой.
Сделал клиппинг. (Revision 16) https://seadragon.svn.sourceforge.ne...oot/seadragon/
а снапшот где?
Да там тоже самое, только клиппинг по краям экрана сделан.
Вложение 14322
Ты же конструируешь пейзажи :)Цитата:
Сообщение от ace210
значит будешь точно знать какие комбинации будут
а каких не будет :)
в идеале должен быть полностью построенный лабиринт из которого уже и создавать тайловый массив
потому как комбинации
1,3,0 и 1,4,0
могут быть одной и той же комбинацией надо смотреть уже на месте
кстати вот более правильный вариант
Изучаю дальше твой код.
1) Как данные депакируются? На очередном шаге просто добавляются данные в конец, на который указывает указатель? Но если так, то как быстро заполнится память устаревшими данными? Не хватит никакой. А если, допустим, переносить кусок на каком нибудь шаге (ну допустим через 5 экранов), то на это нужно будет время.
Хотя нет. В твоем случае на экран 10*16=160 байт. Ландшафт имеет длину 40 экранов. Получается к концу ландшафта будет 6400 байт распаковано. В принципе, вопрос снимается. А если так мало получилось, так вообще можно не паковать.
2) Прикинул скорость. Вот такой ландшафт рисуется 45Ктактов.
Вложение 14327
У меня на аналогичный тратится 14Ктактов. Причем я использую маску при выводе для левых байтов тайла (на это тратится очень много времени из расчета на 1 байт). Правда я пока не выводил атрибуты. Ну, добавится 2Ктакта у меня не больше.
Это и понятно, почему так у тебя. Много времени тратится на ненужный пропуск 0-х тайлов, а также на переход на след строку адреса. Еще размер тайлов играет большую роль в таком расхождениии. У тебя они больше в 2 раза. Соответственно, выводить надо в 2 раза больше байтов.
Я же предлагаю хранить адреса уже расчитанные в данных ландшафта и просто потом на шаге пробежаться по младшим байтам и inc их сделать.
обьем буфера 256 байт :)Цитата:
Сообщение от ace210
когда указатель дойдет до конца буфера
он начнет его сначала
карта одного экрана занимает 17*10=170 байт
надо посмотреть :)Цитата:
Сообщение от ace210
ты уже решил проблему со стиранием\рисованием спрайтов под лучем?
Думаю. Но кажется, врубаюсь. В этот буфер самое главное на 1 объект записывается адрес обработчика-рисователя и данные за этим адресом. Данные имеют формат специфичный для каждого обработчика-рисователя.Цитата:
Сообщение от jerri
Потом снимаем с этого буфера адрес, если он не 0, то передаем управление этому адресу, т.е. jp.
И так для каждой строки знакоместной вслед за лучом.
Вот только сколько этих буферов? Для каждой строки свой, заполненный ранее? Или он один и заполнение происходит после разбора этого буфера при выводе каждой строки?
---------- Post added at 14:38 ---------- Previous post was at 14:33 ----------
Вот размышляю, какой размер тайла все же нужен?
Если 16на16, то будет клэшинг аттрибутов просто огромный. 8на8 меньше, но тоже будет.
16на16 ландшафт занимает в 4 раза меньше места, но при выводе каждого тайла надо выводить в 3 раза больше байтов. (в прошлом посте я ошибся). Т.е. 3 байта ширина и 16 байт высота = 48 байт выводится. В случае 8на8 2 байта ширина и 8 высота, 16 байт выводится. Теперь и понятно почему общее время у тебя ровно в 3 раза больше моего.
Где-то я читал в каком-то журнале, что для спектрума 16на16 размер тайла самый идеальный. Не последовать ли этому совету?
поправочка - у меня 2 байта ширины и 8 байт высоты
но выводится 2 на 16 да :)
так что 16х16 :)
чтобы не было такого клэшинга надо еще 4 байта на каждый тайл под цвет
Получается 32 байта выводится при печати тайла. Непонятно тогда, почему у тебя так долго. К тому же у тебя количество тайлов меньше раза в 1,5. Можешь посмотреть у себя почему так долго? Можно ли как нибудь существенно ускорить?Цитата:
Сообщение от jerri
В противном случае ты рискуешь не успеть отрисоваться за прерывание. Т.к. сложность экрана приведенного мной - типичная. Есть еще пещеры. Там в 2 раза больше тайлов получится.
процедуры не оптимизированные :)
у меня демонстрация алгоритма а не демонстрация движка :)
сейчас дорисую версию 7 и посмотрим
Версия 7
1 оптимизирована карта 0 - не отображается :)
2 оптимизирован вывод на экран, жестко
Что-то не пойму. Все равно 45Ктактов процедура Refresh работает. Нужно существенное ускорение. Чтобы хотя бы за 30Ктактов.
голубой бордюр - время отрисовки данных на экране
остальное время занимают расчеты
в 1 фрейм ты по любому не уложишься
значит в 1 фрейм надо вывести все на экран
с учетом количества объектов и способа вывода можно все прекрасно успеть вывести
Почему? У меня всего 15Ктактов. Еще с лихвой времени стереть спрайты, и нарисовать их. Всё в 1 фрейм.Цитата:
Сообщение от jerri
А ты хочешь за 2 прерывания - 1 перерисовку? Жаргон этот мне не очень превычен. Это называется 2 фрейма?
fps - frame per second
обновление экрана
25 fps - 25 кадров в секунду
50 fps - максимум для Спектрума :)
15к тактов при отсутствии активных действий на игровом поле
для того чтобы сравнить скорость необходимо сравнивать модели в идентичных условиях
основная идея моего движка - вывод на экран графики последовательно
т.е обновил графику в строке - вывел спрайты из этой строки
таким образом не возникнет ситуации когда на экране есть фон, но нет персонажей
такая ситуация автоматически отсекается.
при таком алгоритме даже если и возникнет ситуация с проходом луча, то картинка не будет ломаться постоянно в одном и том же месте.
кроме того оптимизация ради оптимизации - ересь ;)
сейчас необходимо сделать реальный уровень со всеми переходами и уже посмотреть как оно будет
Но ведь и у тебя тоже нет активных действий. Вывод спрайтов никак не будет привязан к выводу фона. Сначала фон в строке, потом спрайты.Цитата:
Сообщение от jerri
Да, у меня пока этого нету. Думаю. Надо сделать вывод фона по строкам, а не по столбцам как у меня сейчас. Буду переделывать однозначно. Я ведь только сейчас врубился, как же этот Zynaps устроен.Цитата:
Сообщение от jerri
Я твой движок понял. В конечном итоге у меня будет примерно так же как и у тебя. Просто я хочу понять, где можно соптимизировать существенно чтобы уложиться во фрейм. Ведь в Zynapse 1 фрейм?
Оригинал Sea Dragon Atari есть еще 3-й уровень сложности. Там скорость скролла в 2 раза выше, но тоже на 2 пиксела. Вот поэтому и надо стремиться к 1 фрейму. Вот поэтому я тебя и напрягаю, ты не обижайся. Ведь свой код ты лучше знаешь - быстрее переделываешь. А я в это время параллельно свои исследования делаю.
Тут у нас классическая ситуация память-скорость. У меня ландшафт занимает больше памяти, но выводится быстрее. У тебя, наоборот, мизер памяти под ландшафт, но выводится в 3 раза дольше. Надо найти золотую середину.
---------- Post added at 17:53 ---------- Previous post was at 17:50 ----------
Так что такое 1 фрейм? я не понял. Это время между прерываниями?
---------- Post added at 17:56 ---------- Previous post was at 17:53 ----------
У меня реальные первые 3 экрана. У тебя очень похожий сейчас ландшафт по сложности. Поэтому разница несущественная, ею можно пренебречь сравнивая нас.Цитата:
Сообщение от jerri
---------- Post added at 18:03 ---------- Previous post was at 17:56 ----------
Тут надо еще угадать - как бы луч не прошел по строке в которой стерты спрайты, но еще не нарисованы. Ведь сейчас ты убрал из своего начального движка вывод пустого места. Ты не забыл, что спрайты надо еще стереть перед выводом фона?Цитата:
Сообщение от jerri
Ну и наворотили... сами себе трудности создаете... а у меня все времени нет вмешаться :mad:
Ладно, может к утру отпишусь подробно ;)
у меня есть идеи как это реализоватьЦитата:
Сообщение от ace210
посмотрел как он работает? по моим объяснениям можно составить только общее представлениеЦитата:
Сообщение от ace210
в Зинапсе от 2 до 3х фреймовЦитата:
Сообщение от ace210
в зависимости от сложности местности и количества врагов
в 1 фрейм точно не уложится зато можно поднять скорость в 2 разаЦитата:
Сообщение от ace210
твою версию видел только вначале последние не смотрелЦитата:
Сообщение от ace210
фрейм - цикл игры за который обновляется экранЦитата:
Сообщение от ace210
25 fps - 25 фреймов в секунду экран обновляется раз в 2 прерывания
12.5 fps - экран обновляется раз в 4 прерывания
не знаю надо смотреть :)Цитата:
Сообщение от ace210
нет не забыл :) там просто - если спрайты накладывать по XOR то и удалять можно такжеЦитата:
Сообщение от ace210
просто получится что каждый спрайт рисуется по 2 раза
---------- Post added at 22:18 ---------- Previous post was at 22:13 ----------
мы не создаем трудностей :)Цитата:
Сообщение от Lethargeek
а от тебя сначала визуализацию своих идей в виде снапшота ;)
Бегло просмотрел исходники ace210 и последние сообщения
Замечания
Во-первых, спрайты в общем случае "все сразу" стирать нельзя - будут мерцать
Или нужно будет ВЕСЬ экран успеть обновить, пока луч на бордюре
Все-таки 32 "четвертайла" 8x8 маловато будет
Возможен такой вариант:
Когда луч на бордюре, не только рисуем спрайты, но также
заблаговременно помечаем координаты для быстрого стирания
Потом пристроиться за лучом и последовательно заполнять строки
предварительно стирая спрайты в строке, если нужно
Далее - тайлы 8x8 слишком мелкие, раз уж все объекты в оригинале вчетверо больше
В итоге печать игрового поля неоправданно замедляется раза в полтора-два
Нужно взять "полутайлы" 16x8 (в сдвинутом виде 24x8, три байта в ширину)
Тайл печатать байтовыми столбцами - клиппинг проще получится
(левый так просто переходом внутрь той же процедуры)
Маска НЕ НУЖНА вообще - просто наксорить поверху левый байт
Только один нюанс - в тайле правой кромки левый байт должен быть инверсный
точнее не весь байт, а несколько младших битов (потому что ксорится на землю)
В таком случае одной универсальной процедуры может хватить на фрейм
Но лучше сделать косвенным переходом на отдельную процедуру печати каждого
(а уж там может сразу стоять переход на универсальную, если нужно)
Получим небольшое замедление универсальной, однако снизится пиковая нагрузка
Например при печати длинных тросов, обрывов или отвесных шахт
Нужны будут отдельные процедуры не на каждую фазу, а на весь объект
(сдвиг один раз в начале, потом простое копирование вниз)
По цветности - атрибуты необязательно сдвигать синхронно
Можно подбирать, как лучше будет смотреться
Например, хотим красную землю и черные мины, так вот если к примеру рисуем
кромку и она высунулась на соседнее знакоместо только на пару пикселей
то эти несчастные пиксели в цвет земли красить необязательно
таким образом края будут мерцать, но меньше
Если хотим к тому же белую лодку, нужно сначала проверить атрибут фона
Если красный, а лодка высунулась несильно, ксорим поверху, не трогая атрибут
В остальных случаях фон лучше затереть и поверху напечатать белым
У земли будет не так заметно, а мину можно и затереть (все равно взорвется)
Или можно сделать покадровым чередованием - см. Wheelie к примеру
(там правда спрайт целиком мерцает, а можно только краем)
По хранению тайлового поля пока ничего не скажу
Не было времени разбираться
стирать можно, но есть нюансыЦитата:
Сообщение от Lethargeek
см Red heat, Commando
посмотри внимательнее не только его исходники но и моиЦитата:
Сообщение от Lethargeek
также смотри RoboCop, Stormlord
жаль - ведь это самое интересноеЦитата:
Сообщение от Lethargeek
по поводу спрайтов
можно не красить лодку вообще - если правильно все рассчитать
то пока лодка не въедет в землю то ее и не покрасит
наилучший вариант - 4 байта цвета на 16х16 тайл
т.е земля вида
/
//
будет покрашена правильно
бч
чч
Как это лодка не окрасится? Очень даже окрасится и проплывет рядом, я ведь делал много много постов назад. http://zx.pk.ru/attachment.php?attac...2&d=1257502626Цитата:
Сообщение от jerri
Не надо смотреть. В исходниках долго разбираться, да и там далеко не всё оптимизировано. А если исходники игрушек - то лучше, кто знает их, так (на пальцах) разъясняйте. Лучше, народ, давайте обсуждать алгоритмы, концепции, форматы хранения...Цитата:
Сообщение от jerri
вот смотри :) у тебя есть чистая водаЦитата:
Сообщение от ace210
(пустота)она имеет цвет белый на синем
и у тебя есть скала
(грунт) она имеет цвет чорный на синем
когда ты рисуешь лодку у тебя есть 2 варианта
красить ее или не красить
если ты ее красишь
то при наезжании чуть чуть (на 1 пиксел, не факт что лодка даже залезет корпусом на камни) она покрасит камни в цвет лодки
если ты ее не красишь (именно лодку) она остается цвета местности т.е на фоне воды будет белая на синем, на камнях - чёрная на синем
примеры - Three weeks in paradise там есть режим включить\выключить цвет
опять же как
нуу скажем так - не всегда нужна сверхточная оптимизация, чаще всего хватает достаточной :)Цитата:
Сообщение от ace210
Не согласен. Очень мест в ландшафтов, где много резких обрывов. И в этих местах, если выводить полутайл, т.е. 3 байта, то 1 байт однозначно печататься будет как ненужный. время.Цитата:
Сообщение от Lethargeek
Полутайлы оправданы бы были если б ландшафт состоял преемущественно из пологих спусков.
У нас ландшафт преемущественно из отвесных обрывов. Особенно это видно где шахты.
---------- Post added at 13:00 ---------- Previous post was at 12:53 ----------
Думаю, что с шахтами то получиться? они ведь шириной 2 знакоместа. Видимо надо поступить с минами так:красить ее в черный только если она не в шахте. А если в шахте, то не подкрашивать и она будет цвета земли.
---------- Post added at 13:37 ---------- Previous post was at 13:00 ----------
Не получается. Вот 2 тайла. Правый тайл таким способом выведется, а левый - нет.Цитата:
Сообщение от Lethargeek
Нужно чтобы перед выводом не было ничего в экране.
Или знать какой из тайлов крайний левый и выводить его просто.
Вообще, в этом что-то есть... Надо подумать.
Вот здесь ссылочка на оригинальную версию Sea Dragon
---------- Post added at 15:28 ---------- Previous post was at 15:24 ----------
А здесь версия для атари
Помню ее по Агату, скорее всего в режиме Apple ][.Цитата:
Сообщение от jerri
По тем временам увлекательная игра!
Игрушка - чума на TRS-80! Как из пулемета из торпедных аппаратов... :-)
---------- Post added at 16:49 ---------- Previous post was at 16:34 ----------
В настоящее время - игры в псевдографике, я знаю, существует как целое исскусство. Как-то запускал Doom в псевдографике - весело. Там всё так здорово детализируется простыми символами ASCII, да еще цветными, просто дух захватывает!