Sea Dragon

[ace210]

15к тактов при отсутствии активных действий на игровом поле
для того чтобы сравнить скорость необходимо сравнивать модели в идентичных условиях

Но ведь и у тебя тоже нет активных действий. Вывод спрайтов никак не будет привязан к выводу фона. Сначала фон в строке, потом спрайты.

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

Да, у меня пока этого нету. Думаю. Надо сделать вывод фона по строкам, а не по столбцам как у меня сейчас. Буду переделывать однозначно. Я ведь только сейчас врубился, как же этот Zynaps устроен.

Я твой движок понял. В конечном итоге у меня будет примерно так же как и у тебя. Просто я хочу понять, где можно соптимизировать существенно чтобы уложиться во фрейм. Ведь в 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 экрана. У тебя очень похожий сейчас ландшафт по сложности. Поэтому разница несущественная, ею можно пренебречь сравнивая нас.

---------- Post added at 18:03 ---------- Previous post was at 17:56 ----------

ломаться постоянно в одном и том же месте

Тут надо еще угадать - как бы луч не прошел по строке в которой стерты спрайты, но еще не нарисованы. Ведь сейчас ты убрал из своего начального движка вывод пустого места. Ты не забыл, что спрайты надо еще стереть перед выводом фона?

[Advertiser]

[Lethargeek]

Ну и наворотили... сами себе трудности создаете... а у меня все времени нет вмешаться

Ладно, может к утру отпишусь подробно

[jerri]

Но ведь и у тебя тоже нет активных действий. Вывод спрайтов никак не будет привязан к выводу фона. Сначала фон в строке, потом спрайты.

у меня есть идеи как это реализовать

Да, у меня пока этого нету. Думаю. Надо сделать вывод фона по строкам, а не по столбцам как у меня сейчас. Буду переделывать однозначно. Я ведь только сейчас врубился, как же этот Zynaps устроен.

посмотрел как он работает? по моим объяснениям можно составить только общее представление

Я твой движок понял. В конечном итоге у меня будет примерно так же как и у тебя. Просто я хочу понять, где можно соптимизировать существенно чтобы уложиться во фрейм. Ведь в Zynapse 1 фрейм?

в Зинапсе от 2 до 3х фреймов
в зависимости от сложности местности и количества врагов

Оригинал Sea Dragon Atari есть еще 3-й уровень сложности. Там скорость скролла в 2 раза выше, но тоже на 2 пиксела. Вот поэтому и надо стремиться к 1 фрейму. Вот поэтому я тебя и напрягаю, ты не обижайся. Ведь свой код ты лучше знаешь - быстрее переделываешь. А я в это время параллельно свои исследования делаю.

в 1 фрейм точно не уложится зато можно поднять скорость в 2 раза

Тут у нас классическая ситуация память-скорость. У меня ландшафт занимает больше памяти, но выводится быстрее. У тебя, наоборот, мизер памяти под ландшафт, но выводится в 3 раза дольше. Надо найти золотую середину.

твою версию видел только вначале последние не смотрел

Так что такое 1 фрейм? я не понял. Это время между прерываниями?

фрейм - цикл игры за который обновляется экран
25 fps - 25 фреймов в секунду экран обновляется раз в 2 прерывания
12.5 fps - экран обновляется раз в 4 прерывания

У меня реальные первые 3 экрана. У тебя очень похожий сейчас ландшафт по сложности. Поэтому разница несущественная, ею можно пренебречь сравнивая нас.

не знаю надо смотреть

Тут надо еще угадать - как бы луч не прошел по строке в которой стерты спрайты, но еще не нарисованы. Ведь сейчас ты убрал из своего начального движка вывод пустого места. Ты не забыл, что спрайты надо еще стереть перед выводом фона?

нет не забыл там просто - если спрайты накладывать по XOR то и удалять можно также
просто получится что каждый спрайт рисуется по 2 раза

---------- Post added at 22:18 ---------- Previous post was at 22:13 ----------

Ну и наворотили... сами себе трудности создаете... а у меня все времени нет вмешаться

Ладно, может к утру отпишусь подробно

мы не создаем трудностей
а от тебя сначала визуализацию своих идей в виде снапшота

[Lethargeek]

Бегло просмотрел исходники ace210 и последние сообщения

Замечания

Во-первых, спрайты в общем случае "все сразу" стирать нельзя - будут мерцать
Или нужно будет ВЕСЬ экран успеть обновить, пока луч на бордюре
Все-таки 32 "четвертайла" 8x8 маловато будет

Возможен такой вариант:
Когда луч на бордюре, не только рисуем спрайты, но также
заблаговременно помечаем координаты для быстрого стирания
Потом пристроиться за лучом и последовательно заполнять строки
предварительно стирая спрайты в строке, если нужно

Далее - тайлы 8x8 слишком мелкие, раз уж все объекты в оригинале вчетверо больше
В итоге печать игрового поля неоправданно замедляется раза в полтора-два
Нужно взять "полутайлы" 16x8 (в сдвинутом виде 24x8, три байта в ширину)
Тайл печатать байтовыми столбцами - клиппинг проще получится
(левый так просто переходом внутрь той же процедуры)

Маска НЕ НУЖНА вообще - просто наксорить поверху левый байт
Только один нюанс - в тайле правой кромки левый байт должен быть инверсный
точнее не весь байт, а несколько младших битов (потому что ксорится на землю)

В таком случае одной универсальной процедуры может хватить на фрейм
Но лучше сделать косвенным переходом на отдельную процедуру печати каждого
(а уж там может сразу стоять переход на универсальную, если нужно)
Получим небольшое замедление универсальной, однако снизится пиковая нагрузка
Например при печати длинных тросов, обрывов или отвесных шахт
Нужны будут отдельные процедуры не на каждую фазу, а на весь объект
(сдвиг один раз в начале, потом простое копирование вниз)

По цветности - атрибуты необязательно сдвигать синхронно
Можно подбирать, как лучше будет смотреться

Например, хотим красную землю и черные мины, так вот если к примеру рисуем
кромку и она высунулась на соседнее знакоместо только на пару пикселей
то эти несчастные пиксели в цвет земли красить необязательно
таким образом края будут мерцать, но меньше

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

По хранению тайлового поля пока ничего не скажу
Не было времени разбираться

[jerri]

Бегло просмотрел исходники ace210 и последние сообщения

Замечания

Во-первых, спрайты в общем случае "все сразу" стирать нельзя - будут мерцать
Или нужно будет ВЕСЬ экран успеть обновить, пока луч на бордюре
Все-таки 32 "четвертайла" 8x8 маловато будет

стирать можно, но есть нюансы
см Red heat, Commando

Возможен такой вариант:
Когда луч на бордюре, не только рисуем спрайты, но также
заблаговременно помечаем координаты для быстрого стирания
Потом пристроиться за лучом и последовательно заполнять строки
предварительно стирая спрайты в строке, если нужно

Далее - тайлы 8x8 слишком мелкие, раз уж все объекты в оригинале вчетверо больше
В итоге печать игрового поля неоправданно замедляется раза в полтора-два
Нужно взять "полутайлы" 16x8 (в сдвинутом виде 24x8, три байта в ширину)
Тайл печатать байтовыми столбцами - клиппинг проще получится
(левый так просто переходом внутрь той же процедуры)

посмотри внимательнее не только его исходники но и мои
также смотри RoboCop, Stormlord

многа многа букаф

По хранению тайлового поля пока ничего не скажу
Не было времени разбираться

жаль - ведь это самое интересное

по поводу спрайтов
можно не красить лодку вообще - если правильно все рассчитать
то пока лодка не въедет в землю то ее и не покрасит

наилучший вариант - 4 байта цвета на 16х16 тайл

т.е земля вида
/
//
будет покрашена правильно
бч
чч

[ace210]

можно не красить лодку вообще

Как это лодка не окрасится? Очень даже окрасится и проплывет рядом, я ведь делал много много постов назад. http://zx.pk.ru/attachment.php?attac...2&d=1257502626

посмотри внимательнее не только его исходники но и мои

Не надо смотреть. В исходниках долго разбираться, да и там далеко не всё оптимизировано. А если исходники игрушек - то лучше, кто знает их, так (на пальцах) разъясняйте. Лучше, народ, давайте обсуждать алгоритмы, концепции, форматы хранения...

[jerri]

Как это лодка не окрасится. Очень даже окрасится и проплывет рядом, я ведь делал много много постов назад. http://zx.pk.ru/attachment.php?attac...2&d=1257502626

вот смотри у тебя есть чистая вода
(пустота)она имеет цвет белый на синем
и у тебя есть скала
(грунт) она имеет цвет чорный на синем

когда ты рисуешь лодку у тебя есть 2 варианта
красить ее или не красить

если ты ее красишь
то при наезжании чуть чуть (на 1 пиксел, не факт что лодка даже залезет корпусом на камни) она покрасит камни в цвет лодки

если ты ее не красишь (именно лодку) она остается цвета местности т.е на фоне воды будет белая на синем, на камнях - чёрная на синем

примеры - Three weeks in paradise там есть режим включить\выключить цвет

опять же как

Не надо смотреть. В исходниках долго разбираться, да и там далеко не всё оптимизировано. А если исходники игрушек - то лучше, кто знает их, так (на пальцах) разъясняйте. Лучше, народ, давайте обсуждать алгоритмы, концепции, форматы хранения...

нуу скажем так - не всегда нужна сверхточная оптимизация, чаще всего хватает достаточной

[ace210]

неоправданно замедляется раза в полтора-два

Не согласен. Очень мест в ландшафтов, где много резких обрывов. И в этих местах, если выводить полутайл, т.е. 3 байта, то 1 байт однозначно печататься будет как ненужный. время.
Полутайлы оправданы бы были если б ландшафт состоял преемущественно из пологих спусков.
У нас ландшафт преемущественно из отвесных обрывов. Особенно это видно где шахты.

---------- Post added at 13:00 ---------- Previous post was at 12:53 ----------

Думаю, что с шахтами то получиться? они ведь шириной 2 знакоместа. Видимо надо поступить с минами так:красить ее в черный только если она не в шахте. А если в шахте, то не подкрашивать и она будет цвета земли.

---------- Post added at 13:37 ---------- Previous post was at 13:00 ----------

Маска НЕ НУЖНА вообще - просто наксорить поверху левый байт
Только один нюанс - в тайле правой кромки левый байт должен быть инверсный
точнее не весь байт, а несколько младших битов (потому что ксорится на землю)

Не получается. Вот 2 тайла. Правый тайл таким способом выведется, а левый - нет.
Нужно чтобы перед выводом не было ничего в экране.
Или знать какой из тайлов крайний левый и выводить его просто.

Вообще, в этом что-то есть... Надо подумать.

[jerri]

Вот здесь ссылочка на оригинальную версию Sea Dragon

---------- Post added at 15:28 ---------- Previous post was at 15:24 ----------

А здесь версия для атари

[Кирлиан]

Вот здесь ссылочка на оригинальную версию Sea Dragon

Помню ее по Агату, скорее всего в режиме Apple ][.
По тем временам увлекательная игра!