Просмотр полной версии : 2D движки на спектруме.
moroz1999
09.03.2008, 17:56
Существует ли на спектруме готовый движок с открытыми исходниками? Не заточенный под определенную игру, а имеющий более-менее широкие возможности, как, например:
-вывод спрайтов в разных режимах, попиксельно и познакоместно
-вывод тайлового бэкграунда
-познакоместное/попиксельное скроллирование
Есть что-нибудь на примете, где всё это реализовано? Желательно с исходниками, потому что хотелось бы всё это дело перетащить на sjasm+
имхо нереально для спека - для универсальности ресурсов нехватит...
был Laser Basic, который вполне тянул на универсальный 2D движок, но исходники явно закрытые были.. знакомый декомпилил и сделал из них библиотеку.. но я не знаю где она, если удастся накопать то выложу
Думаю проще написать с нуля, чем искать что-то подобное, тем более процедур по выводу спрайтов вагон было... я вот сейчас хочу подобную либу для 16colorz сделать ;)
Lethargeek
10.03.2008, 07:13
Песюканство!! :v2_devil:
Песюканство!! :v2_devil:ты о чом?
Lethargeek
10.03.2008, 13:28
ты о чом?
А вот о чем:
Не заточенный под определенную игру, а имеющий более-менее широкие возможности
Дас ист фантастиш - на Спеке движок всегда зависел от желаемого результата (как стиля, так и динамики). Кто-нить может себе представить движок, способный эффективно отображать графику по типу (одновременно) - ЧВ, Cybernoid, AMC и Trapdoor?
из универсальных знаю только spritepack: http://www.worldofspectrum.org/forums/showthread.php?t=11729
последняя версия, насколько знаю, берется из z88dk, однако написан на ассемблере, не на С. не идеален, но довольно хорош, и идеи в него заложены весьма стоящие.
Кто-нить может себе представить движок
Я могу. А почему нет?
Просто профессионально никто этим не занимался.
А жаль, будь написан такой движок году эдак к 95-му, имели бы мы сегодня на Virtual TR-DOS'е раза в 3 больше игр.
Lethargeek
10.03.2008, 19:48
Просто профессионально никто этим не занимался.
С чего бы это? :rolleyes:
имели бы мы сегодня на Virtual TR-DOS'е раза в 3 больше игр.
Чур меня!!
Кстати, стоит заметить, что многие авторы западных игр использовали свои движки. Например посмотрите игры фирмы Altantis или Opera Soft.
Lethargeek
10.03.2008, 20:02
Кстати, стоит заметить, что многие авторы западных игр использовали свои движки.
Угу, бесконечно разрабатываемые и подгоняемые на каждый конкретный случай.
moroz1999
10.03.2008, 20:18
речь, собственно, не о том, чтобы объять необъятное, а о том, как повысить эффективность труда программиста при разработке аркад.
я согласен, что в условиях спектрума технологические шедевры типа ЧВ могут быть реализованы только узко специализированным подходом, но наличие более-менее простого в использовании и сборке движка сильно упростило бы создание всевозможных бродилок, квестов, например. Судя по тому, что я сам потихоньку пробую в собственных целях, вполне реально получить и что-то более динамичное, например уж точно не хуже 80% того, что сейчас продает тот же хронософт.
кто-нибудь вообще заинтересован в том, чтобы иметь набор процедур, которые работали бы по принципу: из отдельной процедуры пишем в определенный буфер номер спрайта, режим вывода и координаты, а движок всё это самостоятельно выводит? или просто указываем координаты текущего положения экрана для тайлового бэкграунда, а движок сам определяет, сдвигать или нет? этот принцип обладает прежде всего тем плюсом, что его можно расширять, не меняя основного функционала. Например, при выходе новых версий открытых процедур можно было бы взять построенную на базе движка игру и скомпилить её заново, получив больше скорости при нулевых личных усилиях.
специально уточню еще раз, что речь не о каком-то супер универсальном game maker, а просто об удобном инструментарии, имея который можно не заморачиваться на написание уже сто раз написанного. такой инструментарий в каком-то роде есть у любого программера, но, судя по всему, никто пока особо не задумывался о его оформлении, организации, документировании и выкладывании в массы.
Чем универсальнее этот некий гипотетический движок, тем он сложнее в написании и/или использовании. Т.е. меньше шансов его написать и/или использовать. Если же он узкозаточен, то получаем ряд однообразных игр. Что не есть хорошо. А вполне естественная мысль гейммейкера "а я построю свою игру с блекджеком и шлюхами" (с) наталкивается на рамки существующего узкозаточенного движка, что в свою очередь приводит к... (см. начало).
Lethargeek
10.03.2008, 20:37
Вот я и грю - песюканство.
Сначала хотим универсальный движок, потом выясняеется, что мегагерц не хватает...
Сначала хотим универсальный движок, потом выясняеется, что мегагерц не хватает... мгм.. кому именно не хватает и для каких конкретно целей? желательно с примером кода ;)
moroz1999
10.03.2008, 21:00
только, пожалуйста, без эмоций, кратко и по существу.
я абсолютно согласен с тем, что чем больше универсальности, тем тормознутее, а, значит, сложнее в написании, но тем не менее, уверен, что существует определённое соотношение, которое можно было бы использовать в довольно большом спектре задач.
Lethargeek
10.03.2008, 22:41
мгм.. кому именно не хватает и для каких конкретно целей? желательно с примером кода
А я не пишу кода, которому мегагерц не хватает... даже начинать не хочу ;)
но тем не менее, уверен, что существует определённое соотношение, которое можно было бы использовать в довольно большом спектре задач.
И нафига нам куча игрушек уровня ~1985 года? :v2_conf2:
moroz1999
10.03.2008, 22:49
И нафига нам куча игрушек уровня ~1985 года? :v2_conf2:Ну, на момент допустим, что технический уровень и правда будет настолько невысок. Тогда встречный вопрос: какова альтернатива?
Просто я в этом вопросе вижу только негатив, а конструктивной мысли нет.
Для случая наибольшей универсальности движок будет состоять из набора процедур вывода спрайтов, печати текста и т.д. С этим проблем вообще никаких нет. Это праматерия всего и вся.
А если наворачивать еще чего-то, то и этого в конце концов будет мало, а идеальные результат с точки зрения игродела будет выглядеть как "я внимательно посмотрел на программу и нажал кнопку "сделай мне игру". после чего получил мегахит с моим копирайтом".
moroz1999
10.03.2008, 22:58
Для случая наибольшей универсальности движок будет состоять из набора процедур вывода спрайтов, печати текста и т.д. С этим проблем вообще никаких нет. Это праматерия всего и вся.вот, по большому счету я это и имею в виду. единственно только с тем дополнением, что доступ к этим вещам сделан не напрямую, а через небольшую процедурку-менеджера, которая работает с элементарными запросами, записанными в буфер.
через небольшую процедурку-менеджера
Оцени трудоемкость написания этого менеджера. В частности, в сравнении с трудоемкостью написания набора необходимых процедур.
И нафига нам куча игрушек уровня ~1985 года?
Звездное Наследние по уровню кода наверное и до 85 года не дотягивает и что с того?
SAM style
10.03.2008, 23:29
Движок VQ3 - вполне себе движок (в моём понимании слова). Точки вызова (наиболее нужные) сделаны JP-ами в начало самого движка. Только под требования первого поста не подходит - он больше квестовый, а не аркадный.
moroz1999
10.03.2008, 23:35
Оцени трудоемкость написания этого менеджера. В частности, в сравнении с трудоемкостью написания набора необходимых процедур.По моим оценкам - довольно просто. Весь т.н. "менеджер" состоит из циклического прохода по заполненному буферу, в котором каждый спрайт описан 5-6 байтами, и передачи этих байт в процедуры вывода на экран. Единственное серьезное упущение по скорости в данном случае в том, что сами процедуры становится нельзя узко заточить под какое-то конкретное применение, но никто не мешает сделать заточенные копии с основных, работающие только при определенных частных случаях.
Технически всё это упирается в написание и отладку самих процедур вывода, которые должны быть максимально быстрыми без потери универсальности.
Примеры процедур вывода, чтобы было понятно, о чем я:
1. функция познакоместного вывода цветного спрайта на экран. входные параметры - координаты, адрес спрайта в памяти, адрес вывода на экран, может еще чего по мелочам.
2. функция попиксельного вывода монохромного спрайта на экран, входный параметры - координаты, адрес в памяти, адрес вывода на экран.
3....
4...
Добавлено через 3 минуты
Движок VQ3 - вполне себе движок (в моём понимании слова). Точки вызова (наиболее нужные) сделаны JP-ами в начало самого движка. Только под требования первого поста не подходит - он больше квестовый, а не аркадный.Меня интересует такой вопрос: как ты сам оцениваешь, насколько легко его повторное использование в других проектах, мало похожих на Viking Quest?
Да и про внутреннюю организацию было бы интереснее подробнее послушать, потому что у меня самого опыта в это не так много.
По моим оценкам - довольно просто
Ну дак в чем тогда проблема?
Даже если предположить, что ты например (или еще кто) напишешь этот менеджер, перейдя в лагерь считающих, что "для написания игр все уже есть", найдется кто-то еще, который будет стонать, что это все сложно, что надо еще генератор названий героев или еще какую спиночесалку написать. Это бесконечный процесс..
moroz1999
10.03.2008, 23:51
Ну дак в чем тогда проблема?Проблема в умении :) У меня есть кой-какие наработки, но скорость работы оставляет желать лучшего. Я много занимался оптимизацией и анализом написанного, переписывая всё с нуля уже наверное в 10й раз, но тем не менее нехватка опыта в работе с графикой даёт себя знать.
Даже если предположить, что ты например (или еще кто) напишешь этот менеджер, перейдя в лагерь считающих, что "для написания игр все уже есть", найдется кто-то еще, который будет стонать, что это все сложно, что надо еще генератор названий героев или еще какую спиночесалку написать. Это бесконечный процесс..Конечно, всем не угодишь, но это и не цель. Цель могла бы быть такой - заполнить огромную пустующую сейчас нишу, и не более.
Естественно, что если у человека нет желания что-либо делать, то никакой самый навороченный движок/исходник ему не поможет, но я уверен, что при должной документации и примерах можно было бы оказать хорошую помощь многим кодерам типа меня.
Имеются конструкторы адвентюр- притока оных не наблюдается. Имеется редактор (хотя бы так) карт для ЧВ - кроме одного-двух людей новые карты никто не делает. Имеется конструктор трехмерных сцен - хотя бы повторов TotalEclipse тоже не замечено. Продолжать?..
moroz1999
11.03.2008, 00:04
Имеются конструкторы адвентюр- притока оных не наблюдается. Имеется редактор (хотя бы так) карт для ЧВ - кроме одного-двух людей новые карты никто не делает. Имеется конструктор трехмерных сцен - хотя бы повторов TotalEclipse тоже не замечено. Продолжать?..Так то конструкторы! спектрум на данный момент - сугубо творческая платформа, поэтом вряд ли кому-то особо интересно дополнять чужую игру, а именно на это как правило смахивает использование готовых конструкторов и редакторов карт. Речь всё же идёт не о конструкторе, а об инструментарии, с которым удобно работать, который имеет минимальные насколько это возможно ограничения по концепции и внешнему виду, и который легко и просто дополняется и оптимизируется.
Так то конструкторы!
Опиши свое видение этого "инструмента разработчика" как можно более детальнее.
вывод спрайтов, текста и тп оно понятно. но на примере пц-шных движков, очень удобно юзать абстракцию "полотна" (canvas), или "сцены", у которой есть тайловый фон, и по которой движутся объекты (спрайты или наборы спрайтов), причем для последних поддерживается детекция столкновений с другими обьектами, а также маски (куски фона, которые закрывают объекты, типа ствол дерева, за которым проходит персонаж...)
ИМХО дальше этого что-то воротить уже бред, а вот это самое сделать на ZX вполне возможно. spritepack довольно удачный пример этого подхода (с очевидными для zx упрощениями), сомневающиеся могут позырить демки, и убедиться, что тормозов нет. впрочем, у спрайтпака есть свои недостатки -- к примеру, нельзя вменяемо намутить скроллинг фона, и памяти он жрет много. но как proof of concept он рулит.
Добавлено через 2 минуты
Имеются конструкторы адвентюр
эти конструкторы -- для англ. языка (нормального русского парсера для этих целей AFAIK нету). но английских же игр на них сделано очень много.
(я не говорю про менюшные адвентюры -- это IMHO мало кому интересно, потому что убого...)
moroz1999
11.03.2008, 00:23
Опиши свое видение этого "инструмента разработчика" как можно более детальнее.
Сугубо моё видение того, к чему надо стремиться, на данный момент таково:
1. Должен использоваться кросс ассемблер (sjasm+) с самосборкой и автозапуском в эмуляторе для отладки.
2. Процедуры движка поделены на функции и минимально документированы. Комменты - не обязательны, достаточно описания функционала и входных параметров.
3. Во внутренней архитектуре отдельно выделена функция логики (в которой происходит обработка действий игрока, AI, минимальная игровая физика для и тд). Логика по мере отработки игровой ситуации записывает в небольшой буфер обмена информацию по типу: номер отображаемого спрайта, координаты на экране, тип спрайта (попиксельный, аттрибутный итд). Логика каким-то еще образом (детально еще не продумывал) может репортить необходимость перерисовки тайлового бэкграунда, скорее всего в виде текущей координаты левого верхнего угла экрана относительно карты бэкграунда.
4. Буфер обмена отдельно отрабатывается т.н. "мэнэджером" который берет информацию о спрайтах из таблицы, подключает нужные банки памяти и запускает с этой инфой запрошенные процедуры отрисовки спрайтов. Здесь же может производиться бэкап бэкграунда под спрайтами, вывод тайлового фона и что угодно. Этот же менеджер выбирает в каком экране надо рисовать, а какой отображать.
5. На данный момент логика у меня выведена на прерывания, что даёт некоторые преимущества (типа естественной системы FPS), но и несёт с собой множество спорных нюансов. Сей пункт даже сейчас под вопросом.
Основной плюс такой системы - если я захочу оптимизировать движок и что-то кардинально переделать в системе вывода на экран, то игровую логику это не затронет вообще никак. В идеале в ней не изменится ни байта, плюс ко всему она полностью вынесена в отдельный файл, что позволяет менять только её.
Таблица спрайтов сделана элементарно просто, это не более чем номер спрайта, адрес в памяти, номер банка и ширина с высотой. Соответственно такую таблицу можно довольно просто хранить отдельно и при желании даже автоматом генерить.
Добавлено через 4 минуты
вывод спрайтов, текста и тп оно понятно. но на примере пц-шных движков, очень удобно юзать абстракцию "полотна" (canvas), или "сцены", у которой есть тайловый фон, и по которой движутся объекты (спрайты или наборы спрайтов), причем для последних поддерживается детекция столкновений с другими обьектами, а также маски (куски фона, которые закрывают объекты, типа ствол дерева, за которым проходит персонаж...)спасибо за пример, это очень близко к тому, каким подобную концепцию вижу себе я :v2_thumb:. В вышеприведенном я бы только отделил детекцию столкновений в отдельный функционал, потому что в разных проектах это может требоваться по-разному. То, что представляю себе я - это чисто графический инструментарий, поэтому любая логика/псевдофизика, имхо, должна быть реализована отдельно.
SAM style
11.03.2008, 00:39
Добавлено через 3 минуты
Меня интересует такой вопрос: как ты сам оцениваешь, насколько легко его повторное использование в других проектах, мало похожих на Viking Quest?
Да и про внутреннюю организацию было бы интереснее подробнее послушать, потому что у меня самого опыта в это не так много.
Смотря что понимать под "мало похож". можно скормить движку другие спрайты тайлов и персонажей, другую карту, в корне поменять сюжет, поменять скин и написать кучу оверлеев на каждый случай. только основа останется - главгерой ходит по карте, собирает-использует предметы, говорит с другими и.т.д.
Про внутреннее устройство. Двигало VQ3 состоит из:
1. аниматор - интерпретатор анимаионных скриптов персонажей, по необходимости перерисовывает их на экране. данные о персонажах вне движка.
2. контроллер действий героя (взять, использовать итд). в зависимости от действия прошаривается одна из таблиц данных в случае успеха вызов нужной процедурины или печать текста. (напр: "отдать предмет" поимел два параметра - ЧТО и КОМУ)
3. интерпретатор текста с обработчиком встроеных команд. команд около 30 - это и ветвление сюжета, и манипуляция с параметрами героя, и изменение карты, и вызов оверлеев...
4. система боя - сильно специфичная часть.
5. собственно, базовые функции - вывод части карты, спрайтов, печать текста и пр...
подробнее не помню - уж полтора года как... сейчас ваяю новый движок, старый раздаю в первые попавшиеся руки.
Lethargeek
11.03.2008, 06:48
Звездное Наследние по уровню кода наверное и до 85 года не дотягивает и что с того?
Это че, такой пример спрайтового движка? :rolleyes:
Ну ладно, ты как представляешь себе появление сотен игр типа ЗН на Спеке? Кто на них сценарии-то писать будет? НЕТ сейчас "проблемы графического движка" в игростроении, на это времени уйдет минимум - проблемы начинаются, когда надо написать сценарий, сгенерить уровни, придумать правила, задать ИИ итд итп. Сам же прекрасно знаешь, отчего глохнут красивые проекты ;)
Ну, на момент допустим, что технический уровень и правда будет настолько невысок. Тогда встречный вопрос: какова альтернатива?
Читайте книжки
Ищите кодера :)
Существует ли на спектруме готовый движок с открытыми исходниками?
если еще не вспоминали, то: http://www.zx.pk.ru/showthread.php?t=3152
Читайте книжки
Ищите кодера
Да, именно проблема в том что надо читать и искать.
Не любять этого...
moroz1999
15.03.2008, 19:32
Да, я не люблю копаться в архивных документах, когда есть возможность спросить у человека, уже эту работу проделавшего. если я начну перерывать старые издания в поисках полезного совета, то это, извините, как иголку в стоге сена искать, и в направлении моей цели меня это вряд ли вообще приблизит.
То, чем подавляющее большинство людей занимается на спектруме - это хобби, а хобби, к сожалению, не накормит, поэтому посвящать 100% своего времени Спектруму лично я, например, не могу, да и не единственное это хобби у меня.
С таким саркастическим подходом единственным результатом будет то, что те, кто еще чего-то хотят сделать и написать, плюнут на всё и свалят окончательно на pc.:mad:
Кто на них сценарии-то писать будет?
Да нет конечно, не пример.
Нужен был скорее не движок, что то вроде продвинутого Laser Basic'a заточенного под 128к и дисковод.
НЕТ сейчас "проблемы графического движка" в игростроении,
У меня есть графика ну к 3-5 играм разных жанров. Еще знаю художника с графикой для игры вроде Robocop'a.
А вот движков нет.
на это времени уйдет минимум - проблемы начинаются, когда надо написать сценарий, сгенерить уровни, придумать правила, задать ИИ итд итп. Сам же прекрасно знаешь, отчего глохнут красивые проекты
Ну вот есть и сценарий и графика, а кодеров желающих доделать игру что то не видно.
(Я про Dizzy Main Day)
В аркадах сценарий так вообще не нужен, а уровни нарисовать все таки проще чем накодить движок игры, точнее найти левелдизайнера проще чем кодера.
Слава - давнобы выложил исходы с наработками - глядишь ктонить чтонить и сделал... а так....
Если выложить то подавно не доделают, психология такая, если проект валяется где то, значит он мертвый и никому не нужный, к тому же потроха увидят все кому не лень.
В принципе я наверное могу создать закрытую тему и там выложить все добро что у меня есть. Надо?
moroz1999
15.03.2008, 23:16
имхо, есть смысл что-то выкладывать только если кто-то лично выразит готовность заниматься проектом.
Если выложить то подавно не доделают, психология такая, если проект валяется где то, значит он мертвый и никому не нужный, к тому же потроха увидят все кому не лень.
В принципе я наверное могу создать закрытую тему и там выложить все добро что у меня есть. Надо?
Нет совершенно не надо
у игры есть название т.е ктото чтото уже закладывал в сценарий а где этот ктото?
никто не сделает игру такой какой задумал ее автор
ИмХО конечно :) но моё:v2_devil:
slight_mpx
19.05.2008, 02:46
Дас ист фантастиш - на Спеке движок всегда зависел от желаемого результата (как стиля, так и динамики). Кто-нить может себе представить движок, способный эффективно отображать графику по типу (одновременно) - ЧВ, Cybernoid, AMC и Trapdoor?
ничего нереального нет. написать можно было бы, просто сделать на макросах библиотеку для использования для каждого случая. вот только кому это надо на самом деле, если тебе это может никогда не понадобиться. действительно проще написать с нуля или воспользоваться конкретной для похожей игры. но насколько я знаю каждый кодер пишет под себя и поэтому под другую игру другому кодеру будет использовать движок проблематично.
Добавлено через 2 минуты
Нет совершенно не надо
у игры есть название т.е ктото чтото уже закладывал в сценарий а где этот ктото?
никто не сделает игру такой какой задумал ее автор
ИмХО конечно но моё
__________________
и сложно кому то будет разобраться во всем коде кроме автора, да и скорее автор уже многого не помнит, если проект был давно и достаточно большой
Lethargeek
19.05.2008, 03:00
ничего нереального нет. написать можно было бы, просто сделать на макросах библиотеку для использования для каждого случая
Совет из серии "если хочешь быть счастливым - будь им!" :)
Движок - это все-таки рабочий итоговый код.
Думаю была бы полезней эдакая энциклопедия всех использовавшихся приемов (с объяснением зачем и почему) - хотя работа немногим менее титаническая имхо, чем "библиотека на макросах".
slight_mpx
19.05.2008, 03:17
Думаю была бы полезней эдакая энциклопедия всех использовавшихся приемов (с объяснением зачем и почему) - хотя работа немногим менее титаническая имхо, чем "библиотека на макросах".
вопрос был именно о том чтобы сделать типа универсального движка, я предложил несколько вариантов в библиотеку, энциклопедий таких навалом с подробныи описаниями( куча журналов, газет, в конце концов самих исходников, в свое время Слава Медноногов разжевал что мог про свой движок, хоть далеко и не идеальный, и т.п.) где подробно описано и разжевано. прикол с макросами именно в том что ты просто подставляешь цифры в нужные адреса так сказать. типа "а" пошел в "ж" и т.п.))) минимальные затраты средне-максимальные прибыли. все-таки никакие библиотеки не подстроятся под конкретную игру так, чтобы она работала на отношении например скорости-памяти. но подойдут для тех кому лень писать с нуля, типа как и все журнало-газето-постройщики. например у нас гейма была написано во многом на макросах, но не по движку конечно, а исходниках. однако удобно
Lethargeek
19.05.2008, 03:38
энциклопедий таких навалом с подробныи описаниями( куча журналов, газет, в конце концов самих исходников,
Энциклопедия "россыпью" - это сильно... так можно на любой вопрос просто в инет посылать :D
Суть энциклопедии именно в том, чтобы в одну кучу собрать (ага, повыгрызать изо всех неизвестно как пожатых журналов) и желательно сравнительный анализ добавить.
Хотя лично мне побоку, мне интереснее, если че - выдумать самому :)
Существует ли на спектруме готовый движок с открытыми исходниками? Не заточенный под определенную игру, а имеющий более-менее широкие возможности
В большинстве проектов вывод спрайтов это ок-ло 5% всего проекта. А если считать усилия затраченные на реализацию - то 1% а может и менее. Рутинные процедуры вывода спрайтов составляются за считанные часы. Тогда как остальные вещи в игре- десятки или сотни часов.
Вместо поиска или изучения "движка" проще поставить четкую задачу и проконсультироваться с кем-л. как ее решить. Спрайты - одна из очень хорошо и глубоко проработанных вещей на синклере.
Что касается "универсальных энжин для синклера" - это не очень умно само по себе. На PC подобное реализовали и реализуют по одной простой причине - организация графики не то чтобы уж сильно сложна, но на то, чтобы ее все-таки выполнить требуется время изучить (читать документацию по DirectDraw, читать WinApi) и написать чтобы заработало нужно не пару строчек. Вот поэтому для тех кто хочет быстро и сразу - писали, пишут и будут писать API из строчек
включитьэкран(1024,768); или вывестиспрайт(x,y,спрайт22);
А на синклере - зачем? Это может понадобится только тем, кто не почитал информацию про вывод графики и не желает ее получить вовсе.
Я намеренно не написал про скорость/эффективность универсальных решений. Не написал потому, что на самом деле "энжину" можно представлять себе как некую универсальную библиотеку, конфигурирующуюся на этапе компиляции (а не в run-time). Т.е. просто большой набор разных исходников и собираем из них себе то что нужно.
Но это, правда, не сильно нужно. Синклер это такая платформочка, где свое пишется/думается быстрее чем ты это где-то найдешь.
В общем, "энжины" под синклер лишены смысла. Можно попытаться изобретать (для того чтобы было чем себя занять) - но где-то в чем-то будет обязательно пролёт.
moroz1999
12.06.2008, 13:34
спасибо за большой и развернутый ответ, но топик создавался преимущественно не для обсуждения нужности/ненужности, а для конкретных советов по сабжу и обмена конкретным опытом реализации.
спасибо за большой и развернутый ответ, но топик создавался преимущественно не для обсуждения нужности/ненужности, а для конкретных советов по сабжу и обмена конкретным опытом реализации.
Да, ответил я в глобальном смысле. Причем на первый пост. Ответил чтобы переработать и извлечь полезную информацию. Если тебе требуется действительно получить практическую информацию (построить вывод спрайтов и другие блоки) - спрашивай. А если ты, так сказать, "парировал" то это сродни:
- "Здравствуйте, как мне сделать вечный двигатель для получения даровой энергии".
- Вы понимаете, существует закон сохранения энергии, еще никому не удавалось.. бла-бла-бла... Вот лучше смотрите - даю вам идею бла-бла-бла....
- Спасибо вам за глубокий и обстоятельный ответ, но все таки я спрашивал для конкретных советов как сделать вечный двигатель и обмена опытом реализации..
p.s.
Кстати, не поверишь, совершенно случайно взгляд упал на фразу одного из моих фрэндов:
"Любой независимый геймдев, который решил писать свой движок - обречен на 90%."
"Любой независимый геймдев, который решил писать свой движок - обречен на 90%."
Это типа как - "никто не хочет выдумывать программу и реализовать бизнесс требования, но все хотят выдумывать новую технологию которая якобы поможет написать программу".
Или там - ненужно думать как бросить курить, нужно "не курить". :)
А по сути то тут все просто: "если хватит сил и времени и желания то можно все переписать, точнее планируйте расход своих ресурсов и не сбивайтесть с курса".
slight_mpx
17.08.2008, 16:19
Существует ли на спектруме готовый движок с открытыми исходниками? Не заточенный под определенную игру, а имеющий более-менее широкие возможности, как, например:
-вывод спрайтов в разных режимах, попиксельно и познакоместно
-вывод тайлового бэкграунда
-познакоместное/попиксельное скроллирование
Есть что-нибудь на примете, где всё это реализовано? Желательно с исходниками, потому что хотелось бы всё это дело перетащить на sjasm+
если нужно то что ты именно перечислил, то есть по любому. у меня были созданы библиотеки, в них было любой вывод спрайта, скроллирование и тп.
при написании чего либо,возьмем тех же вормсов, просто указывал минимальные данные(координаты,что угодно)обращался на макросах к ней, соответсятвенно при компилировании все вставлялось проблемма решена. Scenergy(конечно не игра,но работа там была гигантская с использованием библиотек) полностью на макросах забацан. при его дальнейшем создании(если бы появился 3 номер), достаточно было бы давать данные и все. создание заняло бы минимум времени(учитывая что все готово). кароче я говорю что это на самом деле не трудно. что-то конечно по любому пришлось бы писать с нуля,без этого никак.
конечно это не движок в некотором смысле, но сделать его можно было бы за короткое время,данные подсовывать надо все равно
у меня были созданы библиотеки, в них было любой вывод спрайта, скроллирование и тп.
Поделись, а?
slight_mpx
20.08.2008, 00:24
Поделись, а?
ща покопаюсь
http://www.z88dk.org/wiki/doku.php?id=library:sprites:sp1#tutorial_documenta tion
Еще особо не разбирался, но на первый взгляд это LaserBasic только на C++.
Это хотел moroz1999?
moroz1999
08.09.2009, 11:29
Спасибо за пример. Для C++ бегает довольно шустро, но, честно говоря, хотелось бы большего.
Pang 16C / Ball Quest - трёхплатформенный движок (Pentagon 16C, ATM Turbo 2, MSX2). Исходники были выложены сразу. Всё было описано в журнале. Не заинтересовался НИКТО.
http://alonecoder.nedopc.com/zx/BQ_SRC.rar
Pang 16C / Ball Quest - трёхплатформенный движок (Pentagon 16C, ATM Turbo 2, MSX2). Исходники были выложены сразу. Всё было описано в журнале. Не заинтересовался НИКТО.http://alonecoder.nedopc.com/zx/BQ_SRC.rar
Дим, как ты так определил, что никто не заинтересовался телепатия? кодеры, кто действительно интересуется - они и без исходников всю жизнь дизассемблируют и смотрят движки.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot