вот, по большому счету я это и имею в виду. единственно только с тем дополнением, что доступ к этим вещам сделан не напрямую, а через небольшую процедурку-менеджера, которая работает с элементарными запросами, записанными в буфер.Сообщение от Vitamin
Оцени трудоемкость написания этого менеджера. В частности, в сравнении с трудоемкостью написания набора необходимых процедур.
Последний раз редактировалось Vitamin; 10.03.2008 в 23:12. Причина: Добавлено сообщение
Звездное Наследние по уровню кода наверное и до 85 года не дотягивает и что с того?
Движок VQ3 - вполне себе движок (в моём понимании слова). Точки вызова (наиболее нужные) сделаны JP-ами в начало самого движка. Только под требования первого поста не подходит - он больше квестовый, а не аркадный.
Все любят гипножабу
По моим оценкам - довольно просто. Весь т.н. "менеджер" состоит из циклического прохода по заполненному буферу, в котором каждый спрайт описан 5-6 байтами, и передачи этих байт в процедуры вывода на экран. Единственное серьезное упущение по скорости в данном случае в том, что сами процедуры становится нельзя узко заточить под какое-то конкретное применение, но никто не мешает сделать заточенные копии с основных, работающие только при определенных частных случаях.
Технически всё это упирается в написание и отладку самих процедур вывода, которые должны быть максимально быстрыми без потери универсальности.
Примеры процедур вывода, чтобы было понятно, о чем я:
1. функция познакоместного вывода цветного спрайта на экран. входные параметры - координаты, адрес спрайта в памяти, адрес вывода на экран, может еще чего по мелочам.
2. функция попиксельного вывода монохромного спрайта на экран, входный параметры - координаты, адрес в памяти, адрес вывода на экран.
3....
4...
Добавлено через 3 минуты
Меня интересует такой вопрос: как ты сам оцениваешь, насколько легко его повторное использование в других проектах, мало похожих на Viking Quest?
Да и про внутреннюю организацию было бы интереснее подробнее послушать, потому что у меня самого опыта в это не так много.
Последний раз редактировалось moroz1999; 10.03.2008 в 23:39. Причина: Добавлено сообщение
Ну дак в чем тогда проблема?
Даже если предположить, что ты например (или еще кто) напишешь этот менеджер, перейдя в лагерь считающих, что "для написания игр все уже есть", найдется кто-то еще, который будет стонать, что это все сложно, что надо еще генератор названий героев или еще какую спиночесалку написать. Это бесконечный процесс..
Проблема в уменииУ меня есть кой-какие наработки, но скорость работы оставляет желать лучшего. Я много занимался оптимизацией и анализом написанного, переписывая всё с нуля уже наверное в 10й раз, но тем не менее нехватка опыта в работе с графикой даёт себя знать.
Конечно, всем не угодишь, но это и не цель. Цель могла бы быть такой - заполнить огромную пустующую сейчас нишу, и не более.
Естественно, что если у человека нет желания что-либо делать, то никакой самый навороченный движок/исходник ему не поможет, но я уверен, что при должной документации и примерах можно было бы оказать хорошую помощь многим кодерам типа меня.
Имеются конструкторы адвентюр- притока оных не наблюдается. Имеется редактор (хотя бы так) карт для ЧВ - кроме одного-двух людей новые карты никто не делает. Имеется конструктор трехмерных сцен - хотя бы повторов TotalEclipse тоже не замечено. Продолжать?..
Так то конструкторы! спектрум на данный момент - сугубо творческая платформа, поэтом вряд ли кому-то особо интересно дополнять чужую игру, а именно на это как правило смахивает использование готовых конструкторов и редакторов карт. Речь всё же идёт не о конструкторе, а об инструментарии, с которым удобно работать, который имеет минимальные насколько это возможно ограничения по концепции и внешнему виду, и который легко и просто дополняется и оптимизируется.
Опиши свое видение этого "инструмента разработчика" как можно более детальнее.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием