Я тут подумал.
Так как в Atari нет видеопамяти как таковой, а только отдельные регистры для двух игроков, мяча (пикселя) и ракеты (пикселя), то с помощью каких-нибудь жестких хаков можно в качестве видеопамяти использовать эти два регистра игроков.
Допустим, у нас есть изображение, зашитое в памяти.
Надо учесть, что весь экран таким образом закодировать не получится, так как на одну линию отрисовки надо 20 байт (160 пикселей/8 бит). В PAL версии, как у меня, 242 линии отрисовки основного экрана, что в сумме дает 4840 байт, а это превышает размер картриджа.
Но если это не учитывать, то, думаю можно добиться нужного эффекта. Пока луч рисует спрайт первого игрока, мы кладем в спрайт второго игрока следующий байт, и vice versa. Думаю, что таким же образом можно менять цвета каждого спрайта на линии. Хотя я так прикинул, процессор должен будет успевать менять нужные регистры в худшем случае за 3 такта, а это очень мало. Но есть также вариант расширить спрайты, что снизит разрешение, но позволит выбить немного тактов для процессора (и уменьшит размер изображения в памяти).
И конечно, не получится таким образом делать динамическую графику, потому что динамика подразумевает RAM, а у нас оперативки 128 байт...
Короче, я пока что пребываю в шоке от архитектуры этой консоли=)
Так как в Atari нет видеопамяти как таковой, а только отдельные регистры для двух игроков, мяча (пикселя) и ракеты (пикселя), то с помощью каких-нибудь жестких хаков можно в качестве видеопамяти использовать эти два регистра игроков.
Допустим, у нас есть изображение, зашитое в памяти.
Надо учесть, что весь экран таким образом закодировать не получится, так как на одну линию отрисовки надо 20 байт (160 пикселей/8 бит). В PAL версии, как у меня, 242 линии отрисовки основного экрана, что в сумме дает 4840 байт, а это превышает размер картриджа.
Но если это не учитывать, то, думаю можно добиться нужного эффекта. Пока луч рисует спрайт первого игрока, мы кладем в спрайт второго игрока следующий байт, и vice versa. Думаю, что таким же образом можно менять цвета каждого спрайта на линии. Хотя я так прикинул, процессор должен будет успевать менять нужные регистры в худшем случае за 3 такта, а это очень мало. Но есть также вариант расширить спрайты, что снизит разрешение, но позволит выбить немного тактов для процессора (и уменьшит размер изображения в памяти).
И конечно, не получится таким образом делать динамическую графику, потому что динамика подразумевает RAM, а у нас оперативки 128 байт...
Короче, я пока что пребываю в шоке от архитектуры этой консоли=)
🤯2❤🔥1
А дальше больше!
Нам нужно конце каждого ROM (картриджа) указывать векторы для прерываний, которые этот процессор поддерживает. Но, насколько я понимаю, Atari 2600 вообще с этим не дружит. Тут никакие прерывания не помогут...
Не получится, как в Commodore, внезапно изменить метод отрисовки. А если я захочу добавить текст, то это нужно будет делать с уже имеющимся спрайтами.
И тем не менее, меня удивило то, что ребята реально делают рейкастинг на этой штуке.
https://www.youtube.com/watch?v=zk-QhYE4jxw
Как будто бы, надо попробовать перенести текстурированный рейкастинг с Commdoore 64, если это вообще возможно.
Нам нужно конце каждого ROM (картриджа) указывать векторы для прерываний, которые этот процессор поддерживает. Но, насколько я понимаю, Atari 2600 вообще с этим не дружит. Тут никакие прерывания не помогут...
Не получится, как в Commodore, внезапно изменить метод отрисовки. А если я захочу добавить текст, то это нужно будет делать с уже имеющимся спрайтами.
И тем не менее, меня удивило то, что ребята реально делают рейкастинг на этой штуке.
https://www.youtube.com/watch?v=zk-QhYE4jxw
Как будто бы, надо попробовать перенести текстурированный рейкастинг с Commdoore 64, если это вообще возможно.
❤🔥1
Наконец-то начал двигаться в сторону переноса всех данных уровней на дискету.
Создал новое игровое состояние для загрузки нового уровня и... два часа переносил его в новый файл, потому что пришлось повозиться с адресами меток. Раньше то все файлы вместе компилировались.
Ну и возникла вот такая проблема, как на первом видео. Понятное дело, что из-за прерываний.
Попробовал отключить прерывания на время загрузки и сделал вот такой эффект, как на втором видео: пишем, что надо приготовиться к загрузке, меняем цвет рамки, ждем 4 секунды и выключаем на время видеочип. Кривовато, но пока сойдет.
Надеюсь, что прерывания правильно отключаю и в будущем не придется ничего чинить=)
Создал новое игровое состояние для загрузки нового уровня и... два часа переносил его в новый файл, потому что пришлось повозиться с адресами меток. Раньше то все файлы вместе компилировались.
Ну и возникла вот такая проблема, как на первом видео. Понятное дело, что из-за прерываний.
Попробовал отключить прерывания на время загрузки и сделал вот такой эффект, как на втором видео: пишем, что надо приготовиться к загрузке, меняем цвет рамки, ждем 4 секунды и выключаем на время видеочип. Кривовато, но пока сойдет.
Надеюсь, что прерывания правильно отключаю и в будущем не придется ничего чинить=)
👍3🔥2❤🔥1
https://www.youtube.com/watch?v=ql5edE8zje4
Тут мужик делает псевдо-3Д движок на GBA с редактором, в котором можно уровни в реальном времени делать прямо на консоли.
Очень похоже на Doom Builder.
Выглядит офигенно, правда, как я понял, реальную игру пока в редакторе сделать нельзя.
Тут мужик делает псевдо-3Д движок на GBA с редактором, в котором можно уровни в реальном времени делать прямо на консоли.
Очень похоже на Doom Builder.
Выглядит офигенно, правда, как я понял, реальную игру пока в редакторе сделать нельзя.
YouTube
The 3DSage Game Engine Demo | Download Link
Let me know in the comments what you think. I can't wait to see what you create with the next version coming soon!
Download Link: https://www.gbadev.org/demos.php?showinfo=1575
(The .sav save file must be next to the rom. If you use a flashcart, place the…
Download Link: https://www.gbadev.org/demos.php?showinfo=1575
(The .sav save file must be next to the rom. If you use a flashcart, place the…
🔥3❤🔥1
Осталось попробовать что-нибудь свое написать и запустить на реальной консоли.
И, насколько я понимаю, этот картридж поддерживает бэнк-свитчинг и вообще современные игры на Атари, но это не так интересно.
Но сперва, конечно, Коммодор!! У меня одна идея появилась, как сделать внутригровую карту, и это не так много ресурсов должно занять:)
И, насколько я понимаю, этот картридж поддерживает бэнк-свитчинг и вообще современные игры на Атари, но это не так интересно.
Но сперва, конечно, Коммодор!! У меня одна идея появилась, как сделать внутригровую карту, и это не так много ресурсов должно занять:)
🔥2❤🔥1
У меня дилемма. Не могу понять, как лучше сделать мини-карту.
В первом случае я могу использовать схематические одноцветные значки. Это займет чуть больше места в памяти, но имплементировать такой вариант в код будет проще.
А во втором случае я буду использовать уже имеющиеся текстуры. Это будет сложнее в плане алгоритма, но позволит убрать из каждого файла уровня лишнюю таблицу на 576 байт и отказаться от дополнительных текстур.
Вот не могу решить...
В первом случае я могу использовать схематические одноцветные значки. Это займет чуть больше места в памяти, но имплементировать такой вариант в код будет проще.
А во втором случае я буду использовать уже имеющиеся текстуры. Это будет сложнее в плане алгоритма, но позволит убрать из каждого файла уровня лишнюю таблицу на 576 байт и отказаться от дополнительных текстур.
Вот не могу решить...
❤🔥1
И за два вечера справился с проблемой.
Решил пойти по сложному пути. И пусть это потребовало лишних 768 байт, но зато выглядит вроде неплохо. Тем более, что у меня есть еще больше 18 Кб свободных. И это довольно много.
Но как же я задолбался подстраивать текстуры для их отрисовки на мини-карте (для этого и потребовалась память и новые таблицы). Текстуры лежат в памяти в кривом виде для более быстрого рейкастинга и не очень подходят для отрисовки в обычном виде, поэтому пришлось помучиться.
Карту можно двигать на WASD, и на ней рисуется значок игрока. А еще отображаются только те блоки, которые игрок уже видел (туман войны).
А если изменить текстуру на карте или убрать блок, то мини-карта тоже поменяется.
Ну и конечно при создании уровня можно отметить блоки, которые никогда не будут отображаться на мини-карте. Это я буду использовать для секретов.
Решил пойти по сложному пути. И пусть это потребовало лишних 768 байт, но зато выглядит вроде неплохо. Тем более, что у меня есть еще больше 18 Кб свободных. И это довольно много.
Но как же я задолбался подстраивать текстуры для их отрисовки на мини-карте (для этого и потребовалась память и новые таблицы). Текстуры лежат в памяти в кривом виде для более быстрого рейкастинга и не очень подходят для отрисовки в обычном виде, поэтому пришлось помучиться.
Карту можно двигать на WASD, и на ней рисуется значок игрока. А еще отображаются только те блоки, которые игрок уже видел (туман войны).
А если изменить текстуру на карте или убрать блок, то мини-карта тоже поменяется.
Ну и конечно при создании уровня можно отметить блоки, которые никогда не будут отображаться на мини-карте. Это я буду использовать для секретов.
❤🔥4👍2
После того как добавил мини-карту, вылез жесткий баг.
Некоторые текстуры в случайном порядке начинали съезжать на 1 пиксель вверх (верхняя линия не рисуется, а нижняя берется из следующей текстуры).
Опытным путем я выяснил, что некоторые байты в таблице указателей на текстуры почему-то иногда увеличиваются на 1. Но из-за чего они увеличиваются, было непонятно.
Хорошо, что в Vice есть замечательная возможность записать процесс работы компьютера и потом все это дело изучить в отладчике.
Я записал небольшую часть геймплея до момента смещения текстур. Нашел в памяти изменившийся адрес, поставил на него watchpoint и изучил запись.
В общем, по цепочке я выявил баг.
Оказалось, что дело в том самом "тумане войны".
Когда игрок переходит на следующий блок, перед ним считывается 9 блоков. И некоторые из этих блоков могут быть вне координат уровня.
Для рендеринга уровня пофиг, потому что он огорожен стенами (и я ничего не пишу в таблицу уровня), но не для мини-карты.
Сами блоки мини-карты хранятся в таблице 24*24. Есть другая таблица с указателями на строки мини-карты. Я беру блок в нужной строке со смещением по X и включаю первый бит (отображение на карте).
Но что, если блок находится за пределами карты?
Правильно, мы выходим за пределы таблицы указателей и включаем первый бит в совершенно другом месте.
Хорошо, что под раздачу попали только текстуры, и косяк было видно визуально...
Некоторые текстуры в случайном порядке начинали съезжать на 1 пиксель вверх (верхняя линия не рисуется, а нижняя берется из следующей текстуры).
Опытным путем я выяснил, что некоторые байты в таблице указателей на текстуры почему-то иногда увеличиваются на 1. Но из-за чего они увеличиваются, было непонятно.
Хорошо, что в Vice есть замечательная возможность записать процесс работы компьютера и потом все это дело изучить в отладчике.
Я записал небольшую часть геймплея до момента смещения текстур. Нашел в памяти изменившийся адрес, поставил на него watchpoint и изучил запись.
В общем, по цепочке я выявил баг.
Оказалось, что дело в том самом "тумане войны".
Когда игрок переходит на следующий блок, перед ним считывается 9 блоков. И некоторые из этих блоков могут быть вне координат уровня.
Для рендеринга уровня пофиг, потому что он огорожен стенами (и я ничего не пишу в таблицу уровня), но не для мини-карты.
Сами блоки мини-карты хранятся в таблице 24*24. Есть другая таблица с указателями на строки мини-карты. Я беру блок в нужной строке со смещением по X и включаю первый бит (отображение на карте).
Но что, если блок находится за пределами карты?
Правильно, мы выходим за пределы таблицы указателей и включаем первый бит в совершенно другом месте.
Хорошо, что под раздачу попали только текстуры, и косяк было видно визуально...
🔥4❤🔥1
Я вообще думаю, а не убивает ли мини-карта всю атмосферу исследования.
Anonymous Poll
93%
Оставляй. В твоих трёх текстурах запутаться проще простого. Хочу подсказку.
7%
Убери эту дичь. Становится слишком просто, а я за олдскул.
❤🔥1
Media is too big
VIEW IN TELEGRAM
Немного помучился с Atari 2600 и наконец-то сделал движущийся спрайт, который даже в разные стороны смотрит при повороте:)
Интересно, были ли в те времена похожие адские консоли для программистов.
Потому вроде даже в прямых конкурентах: Intellivision и ColecoVision была экранная память...
Интересно, были ли в те времена похожие адские консоли для программистов.
Потому вроде даже в прямых конкурентах: Intellivision и ColecoVision была экранная память...
👍2❤🔥1
В общем, что здесь происходит:)
Как я уже сказал, у объектов Atari нет понятия координат. Нельзя просто выставить спрайту X и Y. Вместо этого, когда луч доходит до нужной линии, а главное - нужной точки на линии, мы говорим: "Рисуй прямо сейчас".
С Y все понятно, хотя все равно непривычно, что Y идет от наибольшего значения к наименьшему и означает, сколько линий до конца экрана осталось.
Как я уже сказал, у объектов Atari нет понятия координат. Нельзя просто выставить спрайту X и Y. Вместо этого, когда луч доходит до нужной линии, а главное - нужной точки на линии, мы говорим: "Рисуй прямо сейчас".
С Y все понятно, хотя все равно непривычно, что Y идет от наибольшего значения к наименьшему и означает, сколько линий до конца экрана осталось.
👍2❤🔥1
А вот с X сложнее. Нам надо высчитать, сколько тактов займет у видеочипа пройти по линии именно столько пикселей, сколько нам надо. А после этого записать что-нибудь в регистры RESxx (для разных объектов), что сбросит спрайт до текущей позиции луча.
Проблема в том, что это надо делать в цикле, особенно, если предполагается, что объект будет двигаться. Но одна итерация цикла занимает аж 5 тактов. За это время луч успевает пройти 15 пикселей, что делает движения дерганными.
Но Atari это предусмотрели в своем стиле. Есть регистры HMxx. Запись в последние 4 бита смещает спрайт от -7 до +8 пикселей от текущей позиции.
То есть надо взять текущую координату X, поделить на 15. Получаем количество итераций (по 5 тактов каждая). А потом берем остаток от деления X на 15. Получаем количество пикселей, на которое надо сместить спрайт влево или вправо.
А потом записью в регистр HMOVE двигаем спрайт.
Проблема в том, что это надо делать в цикле, особенно, если предполагается, что объект будет двигаться. Но одна итерация цикла занимает аж 5 тактов. За это время луч успевает пройти 15 пикселей, что делает движения дерганными.
Но Atari это предусмотрели в своем стиле. Есть регистры HMxx. Запись в последние 4 бита смещает спрайт от -7 до +8 пикселей от текущей позиции.
То есть надо взять текущую координату X, поделить на 15. Получаем количество итераций (по 5 тактов каждая). А потом берем остаток от деления X на 15. Получаем количество пикселей, на которое надо сместить спрайт влево или вправо.
А потом записью в регистр HMOVE двигаем спрайт.
🔥3💊3❤🔥1
Нарисовал текстуры для второго уровня. Как-то получилось более объемно, чем в прошлый раз. Но надо смотреть, как они будут выглядеть в игре. И видимо надо перерисовать текстуры для первого уровня.
А еще на каждом уровне будет отсылка к какой-нибудь классике. Здесь попытался нарисовать какодемона, но в условиях трех цветов вышло так себе)
А еще на каждом уровне будет отсылка к какой-нибудь классике. Здесь попытался нарисовать какодемона, но в условиях трех цветов вышло так себе)
🔥6❤🔥1