Просмотр полной версии : Sea Dragon
Добро пожаловать!
Эта ветка создана для разработки игры Sea Dragon, оригинал которой есть на других платформах, но нет на ZX-SPECTRUM.
Вот на каких платформах была выпущена эта игра:http://www.trs-80.org/sea-dragon/
В качестве технического задания взята версия с Atari http://www.atarimania.com/game-atari-400-800-xl-xe-sea-dragon_4559.html
http://zx.pk.ru/attachment.php?attachmentid=13948&d=1256807899
Оригинальный ландшафт:14721
Игра на Atari появилась в далеком 1982 году и для своего времени была довольно прогрессивной.
Вот ссылка на сайт, на котором можно скачать оригинал, а также эмулятор Atari:http://vjetnam.hopto.org/
Проект объявляется открытым. Все желающие могут помочь в разработке. Сайт разработки https://sourceforge.net/projects/seadragon/
Исходные тексты проекта хранятся здесь http://seadragon.svn.sourceforge.net/viewvc/seadragon/
Можно помогать как советом, так и конкретными реализациями в коде.
Руководителем и администратором проекта назначается Андрей Жиглов http://zx.pk.ru/member.php?u=4949. Все желающие получить доступ на запись в репозиторий могут обратиться к нему напрямую.
---------- Post added 30.12.2010 13:46 ----------
Проект завершён. Всем спасибо.
Download TZX (http://p-monty.narod.ru/seadragontzx.zip)
Download SCL (http://p-monty.narod.ru/seadragonscl.zip)
Обсуждаем также здесь:
http://www.worldofspectrum.org/forums/showthread.php?t=31344
Пока только пробы. Вот что получается: http://zx.pk.ru/attachment.php?attachmentid=14102&d=1257502626
Сколл попиксельный. На всю ширину экрана. Высота скрола 160 пикселей.
Скролл за 2 прерывания. Сначала пристраиваюсь за лучом (скролл 72 линии), а потом - наоборот до луча(скролл 88 линий). Поэтому скролл плавный и без мельтешений.
1 линия скроллируется 652 такта командами POP HL, RL (HL),INC L, RL (HL),INC L, ... Быстрее вряд ли получится.
14103
Хочется скролл именно такой большой, как в оригинале. Опускаться до маленького окошка не желаю.
----------------------------------
Что-то мне не нравиться как цвета скроллируются. Може попробовать подкрашивать лодку (INK). Но тогда при подплыве вплотную к ландшафту будет подкрашиваться и он тоже.
Подскажите, как быть.
---------- Post added at 14:29 ---------- Previous post was at 14:07 ----------
Что то оно у тебя много тактов сжирает, при том что 80% экрана это залитый или пустой фон который скролировать не требуется...
Скрол надводной части тоже идет. Там будет тоже ландшафт. Поэтому пустой фон приходиться скроллировать тоже.
Скрол надводной части тоже идет. Там будет тоже ландшафт. Поэтому пустой фон приходиться скроллировать тоже.
Надводная это с влюченой яркостью?
Ну так скролируй ее честно, а остальное по необходимости. Думаю во фрейм можно уложиться. Скриншоты оригинала есть?
А как по необходимости? Это получается надо хранить массив - вот отсюда до туда не скролировать, оттуда, опять скроллировать... Вода будет изрезана всякими минами, выстрелами - не получиться. Вот только если к земле это применить... Но ее мало, сомневаюсь в целесообразности.
http://zx.pk.ru/attachment.php?attachmentid=13948&d=1256807899http://zx.pk.ru/attachment.php?attachmentid=13949&d=1256807908http://zx.pk.ru/attachment.php?attachmentid=13950&d=1256807913
---------- Post added at 15:49 ---------- Previous post was at 15:41 ----------
хотя, что-то в этом положительное есть... Можно попробовать! Это получается массив адресов в экране.
1 элемент этого массива(2байта) указывает на байт в экране, который надо скроллировать.
Но сомневаюсь, что удасться во фрейм уложиться.
1 линия скроллируется 652 такта командами POP HL, RL (HL),INC L, RL (HL),INC L, ... Быстрее вряд ли получится.
На Атари не спроста линии толщиной 3 пикселя...
Вероятно скролится только первая и потом копируется два раза вниз.
хотя, что-то в этом положительное есть... Можно попробовать! Это получается массив адресов в экране.
1 элемент этого массива(2байта) указывает на байт в экране, который надо скроллировать.
Но сомневаюсь, что удасться во фрейм уложиться.
А для чего в снапшоте скролятся атрибуты если ланшафт одноцветый?
- чтобы лодка была белая, а мины черные. А планирую мины не перерисовывать, а тоже скроллировать.
Для скорости можно скроллировать только те знакоместа, которые содержат информацию. А те, что содержат все 0 или все 0xFF, рисовать только атрибутами.
Можно чуть чуть поиграться, не врезаясь.
14106
Так что с цветами-то делать? Что-то думаю, вообще, сделать нецветной. Там еще мины будут глубоко в шахтах.
Так что с цветами-то делать? Что-то думаю, вообще, сделать нецветной. Там еще мины будут глубоко в шахтах.
Дык нормально, только вместо красного лучше черный.
Враги в игре есть?
Врагов нету.
Есть пушки и корабли. Не двигаются, только стреляют. А мины всплывают.
---------- Post added at 18:33 ---------- Previous post was at 17:40 ----------
На Атари не спроста линии толщиной 3 пикселя...
Вероятно скролится только первая и потом копируется два раза вниз.
Круто! Переделал на скорую руку скролл. Сэкономил 10440 тактов на прерывание!
Lethargeek
07.11.2009, 03:15
На Атари не спроста линии толщиной 3 пикселя...
Вероятно скролится только первая и потом копируется два раза вниз.
Не три, а два толщиной. Там сие ОДНА аппаратная линия.
Круто! Переделал на скорую руку скролл. Сэкономил 10440 тактов на прерывание!
Нафиг там вообще скролл как таковой? Памяти свободной много, а графики мало. Сделай на каждый сдвинутый спрайтайл отдельную процедурку с встроенной графикой (причем правый край тупо печатай без маски, чтобы прошлый кадр затирать). Выстрелы лучше ксоркой.
Не три, а два толщиной. Там сие ОДНА аппаратная линия.Всё равно намного быстрее пуш-поп её откопировать чем сдвигать....
Продолжаю исследования.
Оказывается, основные трудность не в том как заскроллироваться, а как отрисовать спрайты!
Да, сделал я копирование каждой второй линии. Стал думать как теперь отрисовать хотя бы лодку. Получился такой алгоритм:
1) Стереть лодку XOR, т.е. восстановить ландшафт
2) Заскроллировать ландшафт
3) Нарисовать лодку XOR в новом месте
Этот алгоритм усугубляется тем, что нужно все шаги проделывать за лучом, а не как попало. Т.е. по знакоместам снижаясь.
В общем, получается а-ля Zynaps. Там сделано именно так. За исключением, что ландшафт не скроллируется, а рисуется заново каждый кадр.
А вообще, нет ли какой книги типа с названием "Как устроены популярные игры на ZX"? Чтоб не изобретать велосипед.
там вообще скролл как таковой? Памяти свободной много, а графики мало. Сделай на каждый сдвинутый спрайтайл отдельную процедурку с встроенной графикой (причем правый край тупо печатай без маски, чтобы прошлый кадр затирать)
Вот и думаю, может в этом направлении и двигаться? Т.е. Zynaps полный. Заодно все исследования пригодятся для первостепенного проекта Fort Apocalypse.
Но тут не всё так просто. Графики-то ландшафтной не так уж мало. Еще спрайты-мины будут штук 7, выстрелы, корабли, глубинные бомбы.
Первоначально я планировал спрайтами рисовать только подвижные объекты, т.е. лодку, пару-тройку мин которые всплывают, выстрелы. 7 штук мин не надо в таком случае рисовать - они будут скроллироваться с ландшафтом.
Выкладываю для всеобщего исследования исходники.
Репозиторий SVN: https://seadragon.svn.sourceforge.net/svnroot/seadragon
Revision 12 сейчас.
Мож кто чего посоветует?
А вообще, нет ли какой книги типа с названием "Как устроены популярные игры на ZX"? Чтоб не изобретать велосипед.
Размечтался. :)
Этот алгоритм усугубляется тем, что нужно все шаги проделывать за лучом,
Почему не юзаешь 2-й экран?
Lethargeek
10.11.2009, 22:59
Но тут не всё так просто. Графики-то ландшафтной не так уж мало. Еще спрайты-мины будут штук 7, выстрелы, корабли, глубинные бомбы.
Первоначально я планировал спрайтами рисовать только подвижные объекты, т.е. лодку, пару-тройку мин которые всплывают, выстрелы. 7 штук мин не надо в таком случае рисовать - они будут скроллироваться с ландшафтом.
Ну не знаю... В оригинале вся игрушка 16К. Можно попробовать сделать в лоб - хранить все 8 сдвинутых экранов кольцевыми строками. Итого потребуется 160/2*8*32=20K.
Выкладываю для всеобщего исследования исходники.
Ты мне лучше другие исходники отдай ;)
Почему не юзаешь 2-й экран?
Потому что если делать скроллом, то неактивный экран надо уже скроллировать не на 1, а на 2 пиксела. На это уйдет в 1.5 раза больше времени.
---------- Post added at 11:04 ---------- Previous post was at 10:40 ----------
Итого потребуется 160/2*8*32=20K.
итого /32 = 640 байт на 1 столбец ландшафта.
...а длина ландшафта 1196 столбцов. =765К. Многовато. Только если под 1024К делать. Или делать подзагрузки (генерирование) через каждые 128К/20=6 экранов.
Для скорости можно скроллировать только те знакоместа, которые содержат информацию. А те, что содержат все 0 или все 0xFF, рисовать только атрибутами
на некоторых компах такие знакоместа будут с артефактами - будет каша на экране.
Памяти свободной много, а графики мало. Сделай на каждый сдвинутый спрайтайл отдельную процедурку с встроенной графикой (причем правый край тупо печатай без маски, чтобы прошлый кадр затирать).
Что-то думаю надо именно так и поступить. Грубый подсчет:
1) на экране максимум 80 тайлов 8x8 = 640 байт
2) если выводить 1 тайл на 2 знакоместа. *2 = 1280 байт надо вывести в область экрана.
3) 1 байт выводится 16 тактов грубо говоря *16 = 20480 тактов на прорисовку ландшафта.
Получается, ландшафт можно запросто нарисовать за 1 прерывание!
а выводить как-нибудь так ;)
pop bc
ld (hl),c
inc h
ld (hl),c
inc h
ld (hl),b
inc h
ld (hl),b
inc h
...
или
pop bc
ld (hl),c
inc l
ld (hl),b
inc h
ld (hl),b
dec l
ld (hl),с
inc h
...
:)
Lethargeek
11.11.2009, 16:13
Потому что если делать скроллом, то неактивный экран надо уже скроллировать не на 1, а на 2 пиксела. На это уйдет в 1.5 раза больше времени.
...и буржуи не поймут ;)
...а длина ландшафта 1196 столбцов. =765К. Многовато. Только если под 1024К делать. Или делать подзагрузки (генерирование) через каждые 128К/20=6 экранов.
Блин, я же просто про 8 сдвинутых теневых буферов толковал. Ландшафт точно так же тайлами с краю добавляется. В исходный экран без сдвига, а уже при переброске на экран в конце строки последний байтик сдвигаем и пишем в следующий буфер. В 48К все влезает, но минусы тоже есть.
Если же решил напрямую на экран тайлы кидать:
Что-то думаю надо именно так и поступить. Грубый подсчет:
1) на экране максимум 80 тайлов 8x8 = 640 байт
2) если выводить 1 тайл на 2 знакоместа. *2 = 1280 байт надо вывести в область экрана.
3) 1 байт выводится 16 тактов грубо говоря *16 = 20480 тактов на прорисовку ландшафта.
Получается, ландшафт можно запросто нарисовать за 1 прерывание!
Я считал по-другому. В общем случае тайловый столбец выглядит вот так, сверху вниз:
1. земля сплошная...
2. кромка или пушка
3. вода пустая...
4. кромка или мина
5. трос от мины
6. земля сплошная...
Сплошную землю и воду рисовать не надо - само получится. Итого три тайла 16x16 (и возможно трос 16x?) на столбец. На экране 16 полных столбцов или 15 плюс 2 обрезанных (с правым краем придется немного похимичить).
а печатать как-нибудь так ;)
Полутайл 8x16 (в сдвинутом виде 8x24) побайтно:
L1 C1 R1
L1 C1 R1
L2 C2 R2
L2 C2 R2
L3 C3 R3
L3 C3 R3
L4 C4 R4
L4 C4 R4
Движемся двойной змейкой "L1-L1-C1-C1-R1-R1-R2-R2-C2-C2-L2-L2-...",
причем левый край предыдущий тайл не портит, а вот справа останется чистая вода либо земля.
Первые четыре строчки:
ld a,(hl)
or L1
ld (hl),a
inc h
ld (hl),a
inc l
ld bc,C1R1
ld (hl),b
dec h
ld (hl),b
inc l
ld (hl),c
inc h
ld (hl),c
inc h
ld bc,C2R2
ld (hl),c
inc h
ld (hl),c
dec l
ld (hl),b
dec h
ld (hl),b
dec l
ld a,(hl)
or L2
ld (hl),a
inc h
ld (hl),a
inc h
...повторить то же самое на следующие четыре
Итого 72 байта, 360 тактов только на рисование, столько же для второго полутайла (плюс down_hl, если сразу печатать весь), минус в случае каждого конкретного тайла распиханные по регистрам совпадающие байты и пропуск вывода пустого по пустому. Трос универсальной процедурой можно быстро напечатать (на входе только сдвинутый байт и адрес). Всплывающие мины либо тупо размножить еще и по вертикальным кадрам, либо усложнить каждую процедуру (down_hl уже каждые две строчки).
Получилось без накладных расходов и спрайтов где-то минимум полфрейма на весь фон,
максимум... эээ... ну вряд ли вдвое больше ;)
Должны уложиться, главное - ненароком луч не переехать.
Если я нигде не обсчитался ;)
Итого три тайла 16x16
а как же тайлы просто ландшафта - (земля+вода)? Там же куча разнообразий переходов.
а может эта, - скроллировать rl (hl) не весь экран, а только то, что нужно? :)
Lethargeek
11.11.2009, 19:49
а как же тайлы просто ландшафта - (земля+вода)? Там же куча разнообразий переходов.
Ты про сами кромки, что ли? Да не так уж их много. На каждый тайл (на все 8 сдвинутых фаз) уйдет меньше килобайта процедурами. Еще можно разными полутайлами верх-низ комбинировать. Зато справа автоматически тянется нужный хвост (вода или сплошная земля). Для особых случаев вроде мины в шахте можно добавить дополнительные кромки, которые выглядят, как сплошной квадрат. Этих может быть несколько в ландшафтном столбце, зато печатаются они очень быстро.
---------- Post added at 19:49 ---------- Previous post was at 19:43 ----------
а может эта, - скроллировать rl (hl) не весь экран, а только то, что нужно? :)
а может эта, - ветку внимательно почитаешь? ;)
Убивает низкая скорость
сдвиг лодки на 1 пиксель за 2 фрейма убивает динамичность в 0
за 2 фрейма лодка должна двигаться на 2 пикселя
и земля тоже, если надо реальной как в оригинале динамики
ну собственно технология то есть :)
скроллировать rl (hl) не весь экран, а только то, что нужно?
По скорости получится то же, что и если перерисовывать то что нужно, т.е. тайлами. Т.к. информацию о том где скроллировать надо еще обработать. Да еще в этом случае мины надо нарисовать поверх того, что заскроллировали (а скроллируем в этом случае только края ландшафта ведь?).
---------- Post added at 10:14 ---------- Previous post was at 10:13 ----------
Буду делать тайлами. Сделаю - напишу.
---------- Post added at 10:18 ---------- Previous post was at 10:14 ----------
меньше килобайта процедурами
Что-то уж сложно.
Может всё таки просто тайлы выводить одной процедурой, а не зашивать их(тайлы) в множество процедур?
---------- Post added at 10:21 ---------- Previous post was at 10:18 ----------
Да, и задействую, всё же, второй экран. Чтобы не заморачиваться с лучом.
Lethargeek
12.11.2009, 14:31
Что-то уж сложно.
Да что там сложного-то? Схема-то одна.
Если надо, могу немного погодя в закрытый подробнее написать, чтоб тут не засорять.
Может всё таки просто тайлы выводить одной процедурой, а не зашивать их(тайлы) в множество процедур?
Так медленно же будет
Да, и задействую, всё же, второй экран. Чтобы не заморачиваться с лучом.
Да нафиг он не нужен, ежели с умом подойти
Пускай бедолаги буржуи смогут запустить на своих реалах ;)
Если надо, могу немного погодя в закрытый подробнее написать, чтоб тут не засорять
А что, пиши тут. По теме ведь.
Зато бедолаги буржуи смогут запустить на своих реалах
А что у них нет второго экрана? 4 бит в #7FFD не переключает что ли?
Так медленно же будет
Ну, допустим. Вот я только что оценил количество разннобразий тайлов только одного перехода земля-вода. получилось 32 тайла. Это что? 32 процедуры делать?
Lethargeek
12.11.2009, 16:51
А что, пиши тут. По теме ведь.
Нунах, простынищи развешивать. Может, лучше вообще по почте.
А что у них нет второго экрана? 4 бит в #7FFD не переключает что ли?
У них очень много фирменных 48-х реалов.
Ну, допустим. Вот я только что оценил количество разннобразий тайлов только одного перехода земля-вода. получилось 32 тайла.
А мне кажется - меньше там. Видимость одна.
Это что? 32 процедуры делать?
Сколько потребуется. А что такого ужасного-то?
зачем городить огород?
вот вам скролилка экрана в аттаче
в процессе игры все равно придется освежать экран
и соответственно удалять то что уже прорисовано
в данной скролилке можно более гибко менять даже скорость игры (за счет памяти)
да и переделка под 2экрана не сильно сложная
Lethargeek
13.11.2009, 18:53
Ужоснах.
jerri, хоть бы ветку толком прочел сначала.
Тайлы сами за собой прекрасно стирают.
И скорость можно тоже задать любую.
Хоть и не нужно.
Тю :) я все прочел
что прежде всего отличает игры с атари от игр спека?
динамика!
они более динамичны хотя и страшны как смертный грех
в приложенном снапе демонстрация одной известной спековской технологии
которая позволит поднять динамику по сравнению со снапом с первой страницы
хотя конечно это еще сырая демонстрация идеи а не полноценный движок
Lethargeek
15.11.2009, 01:28
Тю :) я все прочел
Тю, тогда б ты понял, что как раз динамизьма ради лучше весь экран не прокручивать :p
Для динамизма лучше сделать статические экраны ага :)
от автора вариант есть
от меня кстати демка концепции уже есть
а от тебя пока визуализации твоего концепта не вижу, ага? ;)
нарисуй уже...
Сделал тайлами!
14311
Тайл имеет размеры 8x8 пикселей, при печати нечетная строка дублируется (для печати используется размер 16x8 пикселей естественно)
Левый байт при печати выводится с маской. Это делается чтобы не затереть предыдущий напечатанный тайл слева.
Как уже здесь говорилось, сплошная вода(земля) получается естественным образом когда после сдвига уже напечатанное так и остается на экране.
Если на экране около 32 тайлов, то печать ландшафта занимает всего 13К тактов!
Выглядит обнадеживающе. Для печати спрайтов с лихвой еще времени.
Общий алгоритм вижу таким:
1) Стерание всех спрайтов
2) Печать ландшафта
3) Печать всех спрайтов
Можно шаг 1) пропустить для мин, т.к они движуться только вверх через 4 пикселя. И затирать эти 4 пикселя снизу мины при ее выводе, а также затирать 2 пикселя справа оставшиеся после сдвига.
Пока не решал вопрос с клиппингом по краям экрана.
А также не знаю, что же делать с цветами. Делать нецветное?
Или же, как в прошлом посте, выводить их с землей. Но что-то мне уж жутко не нравится когда лодка подплывает к земле, то она окрашивается частично, да еще и квадратиками. Также в этом случае будут такие же проблемы и с минами.
https://seadragon.svn.sourceforge.net/svnroot/seadragon
Не уходите с обсуждением в приват -- интересно почитать.
https://seadragon.svn.sourceforge.net/svnroot/seadragon
В плане контроля версий советую code.google.com -- работает заметно шустрее SF, есть трекинг (удобнее чем в SF) и вики.
Ещё рекомендую завести один SVN под все свои порты -- так удобнее, впрочем это на вкус и цвет...
клэшинг аттрибутов - неизбежное зло спектрума :)
вот есть такой еще способ обработки
1 чистим буфер обработки
2 обрабатываем обьекты
у тебя все обьекты имеют высоту 16 или менее
соответсвенно если координаты спрайта+высота спрайта меньше или равно наачалу следующей линии то он принадлежит текущей линии
прибавляем единичку и сохраняем номер текущего обьекта (для ускорения обработки)
3 парсим бакграунд
и составляем карту отрисовки вида:
адрес обработчика, данные для отрисовки, по завершении строки проверяем счетчик обьектов в строке если не 0, то создаем массив обьектов
вида: обработчик, координаты, адрес, размеры
4 ждем прерывание и запускаем обработку.
Не очень понятно. Что делает обработчик? Какой размер буфера? Что в нем хранится?
размер буфера = высоте экрана в тайлах т.е 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 ----------
Их же делать нада
Да, что-то я сомневаюсь в сдвигах тайлов. А где там маска для вывода? Нужны серьезные доработки.
Должно работать хз - я не тестил
цвет грунта наверное имеет смысл сделать песчано-желтый :) а то черный страшно выглядит
14317
Без маски не обойтись если нужно изобразить пологий спуск, а не резкий обрыв.
Желтый не плох, но тогда атмосфера таинственности, думаю, будет нарушена. Ведь тут как? плывешь в неизвестном лабиринте-пещере, не знаешь какая мина всплывет, всё в тени...
А с желтым получиться, что ты на веселом солнечном пляже.
во первых зачем и здесь маска это раз?
все делается тайлами
во вторых как именно ты ее собираешься использовать?
изобрази ландщафт как я сфотал 2 тайла рядом, всё и увидишь.
---------- Post added at 17:06 ---------- Previous post was at 17:03 ----------
В общем, ты поясни на пальцах свой алгоритм еще раз. Как я понял есть байтовая матрица размером 16 на 10. Каждый байт означает номер тайла. Пробегаемся по матрице слева-направо, сверху вниз. Для каждого тайла вычисляем адрес его данных и выводим в экран. Адрес в экране не вычисляется, а "бежит" по ячейкам 2x2 знакоместа. Так?
изобрази ландщафт как я сфотал 2 тайла рядом, всё и увидишь.
---------- Post added at 17:06 ---------- Previous post was at 17:03 ----------
В общем, ты поясни на пальцах свой алгоритм еще раз. Как я понял есть байтовая матрица размером 16 на 10. Каждый байт означает номер тайла. Пробегаемся по матрице слева-направо, сверху вниз. Для каждого тайла вычисляем адрес его данных и выводим в экран. Адрес в экране не вычисляется, а "бежит" по ячейкам 2x2 знакоместа. Так?
что-то вроде
но есть нюансы
ты не очень хорошо понял тайловую концепцию
в аттаче твои 2 тайла находятся по центру вверху
у тебя есть 4 тайловых набора сверху вниз проскролленые вправо
А если таким будет ландшафт? 14320
Т.е. первый тайл тот же, а правый уже другой.
Сделал клиппинг. (Revision 16) https://seadragon.svn.sourceforge.net/svnroot/seadragon/
Да там тоже самое, только клиппинг по краям экрана сделан.
14322
А если таким будет ландшафт? 14320
Т.е. первый тайл тот же, а правый уже другой.
Ты же конструируешь пейзажи :)
значит будешь точно знать какие комбинации будут
а каких не будет :)
в идеале должен быть полностью построенный лабиринт из которого уже и создавать тайловый массив
потому как комбинации
1,3,0 и 1,4,0
могут быть одной и той же комбинацией надо смотреть уже на месте
кстати вот более правильный вариант
Изучаю дальше твой код.
1) Как данные депакируются? На очередном шаге просто добавляются данные в конец, на который указывает указатель? Но если так, то как быстро заполнится память устаревшими данными? Не хватит никакой. А если, допустим, переносить кусок на каком нибудь шаге (ну допустим через 5 экранов), то на это нужно будет время.
Хотя нет. В твоем случае на экран 10*16=160 байт. Ландшафт имеет длину 40 экранов. Получается к концу ландшафта будет 6400 байт распаковано. В принципе, вопрос снимается. А если так мало получилось, так вообще можно не паковать.
2) Прикинул скорость. Вот такой ландшафт рисуется 45Ктактов.
14327
У меня на аналогичный тратится 14Ктактов. Причем я использую маску при выводе для левых байтов тайла (на это тратится очень много времени из расчета на 1 байт). Правда я пока не выводил атрибуты. Ну, добавится 2Ктакта у меня не больше.
Это и понятно, почему так у тебя. Много времени тратится на ненужный пропуск 0-х тайлов, а также на переход на след строку адреса. Еще размер тайлов играет большую роль в таком расхождениии. У тебя они больше в 2 раза. Соответственно, выводить надо в 2 раза больше байтов.
Я же предлагаю хранить адреса уже расчитанные в данных ландшафта и просто потом на шаге пробежаться по младшим байтам и inc их сделать.
Изучаю дальше твой код.
1) Как данные депакируются? На очередном шаге просто добавляются данные в конец, на который указывает указатель? Но если так, то как быстро заполнится память устаревшими данными? Не хватит никакой. А если, допустим, переносить кусок на каком нибудь шаге (ну допустим через 5 экранов), то на это нужно будет время.
Хотя нет. В твоем случае на экран 10*16=160 байт. Ландшафт имеет длину 40 экранов. Получается к концу ландшафта будет 6400 байт распаковано. В принципе, вопрос снимается. А если так мало получилось, так вообще можно не паковать.
обьем буфера 256 байт :)
когда указатель дойдет до конца буфера
он начнет его сначала
карта одного экрана занимает 17*10=170 байт
2) Прикинул скорость. Вот такой ландшафт рисуется 45Ктактов.
14327
У меня на аналогичный тратится 14Ктактов. Причем я использую маску при выводе для левых байтов тайла (на это тратится очень много времени из расчета на 1 байт). Правда я пока не выводил атрибуты. Ну, добавится 2Ктакта у меня не больше.
Это и понятно, почему так у тебя. Много времени тратится на ненужный пропуск 0-х тайлов, а также на переход на след строку адреса. Еще размер тайлов играет большую роль в таком расхождениии. У тебя они больше в 2 раза. Соответственно, выводить надо в 2 раза больше байтов.
Я же предлагаю хранить адреса уже расчитанные в данных ландшафта и просто потом на шаге пробежаться по младшим байтам и inc их сделать.
надо посмотреть :)
ты уже решил проблему со стиранием\рисованием спрайтов под лучем?
ты уже решил проблему со стиранием\рисованием спрайтов под лучем?
Думаю. Но кажется, врубаюсь. В этот буфер самое главное на 1 объект записывается адрес обработчика-рисователя и данные за этим адресом. Данные имеют формат специфичный для каждого обработчика-рисователя.
Потом снимаем с этого буфера адрес, если он не 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 байта на каждый тайл под цвет
у меня 2 байта ширины и 8 байт высоты
Получается 32 байта выводится при печати тайла. Непонятно тогда, почему у тебя так долго. К тому же у тебя количество тайлов меньше раза в 1,5. Можешь посмотреть у себя почему так долго? Можно ли как нибудь существенно ускорить?
В противном случае ты рискуешь не успеть отрисоваться за прерывание. Т.к. сложность экрана приведенного мной - типичная. Есть еще пещеры. Там в 2 раза больше тайлов получится.
процедуры не оптимизированные :)
у меня демонстрация алгоритма а не демонстрация движка :)
сейчас дорисую версию 7 и посмотрим
Версия 7
1 оптимизирована карта 0 - не отображается :)
2 оптимизирован вывод на экран, жестко
Что-то не пойму. Все равно 45Ктактов процедура Refresh работает. Нужно существенное ускорение. Чтобы хотя бы за 30Ктактов.
голубой бордюр - время отрисовки данных на экране
остальное время занимают расчеты
в 1 фрейм ты по любому не уложишься
значит в 1 фрейм надо вывести все на экран
с учетом количества объектов и способа вывода можно все прекрасно успеть вывести
в 1 фрейм ты по любому не уложишься
Почему? У меня всего 15Ктактов. Еще с лихвой времени стереть спрайты, и нарисовать их. Всё в 1 фрейм.
А ты хочешь за 2 прерывания - 1 перерисовку? Жаргон этот мне не очень превычен. Это называется 2 фрейма?
fps - frame per second
обновление экрана
25 fps - 25 кадров в секунду
50 fps - максимум для Спектрума :)
15к тактов при отсутствии активных действий на игровом поле
для того чтобы сравнить скорость необходимо сравнивать модели в идентичных условиях
основная идея моего движка - вывод на экран графики последовательно
т.е обновил графику в строке - вывел спрайты из этой строки
таким образом не возникнет ситуации когда на экране есть фон, но нет персонажей
такая ситуация автоматически отсекается.
при таком алгоритме даже если и возникнет ситуация с проходом луча, то картинка не будет ломаться постоянно в одном и том же месте.
кроме того оптимизация ради оптимизации - ересь ;)
сейчас необходимо сделать реальный уровень со всеми переходами и уже посмотреть как оно будет
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 ----------
ломаться постоянно в одном и том же месте
Тут надо еще угадать - как бы луч не прошел по строке в которой стерты спрайты, но еще не нарисованы. Ведь сейчас ты убрал из своего начального движка вывод пустого места. Ты не забыл, что спрайты надо еще стереть перед выводом фона?
Lethargeek
18.11.2009, 20:28
Ну и наворотили... сами себе трудности создаете... а у меня все времени нет вмешаться :mad:
Ладно, может к утру отпишусь подробно ;)
Но ведь и у тебя тоже нет активных действий. Вывод спрайтов никак не будет привязан к выводу фона. Сначала фон в строке, потом спрайты.
у меня есть идеи как это реализовать
Да, у меня пока этого нету. Думаю. Надо сделать вывод фона по строкам, а не по столбцам как у меня сейчас. Буду переделывать однозначно. Я ведь только сейчас врубился, как же этот 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 ----------
Ну и наворотили... сами себе трудности создаете... а у меня все времени нет вмешаться :mad:
Ладно, может к утру отпишусь подробно ;)
мы не создаем трудностей :)
а от тебя сначала визуализацию своих идей в виде снапшота ;)
Lethargeek
19.11.2009, 06:58
Бегло просмотрел исходники ace210 и последние сообщения
Замечания
Во-первых, спрайты в общем случае "все сразу" стирать нельзя - будут мерцать
Или нужно будет ВЕСЬ экран успеть обновить, пока луч на бордюре
Все-таки 32 "четвертайла" 8x8 маловато будет
Возможен такой вариант:
Когда луч на бордюре, не только рисуем спрайты, но также
заблаговременно помечаем координаты для быстрого стирания
Потом пристроиться за лучом и последовательно заполнять строки
предварительно стирая спрайты в строке, если нужно
Далее - тайлы 8x8 слишком мелкие, раз уж все объекты в оригинале вчетверо больше
В итоге печать игрового поля неоправданно замедляется раза в полтора-два
Нужно взять "полутайлы" 16x8 (в сдвинутом виде 24x8, три байта в ширину)
Тайл печатать байтовыми столбцами - клиппинг проще получится
(левый так просто переходом внутрь той же процедуры)
Маска НЕ НУЖНА вообще - просто наксорить поверху левый байт
Только один нюанс - в тайле правой кромки левый байт должен быть инверсный
точнее не весь байт, а несколько младших битов (потому что ксорится на землю)
В таком случае одной универсальной процедуры может хватить на фрейм
Но лучше сделать косвенным переходом на отдельную процедуру печати каждого
(а уж там может сразу стоять переход на универсальную, если нужно)
Получим небольшое замедление универсальной, однако снизится пиковая нагрузка
Например при печати длинных тросов, обрывов или отвесных шахт
Нужны будут отдельные процедуры не на каждую фазу, а на весь объект
(сдвиг один раз в начале, потом простое копирование вниз)
По цветности - атрибуты необязательно сдвигать синхронно
Можно подбирать, как лучше будет смотреться
Например, хотим красную землю и черные мины, так вот если к примеру рисуем
кромку и она высунулась на соседнее знакоместо только на пару пикселей
то эти несчастные пиксели в цвет земли красить необязательно
таким образом края будут мерцать, но меньше
Если хотим к тому же белую лодку, нужно сначала проверить атрибут фона
Если красный, а лодка высунулась несильно, ксорим поверху, не трогая атрибут
В остальных случаях фон лучше затереть и поверху напечатать белым
У земли будет не так заметно, а мину можно и затереть (все равно взорвется)
Или можно сделать покадровым чередованием - см. Wheelie к примеру
(там правда спрайт целиком мерцает, а можно только краем)
По хранению тайлового поля пока ничего не скажу
Не было времени разбираться
Бегло просмотрел исходники ace210 и последние сообщения
Замечания
Во-первых, спрайты в общем случае "все сразу" стирать нельзя - будут мерцать
Или нужно будет ВЕСЬ экран успеть обновить, пока луч на бордюре
Все-таки 32 "четвертайла" 8x8 маловато будет
стирать можно, но есть нюансы
см Red heat, Commando
Возможен такой вариант:
Когда луч на бордюре, не только рисуем спрайты, но также
заблаговременно помечаем координаты для быстрого стирания
Потом пристроиться за лучом и последовательно заполнять строки
предварительно стирая спрайты в строке, если нужно
Далее - тайлы 8x8 слишком мелкие, раз уж все объекты в оригинале вчетверо больше
В итоге печать игрового поля неоправданно замедляется раза в полтора-два
Нужно взять "полутайлы" 16x8 (в сдвинутом виде 24x8, три байта в ширину)
Тайл печатать байтовыми столбцами - клиппинг проще получится
(левый так просто переходом внутрь той же процедуры)
посмотри внимательнее не только его исходники но и мои
также смотри RoboCop, Stormlord
многа многа букаф
По хранению тайлового поля пока ничего не скажу
Не было времени разбираться
жаль - ведь это самое интересное
по поводу спрайтов
можно не красить лодку вообще - если правильно все рассчитать
то пока лодка не въедет в землю то ее и не покрасит
наилучший вариант - 4 байта цвета на 16х16 тайл
т.е земля вида
/
//
будет покрашена правильно
бч
чч
можно не красить лодку вообще
Как это лодка не окрасится? Очень даже окрасится и проплывет рядом, я ведь делал много много постов назад. http://zx.pk.ru/attachment.php?attachmentid=14102&d=1257502626
посмотри внимательнее не только его исходники но и мои
Не надо смотреть. В исходниках долго разбираться, да и там далеко не всё оптимизировано. А если исходники игрушек - то лучше, кто знает их, так (на пальцах) разъясняйте. Лучше, народ, давайте обсуждать алгоритмы, концепции, форматы хранения...
Как это лодка не окрасится. Очень даже окрасится и проплывет рядом, я ведь делал много много постов назад. http://zx.pk.ru/attachment.php?attachmentid=14102&d=1257502626
вот смотри :) у тебя есть чистая вода
(пустота)она имеет цвет белый на синем
и у тебя есть скала
(грунт) она имеет цвет чорный на синем
когда ты рисуешь лодку у тебя есть 2 варианта
красить ее или не красить
если ты ее красишь
то при наезжании чуть чуть (на 1 пиксел, не факт что лодка даже залезет корпусом на камни) она покрасит камни в цвет лодки
если ты ее не красишь (именно лодку) она остается цвета местности т.е на фоне воды будет белая на синем, на камнях - чёрная на синем
примеры - Three weeks in paradise там есть режим включить\выключить цвет
опять же как
Не надо смотреть. В исходниках долго разбираться, да и там далеко не всё оптимизировано. А если исходники игрушек - то лучше, кто знает их, так (на пальцах) разъясняйте. Лучше, народ, давайте обсуждать алгоритмы, концепции, форматы хранения...
нуу скажем так - не всегда нужна сверхточная оптимизация, чаще всего хватает достаточной :)
неоправданно замедляется раза в полтора-два
Не согласен. Очень мест в ландшафтов, где много резких обрывов. И в этих местах, если выводить полутайл, т.е. 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 тайла. Правый тайл таким способом выведется, а левый - нет.
Нужно чтобы перед выводом не было ничего в экране.
Или знать какой из тайлов крайний левый и выводить его просто.
Вообще, в этом что-то есть... Надо подумать.
Вот здесь ссылочка на оригинальную версию Sea Dragon (http://www.trs-80.org/sea-dragon/)
---------- Post added at 15:28 ---------- Previous post was at 15:24 ----------
А здесь версия для атари (http://www.atarimania.com/game-atari-400-800-xl-xe-sea-dragon_4559.html)
Вот здесь ссылочка на оригинальную версию Sea Dragon (http://www.trs-80.org/sea-dragon/)
Помню ее по Агату, скорее всего в режиме Apple ][.
По тем временам увлекательная игра!
Игрушка - чума на TRS-80! Как из пулемета из торпедных аппаратов... :-)
---------- Post added at 16:49 ---------- Previous post was at 16:34 ----------
В настоящее время - игры в псевдографике, я знаю, существует как целое исскусство. Как-то запускал Doom в псевдографике - весело. Там всё так здорово детализируется простыми символами ASCII, да еще цветными, просто дух захватывает!
Lethargeek
19.11.2009, 17:31
стирать можно, но есть нюансы
Нюанс в том, что если очень точно проверять коллизии с фоном
может случиться, что кусочек спрайта тупо затерт правой стороной тайла
но столкновения не произошло, игра не останавливается!
Если такой спрайт стирать той же ксоркой, будет глючок на фоне
Если двигаться впритирку со склоном - может быть очень заметно
можно не красить лодку вообще - если правильно все рассчитать
то пока лодка не въедет в землю то ее и не покрасит
Да это понятно, но я хотел, чтобы выглядело опрятнее
Лодка может не ткнуться в саму землю, но сильно высунуться
в такое знакоместо где этой земли всего пара пикселей
Не согласен. Очень мест в ландшафтов, где много резких обрывов. И в этих местах, если выводить полутайл, т.е. 3 байта, то 1 байт однозначно печататься будет как ненужный. время.
Полутайлы оправданы бы были если б ландшафт состоял преемущественно из пологих спусков.
У нас ландшафт преемущественно из отвесных обрывов. Особенно это видно где шахты.
Ну в оригинале ландшафт довольно корявый, всякие закругления
Вылезет один пиксель, и уже считай участок "пологим"
Мины опять же широкие... ты же не спрайтами их рисовать собрался?
По времени нужно посчитать (вот если взять случай без клиппинга):
Универсальная процедура 24x8, тупо вписанная в твой цикл, кушает около 470 тактов
Твой нынешний 16x8 цикл _1PrnLandscape где-то 370 тактов, дважды получится 740
То есть если "широких" объектов на экране больше четверти, то лучше 24x8
А для тросов с шахтами, повторяю, в любом случае отдельные процедуры лучше
Одна-две процедуры на все фазы, просто в начале задается исходный байт
Я правда пока твою стыковку печати с распаковкой еще не понял...
Думаю, что с шахтами то получиться? они ведь шириной 2 знакоместа. Видимо надо поступить с минами так:красить ее в черный только если она не в шахте. А если в шахте, то не подкрашивать и она будет цвета земли
А как думаешь проверять? По распакованному ладшафту или по атрибутам?
Или можно сделать так, чтобы край шахты немножко черным мерцал,
а край мины - немножко красным, неравномерно сдвигая атрибуты
(атрибуты для каждой отдельной фазы можно сдвигать как хочешь)
Не получается. Вот 2 тайла. Правый тайл таким способом выведется, а левый - нет.
Нужно чтобы перед выводом не было ничего в экране.
ДОСТАТОЧНО, чтобы слева ничего не было ТОЛЬКО в нескольких младших битах!
А в них и НЕ МОЖЕТ ничего быть, потому что тайлы одной ширины одинаково сдвинуты
Кроме единственного случая, когда там на весь байт тянется сплошная земля
Но на этот случай у нас есть хитро устроенный полутайл правой кромки
Спрайты тут не волнуют (либо их уже нет, либо тоже ксоркой потом стираются)
Игрушка - чума на TRS-80! Как из пулемета из торпедных аппаратов... :-)
Кстати на атари вроде нету сталактитов падающих? ;)
Кстати на атари вроде нету сталактитов падающих?
Есть
Lethargeek
20.11.2009, 04:27
Не помню совсем, проходил давно
Тоже блин делать надо
Нюанс в том, что если очень точно проверять коллизии с фоном
может случиться, что кусочек спрайта тупо затерт правой стороной тайла
но столкновения не произошло, игра не останавливается!
Если такой спрайт стирать той же ксоркой, будет глючок на фоне
Если двигаться впритирку со склоном - может быть очень заметно
значит спрайт должен накладываться так чтобы не затираться тайлом :)
Да это понятно, но я хотел, чтобы выглядело опрятнее
Лодка может не ткнуться в саму землю, но сильно высунуться
в такое знакоместо где этой земли всего пара пикселей
вот смотри
зз0000лл
зз0000лл
ззз0000л
ззз00000
это знакоместо где слева (з)емля справа (л)одка
в этом случае если лодка красит бакграунд то земля получает цвет фона
если лодка красится фоном то лодка красится землей
зз000000
зз000000
ззз00000
ззз00000
а вот другой вариант - здесь тоже есть лодка но ты ее не видишь :)- она же не сферический куб в вакууме - она форму имеет
если красим лодкой местность то земля поменяет цвет
если лодка красится фоном то все нормально
Ну в оригинале ландшафт довольно корявый, всякие закругления
Вылезет один пиксель, и уже считай участок "пологим"
Мины опять же широкие... ты же не спрайтами их рисовать собрался?
лучший вариант - Мина спрайтом- для корректной обработки торпед
цепь - фоном
По времени нужно посчитать (вот если взять случай без клиппинга):
Универсальная процедура 24x8, тупо вписанная в твой цикл, кушает около 470 тактов
Твой нынешний 16x8 цикл _1PrnLandscape где-то 370 тактов, дважды получится 740
То есть если "широких" объектов на экране больше четверти, то лучше 24x8
а кто будет считать объекты?
К черту дверь
- Слепой Пью, "Остров сокровищ"
Я вот что подумал. А зачем нам вообще тайлы? К черту их. Нам нужны спрайты!
В самом деле, Jerri, зачем использовать байтовую матрицу, которая содержит очень много нулей? Однозначно тратиться очень много времени на ее сканирование. А тайлы 16x16 однозначно очень большие - тоже время.
Я предлагаю спрайты! Размер в высоту 8 пикселей, а в ширину - переменное число. Тогда не нужно будет ксерить (маскировать) левый байт. Просто тупо выводим по знакоместам и всё! Крутые обрывы - это ширина 1 знакоместо. Пологие спуски и вершины - 2,3,4 знакоместа в ширину.
Да таким макаром можно не только сплошную землю (воду) рисовать. Можно даже более выразительные элементы фона рисовать. Это ж Zynaps получается.
Нужно только с форматом хранения такого ландшафта определиться. Jerri расскажи как там в Zynaps эти элементы хранятся.
Во! Других элементов не бывает:
14356
Только еще от них производные: правые зеркальные, верхние зеркальные, нижние зеркальные
делай как хочешь :)
ты же игру пишешь а не я ;)
ты так и не разобрался с моей технологией
а уже хочешь битлов перепеть :)
зинапс - размер элементов 1зм на 4 (хотя конечно там гоораздо сложнее)
сам элемент генерится из символов 8 на 8 пикселов т.е 1 зм
но не просто так генерится
генерится сразу 4 фазы
от
со скроллом вправо 0
до
со скроллом вправо 6
в зависимости от элемента стоящего слева
т.е слева имеем элемент 1 состоящий из тайлов 1234
справа генерим элемент 2 состоящий из тайлов 5678
в результате у тебя получится 4 фазы элемента 2 от 5678 до 45678
все элементы - автогенерящиеся по мере появления на экране
первый экран в аттаче - фонт
2 остальных - сгенеренные в буфере 4 набора тайлов
тайлы-текущие т.е по мере передвижения по уровню набор постепенно меняется но то КАК Рафаэль выводит все это на экран надо видеть самому
разумеется при таком раскладе думать об 50 фпс - мечта
максимум 25 фпс при условии менее 1\3 экрана элементов
а "генерятся" - это значит печатаются в буфере? Или в буфер заносится только информация о последовательности символов 8x8?
перепечатываются в буфер
в первый буфер без скролла
во второй третий и четвертый со скроллом
я ж картинки приложил
на них все видно :)
Lethargeek
20.11.2009, 19:28
значит спрайт должен накладываться так чтобы не затираться тайлом
Лишние проверки - проще стирать построчно
(или по очереди, но главно чтоб за лучом)
вот смотри
...
если красим лодкой местность то земля поменяет цвет
если лодка красится фоном то все нормально
Снова ты не понял
Нужно снизить средневзвешенную по яркости разницу с идеальным случаем (три цвета на знакоместо)
То есть нужно не просто стирать меньший кусок, а красить его в ближайший цвет (из двух доступных)
Белую лодку в красный ИЛИ красную землю в синий
лучший вариант - Мина спрайтом- для корректной обработки торпед
Разве только после начала движения
а кто будет считать объекты?
Любой, кому известен ландшафт на всем протяжении (тоись аффтар))
Можно "вычислить" самый забитый экран (пиковый случай)
Хоть на глаз, хоть утилиткой автоматической
Я предлагаю спрайты! Размер в высоту 8 пикселей, а в ширину - переменное число. Тогда не нужно будет ксерить (маскировать) левый байт. Просто тупо выводим по знакоместам и всё!
Это с какой же радости не нужно маскировать или хотя бы ксорить?
Если не нужно маскировать, это уже не спрайт, а бяка квадратная
И вообще, раз пошла такая пьянка, у меня предложение:
Sea DraGon oLdsK0ol Demo Remix
Всю атаривскую угловатую графику можно безболезненно линейно уменьшить вдвое
Таким образом, нам придется обслуживать только 80 строк без дублирования
А размеры собственно игрового поля даже возрастут
А главное - на экране еще останется много места для всяких переливчатых и бегущих строк
с гритингсами и факами, которые (строки, а не факи) несомненно порадуют AAA!
и прочих олдскул маньяков :v2_yahoo:
Можно даже исхитриться и добавить простых бордюрных эффектов (продолжение по краям цвета воды и неба)
А также вместо резкого клиппинга - плавный блендинг
Получается игра и дема в одном флаконе! :v2_finge:
Можно отправить сразу на два разных конкурса!!
Lethargeek
Ладно понятно связной концепции нет
то что ты предлагаешь не очень весело и не очень быстро
движок мой тоже еще никто не понял
как разберетесь - призовете
Обновил первый пост ветки http://zx.pk.ru/showthread.php?t=11233
Уф. Закончил делать познакоместный вывод. Чем дальше - тем сложнее.
Это уже 3-я по счету реализация.
Немного комментариев к ревизии 18:
1) Теперь ландшафт рисуется не тайлами, а спрайтами высотой 8 пикселей и различной шириной (1,2,3,4 знакоместа). За счет этого удалось избавиться от маскирования левого тайла.
2) Для быстроты вывода прямо в данных ландшафта зарезервированы (и используются) дополнительные данные такие как: адрес процедуры вывода спрайта, адрес спрайта, координата X спрайта, адрес экрана.
Т.е. это и есть буфер, что предложил Jerri. Но он не строится заново на каждой обработке, а только немного корректируется.
В снапшоте голубой бордюр отмечает общее время цикла (обработка+отрисовка). Причем обработка делается только каждые 4 кадра, поэтому бордюр в это время мерцает.
14477
https://seadragon.svn.sourceforge.net/svnroot/seadragon/
В пике уже больше 40 Ктактов получается. Что-то я забеспокоился. Удастся ли уложится в 1 фрейм?
Немного продлил ландшафт
14479
jerri,
ace210,
по вашим коментариям я понял что вы вроде играли в эту игрушку на trs80,
не можете подсказать где взять биосы для этого компьютера ?
у меня пара эмуляторов trs80 есть, но запустить не могу.
не поможете ?
1) Теперь ландшафт рисуется не тайлами, а спрайтами высотой 8 пикселей и различной шириной
Может все таки 4 пикселя?
(или это спрайты так нарисованы, c парными строками?)
Может все таки 4 пикселя?
Правильно. Хранится 4, выводится - 8 дублированием.
Lethargeek
28.11.2009, 06:40
Уф. Закончил делать познакоместный вывод. Чем дальше - тем сложнее.
А нужны ли такие сложности
Ты хоть считаешь, будет ли реальное ускорение?
Как бы экономия на спичках не получилась
1) Теперь ландшафт рисуется не тайлами, а спрайтами высотой 8 пикселей и различной шириной (1,2,3,4 знакоместа). За счет этого удалось избавиться от маскирования левого тайла.
А например мину в шахте (или просто слева по склону) ты как рисовать собрался?
В пике уже больше 40 Ктактов получается. Что-то я забеспокоился. Удастся ли уложится в 1 фрейм?
Так вроде в оригинале скорость в два раза меньше
В два неполных (за лучом/перед лучом) фрейма точно уложишься
Barmaley_m
29.11.2009, 02:25
В снапшоте голубой бордюр отмечает общее время цикла (обработка+отрисовка). Причем обработка делается только каждые 4 кадра, поэтому бордюр в это время мерцает.
Очень хорошо получилось! Ландшафт скроллится каждый фрейм, и в основном это происходит за весьма малое время. Респект!
Что касается мерцания каждые 4 такта - то оно весьма существенное. По-видимому, обработка занимает немало времени. В связи с этим идея: разделить обработку на 4 этапа и выполнять каждый из них каждый фрейм, так чтобы более равномерно распределить нагрузку на проц. Но это можно сделать и после.
Наибольшая нагрузка на прорисовку ландшафта наблюдается в случае, когда на экране много шахт. В связи с этим идея - рисовать шахты специализированной процедурой, оптимизированной под шахты. Ведь пологий ландшафт и шахты имеют существенно разный вид на экране, и рисование их одним и тем же алгоритмом неминуемо приведет к неоптимальности.
В 1 фрейм нужно обязательно уложиться. Судя по тому, что у тебя уже получилось, это должно быть возможно. Насколько при этом игра будет более динамичной!
Что касается плавности восприятия движения человеком, то здесь можно сравнить 3 варианта, а именно:
1. изображение смещается на 1 пиксел каждый кадр
2. изображение смещается на 2 пиксела каждый кадр
3. изображение смещается на 1 пиксел каждые 2 кадра.
Так вот, в первом и втором случае (а также в случае смещения на >2 пикселов каждый кадр) движение воспринимается идеально плавным, а вот в случае 3 оно получается дерганным и размытым. В чем тут дело?
А дело в том, что когда человек присматривается к движущемуся по экрану объекту, то он зрачком следит за этим объектом, то есть зрачок перемещается плавно так, чтобы движущийся объект всегда оказывался в одном и том же месте сетчатки. И если объект смещается на равное расстояние каждый кадр - то его изображение будет вспыхивать (экран мерцает) всегда на одном и том же месте сетчатки. То есть объект будет виден четко.
А вот если объект смещается не каждый кадр, то когда зрачок следит за объектом, то один раз на 2 кадра изображение будет появляться в другом месте сетчатки глаза, смещенно относительно предыдущего кадра. Поскольку глаз и последующие области мозга, которые обрабатывают изображение, обладают некоторой инерционностью, то изображение размывается, а также те области мозга, которые детектируют движение (а действуют они подобно тому, как детектируется движение в видео кодеках, только более точно) - эти области тоже начнут срабатывать нерегулярно.
Я видел недавно в общественном месте такой прикол. Было несколько вертикальных столбиков светодиодов, которые хитрым образом мерцали, так вот, если относительно медленно (но не слишком медленно) перемещать взгляд мимо этих столбиков, то удавалось увидеть различные картинки (движущиеся и статические). Механизм здесь тот же. Зрачок движется, а источник света стоит, в результате получается, что изображение источника света движется относительно сетчатки, что и формирует на некой ее протяженной области изображение картинки.
---------- Post added at 01:25 ---------- Previous post was at 01:08 ----------
Еще более радикальная идея устранить неравномерность нагрузки на проц, которая обусловлена обработкой ландшафта и пр. - это использовать концепцию вытесняющей многозадачности.
У нас есть две задачи, первая - прорисовка ландшафта - критичная по времени, и она должна выполняться каждый кадр, причем синхронно с лучом. Вторая задача менее критична во времени, потому что она может быть выполнена (сразу или поэтапно) в течение 4х кадров, причем неважно, когда именно. Вытесняющая многозадачность подразумевает выполнение второй задачи тогда и только тогда, когда процессор не занят выполнением первой.
Реализовать это просто: прорисовка ландшафта может выполняться по прерываниям (в процедуре обработки прерывания), а обработка буферов и т.д. - на заднем плане, с разрешенными прерываниями. Процедура обработки прерываний должна будет, разумеется, сохранять значения регистров, чтобы можно было вернуться к исполнению прерванной программы. В этом заключается плата за вытесняющую многозадачность. Без нее регистры сохранять не надо.
С таким подходом "на задний план" в игре можно напихать много разных задач, лишь бы только в среднем за какой-то промежуток времени они успевали исполниться. А проц будет простаивать только тогда, когда ему совсем уж нечего делать.
Barmaley_m, а вот например в играх Firefly и Zynaps разве движение дерганое?
zynaps надо смотреть на оригинальном zx -скролл заточен под него, на пентагоне рывки заметны.
а firefly? да и RED Heat
скорость - 25 фпс
первый фрейм - считаем данные - второй фрейм и начало следующего - рисуем
goodboy, Zynaps ковырял?
игра имеет скорость 25-17 фпс
никакой синхронизации или заточки под оригинал там нет
технология такова что графика на экран только рисуется
сверху вниз
если много обьектов, то бывает не укладывается во фрейм потому заметно легкое подтормаживание
никакой синхронизации или заточки под оригинал там нет
технология такова что графика на экран только рисуется
сверху вниз
ковырял давно и помню что там были задержки (в коде) при выводе. сейчас глянул на SpecEmu - на пентагоне дёргается. хотя может быть это неточная эмуляция.
эмуляция точная
задержки в основном под мультиколор там
перед экраном там одна чтобы за лучом рисовать
критичные задержки в RedHeat И Firefly
в Zynaps картинка только рисуется - не бывает ситуации когда бакграунд есть а обьектов нет
jerri,
ace210,
по вашим коментариям я понял что вы вроде играли в эту игрушку на trs80,
не можете подсказать где взять биосы для этого компьютера ?
у меня пара эмуляторов trs80 есть, но запустить не могу.
не поможете ?
Лови
Отделена печать Strip-тайлов (тайлы составляющие отвесные склоны, шахты). 1 тайл стал печататься 251 такт вместо 313. Это на 62 такта быстрее. Экономия в пиковом экране(11-й по счету, где много шахт) примерно 4100 тактов. Сам экран в этом месте рисуется примерно 29191 тактов, а обрабатывается 12658 тактов. Итого цикл - около 41849 тактов. В общем, экономия не особо...
Ведь этот пиковый экран состоит не только из шахт, там и извилин тоже много. Видимо поэтому особо не экономится. Но 4Ктакта тоже неплохо, памяти при этом лишней (на спец. процедуры) затратилось 256 байт всего.
14520
Балуемся с текстурами и скоростью.
Балуемся с текстурами и скоростью.
Lethargeek
01.12.2009, 03:25
Отделена печать Strip-тайлов (тайлы составляющие отвесные склоны, шахты). 1 тайл стал печататься 251 такт вместо 313. Это на 62 такта быстрее. Экономия в пиковом экране(11-й по счету, где много шахт) примерно 4100 тактов. Сам экран в этом месте рисуется примерно 29191 тактов, а обрабатывается 12658 тактов. Итого цикл - около 41849 тактов. В общем, экономия не особо...
Ведь этот пиковый экран состоит не только из шахт, там и извилин тоже много. Видимо поэтому особо не экономится. Но 4Ктакта тоже неплохо, памяти при этом лишней (на спец. процедуры) затратилось 256 байт всего.
А кинь-ка мне этот пиковый экран символьным массивом 32x20
Тут мыслишки новые появились, прикинуть надо, сравнить
Балуемся с текстурами и скоростью.
На мой взгляд, больше всего подходит текстура как в примере 12 и 13. Красный получается не такой яркий. Ну и плавность конечно впечатляет. Молодец! Так держать! :eek:
символьным массивом 32x20
Я же сказал. Нет теперь байтовой матрицы. Есть структуры спрайтов, типа изрезанных массивов . Т.е. ландшафт хранится в виде:номер тайла, координата X... И так для каждой строки. Нули не храняться.
Если нарисовать эту структуру в экране то получится вот:
14542
Здесь 78 тайлов. Это 11-й экран.
Простейший редактор прилагается:14543
Состряпал на скорую руку.
Клавиши управления:
Cursor
Kempston mouse
O,P,SS+O,SS+P - перемещение по ландшафту
1,2,3,4 - выбор группы тайлов
SS+L - загрузить ландшафт
SS+S - сохранить ландшафт
SS+N - загрузить scr
N - показать scr/ландшафт
Если у кого есть желание, дорисуйте ландшафт. Буду очень благодарен. Файл trd лежит в исходниках.
Lethargeek
01.12.2009, 15:58
Я же сказал. Нет теперь байтовой матрицы. Есть структуры спрайтов, типа изрезанных массивов . Т.е. ландшафт хранится в виде:номер тайла, координата X... И так для каждой строки. Нули не храняться
Не важно, мне только края нужны
Совсем другой способ хочу проверить
Если нарисовать эту структуру в экране то получится вот:
Годится
Lethargeek
03.12.2009, 03:48
Вспомним, с чего все начиналось
С прокрутки каждой строки командами RL(HL) + DEC L
Для двух одинаковых строк очевидный способ RL(HL) + LDD
Казалось бы, улучшать здесь нечего, однако...
В последних изысканиях получил интересный побочный результат
Cамая быстрая полная прокрутка двух совпадающих строк
получается с применением недокументированных команд
Вход: hl = ^массив 128 байт подрисовка
ix = ^конец нечетной строки
sp = ^конец четной = ix-256
rl (hl) правый бит
inc l
rl d,(ix-1) |
rl e,(ix-2) |
push de | всего 16 раз
...
rl d,(ix-31)
rl e,(ix-32)
push de
inc ixh переход на 2 строки ниже
ld sp,ix
inc ixh
...итого 957 тактов (912 сама прокрутка) на ДВЕ растровые строки
Кроме того, данный способ заметно меньше страдает
от задержек медленной памяти фирменных машин
Аналогично делается переброска фона одинарными строками
из теневого буфера с одновременной его прокруткой
(ix = ^буфер с подрисовкой, sp = ^экран)
Один большой недостаток - направление только справа налево
957 * 80= 76560
на 160 строк целый фрейм - многовато - надо же еще и обьекты стирать рисовать
Lethargeek
04.12.2009, 14:37
Мало ли кому пригодится... может быть даже мне :)
Я пока балуюсь автогенерацией процедур кусочной прокрутки
По первым грубым прикидкам даже самый примитивный вариант получается быстрее
Lethargeek
06.12.2009, 11:14
Просчитал кусочную попиксельную прокрутку пикового экрана
Получилось около 21000 тактов, считая строчные переходы
Но без учета предварительной подготовки (о ней потом)
Сначала излагаю сам принцип
Формат хранения ландшафта теперь не важен
лишь бы вовремя получать новый столбец подрисовки
Каждая символьная строка крутится динамически создаваемой процедурой
которая вызывается в кадре 4 раза (а всего в том же виде - 32 раза)
Установка регистров
Один раз на весь экран:
B = правый обрыв (или левая стенка шахты)
A'= not B (противоположная стенка)
(C использовать нельзя, его испортит LDD)
В начале строки:
HL = адрес начального (правого) байта первой строки
DE = адрес начального (правого) байта второй строки
A = L = E
а также сдвигом байта подрисовки устанавливается исходный бит переноса
Сама процедура-скроллер состоит из следующих стандартных фрагментов
чистая вода и сплошная земля просто пропускаются:
пропуск одного знакоместа (8 тактов)
dec l
dec e
пропуск двух знакомест (12 тактов)
dec l
dec l
ld e,l
пропуск трех и более знакомест (15 тактов)
sub N
ld l,a
ld e,a
(внимание - N не всегда равно кол-ву пропускаемых)
(корректируется поcледнее значение аккумулятора)
правый обрыв или левая стенка шахты (22 такта)
ld (hl),b
ex de,hl
ld (hl),b
ex de,hl
левый обрыв или правая стенка шахты (22 такта)
exa
ld (hl),a
ld (de),a
exa
(указатель остался там же, нужен явный пропуск)
(условно) правый склон (31 такт)
sla (hl)
ldd
(условно) левый склон (31 такт)
sli (hl)
ldd
эти два куска нужны только сразу после длинного пропуска
из-за испорченного вычитанием прошлого переноса
во всех остальных случаях используется
rl (hl)
ldd
...ну и возврат по команде ret
Хочу заметить, что и вызывать оную процедуру тоже лучше всего через ret
потому что она будет постоянно "отползать" в младшие адреса каждые 8 кадров
по мере того как будут распакованы и добавлены в подрисовку следующие тайлы
Так что лучше просто корректировать адреса, раз и навсегда уложенные в скрипт,
временно адресуемый указателем стека (там же сортировку спрайтов удобно)
Конечно, "отползать" вечно процедура не может - не хватит памяти
на одну знакоместную строку может потребоваться до 128 байт
а каждые 8 кадров возможен еще прирост (а строк 20 штук)
Что делать? Сдвигать обратно каждый такой кусок слишком долго
Проще всего буфер закольцевать и разбить на две части командой ret
Скрипт получится примерно вот такой:
^установка на первую строку
^скроллер1 голова
^скроллер1 хвост
^переход растровых строк
^скроллер1 голова
^скроллер1 хвост
^переход растровых строк
^скроллер1 голова
^скроллер1 хвост
^переход растровых строк
^скроллер1 голова
^скроллер1 хвост
^переход тайловой строки
^скроллер2 голова
^скроллер2 хвост
^переход растровых строк
...
...
...
^скроллер20 хвост
^переход растровых строк
^скроллер20 голова
^скроллер20 хвост
^завершение
Подготовка тоже (даже вся сразу) должна жрать гораздо меньше
Но если нужно, то размазать задачу по 8 кадрам довольно просто
Например 5 кадров дописываем головы ровно по 4 скроллера
Потом два кадра отмеряем хвосты на обрезку по 10 каждый
Восьмой кадр соответственно корректируем адреса и возвраты
С такой прокруткой мины наверно выгодно делать чистыми спрайтами
кроме разве что тросов, которые лучше в ландшафт засунуть
благо их мало (прокрутка пустого места не так страшна)
а вычистить столбик прямо на экране несложно
См. скриншот в аттаче
Светлыми точками помечены прокручиваемые тайлы
желтые - sla/sli, белые - rl, зеленые - ld
(черные остались с прошлого варианта)
P.S. Однако ветку давно пора перекидывать в "Программирование" :)
Бакграунд это еще не все
1.Спрайты как кидать?
2.скорость 1 или 2 пикселя за фрейм?
Lethargeek
06.12.2009, 18:36
Бакграунд это еще не все
1.Спрайты как кидать?
Да хоть обычной ксоркой (ею же потом и стирать)
Хотя можно хитрее (например ксорить не сам спрайт, а разницу сдвига)
Только нужно ли - мина (или пушка) всяко хавает меньше 500 тактов
Мин таких на простом экране не больше 16 (на сложных и того меньше)
Плюс лодка, выстрелы, логика, то да се... где-то на 40000+ свободных тактов :p
2.скорость 1 или 2 пикселя за фрейм?
Один, конечно (то есть вдвое плавнее оригинала при той же скорости)
Разобрался, вник.
Здорово! :v2_clap2:Особенно если действительно 21000 тактов, не просчитался ли? Вот тут например:
пропуск трех и более знакомест (15 тактов) sub N ld l,a ld e,a
надо бы в начале: ld a,l
В любом случае замечательно!
Оно по идее так и должно быстро скроллироваться. Т.к. в отличии от печатания тайлами, здесь не надо загружать адрес экрана и адрес тайла.
И в концепцию луча тоже хорошо укладывается:
1) затираем спрайты в знаколинии
2) скроллируем знаколинию
3) печатаем спрайты в знаколинии
Еще большой плюс - это то, что можно делать ландшафт любой красоты, а не только ограниченным набором тайлов. Да что тут говорить, это же готовый fantastic dizzy с плавным скроллом! А то тот прикол с хранением графики в 4 копиях, конечно, никуда не годился.
Lethargeek
07.12.2009, 13:19
если действительно 21000 тактов, не просчитался ли
Там может слегка набежать только за счет строчных переходов
Возможно будут нужны задержки, чтоб луч не опередить
(c оценкой по длине процедуры скроллера)
надо бы в начале: ld a,l
Не надо - A в начале строки устанавливается и нигде не портится
Только нужно при дописывании головы последний N корректировать
1) затираем спрайты в знаколинии
2) скроллируем знаколинию
3) печатаем спрайты в знаколинии
а главное, все легко пихается в тот же скрипт ;)
Еще большой плюс - это то, что можно делать ландшафт любой красоты, а не только ограниченным набором тайлов. Да что тут говорить, это же готовый fantastic dizzy с плавным скроллом!
Сомневаюсь, у нас все-таки картинка достаточно специфическая, много сплошных квадратов
Разве что разбить на два кадра и окно урезать...
А то тот прикол с хранением графики в 4 копиях, конечно, никуда не годился
Ну для оставшихся-то немногих спрайтов еще как годится (уже в 8 копиях)
Но про них потом напишу, времени пока мало :(
1. Атрибуты где будут сдвигаться?
2. момент с уходом тайла за экран как решается?
Lethargeek
07.12.2009, 15:07
1. Атрибуты где будут сдвигаться?
Где-где... в экране :) Каждые 8 кадров, простой процедурой (хотя можно и похимичить)
2. момент с уходом тайла за экран как решается?
А что решать, там не тайл уходит, а последний пиксель сдвигается в никуда
^установка на первую строку
^скроллер1 голова
^скроллер1 хвост
^переход растровых строк
^скроллер1 голова
^скроллер1 хвост
^переход растровых строк
^скроллер1 голова
^скроллер1 хвост
^переход растровых строк
^скроллер1 голова
^скроллер1 хвост
^переход тайловой строки
^скроллер2 голова
^скроллер2 хвост
итд
я так понимаю это адреса в списке
вопрос - как удалить из списка последний обьект ушедший за экран
и как добавить в список новый обьект вышедший из-за экрана?
если можно то кусочек кода пожалста
Lethargeek
07.12.2009, 18:18
я так понимаю это адреса в списке
вопрос - как удалить из списка последний обьект ушедший за экран
и как добавить в список новый обьект вышедший из-за экрана?
Йопт :rolleyes: это список стартовых адресов процедур
Здесь они только коректируются (не все)
Ни порядок, ни кол-во не меняются
Способ же модификации самих процедур зависит от способа хранения ландшафта
Ну что ж, до мин недолеча осталось.
Встроил в печать ландшафта печать буфера спрайтов.
- Подготовка лодки к печати - 1150 тактов
- Печать лодки с проверкой на столкновение - 2700 тактов
- Стирание ксоркой - 1900 тактов
Не стал я лодку урезать до 4 знакомест, сделал 5. Но некоторые байты спрайта пропущены. Печатаю змейкой.
Буду метиться на дискретность в 1 пиксел, а там посмотрим.
Есть 2 нюанса
1. перенеси весь исполняемый код выше #8000
2. чего у тебя весь экран одного цвета? :) лодка должна быть белая
---------- Post added at 10:30 ---------- Previous post was at 09:45 ----------
ладно :)
раз уж дошли до момента когда надо рисовать спрайты
вот технология для быстрого сортирования обьектов
итак
создаем таблицу 256 байт (чтоб работать удобнее было)
можно конечно и поболее таблицу создать но это надо смотреть по месту
итак 256 байт
первые 12 байт - счетчики обьектов в строке
последующие 240 байт - данные по обьектам в строках
итак обрабатываем какойто обьект
например мину
в С - номер обьекта
ну или еще какой регистр
ld h,table_object/256
берем координату Y
делим на 16 получаем число 0 до 11
and #f0
rra
rra
rra
rra
ld l,a
inc (hl)
ld a,(hl)
add a,a
add a,(hl)
add a,a
add a,a
//умножаем на 12
add a,l
ld l,a
ld (hl),c //номер обьекта
и теперь обработка обьектов
ld hl,table_object
ld b,12
obj_
ld a,(hl)
берем количество обьектов
or a
jr nz,object_proceed
inc l
djnz obj_
object_proceed
ld b,a количество обьектов
ex de,hl
ld hl,12
add hl,de
hl - список обьектов
переход к следующему обьекту
add hl,12
естественно перед выходом hl восстановить
Другой вариант
в С - номер обьекта
ну или еще какой регистр
ld h,table_object/256
берем координату Y
делим на 32 получаем число 0 до 11
and #e0
ld l,a
inc (hl)
add a,(hl)
ld l,a
ld (hl),c
после отработки получается примерно такая таблица
#8000
#00,#00,#00,....
#8020
#01,#05,.......
#8040
#02,#01,#02,....
т.е строка 1 - координаты Y от 0 до 31 - 0 обьектов
строка 2 - координаты Y от 32 до 63 - 1 обьект ID5
строка 3 - координаты Y от 64 до 93 - 2 обьекта ID1 ID3
зачем это надо
для того чтобы при отрисовке перед лучом нарисовать сначала обьект №5 с координатой 32
а потом уже рисовать №1 с координатой 64 и №3 с координатой 90
ld hl,table_object
ld b,#8
obj_
ld a,(hl)
берем количество обьектов
or a
jr nz,object_proceed
ld a,l
add a,32
ld l,a
djnz obj_
object_proceed
ld b,a количество обьектов
inc l
hl = список обьектов
1. перенеси весб исполняемый код выше #8000
2. чего у тебя весь экран одного цвета? лодка должна быть белая
эт потом. Еще мины должны ведь черные. А они еще и в шахтах. Тут много вариантов:
1) подкрашивать спрайты. Т.е. можно сделать вкл/выкл. режима подкрашивания наподобие "7дней в раю"
2) Мины будут красные пока они не всплывают. Потом- подкрашивать черным, при этом шахта будет вся в квадратиках.
3) Еще много вариантов.
Короче, не знаю я, что же делать с цветами. Надо экспериментировать. Но пока нет мин - не имеет смысла.
вот технология для быстрого сортирования обьектов
ничче не понял.
Зачем сортировать объекты в строке?
Ключ сортировки - это X что ли?
Беглым взглядом - это алгоритм вставок какой-то.
Куда потом применять эту таблицу 256 байт?
Какие данные содержаться в этой таблице?
Что такое 12?
Мне бы лучше алгоритм сортировки (разбивки) объектов по знакострокам и заполнения буфера для последующей печати. Т.е. ключ - Y объекта. А то я сделал лодку - не очень доволен как у меня получилось. Буду скорее всего переделывать.
ошибся я там - :) естественно Y
но есть ограничение - не более 20 обьектов на строку для первого алгоритма
или не более 31 обьекта на строку для второго алгоритма
Lethargeek
08.12.2009, 14:00
Мысли по цветности
Во-первых, предусмотреть ее отключение
черным по синему тоже уже неплохо, взрывами можно помигать,
букафки сверху-снизу цветные - совсем уныло не будет
Во-вторых, прокрутка атрибутов
Можно сдвигать все сразу одновременно, но тогда получится
многовато пустых квадратиков, которые будут зря окрашивать спрайты
С другой стороны, пусть мы не можем двигать атрибут
"с точностью до пикселя", зато можем "с точностью до кадра"
То есть атрибуты смещаем каждый кадр, но не все!
А чтобы лучше совпадали с кромками ландшафта
Здесь какие-то хитрые процедуры не нужны, хватит универсальной
Формат данных в буфере атрибутов (здесь лучше слева направо):
- пропуск до следующего сдвигаемого
- кадр, на котором его нужно сдвинуть
И при прокрутке знаколинии (перед спрайтами) быстро пробегаем
(информацию о кадре сдвига можно к тайлу привязать)
В-третьих, окраска спрайтов
Мины "подкрашивать черным" просто так не нужно, само же получится
Если уж подкрашивать, то в красный и весь спрайт целиком
чтобы цвет потом сменился скачкообразно - так лучше смотрится
А вот лодка, то и дело мигающая красным, уже получится некрасиво
Или можно атрибутный конфликт разрешить простой моргалкой по четности кадра
Что правда усложнит проверку столкновения и стирание, да и дольше будет
С другой стороны, если по скорости есть запас - почему бы нет?
Думаю, сначала лучше добавить неравномерный сдвиг атрибутов, а там видно будет
Караул!
Не успел отрисоваться.
Почти в самом конце, где куча шахт подряд. Около 200 тайлов там. Не помогли даже стрип-тайлы.
Короче, всё окно практически рисуется. Из теории помним, что экран на спектруме за прерывание, ну, никак не успеть перебросить.
В этом месте, если хотим сделать 1 фрейм, придется отступить от оригинала.
Lethargeek
08.12.2009, 17:07
Хехе, у меня прокруткой все равно примерно 30000 получилось :p
Да, действительно, 30000 получается.
Ну что? Попробовать реализовать этот JIT scroller? Уж больно заманчивые тайминги. Нигде мы не просчитались? со спрайтами потом проблем не возникнет? Там еще сталактиты падающие, стреляющие пушки, лазеры...
Тут с печатанием тайлов я вроде всё поджал. Особо быстрее, видимо, не получится. Эти шахты рисуются 62000 тактов. А обработка - 26000. Причем, обработку размазать по кадрам нельзя. Ее надо сразу всю делать тут.
---------- Post added at 18:31 ---------- Previous post was at 18:25 ----------
Только я вот тут чуть чуть не понял:
Проще всего буфер закольцевать и разбить на две части командой ret
Зачем на 2 части разбивать? Как кольцуется?
Lethargeek
08.12.2009, 18:33
Если надо, я подробно все напишу
Только не дави на меня :)
Дай вздохнуть дня два
Зачем на 2 части разбивать? Как кольцуется?
А. Всё. Разобрался. Это когда голова кончается, то головой становится хвост, и хвост начинает расти заново.
Lethargeek
10.12.2009, 18:21
Немного просчитался - последний пиковый около 33000
Причем прокрутками по одной строке почти столько же получилось
Так что может быть лучше перейти на однострочную прокрутку?
Корявый ландшафт, конечно, больше схавает, но не слишком
(до такого пикового с шахтами не дотянет все равно)
зато его можно будет подрихтовать ;)
А также подготовка и сами процедуры упрощаются
Установка регистров:
Один раз на весь экран:
B = правый обрыв (или левая стенка шахты)
С = левый обрыв (или правая стенка шахты)
В начале строки:
HL = адрес начального (правого) байта
A = L; Carry = бит из подрисовки
Фрагменты однострочного скроллера:
обязательный переход на шаг (4 такта)
dec l
или пропуск трех и более знакомест (11 тактов)
sub N
ld l,a
(N так же не всегда равно кол-ву пропускаемых)
правый обрыв или левая стенка шахты (7 тактов)
ld (hl),b
левый обрыв или правая стенка шахты (7 тактов)
ld (hl),с
(условно) правый склон после пропуска (15 тактов)
sla (hl)
(условно) левый склон после пропуска (15 тактов)
sli (hl)
продолжение прокрутки (15 тактов)
rl (hl)
К тому же выйдет короче, так что возможно выгодно уже
не заморачиваться с закольцовкой и разрезанием скроллера
а просто сдвигать его на том же месте (или в другой набор)
таким образом избавимся от пары рестартов на строку
Может, даже выиграем немного, позже посчитаю
Тут с печатанием тайлов я вроде всё поджал
Всё, да не всё.
1) Печать стрип-тайла всегда ограничивается шириной в 1 знакоместо! Раньше я этого не учитывал, шлепал лишнее знакоместо.
Теперь, соответственно, пиковый экран печатается в 2 раза быстрее, так как там почти одни только стрип-тайлы. Получилось 34500 такта. Это без учета рисования спрайтов.
2) Далее. На 0 кадре обыкновенные тайлы тоже можно сделать не 2 знакоместа печатать, а 1. Только нужно сделать тайл так, чтобы он на кадре предшествующем 0-му уже затер землю (нарисовал землю) сплошняком в знакоместе справа. Мне пришлось подкорректировать только 2 тайла. Их сейчас можно увидеть даже невооруженным взглядом (они нессиметричные, на 1 пиксель имеют лесенку).
Тоже выиграл немного времени. Но это не так уж нужно. Но зато когда печатается 0 кадр то и обработка ландшафта тоже выполняется на этом кадре. Поэтому получается некая компенсация.
3) Немного оптимизировал обработку. Выиграл на пиковом экране 4000 тактов. Сейчас 23000 тактов кушает.
Во фрейм уложился, но итого осталось в пиковом экране на отрисовку мин около 6000 тактов.:(
Всё равно маловато. Эх, жаль, что обработку нельзя размазать по кадрам. Там корректируются адреса экрана печати тайла, поэтому никак. :(
Пока, наверное, не буду пробовать реализовывать JIT Scroller. Еще неизвестно что в конечном итоге там выйдет. Может быть как нибудь потом, как вдохновение появится.
Сейчас лучше пущу усилия на спрайты. Хочется уже пострелять.
Lethargeek
10.12.2009, 18:58
А на цвет запас? ;)
Ладно, я пока буду дорабатывать потихоньку
Может, тест напишу (пиковый экран замкну в кольцо)
Погляжу, что выйдет
Lethargeek
11.12.2009, 01:20
Хм, похоже, что двойной скроллер удастся ужать до 26000 в пике
Barmaley_m
11.12.2009, 04:07
1) Печать стрип-тайла всегда ограничивается шириной в 1 знакоместо! Раньше я этого не учитывал, шлепал лишнее знакоместо.
Теперь, соответственно, пиковый экран печатается в 2 раза быстрее, так как там почти одни только стрип-тайлы. Получилось 34500 такта. Это без учета рисования спрайтов.
Йоу, Блэр! (с)
Красиво получилось! И очень обнадеживающе!
Насчет стрип-тайлов и шахт: мне кажется, что если печатать шахты не в виде тайлов (даже стрип-тайлов), а с помощью специализированных процедур, которые максимально быстрым образом рисуют вертикальный столбик - то может быть удастся еще что-нибудь выиграть.
Эх, жаль, что обработку нельзя размазать по кадрам. Там корректируются адреса экрана печати тайла, поэтому никак. :(
Ты имеешь в виду то, что во время обработки нельзя рисовать текущие кадры из-за того, что состояние структур данных находится "в процессе изменений"? А что если использовать два набора данных, один рисуется, а второй обрабатывается? Если обработка делается один раз на 8 кадров - то должен быть способ ее размазать по кадрам, хотя бы ценой дополнительной памяти.
мне кажется, что если печатать шахты не в виде тайлов (даже стрип-тайлов), а с помощью специализированных процедур, которые максимально быстрым образом рисуют вертикальный столбик - то может быть удастся еще что-нибудь выиграть.
К сожалению, печать идет строго по знакострокам чтобы пристраиваться за лучом. Поэтому - никак нельзя.
два набора данных,
Идея хорошая, но в мою структуру данных ландшафта вряд ли впишется. На досуге подумаю.
Насчет спрайтов.
Естественно, чтобы печать шла по знакострокам, нужно заполнить буфер спрайтов в формате приблизительно: адрес процедуры печати знакостроки спрайта, адрес экрана для вывода, адрес спрайта.
Есть 2 метода организации.
1) Один буфер. Как только знакострока кончается, то в буфере вместо адреса процедуры ставим 0.
В этом случае очень усложняется заполнение этого буфера, т.к. Нужно сначала спрайты разбить на объекты - знакоспрайты, потом их отсортировать по Y, потом уже заполнять последовательно буфер.
2) На каждую знакостроку - свой буфер спрайтов. В этом случае спрайты не нужно сортировать. А, последовательно перебирая их, разбивать на объекты-знакоспрайты, и записывать сразу в буфер нужной знакостроки. Недостаток метода 2) - в том, что нужно держать указатели на окончания всех 20 буферов и при записи в буфер соответственно корректировать эти указатели.
Сейчас подлодка печатается по методу 2). Получилось 1000 тактов на заполнение буфера. Много. Правда я еще не особо оптимизировал. Лодка имеет в высоту - 12 пикселей. В ширину - 5 знакомест. К тому же еще не применяется клиппинг.
На обработку мин уйдет больше времени, т.к. там еще нужно обсчитывать клиппинг.
Думаю мины можно не стирать, а печатать с маской поверх старого изображения, затирая маской соседние 2 пикселя справа и снизу.
У кого какие мысли? Может еще есть какие способы, методы?
Думаю мины можно не стирать, а печатать с маской поверх старого изображения, затирая маской соседние 2 пикселя справа и снизу.
У кого какие мысли? Может еще есть какие способы, методы?
pop hl,de,ix
ld sp,hl
ex de,hl
dup 3
pop bc
ld a,(hl)
xor c
ld (hl),a
inc h
ld a,(hl)
xor b
ld (hl),a
inc h
edup
pop bc
ld a,(hl)
xor c
ld (hl),a
inc h
ld a,(hl)
xor b
ld (hl),a
ld sp,ix
ret
эта процедура должна использоваться для отрисовки левого и правого края обьекта (мины?)
для отрисовки середины можно использовать такую же, но просто с копированием
pop hl,de,ix
ld sp,hl
ex de,hl
dup 3
pop bc
ld (hl),c
inc h
ld (hl),b
inc h
edup
pop bc
ld (hl),c
inc h
ld (hl),b
ld sp,ix
ret
естественно перед тем как так рисовать
надо создать таблицу вида
#8000 адрес_обработчика, адрес_спрайта, адрес_на экране, #8008
#8008 адрес_обработчика, адрес_спрайта, адрес_на экране, #8010
#8010 конец обработки строки
вот это примерный алгоритм
как создавать такую таблицу и как к ней обращаться - об этом чуть позже
Lethargeek
11.12.2009, 16:06
Думаю мины можно не стирать, а печатать с маской поверх старого изображения, затирая маской соседние 2 пикселя справа и снизу
Да не "маской затирать", а просто разницу ксорить - примерно как у jerri
Только зачем там 4 раза pop? С двойными строками нужно только 4 байта
Разве что мины по-другому нарисовать (что все равно не стоит возни со стеком)
ну эт на случай если хочется сделать красиво :)
кстати вопрос такой - по вертикали мины будут всплывать со скоростью 2 пикселя так?
и пули из пушек тоже? а сталактиты?
а в оригинале как?
не будет ли нехватать скорости о сравнению с оригиналом
Lethargeek
11.12.2009, 17:11
ну эт на случай если хочется сделать красиво :)
кстати вопрос такой - по вертикали мины будут всплывать со скоростью 2 пикселя так?
и пули из пушек тоже? а сталактиты?
а в оригинале как?
Там не пули, там лучи из тайлов походу
Подозреваю даже, что оригинал юзает текстовый режим для фона
не будет ли нехватать скорости о сравнению с оригиналом
Ну, пик я уже до 25000 ужал, так что запасной вариант у вас всяко будет ;)
(даже с запасом на моргалки и прочие извращения)
В оригинале есть 4 уровня сложности:
1) Yeoman - 2,5 фрейма
2) Ensign - 2 фрейма
3) Captain - 1,5 фрейма
4) Admiral - 1 фрейм
Примечательно, что тайминги у платформы Atari совпадают с Spectrum. Т.е. если расположить рядом 2 эмулятора и запустить одновременно, то ландшафты скроллируются синхронно!;)
---------- Post added at 18:52 ---------- Previous post was at 18:34 ----------
Мины всплываю в 2 раза быстрее чем лодка. Т.е. получается за 1 фрейм - 2 пикселя.
Пули еще быстрее летят. Там да, что-то типа прерывистого луча из пуль получается.
Сталактиты - то же самое как мины.
Скорости нормально. В чем проблема-то может возникнуть? Как надо будет, так и оптимизируем.
---------- Post added at 18:54 ---------- Previous post was at 18:52 ----------
Подозреваю даже, что оригинал юзает текстовый режим для фона
Я совсем не знаю платформу Atari, но слышал, что там есть аппаратная поддержка спрайтов.
Lethargeek
11.12.2009, 20:48
В оригинале есть 4 уровня сложности:
1) Yeoman - 2,5 фрейма
2) Ensign - 2 фрейма
3) Captain - 1,5 фрейма
4) Admiral - 1 фрейм
Мне показалось 1)=2) и 3)=4) только мины злее всплывают
А фреймы умножь на два из-за низкого разрешения
наш реальный пиксель в два раза меньше
Примечательно, что тайминги у платформы Atari совпадают с Spectrum. Т.е. если расположить рядом 2 эмулятора и запустить одновременно, то ландшафты скроллируются синхронно!
Они у всех компов, рассчитанных на PAL, совпадают :)
На спеке только плавней получится
Я совсем не знаю платформу Atari, но слышал, что там есть аппаратная поддержка спрайтов.
Спрайты убогие, зато есть настоящий строчный видеопроцессор
Можно каждую строку ставить новый аппаратный режим
в том числе текстовые с графическими мешать
Lethargeek
13.12.2009, 22:49
Набил тупую проверку нового скроллера для зацикленного экрана
только прокрутка без подготовки, зато без оптимизации смены строк
и без блокировки обработчика MASK-INT (емнип 1720 тактов)
Здесь ровно 384 вертикальных "тайла" (против 204 на пиковом)
Хавает 44922+ без задержек и 48063 c задержками юлы-48
Соответственно (за минусом MASK-INT) на пиковом получается
примерно 23300 без задержек и около 25000 с задержками
(зависит от строки, с которой рисование начинается)
Кстати, Revision31 с медленной памятью на пике все-таки запинается
мой способ не пойдет с данной технологией
вопрос такой - хватит ли скорости для отрисовки и удаления полного спрайта?
т.е 16*3 или 12*5
т.е не бить его на куски
а перед скроллом местности убрать все что есть
прорисовать 2 строки
и после прорисовки нарисовать все спрайты
---------- Post added at 13:54 ---------- Previous post was at 12:42 ----------
//организация спрайтов
//адреса даны примерно
sp_line1 equ #6000
//как организовано?
//сначала в кучку друг за другом все первые линии обьектов
//потом все следующие линии обьектов в следующем параграфе
//и тд
sub_beg equ #00 //8*5 =#38
mine_beg equ #38 //8*3=#18
gunl_beg equ #50 //8*3=#18
gunr_beg equ #68 //8*3=#18
stal_beg equ #80 //8*3=#18
//здесь начинаем рисовать строку спрайтов
beg_line
//вот здесь можно сделать проверку на необходимость отрисовки
//чтото вроде
ld (sprdraw_sp),sp
ld sp,(sprites)
ret
end_line
ld (sprites),sp
ld sp,(sprdraw_sp)
ret
sprites dw 0
//отрисовка обьекта шириной 1
draw_sp1
pop hl //адрес Y
pop de //адрес на экране
pop bc //B высота С координата X
ld (store_sp1),sp
ld sp,hl
loop_sp1
pop hl
ld a,c
add a,l
ld l,a
ld a,(de)
xor (hl)
ld (hl),a
pop hl
ld a,c
add a,l
ld l,a
ld a,(de)
xor (hl)
ld (hl),a
inc d
djnz loop_sp1
ld sp,0
store_sp1 equ $-2
ret
//отрисовка обьекта шириной 2
draw_sp2
pop hl //адрес Y
pop de //адрес на экране
pop bc //B высота С координата X
ld (store_sp2),sp
ld sp,hl
loop_sp2
pop hl
ld a,c
add a,l
ld l,a
ld a,(de)
xor (hl)
ld (hl),a
inc l
ld a,(de)
xor (hl)
ld (hl),a
pop hl
ld a,c
add a,l
ld l,a
ld a,(de)
xor (hl)
ld (hl),a
dec l
ld a,(de)
xor (hl)
ld (hl),a
inc d
djnz loop_sp2
ld sp,0
store_sз2 equ $-2
ret
//отрисовка обьекта шириной 2
draw_sp3
pop hl //адрес Y
pop de //адрес на экране
pop bc //B высота С координата X
ld (store_sp3),sp
ld sp,hl
loop_sp3
pop hl
ld a,c
add a,l
ld l,a
dup 2
ld a,(de)
xor (hl)
ld (hl),a
inc l
edup
ld a,(de)
xor (hl)
ld (hl),a
pop hl
ld a,c
add a,l
ld l,a
dup 2
ld a,(de)
xor (hl)
ld (hl),a
dec l
edup
ld a,(de)
xor (hl)
ld (hl),a
inc d
djnz loop_sp3
ld sp,0
store_sз2 equ $-2
ret
единственное - необходимо 2 раза сканировать спрайты выводимые на экран
один раз для рисования - смотреть где находится нижняя часть спрайта
другой раз для стирания - смотреть где находится верхняя часть спрайта
но здесь нужно уже иметь на руках структуры объектов - как-то так :)
кстати :)
1. сколько фаз у взрыва?
2. как решать проблему ухода спрайта за экран? координаты то от 0 до 255 и если с клиппингом справа все нормально, то слева надо чтото решать
что-то ничего не понял. Ты словами на паЛЦАХ разъясни, что придумал.
Lethargeek
14.12.2009, 16:36
мой способ не пойдет с данной технологией
вопрос такой - хватит ли скорости для отрисовки и удаления полного спрайта?
т.е 16*3 или 12*5
Можно тупо дать лучу нужную фору, те же 16 строчек (~3600 тактов)
Хотя хрен его знает, может даже перед лучом успеем, он и не догонит
(если с прошлого фрейма все заранее подготовить для быстрой печати)
Я уже думал, чтобы не бить на знакостроки - не получается с тросами. Их точно надо бить если не на знакостроки, то на части. А если на части, то - это получается почти что то же самое, что и на знакостроки. Так уж лучше всё под одну гребенку сразу делать да и всё. Т.е. - знакостроки.
Если 1 фрейм - то однозначно надо перед лучом рисовать (у меня сейчас так). Это если бы 2 фрейма, тогда да - надо за лучом. А если 1 фрейм - то ПЕРЕД ЛУЧОМ и не надо мучиться высчитывать, пристраиваться, фору давать... Однозначно не догонит.
---------- Post added at 17:40 ---------- Previous post was at 17:07 ----------
а просто разницу ксорить
это как? Если просто мина сдвигается влево - то понятно. А если еще и всплывает вверх? то что ксорить? какова разница в этом случае? А если мина еще и взрывается в конце?
---------- Post added at 17:43 ---------- Previous post was at 17:40 ----------
Кстати, Revision31 с медленной памятью на пике все-таки запинается
видимо, придется отступить от оригинала. Посмотрим что будет с минами, там видно будет.
---------- Post added at 17:47 ---------- Previous post was at 17:43 ----------
один раз для рисования - смотреть где находится нижняя часть спрайта
другой раз для стирания - смотреть где находится верхняя часть спрайта
Я же предлагаю - давайте маской стирать при выводе, а? Будет экономится на вытаскивании адресов экрана и спрайта?
как решать проблему ухода спрайта за экран? координаты то от 0 до 255 и если с клиппингом справа все нормально, то слева надо чтото решать
Эти клиппинги всегда уйму тактов жрут. Если б захотел, послал бы их куда подальше...
Байта для координаты явно недостаточно. Значит надо 2 байта. Предлагаю 1-й байт - координата знакоместа, 2-й - смещение 0...7. Будем думать, пробовать.
---------- Post added at 17:53 ---------- Previous post was at 17:47 ----------
1. сколько фаз у взрыва?
5 фаз. Меняются каждые 2 фрейма.
Lethargeek
14.12.2009, 20:05
Я уже думал, чтобы не бить на знакостроки - не получается с тросами. Их точно надо бить если не на знакостроки, то на части. А если на части, то - это получается почти что то же самое, что и на знакостроки. Так уж лучше всё под одну гребенку сразу делать да и всё. Т.е. - знакостроки.
Или можно тросы тупо забить в ландшафт и не страдать
Если мина уничтожена, заменяешь тайл на пустой
(в моем случае можно просто стереть в экране)
Если 1 фрейм - то однозначно надо перед лучом рисовать (у меня сейчас так). Это если бы 2 фрейма, тогда да - надо за лучом. А если 1 фрейм - то ПЕРЕД ЛУЧОМ и не надо мучиться высчитывать, пристраиваться, фору давать... Однозначно не догонит.
Только если успеешь после фона еще и спрайты отрисовать
которые, даже отсортированные, могут скопиться наверху
То есть луч до ВЕРХНИХ строк не должен успеть дойти
Но даже 4-я знаколиния ~ 22000 тактов с начала кадра
это как? Если просто мина сдвигается влево - то понятно. А если еще и всплывает вверх? то что ксорить? какова разница в этом случае? А если мина еще и взрывается в конце?
Блииин... ну наксорь одну целую картинку на другую, это и будет разница
Наксорь эту разницу на любую из двух исходных картинок, получишь вторую
О масках вообще забудь, не нужны они здесь
видимо, придется отступить от оригинала. Посмотрим что будет с минами, там видно будет.
Лучше подожди, пока я добью свой скроллер до вменяемого исходника
Или отступать придется далековато :)
Эти клиппинги всегда уйму тактов жрут. Если б захотел, послал бы их куда подальше...
Байта для координаты явно недостаточно. Значит надо 2 байта. Предлагаю 1-й байт - координата знакоместа, 2-й - смещение 0...7. Будем думать, пробовать.
Что там сложного - печатай столбиками, начинай не с первого, вот и все
Вместо смещения брать циклически следующий адрес сдвинутого спрайта
(или процедуры, которая рисует нужную фазу)
что-то ничего не понял. Ты словами на паЛЦАХ разъясни, что придумал.
вот картинка :)
перед тобой проскроленныый спрайт прямоугольника 8*16
в том самом виде в каком он будет хранится в памяти
т.е переход к следующему ряду = inc h
переход по горизонтали - inc l
что дает такой способ хранения - нет необходимости в спец процедурах для клипирования просто берешь и выводишь тупо задавая ширину
далее переход между строками экрана
в стеке - таблица адресов и мы оттуда достаем по 1 и корректируем
так проще?
я вот тут про JITScroll подумал
Lethargeek, а как ты собирался вообще собирался код генерить для компактного выполнения?
просто как я смотрю это же должен быть чистый код. не?
чтото вроде
ld e,l
rl (hl)
ldd
ld e,l
rl (hl)
ldd
dec l
dec l
dec l
ld e,l
rl (hl)
ldd
ret
и в начало добавлять новые элементы?
или я чтото не так понял?
хотя конечно если точно знать - а мы знаем
то можно упростить до
rl (hl)
ldd
rl (hl)
ldd
dec l
dec l
dec l
ld e,l
rl (hl)
ldd
ret
а ld e,l добавлять перед очередным большим блоком
а карту паковать с управляющими кодами
Lethargeek
17.12.2009, 17:53
Да все мы знаем конечно
Там на скроллер каждой строки должен быть дескриптор
Типо адреса начала-конца, отступ справа, левый столбец
А потом каждый восьмой кадр отступ либо увеличить
либо закрыть (записать нужный кусок для пропуска)
и дописать в начало еще кусок любым способом
Нужный кусок можно по-разному выбирать
можно отдельным потоком, можно прямо по номеру тайла
(если нужно, возможны одинаковые с виду с разными номерами)
Потом смотрим, где последний столбец и кусочками режем хвост
(по концевому байту однозначно видно, когда обрезку прекратить)
Также можно сразу же корректировать оценку быстродействия
(для вставки задержек, если за лучом рисовать)
Сам код будет несколько другой, подогнал еще под ландшафт
ну есть пара идей относительно генерения
правда декрунчер получается слишком психаделический
Lethargeek
20.12.2009, 05:32
Для начала лишь бы работало
хоть через таблицу переходов
Кодить некогда...
;JIT алгоритм
;кстати что значит JIT?
итак изначально имеем рабочую область 160 на 256
т.е 20 тайловых строк
итак производим генерацию кода для обработки тайловой строки
для начала определяемся как все будет
итак
буфер под код 256 байтов
при максимальной загрузке
вида
ld e,l
rl (hl)
ldd
5*32 - 160 байтов
буфер должен выглядеть как то так
rl (hl)
ldd
rl (hl)
ldd
dec l
dec l
dec l
dec l
ld e,l
rl (hl)
ldd
ret
l_init
;h-старший байт адреса
звполняем таблицу
ld l,-1
;инициируем таблицу переходов
ld b,32
ld (hl),-27
dec l
djnz $-3
;создаем ссылку на текущий байт в таблице переходов
ld (hl),-1
dec l
;закручиваем скроллер в кольцо
ld (hl),1
dec l
ld (hl),h
dec l
ld (hl),#c3
dec l
ld (hl),#c9
ld a,l
ld l,0
;инициируем трамплин
ld (hl),a
ret
l_proc
;обработчик
ld l,0
ld l,(hl)
ld (jmp_item),hl
ex de,hl
ld a,l
call $+3
call $+3
call $+3
call $
jmp_item equ $-2
ld l,a
ret
l_gen
;генератор
d-старший байт
a-статусный байт
;статусы
0-пустота (камень или вода)
1-начало линии
2-середина линии
3-конец линии
add a,a
add a,jmp_gen
ld l,a
adc a,jmp_gen/256
sub l
ld h,a
ld a,(hl)
inc hl
ld h,(hl)
ld l,a
jp (hl)
jmp_gen dw jit_0,jit_1,jit_2,jit_3
jit_0
ex de,hl
ld l,-32
ld a,(hl)
dec a
or #e0
ld c,a
ld (hl),a
ld b,h
ld l,0
ld l,(hl)
ld a,l
dec a
call z,corr_jitb
dec l
ld (hl),#2d dec l
ld a,l
ld (bc),a
ld l,0
ld (hl),a
ret
corr_jitb
ld a,l
ld l,-33
ld (hl),a
dec l
ld (hl),h
dec l
ld (hl),#c3
ret
jit_1
ex de,hl
ld l,-32
ld a,(hl)
dec a
or #e0
ld c,a
ld (hl),a
ld b,h
ld l,0
ld l,(hl)
dec l
call z,corr_jitb
ld (hl),#5d ld e,l
ld de,#cb16 rl (hl)
call place_word
ld de,#eda8 ldd
call place_word
ld a,l
ld (bc),a
ld l,0
ld (hl),a
ret
place_word
ld a,l
cp 3
call c,corr_jitb
dec l
ld (hl),e
dec l
ld (hl),d
ret
както так
это предварительные прикидки - позже наверное напишу остальное да и багу выловить надо :)
Just In Time? т.е. "реального времени"
---------- Post added at 17:50 ---------- Previous post was at 17:48 ----------
От ldd Lethargeek в свое время отказался, т.к. получается дольше с ней (как ни странно) и сложнее.
Just In Time? т.е. "реального времени"
лучше перевести - "по ходу дела", т.е. как только понадобилось
Just In Time? т.е. "реального времени"
---------- Post added at 17:50 ---------- Previous post was at 17:48 ----------
От ldd Lethargeek в свое время отказался, т.к. получается дольше с ней (как ни странно) и сложнее.
я понимаю что отказался :)
а какая альтернатива?
рассмотрим кусочек
ld e,l (4) если первый сивол в цепочке
srl (hl) (15) скроллим элемент
ldd (16) дублируем линию
35 тактов на эти 2 байта
rl (hl)
ldd
31 такт на следующие
есть вариант короче?
---------- Post added at 20:38 ---------- Previous post was at 20:30 ----------
итак изначально имеем рабочую область 160 на 256
т.е 20 тайловых строк
итак производим генерацию кода для обработки тайловой строки
для начала определяемся как все будет
итак
буфер под код 256 байтов
при максимальной загрузке
вида
ld e,l
rl (hl)
ldd
5*32 - 160 байтов
буфер должен выглядеть как то так
rl (hl)
ldd
rl (hl)
ldd
dec l
dec l
dec l
dec l
ld e,l
rl (hl)
ldd
ret
l_init
;h-старший байт адреса
звполняем таблицу
ld l,-1
;инициируем таблицу переходов
ld b,32
ld (hl),-27
dec l
djnz $-3
;создаем ссылку на текущий байт в таблице переходов
ld (hl),-1
dec l
;закручиваем скроллер в кольцо
ld (hl),1
dec l
ld (hl),h
dec l
ld (hl),#c3
dec l
ld (hl),#c9
ld a,l
ld l,0
;инициируем трамплин
ld (hl),a
ret
l_proc
;обработчик
ld l,0
ld l,(hl)
ld (jmp_item),hl
ex de,hl
ld a,l
call $+3
call $+3
ld d,h
inc d
call $
jmp_item equ $-2
ld l,a
inc h
inc h
ret
l_gen
;генератор
d-старший байт
a-статусный байт
;статусы
0-пустота (камень или вода)
1-начало линии
2-середина линии
3-конец линии
add a,a
add a,jmp_gen
ld l,a
adc a,jmp_gen/256
sub l
ld h,a
ld a,(hl)
inc hl
ld h,(hl)
ld l,a
jp (hl)
jmp_gen dw jit_0,jit_1,jit_2,jit_3
jit_0
ex de,hl
ld l,-32
ld a,(hl)
dec a
or #e0
ld c,a
ld (hl),a
ld b,h
ld l,0
ld l,(hl)
ld a,l
dec a
call z,corr_jitb
dec l
ld (hl),#2d dec l
устанавливаем точку возврата из рисовальщика
наверное можно сделать быстрее но лень думать
ld d,h
ld a,(bc)
ld e,a
ld a,#c9
ld (hl),a
ld a,l
ld (bc),a
ld l,0
ld (hl),a
ret
corr_jitb
ld a,l
ld l,-33
ld (hl),a
dec l
ld (hl),h
dec l
ld (hl),#c3
ret
jit_1
ex de,hl
ld l,-32
ld a,(hl)
dec a
or #e0
ld c,a
ld (hl),a
ld b,h
ld l,0
ld l,(hl)
dec l
call z,corr_jitb
ld (hl),#5d ld e,l
ld de,#cb16 rl (hl)
call place_word
ld de,#eda8 ldd
call place_word
ld d,h
ld a,(bc)
ld e,a
ld a,#c9
ld (hl),a
ld a,l
ld (bc),a
ld l,0
ld (hl),a
ret
place_word
ld a,l
cp 3
call c,corr_jitb
dec l
ld (hl),e
dec l
ld (hl),d
ret
както так
это предварительные прикидки - позже наверное напишу остальное да и багу выловить надо :)
Как продвигается работа по игре?..
Создал статью в ру-вики: http://ru.wikipedia.org/wiki/Sea_Dragon
Кстати, скорее всего под именем "Sea Dragon" имеется в виду вот эта лодка (если конечно какая-то вообще конкретная имеется в виду):
http://en.wikipedia.org/wiki/USS_Seadragon_(SS-194)
http://upload.wikimedia.org/wikipedia/commons/thumb/0/0c/USS_Seadragon_(SS-194)%3B0819404.jpg/300px-USS_Seadragon_(SS-194)%3B0819404.jpg
---------- Post added at 18:24 ---------- Previous post was at 16:43 ----------
Версия для Apple II примечательна тем, что в ходе показа титульного экрана проигрывался оцифрованный голос, произносящий название игры. Когда пользователь начинает игру, голос произносит «Attention Captain. Your ship’s computer is now ready. Please wait while I initialize the systems» («Внимание, капитан. Компьютер вашего корабля готов к работе. Пожалуйста, подождите пока я подготовлю все системы.») и в ходе игры предупреждает: «Air level critical!» («Критический уровень воздуха!») и «Approaching maximum damage!» («Получено множество повреждений!»). Оцифрованная речь была новшеством, динамик Apple II обычно использовался лишь для несложных звуков. Другие порты Sea Dragon не имели такой возможности, кроме версии для TRS CoCo: для титульного экрана голос произносил «Welcome aboard, Captain!» («Добро пожаловать на борт, капитан!»).
Думается, что в версии для спека такая функция бы очень даже не помешала -- этакая фишечка. Лучше даже на русском.
---------- Post added at 18:42 ---------- Previous post was at 18:24 ----------
Посмотрел видео.
На TRS-80 игра удивляет своим динамизмом - это в псевдографике-то! И кстати ощущение что на TRS сложнее пройти.
На Atari 8-bit отличное звуковое оформление: классные звуки выстрелов и время от времени звук похожий на радар.
---------- Post added at 18:47 ---------- Previous post was at 18:42 ----------
На mobygames есть обложки от игры:
http://www.mobygames.com/game/sea-dragon/cover-art
http://www.mobygames.com/images/covers/large/1193719674-00.jpg
Версия для Atari -- самая красивая:
http://www.mobygames.com/game/sea-dragon/screenshots
Посмотрел исходники проекта -- там только код в виде .zx и некий .trd видимо со спрайтами и ещё чем-то. А можно некий ридми поиметь в плане чем вы разрабатываете и что куда засовывается и чем собирается? Или лучше мне куда в другое место сходить почитать как что делается?
.zx для SjASMPlus Z80 кросс ассемблер http://zx.pk.ru/showthread.php?t=447
.trd - для любого эмулятора.
Lethargeek
23.01.2010, 09:18
Погодите, скоро выложу свои наметки
как только выдеру с полудохлого винта
(старый комп сломался)
Для интереса посмотрел код первоначальной версии, под TRS-80.
Там 15,5 КБ бинарника, дизассемблированных это порядка 10000 строк.
Образ игрового экрана они держат отдельно, каждый раз копируя его полностью на экран -- это 15 строк по 64 байта. Пока не понял как хранится рельеф и спрайты -- ещё покопаюсь...
Нашёл как там задётся рельеф. Сильно завязано на особенности TRS-80 -- там в каждой строчке по три пикселя (точнее, там каждый символ экрана может быть "графическим" как матрица 2x3 пикселей). Поэтому, если присмотреться, на рельефе эти строки хорошо видны -- там где соседние пиксели стыкуются углами.
UPD: В итоге оказалось что кода там около 7 КБ, 3300 строк, остальное данные и пустоты.
эхх 15*64 всего 960 байт бросать :(
не то что нам
Во вложении -- результат трудов с пятницы по вторник.
Что сделано:
1. Взят образ диска для TRS-80 и вынут оттуда SEADRAG/CMD -- во вложении SEADRAG.CMD
2. Написана программа для убирания лишних байтиков данных загрузчика -- результат в SEADRAG.BIN -- это то что загружается и запускается с адреса 74ae
3. Декомпилятором dZ80 получен "сырой" исходник
4. Потрачено ещё несколько суток на получение более-менее осмысленного исходника. Раскопал не всё, но многое -- по крайней мере, основная логика есть.
Дальше это рубить пока сил нет, выкладываю как есть.
Буду рад если вам это хоть как-то пригодится.
Тому кто будет разбираться -- пригодятся ссылки:
http://en.wikipedia.org/wiki/TRS-80#Hardware
http://www.trs-80.com/trs80-zaps-internals.htm
Хотел подобным же образом игрушку для Атари посмотреть -- но там несколько замороченный процесс загрузки и незнакомый для меня ассемблер.
Всё что смог пока сделать -- раскодировать из формата CAS, получив "сырые" загружаемые данные.
В аттаче:
"Sea Dragon.cas" -- исходный файл игрушки, образ кассеты в формате CAS, можно например в эмуляторе запустить
"Sea Dragon.bin" -- раскодированный из .cas "сырой" дамп
В начале дампа находится 6-байтный заголовок, из которого следует что нужно загружать первые шесть (первый + 5) 128-байтных блока с адреса 3C80, затем управление передаётся этому загрузчику. Дальше я потерялся...
Формат записи на кассете описан тут: http://www.atariarchives.org/dere/chaptC.php
Формат CAS описан в README.TXT в утилите WAV2CAS тут: http://home.planet.nl/~ernest/atarixle.html
Дизассемблер 6502: http://www.masswerk.at/6502/disassembler.html
Наконец-то хоть что-то сделал с объектами, спрайтами.
Этот объект пока на знаколинии разложишь - мозг сломаешь!:v2_crazy: Ведь всё усугубляется еще и клиппингом.
В итоге - куча процедур печати, куча таблиц для заполнения буфера...
15928
1) Долго долго думал, на каком же способе печати спрайтов остановитсья. В итоге сделал вывод спрайтов маской. Т.е. объекты не затираются перед выводом ландшафта, а затираются краешком маски прямо при выводе.
Правда не совсем понятно как будут затираться пули от пушек - ведь у них шаг где-то 4 или 8 пикселей.
Тросы пока сделал печаткой спрайта 8на8 пикселей поэтому они так много и жрут времени.
2) Можно, конечно, затирать и выводить спрайты ксоркой, но это раза в 1.5 будет времени думаю. Т.к. придется делать 2 буфера спрайтов. Один для вывода на текущем кадре, другой - для затирания на предыдущем. Зато будет проще. Не надо будет заботиться о стирании объектов - прогнав буфер 2-й раз он вернет фон к первоначальному состоянию.
В общем, что-то я не доволен. Как же лучше сделать?
Отличный прогресс за последнее время.
Просматривая ревизию 51 на эмуляторе (EmuZWin 2.7) заметил один артифакт, см. аттач -- пустая линия высотой в две или три строки -- это если долго ждать. Ещё в паре мест скроллинг замирает где-то на 0.1-0.2 секунды.
Ещё -- эффект на бордюре может быть стоит убрать? Ведёт себя очень нестабильно, прыгает, моргает.
эффект на бордюре может быть стоит убрать? Ведёт себя очень нестабильно, прыгает, моргает.
этот эффект скорее всего показывает кол-во тактов.
На скорую руку сделал под 2 буфера (стирание и вывод ксоркой). Как я и предполагал, получилось дольше даже не в 1,5 раза, а в 2 почти.
В общем, полная лажа. Придется обходится одним буфером как в ревизии 51.
Прикольно когда, что-то движеться:)
16005
Пока без взрывов.
Нда, клэшинг неизбежен.:v2_conf3:
Сделал раскраску ландшафта. Цвета сдвигаются одновременно с ландшафтом.
16057
Ну, допустим, мины я подвину подальше от краёв ландшафта, Но пушки-то всё равно будут переливаться!:v2_blink:
Можно попробовать выводить цвета вместе со спрайтами, сохраняя атрибут фона под спрайтом, а потом восстанавливая его. Но от клэшинга это не спасет (будет тогда край ландшафта переливаться), а накладные расходы увеличатся существенно. Нужно ли?
Похвастаюсь процедурой вывода экрана :v2_finge:.
;печать видимой части ландшафта
;IN: LeftLandPtrs
PrnScreen ;{
di
ld (RestoreSPAndReturn+1),sp
ld sp,LeftLandPtrs ;sp - Указатель на указатели начал видимой части строк
jr _1PrnScreen
EndParseTileBuffer
ld sp,ix ;10 ;сохраненный sp
pop hl ;10
ld sp,hl ;6=26 ;загружаем адрес буфера спрайтов
ret ;разбор буфера спрайтов для этой строки
EndParseSpriteBuffer
pop hl ;10 ;в конце каждого буфера спрайтов хранится сохраненный sp
ld sp,hl ;6
_1PrnScreen
pop ix ;14 ;сохраненный sp. Запомним его в ix
pop hl ;10
ld sp,hl ;6=46 ;загружаем адрес буфера тайлов
ret ;разбираем буфер тайлов
;}
Так со стекпоинтом я еще никогда не развращался , спасибо Jerri, что научил.
По мне так лучше выкинуть разные цвета в игровой области -- клэшинг очень сильно заметен. Пусть будут мины в цвет ландшафта, ничего страшного -- за счёт текстуры земля будет от них хорошо отличаться.
Плавность скроллинга сохранилась -- это отлично.
А вот текстуру лучше сделать менее шашечной -- сейчас она создаёт некоторый муаровый эффект. И жёлтый цвет земли смотрелся лучше чем красный.
Там где ряд вертикальных шахт с минами -- скроллинг резко замедлился.
Нда... это карма пора менять монитор - не вижу чорных спрайтов на синем фоне :(
Barmaley_m
19.02.2010, 16:25
Там где ряд вертикальных шахт с минами -- скроллинг резко замедлился.
В этом месте скорость программы недостаточна, чтобы отрисовка всего уложилась в один кадр. Это место всегда было наиболее трудным для реализации - из-за него, собственно, было перепробовано много разных вариантов отрисовки ландшафта. Если почитаешь эту тему сначала, наблюдая за эволюцей проекта, то станет понятно.
Я так понимаю, что автор проекта пока еще не использовал все возможности для оптимизации кода, поэтому можно надеяться, что место с большим числом шахт будет в конце концов сохранять плавность скроллинга.
Что касается цветов - то по мне - смотрится красиво. Шашечность мне тоже не очень понравилось, хотя это дело привычки, наверное. Черные мины смотрятся тоже хорошо, и если возможно уменьшить клэшинг путем их перемещения - то я за такой вариант. Что делать с пушками - наверно, выяснится, когда они появятся.
"А кузов-то - с оцинковкой!"
1) В добавление к текстуре сделана окантовка краёв. Мне кажется - так намного лучше.
2) Так как атрибуты обрабатываются и выводятся независимо от самого ландшафта, то решил сделать и редактор цветов, а не брать их исходя из расположения тайла.
Barmaley_m
15.04.2010, 14:46
Что-то не работает снапшот... Слетает в сброс.
48K теперь в отличие от прошлых ревизий. Может с этим что-то связано?
Сейчас проверил на нескольких эмулях. Везде работает.
ммм а скорости все равно не хватает там где много шахт :(
что делать будешь?
Скорее всего их обрежу по глубине
Вообще, на такой скорости в игру почти невозможно играть и до шахт никто не доберется. Так что, грубо говоря, в запасе есть целый фрейм.
Barmaley_m
19.04.2010, 17:09
Все, разобрался, запустил! Это у меня просто какая-то очень старая версия валялась не в той папке, ее пытался запустить по ошибке. У меня на экране, где много шахт, тормозов не было. И даже с большим запасом! Турбо вроде бы выключено.
---------- Post added at 15:04 ---------- Previous post was at 14:47 ----------
Хотя нет, турбо все-таки было включено - блин, пока нашел способ, как его отключить, замучался.
Без турбо не укладывается в кадр только на том экране, где много шахт. Но ведь это круто, значит остальная часть игры вся укладывается! Надеюсь на дальнейшие успехи автора и жду выход обновлений!
---------- Post added at 15:06 ---------- Previous post was at 15:04 ----------
Вообще, на такой скорости в игру почти невозможно играть и до шахт никто не доберется. Так что, грубо говоря, в запасе есть целый фрейм.
Ну, это не скажи! Всегда находятся фанаты, которые проходят казалось бы невозможную игру на максимальном уровне сложности! Я вон долго тренировался в амижный Speedball 2 и теперь уверенно выигрываю со счетом 130:10 у Fatal Justice. А если еще посмотреть на ютубе ролики, как люди играют в игры - то ты их явно недооцениваешь! Доберутся и до шахт, и до конца игры, и еще скажут, что было слишком легко! :)
---------- Post added at 15:09 ---------- Previous post was at 15:06 ----------
А так вообще я думаю, что можно уже переходить к игровой логике, к отрисовке лодки, пушек и снарядов. Тот экран, где много шахт - на нем можно сделать обновление 1 раз в 2 кадра. Типа graceful degradation. Будет заметно, но не убийственно, да и то чайники могут не понять вообще, в чем тут дело.
Barmaley_m
21.04.2010, 00:05
Обалдеть! Вот это настоящая красота! Даже злобный корабль с глубинными бомбами реализован!
Подправил немного, а то зависало когда много объектов
http://zx.pk.ru/attachment.php?attachmentid=17324&stc=1&thumb=1&d=1271970241
Подлодка не утонет...:speccy:
Ограничения введи на подъем\спуск, а то перепрыгивать через миноносец не прикольно :)
Сегодня разбирал свои архивы и случайно наткнулся на дискетку.
Жаль, запустить уже не на чем, но душу греет.
http://s56.radikal.ru/i152/1004/13/389b1f95d4ff.jpg
Попробовал сделать заставку. За основу взял старую рекламу этой игрушки.
Первый кадр -- подготовленный исходник, второй кадр -- то что получилось.
Художник из меня конечно никакой, но вдруг пригодится.
Это, конечно, никуда не годится. Прогнать через конвертер любой может.
Нужно цветное, адаптированное к атрибутам спектрума.
Вон, смотри на Preliminary Monty. Я ведь тоже не художник, однако помучившись с недельку, все ж накарякал.
Добавлю еще, что та заставка - это моя первая в жизни цветная screen.
Добавлю еще, что та заставка - это моя первая в жизни цветная screen.
Однакооо. С такой картинкой, как в Монти, тебе в лёгхкую на патях выставляться. Я думал, что её кто другой нарисовал.
http://s56.radikal.ru/i152/1004/13/389b1f95d4ff.jpg
На Atari в живую видел только Spy VS Spy, ну, и конечно, Sea Dragon.
Spy VS Spy очень нравилась, долго в нее резались.
Это, конечно, никуда не годится. Прогнать через конвертер любой может. Нужно цветное, адаптированное к атрибутам спектрума.
Окей. Вот второй драфт, уже в цвете, но пока без существенной проработки и без окружающего фона.
В таком направлении нормально будет?
UPD: Добавил фон.
В общем вот пока что получилось -- сегодня сил нет уже доделывать. Покритикуйте пожалуйста.
http://img-fotki.yandex.ru/get/4309/nzeemin.3/0_3da74_69102555_M.jpg
Что там ещё нужно из графики? На главном меню что будет?
Покритикуйте пожалуйста.
nzeemin, в левом нижнем углу надо-бы завихрения от запуска ракеты сделать, белым цветом что-ли. Или наоборот, след от ракеты белым, а там жёлтым с добавками красного. И вот тень от взрыва, что в в середине лодки, что-то не того. Ну и главное, где название игры-то?
Я считаю, названия не надо. Оно будет уже после загрузки в главном меню.
Все детали (лодка, бомбы, торпеда) надо бы почётче, т.е. без излишних крапинок. Особенно лодка, она ведь занимает много пикселей, можно прорисовать. При желании можно даже на борту надпись сделать. Эх, узнать бы что там написано в оригинале (или на прототипе).
Клубы дыма, думаю, должны быть черными.
Взрыв отличный! класс!
scr, тоже кидай в приложении.
Я считаю, названия не надо. Оно будет уже после загрузки в главном меню.
Все детали (лодка, бомбы, торпеда) надо бы почётче, т.е. без излишних крапинок. Особенно лодка, она ведь занимает много пикселей, можно прорисовать. При желании можно даже на борту надпись сделать. Эх, узнать бы что там написано в оригинале (или на прототипе).
Клубы дыма, думаю, должны быть черными.
Взрыв отличный! класс!
scr, тоже кидай в приложении.
Про почётче это понятно -- но уже руки дрожат и глаза слипаются.
Надпись в оригинале -- "U.S.S SEA DRAGON", но при таком уменьшении она неразборчива и трудно сделать её действительно разборчивой. Там ещё и морда дракона была.
Про клубы дыма не понял -- это то что от ракеты, жёлтым? В оригинале этот след вообще белый.
SCR во вложении.
клубы дыма что по периметру картинки.
Barmaley_m
26.04.2010, 15:31
клубы дыма что по периметру картинки.
то по-моему не дым, а края пещер, в которые погружается подлодка. Собсно, по ходу игры она ведь в самом деле в пещерах ходит!
Про клубы дыма не понял -- это то что от ракеты, жёлтым?
Именно от ракеты.
http://img-fotki.yandex.ru/get/4309/nzeemin.3/0_3daff_6a87b154_M.jpg
Ну вот, а теперь внутренность взрыва там слегка подшалмань, а то чисто белый как-то не смотрится. Добавь там жёлтого, и красного немного.
Что там ещё нужно из графики? На главном меню что будет?
Конверсии ацтой, что тут критиковать.
Посмотри работы с Hackers Top и поймешь в каком направлении двигаться.
Конверсии ацтой, что тут критиковать.
Не все. Ты хочешь сказать Spellbound Dizzy плохо сделана? Тут лодка то-же ничего, просто немного надо довести "до ума".
Подлодка прозрачная? :v2_blush: (одного цвета с водой)
Фиолетовое зарево это что?
---------- Post added at 21:00 ---------- Previous post was at 20:59 ----------
Не все. Ты хочешь сказать Spellbound Dizzy плохо сделана? Тут лодка то-же ничего, просто немного надо довести "до ума".
При чем тут дизи?
А до ума.. да часов 5 посидеть может что то и выйдет.
Фиолетовое зарево это что?
Вообще-то это скалы должны быть... Подводные, естественно. :)
http://img-fotki.yandex.ru/get/4309/nzeemin.3/0_3daff_6a87b154_M.jpg VS http://2mus.ru/showscreen.gif
Вот приколисты эти америкосы.
Искренне полагал, что на передней бочке нарисован иероглиф -- типа корейцы.
Только сейчас понял что там серп и молот, только отражённый -- по ошибке.
nzeemin, ты там ещё чего правишь на картинке или всё, так и оставляешь? Если править больше не будешь, выложи скрин пожалуйста.
nzeemin, ты там ещё чего правишь на картинке или всё, так и оставляешь? Если править больше не будешь, выложи скрин пожалуйста.
Правлю ещё. Куда торопится-то.
newart конечно поубавил энтузиазма, но не до конца.
Правлю ещё. Куда торопится-то.
Замечательно.
newart конечно поубавил энтузиазма, но не до конца.
Ты его не слушай. Вот (http://www.zx.pk.ru/showpost.php?p=264694&postcount=698) тоже конверсия начатая скандалист и другозавр-ом и законченная мной. Интересно, какое место она-бы заняла на Hackers Top? ;)
Надеюсь она сподвигнет тебя на новые мысли по улучшению картинки с лодкой.
Barmaley_m
27.04.2010, 00:09
Отличная картинка получается! Поддерживаю nzeemin. Идея: а что если попробовать черный фон? Вода-то в глубине - она черная! Да и лодка тоже черная, а так голубым цветом будут прорисованы только контуры ее корпуса.
А какие проблемы с надписью? Разве сложно ее по пикселям прорисовать, чтобы было разборчиво?
И может название поменять? USS Sea Dragon - это как-то слишком по-американски, а у нас ведь российская подлодка получается - может "Курск"? ;)
И может название поменять? USS Sea Dragon - это как-то слишком по-американски, а у нас ведь российская подлодка получается - может "Курск"?
Не надо менять название, тем более на "Курск".
Отличная картинка получается! Поддерживаю nzeemin. Идея: а что если попробовать черный фон? Вода-то в глубине - она черная! Да и лодка тоже черная, а так голубым цветом будут прорисованы только контуры ее корпуса.
А какие проблемы с надписью? Разве сложно ее по пикселям прорисовать, чтобы было разборчиво?
И может название поменять? USS Sea Dragon - это как-то слишком по-американски, а у нас ведь российская подлодка получается - может "Курск"? ;)
Спасибо.
Думал чёрный использовать для окантовки кораллов -- когда их прорисую.
Надпись стала более разборчивой, если вы заметили.
А название менять не стоит -- сохраним "историческую достоверность".
http://img-fotki.yandex.ru/get/4213/nzeemin.3/0_3db39_764c5116_M.jpg http://img-fotki.yandex.ru/get/4311/nzeemin.3/0_3db4b_93f7b7ec_M.jpg
Ооо, и слева взрыв поменял - отлично!
Barmaley_m
27.04.2010, 13:15
Надпись стала более разборчивой, если вы заметили.
Да и вообще намного лучше стало!
Хотя мне не совсем понятно, почему нельзя сделать надпись разборчивой. Там вроде достаточно пикселей - можно вручную по точкам прорисовать надпись, не беда что будет отличаться чуть-чуть по шрифту от оригинала.
А название менять не стоит -- сохраним "историческую достоверность".
Ну хорошо, сохраним! В самом деле.
Правлю ещё. Куда торопится-то.
newart конечно поубавил энтузиазма, но не до конца.
Вызвался помоч, а занимаешься халтурой (конвертишь).
Оригинал некудышный выбрали, цветных постеров с подлодками сотни по интернету, они без доработки буду выглядеть лучше чем это...
В сабже ракурс отвретительный (не выгодный) лодка получается картонная (плоская) и одинаковым цветом фона и лодки ты этот эффект только усугубляешь.
Оригинал некудышный выбрали, цветных постеров с подлодками сотни по интернету, они без доработки буду выглядеть лучше чем это...
Зато снято с оригинала. Всё нормально.
Не обязательно брать с оригинала.
В игре графику я не буду точь в точь передергивать. Попробую сделать лучше. Хотя т.к. в движке каждая 2 строчка дублируется, то особо детельной прорисовки не получится.
Потому что в Монти правильная была, я считаю, критика. Мол графика квадратная, некрасиво.
Нужно делать красиво. Чтобы было в итоге лучше и приятнее.
---------- Post added at 14:07 ---------- Previous post was at 13:42 ----------
Вызвался помоч, а занимаешься халтурой (конвертишь).
Оригинал некудышный выбрали, цветных постеров с подлодками сотни по интернету, они без доработки буду выглядеть лучше чем это...
В сабже ракурс отвретительный (не выгодный) лодка получается картонная (плоская) и одинаковым цветом фона и лодки ты этот эффект только усугубляешь.
А мне нравится.
Ладно, в общем выкладываю scr -- дальше что хотите делайте.
Ладно, в общем выкладываю scr -- дальше что хотите делайте.
Ну вот, обидели человека. Делай дальше и никого не слушай.
nzeemin, ты это... не бросай. Я вон тоже неделю делаю без передыху, по ночам... потом простаиваю месяц пока вдохновения нет.
Как время у тебя появится, рисуй помаленьку. Правильно ведь подметил, торопится пока некуда.
Попробуй проплыви :v2_devil:
Сделай контроль ухода влево
а то доходишь до края экрана и кирдык
Да сделаю, сделаю... Это легко ведь. А сейчас не принципиально. Ведь выкладываю чтобы просто посмотреть что примерно получается, движок отладить и т.д.
Вопрос: как цвета? клэшинг? Так оставлять? Подлодку подкрашивать не хочу белым цветом. Или все-таки надо?
А пока объявляю конкурс на окончание лабиринта. Каким ему быть?
По легенде подлодка плывёт чтобы уничтожить ядерный реактор, запрятанный СССР глубоко в пещерах.
В версии TRS-80 там - щит, в который нужно много раз стрелять, чтобы пробить.
В версии Atari там - даже непонятно, что это щит.
Ни одна версия по части графики мне не нравится. Надо бы сделать покрасивей. Предлагайте варианты.:confused:
Начало игры на TRS-80 -- подлодка вверху, вся нижняя часть забита землёй -- можно так же сделать чтобы игра не начиналась с вертикальной стены.
Клешинг цветов всё-таки сильно проявляется -- очень заметно будет.
Текстуру земли лучше сделать менее регулярной -- то как сейчас наверняка на многих старых мониторах вызовет муар.
Лодку в белый перекрашивать не стоит -- пусть чёрной остаётся.
В версии для TRS-80 можно было стрелять вверх клавишей Enter -- так же будет?
В версии для TRS-80 можно было стрелять вверх клавишей Enter -- так же будет?
Не знал. Спасибо.
Подумаю...
Уф, фантазия у меня на этом закончилась.
Особо, правда, не детализируешь, т.к. идет повтор каждой 2-й строки. Да еще и тайл занимает всего 1 знакоместо.
Т.е. текстура задается 4-мя байтами. К примеру вариант 01:
TEXTURE0 = %11101110
TEXTURE1 = %01110111
TEXTURE2 = %10111011
TEXTURE3 = %11011101
Ну? Какую оставлять?
Фотографии в альбоме «Текстуры (http://fotki.yandex.ru/users/ace210/album/97309/)» ace210 (http://ace210.ya.ru/index_fotki.xml)
И еще. Ландшафт разноцветным делать, как сейчас, или одного цвета на всём протяжении?
http://img-fotki.yandex.ru/get/4313/ace210.4/0_4bf2a_aa6d4397_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311082/)
[more]
http://img-fotki.yandex.ru/get/4208/ace210.4/0_4bf2c_ec8ee035_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311084/)
http://img-fotki.yandex.ru/get/4207/ace210.4/0_4bf2d_c766ed83_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311085/)
http://img-fotki.yandex.ru/get/4313/ace210.4/0_4bf2e_6e1580ab_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311086/)
http://img-fotki.yandex.ru/get/4314/ace210.4/0_4bf30_c7dcdad1_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311088/)
http://img-fotki.yandex.ru/get/4308/ace210.4/0_4bf31_864fdfcb_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311089/)
http://img-fotki.yandex.ru/get/4209/ace210.4/0_4bf32_a2bcb8e1_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311090/)
http://img-fotki.yandex.ru/get/9/ace210.4/0_4bf33_8e6f7335_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311091/)
http://img-fotki.yandex.ru/get/4214/ace210.4/0_4bf34_9156a348_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311092/)
http://img-fotki.yandex.ru/get/4308/ace210.4/0_4bf35_b647c45e_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311093/)
http://img-fotki.yandex.ru/get/4312/ace210.4/0_4bf36_2284130c_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311094/)
http://img-fotki.yandex.ru/get/4308/ace210.4/0_4bf37_7da2b177_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311095/)
http://img-fotki.yandex.ru/get/4212/ace210.5/0_4bf38_dbf9f65b_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311096/)
http://img-fotki.yandex.ru/get/4212/ace210.5/0_4bf39_de7bcfff_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311097/)
http://img-fotki.yandex.ru/get/2914/ace210.5/0_4bf3a_d41991e6_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311098/)
http://img-fotki.yandex.ru/get/4209/ace210.5/0_4bf3b_b90f0ab3_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311099/)
http://img-fotki.yandex.ru/get/4307/ace210.5/0_4bf3c_bde58b71_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311100/)
http://img-fotki.yandex.ru/get/4209/ace210.5/0_4bf3d_7733334a_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311101/)
http://img-fotki.yandex.ru/get/4211/ace210.5/0_4bf3e_61d9a4d0_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311102/)
http://img-fotki.yandex.ru/get/9/ace210.5/0_4bf3f_49baedc8_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311103/)
http://img-fotki.yandex.ru/get/9/ace210.5/0_4bf40_cf95bcb2_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311104/)
http://img-fotki.yandex.ru/get/2914/ace210.5/0_4bf41_1f41ce53_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311105/)
http://img-fotki.yandex.ru/get/4310/ace210.5/0_4bf42_7cd34a7_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311106/)
http://img-fotki.yandex.ru/get/2914/ace210.5/0_4bf43_145b1d7a_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311107/)
http://img-fotki.yandex.ru/get/7/ace210.5/0_4bf44_fff500e_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311108/)
http://img-fotki.yandex.ru/get/4212/ace210.5/0_4bf45_7665118d_orig.jpg (http://fotki.yandex.ru/users/ace210/view/311109/)
И еще. Ландшафт разноцветным делать, как сейчас, или одного цвета на всём протяжении?
На том же TRS-80 весь путь разбит на участки -- когда умираешь то начинаешь не с начала игры, а с начала текущего участка.
Было бы просто отлично, если бы участки различались цветом. Как вариант -- маской текстуры.
---------- Post added at 15:55 ---------- Previous post was at 15:39 ----------
Ни одна версия по части графики мне не нравится. Надо бы сделать покрасивей. Предлагайте варианты.:confused:
Сколько на сколько знакомест занимает лодка? мина?
Лодка 4 знакомест в ширину, 12 пикселей в высоту (отрисовка каждой строчки)
Мина 2 знакоместа на 16 пикселей (отрисовка повторением каждой 2-й строчки)
Лодка 4 знакомест в ширину, 12 пикселей в высоту (отрисовка каждой строчки)
Мина 2 знакоместа на 16 пикселей (отрисовка повторением каждой 2-й строчки)
Во вложении -- попробовал нарисовать лодку, 31 x 11 пикселей.
Мину сделал более округлой.
Цепочку предлагаю сделать более тонкой.
ace210, посмотри текстуру слева -- может типа такого?
Сделал.
Кусочек подлодки попозже поправлю.
Barmaley_m
29.04.2010, 21:31
Текстуры предлагаю убрать вообще. Особенно когда текстура сложная - то возникает такой зрительный эффект, будто она движется. Объясняется это тем, что глаза входят в режим слежения за ландшафтом, т.е. ландшафт не движется относительно поля зрения - но при этом относительно поля зрения движется текстура. Даже когда текстура была простейшей (шахматной) этот эффект тоже был заметен, но не так сильно.
Что касается лодки - то старая по-моему была лучше, во всяком случае у новой, мне кажется, башня сильно маленькая и хвост какой-то некрасивый... Хотя может дело привычки. Что цепочки стали тоньше - это хорошо.
Что касается концовки - то думаю, надо нарисовать некое подобие ядерного реактора, а не просто мины, как это сделано на Атари. А на защите реактора - может какая-нибудь торпедная установка, которая будет стрелять в лодку самонаводящиеся торпеды, пока та пробивает щит?
---------- Post added at 19:31 ---------- Previous post was at 19:30 ----------
Насчет подводной графики и звуков - вот где сделано красиво, амижная игра Disposable Hero, 4й уровень (подводный).
амижная игра Disposable Hero, 4й уровень (подводный).
Эта что ли? http://www.youtube.com/watch?v=S1gID8faNPw
И чего там такого, что можно было бы взять на ZX?
---------- Post added at 23:57 ---------- Previous post was at 23:47 ----------
Текстуры предлагаю убрать вообще
Да, без текстур приятнее всё же. НО. Но выглядит совсем простяво, убого. Вот чем же пожертвовать?
Что касается лодки - то старая по-моему была лучше
старая простовата.
А эта, в самом деле, похожа больше на малютку из того фильма, что работает "хотел бы я взглянуть в глаза того конструктора, что эту подлодку сделал..."
Может еще варианты будут от кого? Повторяю:
размер 4 знакоместа в ширину. В высоту - максимум 14 пикселей.
Что касается концовки - то думаю, надо нарисовать некое подобие ядерного реактора, а не просто мины, как это сделано на Атари. А на защите реактора - может какая-нибудь торпедная установка, которая будет стрелять в лодку самонаводящиеся торпеды, пока та пробивает щит?
Художники, нарисуйте кто может. Я не умею совсем. А как кодёр, я такое, думаю, смогу сделать.
transman
30.04.2010, 00:01
А скорость скролла регулируется? Ну типа сделать 2 уровня сложности с разной скоростью движения ландшафта.
Сейчас - максимальная скорость, что может выжать спектрум для скролла в 1 пиксель. Это будет 4-я сложность.
1-я сложность будет в 2 раза медленнее. Замедлить не проблема.
2-я и 3-я - где-то посередине между ними.
Призы будут? Апргедящие подлодку (скорость, оружие, защита и т.п.)
---------- Post added at 00:07 ---------- Previous post was at 00:05 ----------
Размеры экрана будут реглуриоваться? (для избежания тормозов на особо кривых клонах)
Призы будут? Апргедящие подлодку (скорость, оружие, защита и т.п.)
нет. Футуристический шутер не будем делать.
нет. Футуристический шутер не будем делать.
Это классика. Что тут футуристичекого? Хотя если цель повторить 1 в 1 УГ 70-х годов... то вопросов больше нет.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot