А ситуация, когда два человека в одно и то же время выкладывают файл? Имена одни и те же будут.
Вид для печати
давайте добавим ещё время в имя файла.
так будет понятнее.
роботам :)
мне страшно вмешиваться даже, но хотелось бы заметить, что давно придуманы такие вещи как svn/git. они решают очень много проблем, и никаких "что если 2 человека выкладывают" даже близко не возникает...
Насколько я понмю, уже была попытка создать библиотеку демомейкера... ну там скоролл был и ещё что-то очень нужное :) Запись мнемоники там была весёлая, почти в строчку... ну чтобы непонятнее было :)
А что за игру то пишут в этом треде? Танчики что ли? Их уже навалом в 90ых понаделали...
Crash Nicker, а вот каждый буржуйсккий игродел, считает за честь сделать JSW. По этому этих модов уже за сотню перевалило. Если делать игру, то что-нибудь конкретное, а не барахло. Survivisection, Alter Ego или Sea Dragon тому примеры. А если автор задумал сделать очередную реинкарнацию танчиков, то нафиг они не нужны.
Я не понимаю, как можно серьёзно относиться к проекту "библиотеки для создания игр начинающими программистами", когда люди в проекте явно не слышали ни о AGD, ни о z88dk в связке с sp1. Одновременно с этим, предлагается писать бибиотеку со следующими "полезными" процедурами:
(*) Вывод звука на BEEPER.
(*) Вывод звука на AY/YM.
(*) Подпрограмму обработки прерывания.
(*) Другие полезные подпрограммы.
Это было бы дико смешно, если бы это не было так грустно. Уже один раз расподписался, но не удержался и прокомментировал. Сейчас расподпишусь ещё раз и больше сюда ни ногой.
А что AGD позволяет написать любую игру?
1. Всего 12 спрайтов. Выводится по 6 спрайтов за фрейм. 9 - в новой версии. Какие типы игр можно написать с помощью этого ? Вы будете в них играть ? Шансов написать что-нибудь стоещее мало.
2. На ассемблере теперь уже никто не пишет ?
Если у кого-то хорошо получается писать на ассемблере - почему бы не научить этому других с помощью примеров и готовых подпрограмм ? Кроме этого предполагается собирать другую полезную информацию по созданию игр. Возможно все это приведет к небольшому увеличению написанных игр.
А неспошно разрабатываемая мной игра только помогает собрать всю эту полезную информацию.
Есть минимум 3 подхода в написании игр:
1. Использовать AGD или подобные программы. Недостаток - низкая скорость и мало свободы.
2. Писать все заново с нуля на основе принципа работы ZX SPECTRUM и дополнительных устройств к нему. Сложно сразу написать оптимальную подпрограмму, а у нас важно место и скорость выполнения. Также долго.
3. Использовать опыт других людей, их подпрограммы. Достоинства - экономия времени, высокая скорость, разнообразие игр, накопление опыта.
А про одинаковые имена файлов архивов с подпрограммами беспокоиться не стоит. Такая ситуация, возможно, будет иметь место только вначале, когда все захотят оставить свой след в истории и помочь начинающим профессионально написанными подпрограммами. Потом все стабилизируется. Да мне нетрудно исправить номер в имени файла. Лишь бы польза была другим от этого.
zst, игра, как и демо и любой софт — штука уникальная. Общие процедуры или аглоритмы можно найти в zx-прессе (zxdn.narod.ru например).
Моя процедура вывода спрайта http://zx.pk.ru/showthread.php?t=20554
Сделана как проба, куда реально её использовать я не придумал.
Вам нужно определиться, вы хотите модульности и доступности для начинающих, или вы хотите хорошую игру? чтобы на ёлку влезть и жопу не ободрать - не выйдет. Если вы хотите модульность и доступность для начинающих, не мешало бы разобраться в ограничениях AGD, откуда они взялись, почему сделано так как сделано. Посмотрели бы на игры, которые, кстати, зачастую выглядят далеко не позорно. Посмотрели бы на SP1, которая вообще говоря, специализированная спрайтовая библиотека, на ассемблере, с органичениями куда меньшими нежели чем у AGD.
Хорошая игра делается не так. Хорошая игра идёт от дизайна, и всё бросается этому дизайну в жертву. Под дизайном я понимаю в равной степени, свежую техническую идею, и идею об игровом процессе. Если мы, например, хотим делать скролл, мы сразу урезаем себе возможности по числу спрайтов. Если мы хотим биперный звук, нам нужно заранее продумывать, как его играть, т.к. тупо прервать игру на бипанье позволяют себе только совсем дурные программисты. Нельзя писать игру, не имея ни технической идеи, ни игрового процесса. Не получится запрограммировать что-нибудь, чтобы было, а потом подреховать молотком, т.е., что-то получится, конечно, но это не будет хорошая игра.
Прочтите, например, тред по SeaDragon. Вот это реальный пример для подражания, где техническая идея оттачивалась до той степени, пока не оказалось возможным реализовать нужный игровой процесс.
Скорее не соглашусь с этим утверждением. В демо уникальный код показывает уникальный видео- или аудиоэффект. Уникальность системного софта обусловленно уникальностью набора решаемых задач. А в играх много рутинного кода, который невидим пользователю и не задает специфику игры. Да, согласен, в некоторых играх нужен уникальный опрос клавиатуры, уникальные видеоэффекты, но очень много тривиальных процедур. Специфика игры - это оформление (графика и звуки) и логика, но не опрос клавиатуры, вывод спрайтов, текста, загрузка состояния, управление прерываниями и еще 100500 мелочей. Вот такую коллекцию часто используемой "рутины" и предлагает создать zst, если я правильно понял. Ну и да, чтобы было с чем поэкспериментировать для начала, в коллекции нужны спрайты, звуки, шрифты - то, что можно потом с легкостью заменить на оригиналь сдизайненное. В идеале, при максимальном использовании библиотеки, останется написать только логику, но никто не мешает использовать из библиотеки только неспецифичные для игры модули.
Кстати, формат исходников - SjAsm? Отлаживать будем в Unreal? Редактировать текст в чем? Я использую ConTEXT, например (с его минусами, ага). У меня есть "готовая" IDE с инструкцией по настройке. Жать чем будем? Я использую MegaLZ, может, от скудности ума.
Да, я с вами полностью согласен. Нужно собрать базовый комплект для начала программирования игр на ассемблере. Файлы лучше добавлять в порядке от простого к сложному. Сначала пришедший программировать человек скачает редактор, компилятор, эмулятор. Потом - настройки к ним, базовые подпрограммы на ассемблере, пример простой программы, использующей эти процедуры. Начнет разбираться в них с помощью комментариев автора. Потом начнет сам комбинировать и использовать готовые подпрограммы. Как научится писать на ассемблере в данной среде - начнет реализовывать свои идеи в простейших играх. Потом... - дальше все зависит от этого человека, мы сделали максимально возможное для его ввода в курс дела.
Да, эти программы подойдут большинству начинающих программистов - давайте их и будем использовать в примерах. Настройки для начинающих очень пригодились бы. Ссылки на первые три программы я добавил на сайт, нужна для пакера MegaLZ.Цитата:
Кстати, формат исходников - SjAsm? Отлаживать будем в Unreal? Редактировать текст в чем? Я использую ConTEXT, например (с его минусами, ага). У меня есть "готовая" IDE с инструкцией по настройке. Жать чем будем? Я использую MegaLZ, может, от скудности ума.
---------- Post added at 10:42 ---------- Previous post was at 10:09 ----------
Спасибо. Добавил ссылку на сайт.
Прошу оформить окончательную версию в виде файла для добавления в общую библиотеку с кратким описанием особенностей вашей процедуры.Цитата:
Моя процедура вывода спрайта http://zx.pk.ru/showthread.php?t=20554
Сделана как проба, куда реально её использовать я не придумал.
Я бы добавил еще ссылку на zxpress и на Virtual TR-DOS. Постараюсь сегодня-завтра выложить свою IDE с инструкциями по настройке и запуску Hello world.
P.S. "русскоязычный" и "англоязычный" пишутся без дефиса.
Уже начали делать тут, правда, всё захлебнулось. :)
девять чего?Цитата:
9 - в новой версии
---------- Post added at 19:30 ---------- Previous post was at 19:18 ----------
На самом деле, написать(достойного) многое можно..Цитата:
А что AGD позволяет написать любую игру?
Без сомнения, играть будут многие..Цитата:
Вы будете в них играть ?
Заблуждение.Цитата:
Шансов написать что-нибудь стоещее мало.
Всё зависит на сколько фантазия позволяет.. и время..
Или ленятся..)Цитата:
На ассемблере теперь уже никто не пишет ?
---------- Post added at 19:33 ---------- Previous post was at 19:30 ----------
Желание и время..)Цитата:
Что нужно для написания игр ?
Нашел на WOS игру ТАНЧИКИ 2013 года -- http://www.worldofspectrum.org/infos...cgi?id=0028161
zst, и? Тема с этой игрой была на форуме. ;)
Я не видел.
Жду настроек IDE (связки редактор->ассемблер->эмулятор) от Alex_Rider-a. Буду тоже осваивать новые технологии программирования на PC. Редактор спрайтов SevenUP убрал из ссылок - возможно там вирус.
Что-то там предлагалась сложная организация хранения - вот и захлебнулось. Да и подпрограммы были сомнительной полезности типа рисования круга. Мы же игры писать собираемся. Да и стиль у Gohlinish-a сложный для начинающих. А вот ваш список очень полезный был. Как раз это и нужно для преодоления барьера ассемблера и других сервисных программ. Psb про это тоже писал. Я так понял, что вы тоже поддерживаете мою идею и сами пишете программы?
По организации библиотеки: чем проще - тем лучше!
Один ассемблер! Один эмулятор! Никаких SVN! Никаких сервисов, форумов и т.п. излишеств!
В библитеке на каждую процедуру лучше размещать 3 файла в одном архиве:
1. Сама процедура для ассемблера SjASMPlus с краткими комментариями сложных мест в коде и шапкой автора типа:
2. Текстовой файл с более подробным описанием и особенностями применения процедуры.Код:;---------------------------------------------------------------------------------
;- Скроллинг фона на 1 точку влево с помощью видеокарты METEOR-2013 www.zxkit.ru -
;- экран размером 320 х 240 точек, 256 цветов на точку -
;- спрайты фона размером 16 х 16 точек, карта уровня размером 15 х 256 спрайтов -
;- время выполнения около 6851 тактов Z80 = 9.8 % от 69888 тактов в кадре TV -
;---------------------------------------------------------------------------------
3. Минимальный проект, готовый для компиляции и автоматического запуска в эмуляторе. В нем пример вызова и использования данной процедуры.
Ладно, займусь, буду наполнять по возможности, быстро не обещаю.
---------- Post added at 09:33 ---------- Previous post was at 09:29 ----------
Вот исходники моих игр, написаны в виндовом Блокноте:
http://zx.pk.ru/showpost.php?p=434945&postcount=128
http://zx.pk.ru/showpost.php?p=478118&postcount=129
http://zx.pk.ru/showpost.php?p=554273&postcount=130
В них куча процедур, которые попадут в базу.
Обещанная IDE. А вот инструкция:
1. Распаковать архив на любой локальный диск (в нем дистрибутив текстового редактора, кросс-ассемблер, эмулятор, пример программы).
2. Установить ConText (папку ConText можно удалить после настройки)
3. Скопировать файл z80.chl в папку с установленным ConText, подпапку Highlighters.
4. Запустить ConText, настроить его опции (Настройки > Настройки среды) согласно приложенным скриншотам
5. Открыть в ConText файл Sample\Sample.a80
6. Нажать F9 для компиляции, F10 для запуска примера
Проект движка для игры "FUTURE TANK".
Уточнение:
7. Как только FT пытается выехать за пределы этого воображаемого квадрата начинается скроллинг экрана. Так как сдвигать за один кадр весь экран невозможно – сдвигать будем часть. Это будет квадрат размером 11 х 11 клеток вокруг FT.
Спасибо огромное. Добавил на сайт www.z80a.ru
Все прекрасно заработало. Теперь любой желающий может приобщиться к написанию игр на ассемблере:
Наброски спрайтов движущихся объектов
http://s019.radikal.ru/i626/1307/e5/323ff959ee02t.jpg
Добавил кнопку 0 - стрельба вперед.
Танки трех типоразмеров в движении.
http://i054.radikal.ru/1307/a8/fa1f8800584dt.jpg
Спрайты для начала есть. Теперь нужно придумать. как их лучше хранить и выводить. Скорее всего при движении по-горизонтали и вертикали будут разные процедуры. При движении по-горизонтали возможна ситуация, когда танк выезжает из-за границы экрана. То есть нужно изображать не весь спрайт, а 1 или 2 столбика. Значит нужно в процедуре вывода спрайта предусмотреть печать тех столбиков, которые входят в диапазон координат X окна игрового поля. Размер игрового поля 24 х 24 клетки, т.е. 192 х 192 точки.
Спрайты симметричные относительно горизонатальной оси, значит можно хранить только половину спрайта для экономии памяти. По 8 байтов в столбике, 3 столбика. В столбике копируем 8 байтов из спрайта, затем повторяем их в обратном порядке. Потом переходим к печати следующего столбика. При печати каждого столбика проверять, входит ли он в область экрана. Если нет, то переходим к следующему столбику спрайта.
Так как танки движутся с максимальной скоростью 1 точка за кадр, нужно хранить 8 фаз движения на каждое направление. Это займет определенное место. На каждый типоразмер при движении влево потребуется 8 полуспрайтов по 3 столбика по 8 байтов, т.е. 192 байта. Для движения вправо еще 192 байта. Для движения вверх и вниз два спрайта по 3 столбика по 16 байтов. Таким образом на один типоразмер танков требуется 192+192+48+48=480 байтов.
Если будет три типоразмера танков и один FT, то для изображения их движений потребуется около 2Кбайт спрайтов. Это без учета цвета.
Однако при выводе спрайтов столбиками по 16 байтов потребует 2 раза переходить границу клетки на каждый столбик, а это около 37 тактов. Да еще проверять, входит ли этот столбик в границы экрана. Это неоправданно замедлит вывод спрайтов, которые полностью входят на экран. Наверно лучше проверять, входит ли спрайт полностью. Если да, выводить спрайт более быстрым способом - Сначала 3 байта 1 строки, потом 3 байта 2 строки и так 16 раз. Но все равно будут 2 перехода границ клеток, но это на весь спрайт, а не каждый столбик. Быстродействие тоже важно.
Для частично отображаемых спрайтов на границах экрана потребуется отдельная процедура с хитрым алгоритмом вывода или индексной адресацией в ОЗУ спрайта, так как при отображении спрайта стольбиками байты спрайта будут браться не подряд. Или хранить спрайты как предлагал Alone Coder. При этом байты в столбике одного спрайта располагаются с шагом 256 байтов. Для перехода к следующему байту в столбике достаточно будет увеличить старший байт адреса. Т.о. данный способ хранения спрайтов подходит для более быстрого вывода спрайта строчками, а на границах экрана его можно использовать и для вывода спрайта столбиками.
Хорошо. С хранением спрайтов разобрался. Теперь нужно написать процедуру достаточно быстрого вывода спрайта, используя процедуру оределения адреса на экране из книжки "Прикладная графика" от Инфоркома или аналогичную. Спрайты будут выводиться зигзагами. Сначала вправо, потом влево, по возможности использовать переход к следующему адресу байта на экране однобайтовыми команадами. Только при переходе через горизонтальные границы клеток потребуется более сложный способ определения следующего адреса на экране. Но он уже придуман. Занимает времени 37 тактов:
Код:4 LD A,L ; увеличиваем номера ряда в сегменте.
7 ADD A, 0010 0000 ; если был ряд номер 7 - установится флаг C (нужен переход в следующий сектор экрана)
4 LD L,A
4 LD A,H
7 ADC A,0 ; переходим в следующий сектор, если необходимо
7 AND 1111 1000 ; обнуляем номер строки в клетке
4 LD H,A
Хранение спрайтов в памяти. Описание для библиотеки. Удобный способ подсказал alone (http://www.zx.pk.ru/showpost.php?p=611409&postcount=82).
Идея такая. 256 байтов в области спрайтов выделяются для хранения первых строк нескольких спрайтов. Следующие 256 байтов выделяются для хранения вторых строк нескольких спрайтов и т.д. на всю высоту спрайта.
При этом байты в столбике одного спрайта располагаются с шагом 256 байтов. Для перехода к следующему байту в столбике (по-вертикали) достаточно будет увеличить старший байт адреса в области спрайтов.
Для перехода к следующему байту спрайта по-горизонтали достаточно увеличить младший байт адреса о области спрайтов.
Таким образом, данный способ хранения спрайтов подходит для вывода спрайта как строками, так и столбцами.
Адрес начала нужного спрайта можно определить, прибавив к адресу начала области спрайтов номер спрайта (от 0 до максимально влезшего) столько раз, сколько байтов в строке каждого спрайта. Это подходит для случая, когда все спрайты одинакового размера. Также можно составить таблицу для определения по номеру спрайта его адреса.
zst, не самый удобный способ кстати
по скорости не самый быстрый и ограничение на высоту спрайта
А какие еще бывают удобные и быстрые способы хранения спрайтов ? Про ограничение в высоту - не вижу ограничений. Объясните, в чем ограничение?
У меня будут полуспрайты высотой 8 точек. 8 удобно тем, что спрайты можно нарисовать прямо на экране. И верхний сегмент картинки (2Кб) можно скопировать без преобразований в область спрайтов. Для других высот спрайтов картинку придется преобразовывать. Но это не ограничение при хранении спрайтов.
На мой взгляд, недостатков у такого способа хранения нет.