Здравствуйте, alx771103, Вы писали:
КЛ>>Попробуйте написать хотя бы аркадную физику для гоночной игры или AI-водителя. A>И куда потом ето девать?
В /dev/null вестимо.
Я за свою жазнь не один мегабайт кода написал зная что нгикуда кроме /dev/null он не подет.
Но опыт останется и это главное.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Напоминает типовую ошибку начинающего № 1.1."Замахус Грандиозус". ИМХО, начинать нужно с конкретных и небольших вещей. Попробуйте написать хотя бы аркадную физику для гоночной игры или AI-водителя.
Здравствуйте, Laughing_Silencer, Вы писали:
L_S>Е мое — вопрос стоял у автора темы достаточно четко, но я пожалуй его конкретизирую дабы избежать разночтений, поскольку это и мне интересно. Какие паттерны и решения применяются по отношению к играм с точки зрения проектирования.
Угу очень четко примерно так: "как мне написать программу?"
L_S>Предлагаю не упираться на понятие игрового движка, поскольку это достаточно спорное понятие, а употреблять термин игра.
L_S>Дабы еще более конкретезировать необходимые результаты предложу следующий набор:
L_S>1. Какие книги имеются по проектированию ИМЕННО игровых движков всех уровней и их взаимодействия для реализации игры ?
Именно по проектированию и именно игровых движков книг не знаю. Но есть книги скорее по конструированию м проектированию некторых типов игр, например "Software Engineering and Computer Games" Rudy Rucker (советую почитать другие его книги ) (подсказка для поиска software.engineering.and.computer.games.chm), другой пример более ограниченный и конкретный "Strategy Game Programming with DirectX 9.0" Todd Barron (Wordware Publishing — Strategy Game Programming With Directx 9.0 2003.chm).
Ну и конечно много статей в интернете, многие хорошие попадают в "Game Programming Gems"
L_S>2. Какие технологии и решения применяются для безболезненной организации патчей ?
Делать меньше ошибок
L_S>3. Какие технологии и решения имеются для хранения графических и музыкальных данных помимо простого раскидывания их по каталогам в не архивированном или архивированном виде ?
То что ты назвал плюс базы данных.
L_S>4. Наиболее удобный способ хранения карт и игровой логики ?
Это сильно зависит от игры, общего ответа нет. Логику конечно лучше хранить в скриптах
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, alx771103, Вы писали:
A>>Мы тут, по-моему, немножко в сторону ушли... A>>Попытаюсь конкретизировать...
A>>Утверждение первое: Движок состоит из модулей. A>>Утверждение второе: Модули общаются между собой.
A>>Вопрос №1: Как его лучше разбить и организовать "общение"?
FR>Если бы был возможен общий ответ на этот вопрос, то специализаций проектировщик и архитектор, в разработке ПО не было бы
Е мое — вопрос стоял у автора темы достаточно четко, но я пожалуй его конкретизирую дабы избежать разночтений, поскольку это и мне интересно. Какие паттерны и решения применяются по отношению к играм с точки зрения проектирования.
Предлагаю не упираться на понятие игрового движка, поскольку это достаточно спорное понятие, а употреблять термин игра.
Дабы еще более конкретезировать необходимые результаты предложу следующий набор:
1. Какие книги имеются по проектированию ИМЕННО игровых движков всех уровней и их взаимодействия для реализации игры ?
2. Какие технологии и решения применяются для безболезненной организации патчей ?
3. Какие технологии и решения имеются для хранения графических и музыкальных данных помимо простого раскидывания их по каталогам в не архивированном или архивированном виде ?
4. Наиболее удобный способ хранения карт и игровой логики ?
Здравствуйте, alx771103, Вы писали:
A>Привет всем!
A>Я в этом деле новенький, но хотел бы (чиста, хобби) написать свой игровой движок... А идеи как это сделать — закончились...
A>Как бы так разбить движок на модули, чтобы при переходе на другую платформу не пришлось переписывать почти всё с нуля?..
A>Если есть идеи (или, еще лучше, проверенные идеи), пожалуйста, поделитесь...
Ты бы сначала объяснил что понимаешь под словом "движок", а то это понятие сильно растяжимое
Здравствуйте, alx771103, Вы писали:
A>Как бы так разбить движок на модули, чтобы при переходе на другую платформу не пришлось переписывать почти всё с нуля?..
Прежде всего нужно полностью абстрагироваться от операционной системы. Это можно сделать с помощью специальных библиотек, у которых есть порты на многие операционные системы. Например, стандартная библиотека С++, Boost и пр.
Разбиение на модули должно зависить от архитектуры проекта.
Здравствуйте, alx771103, Вы писали:
A>Здравствуйте, FR, Вы писали:
FR>>Ты бы сначала объяснил что понимаешь под словом "движок", а то это понятие сильно растяжимое
A>Только у меня язык кривой ...
A>Этакий комплекс систем, которые взаимодействуют в реальном времени...
A>На мой взгляд системы должны быть следующими:
A>Поддержка платформы, Сервер, клиент, обработчик ввода, вывод графики, вывод звука...
Поехали дальше, для какой именно игры должен быть движок, а то под твое определение вполне подходит и простеший OGL движок для вывода 2D картинок написанный не торопясь за недельку и например Unreal engine объемом под десяток человеко лет. Архитектуры как понимаешь у них будут очень непохожие
Здравствуйте, FR, Вы писали:
FR>Поехали дальше, для какой именно игры должен быть движок, а то под твое определение вполне подходит и простеший OGL движок для вывода 2D картинок написанный не торопясь за недельку и например Unreal engine объемом под десяток человеко лет. Архитектуры как понимаешь у них будут очень непохожие
Симулятор космического корабля... То есть, трехмерная графика, звук, поддержка всеразличных джойстиков и мышей, поддержка скриптования, физика... Может, что-то еще...
Здравствуйте, alx771103, Вы писали:
A>Здравствуйте, FR, Вы писали:
FR>>Поехали дальше, для какой именно игры должен быть движок, а то под твое определение вполне подходит и простеший OGL движок для вывода 2D картинок написанный не торопясь за недельку и например Unreal engine объемом под десяток человеко лет. Архитектуры как понимаешь у них будут очень непохожие
A>Симулятор космического корабля... То есть, трехмерная графика, звук, поддержка всеразличных джойстиков и мышей, поддержка скриптования, физика... Может, что-то еще...
Дальше я могу уточнять какой именно симулятор, возможна ли посадка на планеты и т. д. и т. п., но думаю ты уже мораль понял: сначала надо точно знать для каких игр и с какими ограничениями нужен движок, а уже потом думать о его архитектуре.
Здравствуйте, FR, Вы писали:
FR>Дальше я могу уточнять какой именно симулятор, возможна ли посадка на планеты и т. д. и т. п., но думаю ты уже мораль понял: сначала надо точно знать для каких игр и с какими ограничениями нужен движок, а уже потом думать о его архитектуре.
Это — детали... Я потому и советуюсь... Движок который будет просто обрабатывать физику объектов, выводить на экран, озвучивать... А при необходимости, к нему можно прикрутить посадку на планеты и игру по сети... А то можно скатиться до выяснения какую версию шейдеров использовать и сколько каналов на звук...
И вот, чтобы к движку было легко "прикручивать" нужно создать грамотную архитектуру... Я уже не говорю о том, чтобы легко пересесть с OGL на DX, при необходимости...
A>Это — детали... Я потому и советуюсь... Движок который будет просто обрабатывать физику объектов, выводить на экран, озвучивать... А при необходимости, к нему можно прикрутить посадку на планеты и игру по сети... А то можно скатиться до выяснения какую версию шейдеров использовать и сколько каналов на звук...
A>И вот, чтобы к движку было легко "прикручивать" нужно создать грамотную архитектуру... Я уже не говорю о том, чтобы легко пересесть с OGL на DX, при необходимости...
Я не про это. Я про то что с движка начинать, особенно неопытному игроделу не стоит. Нужно начинать с игры. А движок выделится по мере выработки требований к игре. Вообще для начинающего писать сначала движок а потом игру верный путь к провалу. Сначала нужно сделать именно игру, пусть даже несложную, и даже возможно на готовом сторонем движке, иначе ты просто не будешь понимать что нужно, что важно и что второстепенно.
Здравствуйте, FR, Вы писали:
FR>Я не про это. Я про то что с движка начинать, особенно неопытному игроделу не стоит. Нужно начинать с игры. А движок выделится по мере выработки требований к игре. Вообще для начинающего писать сначала движок а потом игру верный путь к провалу. Сначала нужно сделать именно игру, пусть даже несложную, и даже возможно на готовом сторонем движке, иначе ты просто не будешь понимать что нужно, что важно и что второстепенно.
Мы тут, по-моему, немножко в сторону ушли...
Попытаюсь конкретизировать...
Утверждение первое: Движок состоит из модулей.
Утверждение второе: Модули общаются между собой.
Вопрос №1: Как его лучше разбить и организовать "общение"?
Здравствуйте, WolfHound, Вы писали:
WH>Но опыт останется и это главное.
Класс!!! У меня уже терпения не осталось... Название темы "Архитектура ИГРОВОГО движка", а не "Я НЕ В СЕБЕ ГЕЙМДЕВЕЛОПЕР, НЕ ЗНАЮ КУДА ПРИЛОЖИТЬ РУКИ, ПОМОГИТЕ!!!"... Если бы я хотел знать, с чего начать — я бы в другом месте всего этого почитал...
Я призываю порассуждать на тему архитектуры!
Например: есть у меня класс-интерфейс Platform. По идее, он должен содержать в себе все, что необходимо ядру для общения с платформой: функции для получения времени, работы с файлами и еще много чего... Вот и интересно мне: есть ли смысл вообще создавать и использовать этот интерфейс... И если есть, то что в него целесообразно запихнуть... (Косноязычно, но, надеюсь, понятно) Порассуждаем?
Или... Есть у меня низкоуровненвая графическая библиотека (OGL, например). Стоит ли ее обертывать во что-то свое? Или стоит для каждого класса сцены написать свой "выводильщик", который и будет содержать в себе все низкоуровневые вызовы... Обсудим?
Если есть что сказать по этому поводу — прошу...
Если нечего — не надо писать... Пожалуйста!..
A>Мы тут, по-моему, немножко в сторону ушли... A>Попытаюсь конкретизировать...
A>Утверждение первое: Движок состоит из модулей. A>Утверждение второе: Модули общаются между собой.
A>Вопрос №1: Как его лучше разбить и организовать "общение"?
Если бы был возможен общий ответ на этот вопрос, то специализаций проектировщик и архитектор, в разработке ПО не было бы
Здравствуйте, alx771103, Вы писали:
A>Я призываю порассуждать на тему архитектуры! A>Например: есть у меня класс-интерфейс Platform. По идее, он должен содержать в себе все, что необходимо ядру для общения с платформой: функции для получения времени, работы с файлами и еще много чего... Вот и интересно мне: есть ли смысл вообще создавать и использовать этот интерфейс...
ну если проект "сильно платформер",то смысл определенно есть..
а этот класс универсальный для всех платформ или есть несколько различных Platform'ов на все случаи жизни?.
A>И если есть, то что в него целесообразно запихнуть... (Косноязычно, но, надеюсь, понятно) Порассуждаем?
зависит от платформ..базовые функции(время, файлы), работа со специфичными для платформы вещами..
вот в этом Platform'е что уже есть?.
A>Или... Есть у меня низкоуровненвая графическая библиотека (OGL, например). Стоит ли ее обертывать во что-то свое? Или стоит для каждого класса сцены написать свой "выводильщик", который и будет содержать в себе все низкоуровневые вызовы... Обсудим?
имхо лучше обернуть..
по крайней мере, если кто будет это использовать, то не сделает чего нить, что не устраивает вас.. хотя для мелких проектов думаю это не важно..
Здравствуйте, neFFy, Вы писали:
FF>ну если проект "сильно платформер",то смысл определенно есть.. FF>а этот класс универсальный для всех платформ или есть несколько различных Platform'ов на все случаи жизни?.
Есть интерфейс Platform, есть классы Win32Platform, ОкноPlatform, НезнаюЧтоЕщеPlatform, которые наследуются от Platform. Ядро — знает только Platform.
Но! Ведь есть еще графический, звуковой модуль... Модуль устройств ввода... Они-то сильно привязаны к платформе...
То есть, с одной стороны... Хочется, чтобы ядро и сервер не знали вообще ничего о платформе...
С другой, платформа может оказывать влияние на работу ядра...
Как это совместить?..
FF>зависит от платформ..базовые функции(время, файлы), работа со специфичными для платформы вещами.. FF>вот в этом Platform'е что уже есть?.
Это мне и хотелось узнать... Навскидку:
1. Получение системного времени (от него потом и плясать при вычислении разных deltaTime)
2. Обработка сообщений от платформы и интерпретация в сообщения ядра. Например, для Windows, активация/деактивация окна приводит, в зависимости от того, работает ли на этой машине dedicated сервер, к приостановке выполнения приложения.
3. Обертка системы ввода/вывода (по поводу её необходимости есть сомнения).
4. Что еще?
FF>имхо лучше обернуть.. FF>по крайней мере, если кто будет это использовать, то не сделает чего нить, что не устраивает вас.. хотя для мелких проектов думаю это не важно..
Во втором случае (с "выводильщиками"), сделать что-то не так могут только эти самые "выводильщики", а они написаны мной и измнению не подлежат...
Зато, когда завтра выйдет чудесная графическая библиотека "NextGeneration3DGraphicsAPI", в которой будут использоваться не треугольники, а кружочки, этот самый "выводильщик" будет преобразовывать треугольники в кружочки и отдавать их в API.
Здравствуйте, alx771103, Вы писали:
A>Привет всем!
A>Я в этом деле новенький, но хотел бы (чиста, хобби) написать свой игровой движок... А идеи как это сделать — закончились...
A>Как бы так разбить движок на модули, чтобы при переходе на другую платформу не пришлось переписывать почти всё с нуля?..
A>Если есть идеи (или, еще лучше, проверенные идеи), пожалуйста, поделитесь...
игровой движок для различных типов игр будет различен — имхо.
в одних играх нужен движок с элементами искусственного интеллекта, в других — нет.
Re: Архитектура ИГРОВОГО движка
От:
Аноним
Дата:
09.06.06 06:51
Оценка:
Здравствуйте, alx771103, Вы писали:
A>Привет всем!
A>Я в этом деле новенький, но хотел бы (чиста, хобби) написать свой игровой движок... А идеи как это сделать — закончились...
A>Как бы так разбить движок на модули, чтобы при переходе на другую платформу не пришлось переписывать почти всё с нуля?..
A>Если есть идеи (или, еще лучше, проверенные идеи), пожалуйста, поделитесь...
Если хочешь чего то написать, то возьми opensource движок и посмотри на его архитектуру и это будет ответы на твои текущии и буущие вопросы. см. http://www.devmaster.net/engines/
Здравствуйте, alx771103, Вы писали:
A>Попытаюсь конкретизировать...
A>Утверждение первое: Движок состоит из модулей. A>Утверждение второе: Модули общаются между собой.
A>Вопрос №1: Как его лучше разбить и организовать "общение"?
Сам движок явно должен быть представлен паттерном сингельтон, а общение между модулями можно организовать использую паттерн медиатор, чтобы в последствии было проще добавлять новые модули. Разбивать движок нужно в соответствии со здравым смыслом, т.е. на графическую часть, звуковую, скриптовую и какие вы там еще хотели?
Здравствуйте, <Аноним>, Вы писали:
А>Если хочешь чего то написать, то возьми opensource движок и посмотри на его архитектуру и это будет ответы на твои текущии и буущие вопросы. см. http://www.devmaster.net/engines/
+1
Автору темы имеет смысл начать с чего-то подобного + поиска хотя бы в данном форуме rsdn + поиска в онлайн-ресурсах по теме
Здравствуйте, alx771103, Вы писали:
FF>>а этот класс универсальный для всех платформ или есть несколько различных Platform'ов на все случаи жизни?. A>Есть интерфейс Platform, есть классы Win32Platform, ОкноPlatform, НезнаюЧтоЕщеPlatform, которые наследуются от Platform. Ядро — знает только Platform. A>Но! Ведь есть еще графический, звуковой модуль... Модуль устройств ввода... Они-то сильно привязаны к платформе... A>То есть, с одной стороны... Хочется, чтобы ядро и сервер не знали вообще ничего о платформе... A>С другой, платформа может оказывать влияние на работу ядра... A>Как это совместить?..
я не понял в чем проблема.. как платформа может влиять на работу ядра, если все низкоуровневые вещи вынесены в отдельные модули?.
что в ядро тогда входит?.
FF>>зависит от платформ..базовые функции(время, файлы), работа со специфичными для платформы вещами.. FF>>вот в этом Platform'е что уже есть?. A>Это мне и хотелось узнать... Навскидку: A>1. Получение системного времени (от него потом и плясать при вычислении разных deltaTime)
это да..
A>2. Обработка сообщений от платформы и интерпретация в сообщения ядра. Например, для Windows, активация/деактивация окна приводит, в зависимости от того, работает ли на этой машине dedicated сервер, к приостановке выполнения приложения. A>3. Обертка системы ввода/вывода (по поводу её необходимости есть сомнения).
а думаю по любому нужна.. особенно, если используются сильно отличающиеся системы ввода вывода..
A>4. Что еще?
звук, графика.. а вроде ничего больше нет.. ИИ не зависит..
по сути, чтобы абстрагироваться от платформы полностью (включая низкоуровневые библиотеки) нужно создать свой маленький АПИ, у которого, например, есть настройка "вид платформы"
FF>>имхо лучше обернуть.. FF>>по крайней мере, если кто будет это использовать, то не сделает чего нить, что не устраивает вас.. хотя для мелких проектов думаю это не важно.. A>Во втором случае (с "выводильщиками"), сделать что-то не так могут только эти самые "выводильщики", а они написаны мной и измнению не подлежат... A>Зато, когда завтра выйдет чудесная графическая библиотека "NextGeneration3DGraphicsAPI", в которой будут использоваться не треугольники, а кружочки, этот самый "выводильщик" будет преобразовывать треугольники в кружочки и отдавать их в API.
зачем создавать много "выводильщиков" на низком уровне, когда можно создать один, предоставляющий высокий уровень, и в нем преобразовывать в низкий?.
Здравствуйте, RomashkaX, Вы писали:
RX>Сам движок явно должен быть представлен паттерном сингельтон, а общение между модулями можно организовать использую паттерн медиатор, чтобы в последствии было проще добавлять новые модули. Разбивать движок нужно в соответствии со здравым смыслом, т.е. на графическую часть, звуковую, скриптовую и какие вы там еще хотели?
Здравствуйте, alx771103, Вы писали:
A>И куда потом ето девать?
1) При устройстве на работу в какую-нибудь игровую компанию Вы можете продемонстрировать этот пример.
2) Вы можете разместить исходники на Вашем сайте, а на форуме профессионально обсуждать вопросы создания игровой физики или AI. Почему профессионально? Потому что Ваши знания будут базироваться на опыте.
Встречный вопрос: "А что Вы потом будете делать с написанным движком?"
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>1) При устройстве на работу в какую-нибудь игровую компанию Вы можете продемонстрировать этот пример. КЛ>2) Вы можете разместить исходники на Вашем сайте, а на форуме профессионально обсуждать вопросы создания игровой физики или AI. Почему профессионально? Потому что Ваши знания будут базироваться на опыте. КЛ>Встречный вопрос: "А что Вы потом будете делать с написанным движком?"
Здравствуйте, alx771103, Вы писали:
A>Я призываю порассуждать на тему архитектуры!
Не хочу Вас обидеть, но такие обсуждения интересно (и продуктивно!) вести с человеком, который принимал участие в написании движка для какой-нибудь коммерческой игры. Или хотя бы с человеком, который спроектировал не одну программу.
Здравствуйте, neFFy, Вы писали:
FF>я не понял в чем проблема.. как платформа может влиять на работу ядра, если все низкоуровневые вещи вынесены в отдельные модули?. FF>что в ядро тогда входит?
Ядро, на мой взгляд — класс, содержащий основной цикл. Или основной цикл должен содержаться именно в той самой Platform?
FF>а думаю по любому нужна.. особенно, если используются сильно отличающиеся системы ввода вывода..
Поясните...
FF>звук, графика.. а вроде ничего больше нет.. ИИ не зависит.. FF>по сути, чтобы абстрагироваться от платформы полностью (включая низкоуровневые библиотеки) нужно создать свой маленький АПИ, у которого, например, есть настройка "вид платформы"
То есть этакий Framework и для каждой платформы свой?
FF>зачем создавать много "выводильщиков" на низком уровне, когда можно создать один, предоставляющий высокий уровень, и в нем преобразовывать в низкий?.
Ну, например, у меня есть объект класса Mesh и выводить его надо посредством отрисовки какого-то буфера точек. А есть еще объект класса ParticleSystem и выводить его надо совсем по-другому... И для Mesh, и для ParticleSystem есть свой "выводильщик" и он занет что и как нужно отдать низкоуровневой бибилиотеке...
Здравствуйте, alx771103, Вы писали:
FF>>я не понял в чем проблема.. как платформа может влиять на работу ядра, если все низкоуровневые вещи вынесены в отдельные модули?. FF>>что в ядро тогда входит? A>Ядро, на мой взгляд — класс, содержащий основной цикл. Или основной цикл должен содержаться именно в той самой Platform?
имхо в самой Platform..
для примера можно сравнить "основной цикл" в glut и DirectX..
FF>>а думаю по любому нужна.. особенно, если используются сильно отличающиеся системы ввода вывода.. A>Поясните...
ну если есть специфичные вызовы..
или например система предоставляет id'шники разных клавиш.. но при портировании эти id'шники на разных системах отличаются.. поэтому имхо лучше сделать свой какой нить enum, в котором будет набор всех нужных клавиш.. или что нибудь подобное..какой нить преобразователь.. об этом надо еще немного подумать..что то я криво сказал
в кратце: обертка над подсистемой ввода-вывода должна принимать какие либо данные от программы и преобразовывать их под платформу.. как и брать от платформы и передавать в программу данные, которые понятны во всех участках программы.. что то типа стандартизации
вообще зависит от количества поддерживаемых платформ и их различия..возможно и не стоит заморачиваться
FF>>звук, графика.. а вроде ничего больше нет.. ИИ не зависит.. FF>>по сути, чтобы абстрагироваться от платформы полностью (включая низкоуровневые библиотеки) нужно создать свой маленький АПИ, у которого, например, есть настройка "вид платформы" A>То есть этакий Framework и для каждой платформы свой?
вроде того.. маленький набор классов для удобной работы..
FF>>зачем создавать много "выводильщиков" на низком уровне, когда можно создать один, предоставляющий высокий уровень, и в нем преобразовывать в низкий?. A>Ну, например, у меня есть объект класса Mesh и выводить его надо посредством отрисовки какого-то буфера точек. А есть еще объект класса ParticleSystem и выводить его надо совсем по-другому... И для Mesh, и для ParticleSystem есть свой "выводильщик" и он занет что и как нужно отдать низкоуровневой бибилиотеке...
с другой стороны.. есть меш и есть массив частиц.. им вовсе не обязательно уметь рисоваться для разных низкоуровневых библиотек.. имхо логичней сделать отдельный "рисовальщик", который будет уметь работать на разных библиотеках.. да и количество изменяемого кода при портировании на другую платформу сильно меньше..
Прошу прощения за молчание — отпуск, знаете ли...
FF>имхо в самой Platform..
Но тогда под каждую платформу придется писать этот самый основной цикл... А это-то как раз делать и не хочется... Нет никаких идей как этого избежать?
FF>в кратце: обертка над подсистемой ввода-вывода должна принимать какие либо данные от программы и преобразовывать их под платформу.. как и брать от платформы и передавать в программу данные, которые понятны во всех участках программы.. что то типа стандартизации
Уупс!.. Мы про разные системы ввода-вывода говорим... Это всё я виноват ... Мне хочется знать, стоит ли оборачивать во что-то свое дисковый ввод-вывод?
FF>вроде того.. маленький набор классов для удобной работы..
Надо подумать... ...я все еще думаю... ...О!
То есть, на полную независимость от платформы может претендовать только сервер и клиент? Единственные модули, которые будут использовать другие, платформозависимые, модули для работы?
FF>с другой стороны.. есть меш и есть массив частиц.. им вовсе не обязательно уметь рисоваться для разных низкоуровневых библиотек.. имхо логичней сделать отдельный "рисовальщик", который будет уметь работать на разных библиотеках.. да и количество изменяемого кода при портировании на другую платформу сильно меньше..
Но тогда для каждого класса сцены придется код переписывать... Хотя в моем случае тоже самое... ДА, ты, наверное, прав... Намотал на ус...
Здравствуйте, alx771103, Вы писали:
FF>>имхо в самой Platform.. A>Но тогда под каждую платформу придется писать этот самый основной цикл... А это-то как раз делать и не хочется... Нет никаких идей как этого избежать?
а что такого сложного написать несколько "основных циклов"??.
в основном цикле:
— видео
— управление
— звук
— что еще??.
FF>>в кратце: обертка над подсистемой ввода-вывода должна принимать какие либо данные от программы и преобразовывать их под платформу.. как и брать от платформы и передавать в программу данные, которые понятны во всех участках программы.. что то типа стандартизации A>Уупс!.. Мы про разные системы ввода-вывода говорим... Это всё я виноват ... Мне хочется знать, стоит ли оборачивать во что-то свое дисковый ввод-вывод?
вот лично я не знаю как осуществляется ввод-вывод с карты памяти в SonyPS..
если под "платформой" понимаются вин/лин, то можно обойтись стандартной библиотекой..
вообще.. если существуют различия между системами ввода-вывода на разных платформах, то стоит обернуть в свое, чтобы работать со стандартизированным интерфейсом..
FF>>вроде того.. маленький набор классов для удобной работы.. A>Надо подумать... ...я все еще думаю... ...О! A>То есть, на полную независимость от платформы может претендовать только сервер и клиент? Единственные модули, которые будут использовать другие, платформозависимые, модули для работы?
для сервера свой платформозависимый кусочек, а для клиента свой.. абсолютно независимой может быть только логика игры
отступление:
под какие платформы вы ищите подход??. может с этого стоит начать?.
Здравствуйте, neFFy, Вы писали:
FF>а что такого сложного написать несколько "основных циклов"??. FF>в основном цикле: FF>- видео FF>- управление FF>- звук FF>- что еще??.
Плохо то, что код под разные платформы будет почти один и тот же, и если понадобится добавить что-то, придется много ковырять...
Вот что я надумал когда-то давно, и, по-моему, надумал правильно:
Есть интерфейс Platform, который полностью скрывает работу с платформой.
Есть класс Kernel, который реализует основной цикл.
Внимание мысль: Kernel может находиться только в двух основных состояниях: запущен (Running) и стоит (Stopped), кроме того, у него в состоянии Running может быть еще одно этакое "подсостояние" Suspended.
Некая функция MAIN должна создать объект нужной платформы, создать и передать ссылку на платформу объекту Kernel. И передать управление какому-то методу run класса Kernel. Соответственно, Kernel перейдет из состояния Stopped в состояние Running. Platform имеет возможность перевести Kernel в состояние Suspended и Stopped. Ну, и соответственно какие-то другие классы могут Kernel ТОЛЬКО в состояние Stopped.
ТО Kernel — класс, реализующий основной цикл, получился платформонезависимым.
Ну и как?
FF>для сервера свой платформозависимый кусочек, а для клиента свой.. абсолютно независимой может быть только логика игры
Вот именно эти кусочки я и хочу вынести в отдельные классы.
FF>отступление: FF>под какие платформы вы ищите подход??. может с этого стоит начать?.
Не "вы", а "ты": я — один.
По-моему, с этого начинать и не надо: Платформазависим — налево, независим — направо... От того, на какой платформе реализуется, платформонезависимый код не становиться зависимым...
A>По-моему, с этого начинать и не надо: Платформазависим — налево, независим — направо... От того, на какой платформе реализуется, платформонезависимый код не становиться зависимым...
Я не понял ты хочешь писать платформонезависимый код только под одну платформу? Если так то сразу скажу ничего кроме потери времени не получишь, при реальном портировании всплывут такие проблемы которые ты и представить не мог, и в тоже время многие вещи будут неоправданно усложнены.
Здравствуйте, FR, Вы писали:
A>>По-моему, с этого начинать и не надо: Платформазависим — налево, независим — направо... От того, на какой платформе реализуется, платформонезависимый код не становиться зависимым... FR>Я не понял ты хочешь писать платформонезависимый код только под одну платформу? Если так то сразу скажу ничего кроме потери времени не получишь, при реальном портировании всплывут такие проблемы которые ты и представить не мог, и в тоже время многие вещи будут неоправданно усложнены.
+1
хорошо бы еще создать проектик, реализующий работу с платформой по минимуму, и прописать его под несколько доступных платформ.. от результата и идти..
Здравствуйте, neFFy, Вы писали:
FF>Здравствуйте, FR, Вы писали:
A>>>По-моему, с этого начинать и не надо: Платформазависим — налево, независим — направо... От того, на какой платформе реализуется, платформонезависимый код не становиться зависимым... FR>>Я не понял ты хочешь писать платформонезависимый код только под одну платформу? Если так то сразу скажу ничего кроме потери времени не получишь, при реальном портировании всплывут такие проблемы которые ты и представить не мог, и в тоже время многие вещи будут неоправданно усложнены.
FF>+1 FF>хорошо бы еще создать проектик, реализующий работу с платформой по минимуму, и прописать его под несколько доступных платформ.. от результата и идти..
От себя могу добавить — посмотри архитектурный паттерн "Microkernel". Либо делай виртуальную машину, а на ее основе пиши всю основную логику. Цель при разработке кроссплатформенных систем минимизировать усилия при переносе кода на любую другую даже заранее неизвестную систему. Сделать как ты планируешь просто нереально... Задача в общем виде решается, но огромными усилиями — учти это.
Здравствуйте, alx771103, Вы писали:
FF>>а что такого сложного написать несколько "основных циклов"??. A>Плохо то, что код под разные платформы будет почти один и тот же, и если понадобится добавить что-то, придется много ковырять... A>Вот что я надумал когда-то давно, и, по-моему, надумал правильно: A>Есть интерфейс Platform, который полностью скрывает работу с платформой. A>Есть класс Kernel, который реализует основной цикл. A>Внимание мысль: Kernel может находиться только в двух основных состояниях: запущен (Running) и стоит (Stopped), кроме того, у него в состоянии Running может быть еще одно этакое "подсостояние" Suspended.
зачем Suspended?.
A>Некая функция MAIN должна создать объект нужной платформы, создать и передать ссылку на платформу объекту Kernel. И передать управление какому-то методу run класса Kernel. Соответственно, Kernel перейдет из состояния Stopped в состояние Running. Platform имеет возможность перевести Kernel в состояние Suspended и Stopped. Ну, и соответственно какие-то другие классы могут Kernel ТОЛЬКО в состояние Stopped.
A>ТО Kernel — класс, реализующий основной цикл, получился платформонезависимым. A>Ну и как?
как я бы сделал а что то уже было
есть стартовая функция main, в которой основной цикл.. которая создает
я бы не стал делать один класс Platform, который работает с платформой, а вынес бы каждую деталь (видео, управление, звук, етк..) в одтельные классы.. они бы все вместе предоставляли некий API(вроде WTL) для работы всех остальных низкоуровневых классов..
Например, Graph, Input, Sound/Audio.. каждый из этих классов был бы оберткой над различными низкоуровневыми библиотеками..
почему несколько?. например OpenGL не дает работы со звуком.. нужно OpenAl или SDL например.. да и для управления какой нить glut.. это в DirectX удобно, а вдруг что..
можно сделать Kernel, но имхо это некритично.. Kernel будет содержать в себе Sound и Input..А Graph..
имхо можно сделать класс "Сцена"/View, которая будет содержать в себе Graph и сама обрабатывать всё видео..
потом вынести работу с этими классами в отдельные потоки, и аналогами Running, Stopped будут критические секции.. имхо полностью останавливать цикл, чтобы обработать всю новую инфу не стоит..
не знаю точно.. но можно было бы попробовать создать свою подсистему обработки высокоуровневых сообщений..
например, игрок ткнул на юнит, сообщение создалось (юнит ид, состояние: ткнут ), в главном цикле выбрали сообщение и передали в Graph и Sound.. юнит выделился и сказал что нибудь но это не для экшенов
Здравствуйте, alx771103, Вы писали:
A>Привет всем!
A>Я в этом деле новенький, но хотел бы (чиста, хобби) написать свой игровой движок... А идеи как это сделать — закончились...
A>Как бы так разбить движок на модули, чтобы при переходе на другую платформу не пришлось переписывать почти всё с нуля?..
A>Если есть идеи (или, еще лучше, проверенные идеи), пожалуйста, поделитесь...
Здравствуйте, neFFy, Вы писали:
FF>зачем Suspended?.
А, затем, чтобы, например, под Виндами, неактивное приложение не отъедало процессорное время.
FF>как я бы сделал а что то уже было FF>есть стартовая функция main, в которой основной цикл.. которая создает FF>я бы не стал делать один класс Platform, который работает с платформой, а вынес бы каждую деталь (видео, управление, звук, етк..) в одтельные классы.. они бы все вместе предоставляли некий API(вроде WTL) для работы всех остальных низкоуровневых классов.. FF>Например, Graph, Input, Sound/Audio.. каждый из этих классов был бы оберткой над различными низкоуровневыми библиотеками.. FF>почему несколько?. например OpenGL не дает работы со звуком.. нужно OpenAl или SDL например.. да и для управления какой нить glut.. это в DirectX удобно, а вдруг что..
Опять непонятка: до графики, звука, физики и логики я пока в своих разговорах не дошел... Это понятно, что графика, звук и т.д. и т.п. — отдельные модули. Опять же, некоторые классы этих модулей будут платформозависимы и связаны с Platform (для получения какой-то системной информации)...
FF>можно сделать Kernel, но имхо это некритично.. Kernel будет содержать в себе Sound и Input..А Graph..
Нет, нет и нет. Наверное, я объясняю как-то коряво ... Kernel содержит в себе основной цикл и всё... То есть, после запуска (пресловутый метод run), в его задачи входит вычислять (с использованием Platform, конечно) прирост времени (timeDelta) и запускать обновление каждого из модулей: Video, Audio, Physics, Logic, ... (последовательность неправильная)
FF>имхо можно сделать класс "Сцена"/View, которая будет содержать в себе Graph и сама обрабатывать всё видео.. FF>потом вынести работу с этими классами в отдельные потоки, и аналогами Running, Stopped будут критические секции.. имхо полностью останавливать цикл, чтобы обработать всю новую инфу не стоит..
А вот если правильно модули разработать, то и реализовать их можно в виде отдельных потоков (думал об этом, но не глубоко: смутно себе синхронизацию представляю)...
FF>не знаю точно.. но можно было бы попробовать создать свою подсистему обработки высокоуровневых сообщений.. FF>например, игрок ткнул на юнит, сообщение создалось (юнит ид, состояние: ткнут ), в главном цикле выбрали сообщение и передали в Graph и Sound.. юнит выделился и сказал что нибудь но это не для экшенов
FF>вот примерно моё видение.. вопросы принимаются
Здравствуйте, Аноним, Вы писали:
FF>>зачем Suspended?. А>А, затем, чтобы, например, под Виндами, неактивное приложение не отъедало процессорное время.
а оно вроде и так не должно отъедать..отрисовка точно не должна..
А>Опять непонятка: до графики, звука, физики и логики я пока в своих разговорах не дошел... Это понятно, что графика, звук и т.д. и т.п. — отдельные модули. Опять же, некоторые классы этих модулей будут платформозависимы и связаны с Platform (для получения какой-то системной информации)...
мне просто непонятен смысл создания Platform, который будет один(насколько я понял) работать с платформой..
FF>>можно сделать Kernel, но имхо это некритично.. Kernel будет содержать в себе Sound и Input..А Graph.. А>Нет, нет и нет. Наверное, я объясняю как-то коряво ...
нее.. это я не понимаю.. еще пара десятков сообщений и я соображу..
А>Kernel содержит в себе основной цикл и всё... То есть, после запуска (пресловутый метод run), в его задачи входит вычислять (с использованием Platform, конечно) прирост времени (timeDelta) и запускать обновление каждого из модулей: Video, Audio, Physics, Logic, ... (последовательность неправильная)
а как он будет обращаться к модулям для обновления?.
и вообще нафига целый класс с таким "сильным" названием, если он практически ничего не делает?.
FF>>потом вынести работу с этими классами в отдельные потоки, и аналогами Running, Stopped будут критические секции.. имхо полностью останавливать цикл, чтобы обработать всю новую инфу не стоит.. А>А вот если правильно модули разработать, то и реализовать их можно в виде отдельных потоков (думал об этом, но не глубоко: смутно себе синхронизацию представляю)...
Здравствуйте, neFFy, Вы писали:
FF>а оно вроде и так не должно отъедать..отрисовка точно не должна..
То есть как это не должно? Еще как отъедает... И если вовремя не оповестить тот же класс для работы с графикой (подрузамеваю винды) о том, что приложение стало неактивным, можно схватить немало ошибок в процессе отрисовки...
Уже не говоря об обстановке в игре: компьютерные вражины не будут знать о том, что надо подождать пока игрок вернется...
FF>мне просто непонятен смысл создания Platform, который будет один(насколько я понял) работать с платформой..
Не один: и графика, и звук, и пользовательский ввод будут тоже обращаться к платформе, но по-своему... Задача Platform обеспечить обмен сообщениями Kernel и ОС.
FF>а как он будет обращаться к модулям для обновления?.
Да метод какой-нибудь update вызывать с параметром...
FF>и вообще нафига целый класс с таким "сильным" названием, если он практически ничего не делает?.
А как? Тот самый while (Running) вложить в WinMain?
FF>а зачем останавливать весь основной цикл?.
Ну, то есть как это? Ведь у программы должен быть конец ...
Здравствуйте, alx771103, Вы писали:
FF>>а оно вроде и так не должно отъедать..отрисовка точно не должна.. A>То есть как это не должно? Еще как отъедает... И если вовремя не оповестить тот же класс для работы с графикой (подрузамеваю винды) о том, что приложение стало неактивным, можно схватить немало ошибок в процессе отрисовки...
девайс же отключается вроде..
A>Уже не говоря об обстановке в игре: компьютерные вражины не будут знать о том, что надо подождать пока игрок вернется...
я просто не сталкивался в виндах с проблемой остановки..
FF>>мне просто непонятен смысл создания Platform, который будет один(насколько я понял) работать с платформой.. A>Не один: и графика, и звук, и пользовательский ввод будут тоже обращаться к платформе, но по-своему... Задача Platform обеспечить обмен сообщениями Kernel и ОС.
например?.
FF>>а как он будет обращаться к модулям для обновления?. A>Да метод какой-нибудь update вызывать с параметром...
но все равно экземпляры классов будут принадлежать классу Kernel..
FF>>и вообще нафига целый класс с таким "сильным" названием, если он практически ничего не делает?. A>А как? Тот самый while (Running) вложить в WinMain?
а почему бы и нет?.
я, чтобы не загромождать main, выносил в отдельную функцию..
FF>>а зачем останавливать весь основной цикл?. A>Ну, то есть как это? Ведь у программы должен быть конец ...
Здравствуйте, alx771103, Вы писали:
FF>>девайс же отключается вроде.. A>Какой из них?
видео.. его потом и ресетить надо..
FF>>я просто не сталкивался в виндах с проблемой остановки.. A>ALT-TAB
всмысле у меня не продолжалось выполнение..
FF>>но все равно экземпляры классов будут принадлежать классу Kernel.. A>Не очень понял...
всмысле они у него будут членами..
FF>>а почему бы и нет?. FF>>я, чтобы не загромождать main, выносил в отдельную функцию.. A>Идея глобальных функций мне не очень нравится...
а идея создания одного класса, который по сути заменяет эту функцию и ничего больше не делает, лучше??.
функция сделана лишь для удобства.. и ничего крамольного я в этом не вижу..
Здравствуйте, neFFy, Вы писали:
FF>видео.. его потом и ресетить надо..
Это DirectX видимо... Ага, надо... А как ты определяешь момент, когда его надо ресетить?
FF>всмысле у меня не продолжалось выполнение..
Недостаток знаков препинания меня ввел в состояние ступора...
Попробуй так: запускаешь TaskManager, запускаешь прогу, даешь её немного поработать, затем ALT-TAB и в TaskManager смотришь...
FF>всмысле они у него будут членами..
Неее... у него указатели на интерфейсы... А классы — потомки интерфейсов... Причем интерфейс простой. Что-то типа:
class Process
{
public:
void update( Double ) = 0;
};
FF>функция сделана лишь для удобства.. и ничего крамольного я в этом не вижу..
Здравствуйте, alx771103, Вы писали:
A>Здравствуйте, neFFy, Вы писали:
FF>>видео.. его потом и ресетить надо..
A>Это DirectX видимо... Ага, надо... А как ты определяешь момент, когда его надо ресетить?
Здравствуйте, alx771103, Вы писали:
A>Здравствуйте, FR, Вы писали:
FR>>IDirect3DDevice9::TestCooperativeLevel
A>То есть, на каждый проход основного цикла такую проверку выполнять?
Здравствуйте, alx771103, Вы писали:
FR>>Да. A>То есть, если приложение теряет эксклюзивный уровень, ты приостанавливаешь работу и ждешь, пока уровень не восстановиться?
в некоторых игрушках его не восстанавливают вроде в Корсарах2 такое было.. на этом можно было читерить
A>Хорошо, а завтра тебе нужно будет переписать все под OGL и что будешь делать?
для этого и я предлагал работу с графикой обернуть во что нибудь свое.. чтобы можно было менять..
Здравствуйте, alx771103, Вы писали:
A>Недостаток знаков препинания меня ввел в состояние ступора... A>Попробуй так: запускаешь TaskManager, запускаешь прогу, даешь её немного поработать, затем ALT-TAB и в TaskManager смотришь...
запустил TaskManager, запустил StarCraft.. дал поработать.. нажал ALT-TAB и посмотрел в TaskManager.. тишина.. я опять что то не так сделал? надо попробовать с начальными проектами..
FF>>всмысле они у него будут членами.. A>Неее... у него указатели на интерфейсы... А классы — потомки интерфейсов... Причем интерфейс простой.
разница не критична.. кстати, а сами эти классы где будут созданы?.
но я всё равно не понял смысл создания класса для основного цикла..
FF>>функция сделана лишь для удобства.. и ничего крамольного я в этом не вижу.. A>Лучше: есть еще конструктор/деструктор ...
и что?.
ну каждому своё, но одна функция это всё таки не нарушение всех норм и канонов
Здравствуйте, neFFy, Вы писали:
FF>запустил TaskManager, запустил StarCraft.. дал поработать.. нажал ALT-TAB и посмотрел в TaskManager.. тишина.. я опять что то не так сделал? надо попробовать с начальными проектами..
То есть совсем тишина? Даже когда StarCraft крутился? Не может быть!..
FF>разница не критична.. кстати, а сами эти классы где будут созданы?.
Разница как раз очень критична: одно дело — объекты конечных классов (в которых через один — вызовы платформозависимых функций) и другое — указатели на объекты, причем создаются они снаружи, и передаются Kernel... Таже функция MAIN и может их создавать...
FF>но я всё равно не понял смысл создания класса для основного цикла..
Да вот я пятой точкой чувствую, что класс — правильно, а функция — нет... А словами объяснить не могу... Пусть это моим капризом будет, ОК?
Здравствуйте, neFFy, Вы писали:
FF>для этого и я предлагал работу с графикой обернуть во что нибудь свое.. чтобы можно было менять..
А что делать, если библиотека, под которую ты затачиваешь графику не предоставляет средств контроля потери уровня кооперации. Что, если ты не сможешь определить эксклюзивный у тебя уровень или нет?
Здравствуйте, alx771103, Вы писали:
A>Здравствуйте, FR, Вы писали:
FR>>Да.
A>То есть, если приложение теряет эксклюзивный уровень, ты приостанавливаешь работу и ждешь, пока уровень не восстановиться?
Лучше всего приостанавливать только расчет игры и отрисовку, цикл обработки сообщений должен крутится, ну и чтобы не кушало процессор сунуть Sleep(1)
A>Хорошо, а завтра тебе нужно будет переписать все под OGL и что будешь делать?
Переопределю одну виртуальную функцию.
Но дам совет, никогда ни делай фичи на "будущее" просто утонешь. Или сразу пиши хотя бы под пару целевых платформ или забудь о кроссплатформенности.
Здравствуйте, FR, Вы писали:
FR>Лучше всего приостанавливать только расчет игры и отрисовку, цикл обработки сообщений должен крутится, ну и чтобы не кушало процессор сунуть Sleep(1)
На мой взгляд, должен крутиться цикл обработки сообщений от платформы... А платформа решит, размораживать основной цикл или нет... А вызов Sleep, что он дает?
А звук тормозить не надо? А если что-то еще?
FR>Переопределю одну виртуальную функцию.
А как быть с эксклюзивностью-то по которой ты определаешь: спать или нет... У тебя, мне видится, одна из систем берет и тормозит все, когда её в голову взбредет... А если ты в разные потоки все пораскидаешь?
FR>Но дам совет, никогда ни делай фичи на "будущее" просто утонешь. Или сразу пиши хотя бы под пару целевых платформ или забудь о кроссплатформенности.
Я, наверное, очень неопытный еще... Но как количество платформ влияет на проектирование?
И какие, на твой взгляд, фичи я пытаюсь заложить на будущее?
Здравствуйте, alx771103, Вы писали:
A>Здравствуйте, FR, Вы писали:
FR>>Лучше всего приостанавливать только расчет игры и отрисовку, цикл обработки сообщений должен крутится, ну и чтобы не кушало процессор сунуть Sleep(1)
A>На мой взгляд, должен крутиться цикл обработки сообщений от платформы... А платформа решит, размораживать основной цикл или нет... А вызов Sleep, что он дает?
Sleep разгружает процессор когда процесс не активен.
Вообще помоему ты делаешь проблему там где ее нет. Основной цикл это доли процента в общем коде программмы (вот сейчас посмотрел около 100 строк) и проще переписать его для каждой платформы отдельно, особенно если платформы сильно разные.
A>А звук тормозить не надо? А если что-то еще?
Звук восстанавливать только надо, но это можно отдельно сделать вне цикла.
FR>>Переопределю одну виртуальную функцию.
A>А как быть с эксклюзивностью-то по которой ты определаешь: спать или нет... У тебя, мне видится, одна из систем берет и тормозит все, когда её в голову взбредет... А если ты в разные потоки все пораскидаешь?
Тормозит ни когда в голову взбредет а тогда когда нужно.
В разные потоки я раскидывать не буду, мне гемморой на пустом месте не нужен.
FR>>Но дам совет, никогда ни делай фичи на "будущее" просто утонешь. Или сразу пиши хотя бы под пару целевых платформ или забудь о кроссплатформенности.
A>Я, наверное, очень неопытный еще... Но как количество платформ влияет на проектирование?
A>И какие, на твой взгляд, фичи я пытаюсь заложить на будущее?
Мне показалось что ты хочешь писать под одну платформу а в будущем дописать — портировать на другие. Если тебе охота пройтись по всем граблям то именно так и делай. Иначе или пиши только под одну платформу или если действительно нужны несколько, пиши сразу под все, обязательно учитывая все их тонкости, и постоянно делая сборки и тесты под каждую.
Здравствуйте, alx771103, Вы писали:
FF>>запустил TaskManager, запустил StarCraft.. дал поработать.. нажал ALT-TAB и посмотрел в TaskManager.. тишина.. я опять что то не так сделал? надо попробовать с начальными проектами.. A>То есть совсем тишина? Даже когда StarCraft крутился? Не может быть!..
чесслово взял миссию, послал рабов работать, солдат драться.. переключился.. 0% CPU занято StarCraft'ом..
они наверное тестят CooperativeLevel.. поэтому я и хотел посмотреть на проекте, где рендеринг где нить на OnIdle
FF>>разница не критична.. кстати, а сами эти классы где будут созданы?. A>Разница как раз очень критична: одно дело — объекты конечных классов (в которых через один — вызовы платформозависимых функций) и другое — указатели на объекты, причем создаются они снаружи, и передаются Kernel... Таже функция MAIN и может их создавать...
примерно понял почему хочешь создать класс и почему интерфейсы передаются снаружи.. только имхо в этом смысла мало.. если бы количество этих интерфейсов было неизвестным, тогда бы я понял.. а так..
FF>>но я всё равно не понял смысл создания класса для основного цикла.. A>Да вот я пятой точкой чувствую, что класс — правильно, а функция — нет... А словами объяснить не могу... Пусть это моим капризом будет, ОК?
...coding for chaos...
Re[28]: Архитектура ИГРОВОГО движка
От:
Аноним
Дата:
22.06.06 10:37
Оценка:
Здравствуйте, FR, Вы писали:
FR>Sleep разгружает процессор когда процесс не активен.
Sleep, насколько я понял из MSDN, передает управление следующему потоку с таким же приоритетом. Если аргумент 0. Если не 0, то не передает управление данному потоку в течение какого-то времени... То есть, выполняться-то всё будет, просто с паузами... Или не так?
FR>Вообще помоему ты делаешь проблему там где ее нет. Основной цикл это доли процента в общем коде программмы (вот сейчас посмотрел около 100 строк) и проще переписать его для каждой платформы отдельно, особенно если платформы сильно разные.
Да я уже тоже смотрю: всё переливаем из пустого в порожнее... Перехожу на другую тему.
FR>Звук восстанавливать только надо, но это можно отдельно сделать вне цикла.
То есть опять, если у нас отобрали какой-то уровень кооперативности, то надо восстанавливаться?
FR>В разные потоки я раскидывать не буду, мне гемморой на пустом месте не нужен.
В идеале-то было бы хорошо: основной цикл в одном потоке, сервер — в другом, графика — в третьем... Вот только для меня остается загадкой как синхронизировать это все... Мысли-то есть, но боюсь они совсем ламерские...
FR>Мне показалось что ты хочешь писать под одну платформу а в будущем дописать — портировать на другие. Если тебе охота пройтись по всем граблям то именно так и делай. Иначе или пиши только под одну платформу или если действительно нужны несколько, пиши сразу под все, обязательно учитывая все их тонкости, и постоянно делая сборки и тесты под каждую.
Может быть и так... Ладно, оставим и эту тему пока.
А теперь, внимаение, вопрос:
Вот будет у меня Мир, в котором будет некоторое количество объектов. Объекты разные: есть издающие звуки, но невидимые; есть видимые, но не издающие звуки; есть объекты, которых не видно и не слышно; а есть те, которые и видны и слышны. Как лучше сделать:
Способ 1. Классы объектов наследовать от интерфейсов (например, iVisible, iAudible), а интерфейсы эти регистрируют указатели на объекты в соответствующей службе визуализации или вывода звука. Когда приходит время обновить экран, служба вывода видео пробегает свой список указателей на объекты, выделяет объекты, видимые в данный момент, и по полученным от интерфейса данным выводит всё на экран.
Или
Способ 2. Каждая служба пробегает список всех объектов, проверяет, надо ли ей с объектом работать и, если надо, работает.
Здравствуйте, Аноним, Вы писали:
А>Вот будет у меня Мир, в котором будет некоторое количество объектов. Объекты разные: есть издающие звуки, но невидимые; есть видимые, но не издающие звуки; есть объекты, которых не видно и не слышно; а есть те, которые и видны и слышны. Как лучше сделать: А>Способ 1. Классы объектов наследовать от интерфейсов (например, iVisible, iAudible), а интерфейсы эти регистрируют указатели на объекты в соответствующей службе визуализации или вывода звука. Когда приходит время обновить экран, служба вывода видео пробегает свой список указателей на объекты, выделяет объекты, видимые в данный момент, и по полученным от интерфейса данным выводит всё на экран. А>Или А>Способ 2. Каждая служба пробегает список всех объектов, проверяет, надо ли ей с объектом работать и, если надо, работает. А>Как лучше?
имхо способ 3..
пробегает по всем и просит рисоваться.. кто хочет, тот рисуется.. каждый отвечает за себя..
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, FR, Вы писали:
FR>>Sleep разгружает процессор когда процесс не активен.
А>Sleep, насколько я понял из MSDN, передает управление следующему потоку с таким же приоритетом. Если аргумент 0. Если не 0, то не передает управление данному потоку в течение какого-то времени... То есть, выполняться-то всё будет, просто с паузами... Или не так?
Sleep я предлагал использовать только тогда когда программа не активна, чтобы не грузился процессор.
FR>>Звук восстанавливать только надо, но это можно отдельно сделать вне цикла.
А>То есть опять, если у нас отобрали какой-то уровень кооперативности, то надо восстанавливаться?
Со звуком могу соврать, очень давно с DirectSound не работал.
FR>>В разные потоки я раскидывать не буду, мне гемморой на пустом месте не нужен.
А>В идеале-то было бы хорошо: основной цикл в одном потоке, сервер — в другом, графика — в третьем... Вот только для меня остается загадкой как синхронизировать это все... Мысли-то есть, но боюсь они совсем ламерские...
Ничего кроме лишней головной боли не получишь. Выносить в другие потоки можно ассинхроную загрузку, обработку звуковых буферов, и обработку DirectInput, и опционально некторые длительные расчеты, все остальное лучше держать в основном потоке.
А>А теперь, внимаение, вопрос:
А>Вот будет у меня Мир, в котором будет некоторое количество объектов. Объекты разные: есть издающие звуки, но невидимые; есть видимые, но не издающие звуки; есть объекты, которых не видно и не слышно; а есть те, которые и видны и слышны. Как лучше сделать:
А>Способ 1. Классы объектов наследовать от интерфейсов (например, iVisible, iAudible), а интерфейсы эти регистрируют указатели на объекты в соответствующей службе визуализации или вывода звука. Когда приходит время обновить экран, служба вывода видео пробегает свой список указателей на объекты, выделяет объекты, видимые в данный момент, и по полученным от интерфейса данным выводит всё на экран.
А>Или
А>Способ 2. Каждая служба пробегает список всех объектов, проверяет, надо ли ей с объектом работать и, если надо, работает.
А>Как лучше?
Вообще (если игра не простенькая) объекты обычно содержатся не в простых списках, а в более сложной структуре называемой scene graph, обычно это древообразная структура учитывающая пространственное расположение объектов.
Смотри тут http://www.gamedev.ru/terms/SceneGraph и в поиск.
Здравствуйте, neFFy, Вы писали:
FF>пробегает по всем и просит рисоваться.. кто хочет, тот рисуется.. каждый отвечает за себя..
А как?
3.1. В основном цикле пробегаем все объекты и просим посчитать физику, отрисоваться, подать голос, потом к следующему и т.д.?
или
3.2. В основном цикле говорим физике: "Пробегись по объектам и посчитай!", а она, в свою очередь к объектам: "Вы посчитаться не хотите?" и те, если надо, считаются... Потом также с рисовальщиком, пищалкой и т.д.?
А что делать, если завтра нужно будет какой-то класс объекта новый добавить? — А он ведь и будет знать, что ему делать...
А что делать, если измениться, допустим, звуковая платформа? — А у нее по-любому прокладочка есть высокоуровневая...
Вот оно: а что, если завтра появится некая фича, позволяющая эмулировать запахи... Как функциональность добавлять будешь?
Здравствуйте, FR, Вы писали:
FR>Sleep я предлагал использовать только тогда когда программа не активна, чтобы не грузился процессор.
Из MSDN:
Therefore, if you have a thread that creates windows, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than Sleep.
FR>Ничего кроме лишней головной боли не получишь. Выносить в другие потоки можно ассинхроную загрузку, обработку звуковых буферов, и обработку DirectInput, и опционально некторые длительные расчеты, все остальное лучше держать в основном потоке.
В идеале, если есть несколько объектов, которые могут работать параллельно, например, звук, физика, графика, даже обработка пользовательского ввода, нужно, чтобы они работали параллельно... Но это на мой взгляд... Ладно, пока эту тему тоже оставим...
FR>Вообще (если игра не простенькая) объекты обычно содержатся не в простых списках, а в более сложной структуре называемой scene graph, обычно это древообразная структура учитывающая пространственное расположение объектов. FR>Смотри тут http://www.gamedev.ru/terms/SceneGraph и в поиск.
Посмотрел, почитал... Не очень понял... Если не жалко — объясни пожалуйста некоторые вопросы...
Здравствуйте, alx771103, Вы писали:
A>Здравствуйте, FR, Вы писали:
FR>>Sleep я предлагал использовать только тогда когда программа не активна, чтобы не грузился процессор.
A>Из MSDN:
A>
A>Therefore, if you have a thread that creates windows, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than Sleep.
FR>>Вообще (если игра не простенькая) объекты обычно содержатся не в простых списках, а в более сложной структуре называемой scene graph, обычно это древообразная структура учитывающая пространственное расположение объектов. FR>>Смотри тут http://www.gamedev.ru/terms/SceneGraph и в поиск.
A>Посмотрел, почитал... Не очень понял... Если не жалко — объясни пожалуйста некоторые вопросы...
Я как вопрос в начале прочитал — так и сел... Но, не важно.
Как у себя сделал я:
Из основного цикла вызывается Platform::update( timeDelta, waitFlag ). waitFlag — флаг, говорящий платформе, надо ли ждать сообщения о об активации приложения. Если цикл НЕ находится в состоянии ожидания (тот самый Suspended), то waitFlag = false и платформа использует PeekMessage. Если же цикл в состоянии ожидания, то в зависимости от того, запущен ли сервер выделенно (dedicated), waitFlag может быть true. Если сервер не выделенный, то true, и платформа использует уже GetMessage и вне зависимости от того, какие сообщения проходят, ждет сообщения об активации приложения. И только после этого возвращает управление в цикл.
FR>??
Правильны ли следующие утверждения?
1. Граф сцены (блин, звучит как очень "не очень" ) — способ хранения объектов, и придуман для оптимизации всяких там поворотов и переключения состояний рисовальщика.
2. Размещение узлов в дереве может производиться с учетом их пространственного положения для оптимизации и отсечения каких-либо объектов.
3. В процессе выполнения, связи между узлами могут разрушаться и создаваться новые.
A>Я как вопрос в начале прочитал — так и сел... Но, не важно.
A>Как у себя сделал я:
A>Из основного цикла вызывается Platform::update( timeDelta, waitFlag ). waitFlag — флаг, говорящий платформе, надо ли ждать сообщения о об активации приложения. Если цикл НЕ находится в состоянии ожидания (тот самый Suspended), то waitFlag = false и платформа использует PeekMessage. Если же цикл в состоянии ожидания, то в зависимости от того, запущен ли сервер выделенно (dedicated), waitFlag может быть true. Если сервер не выделенный, то true, и платформа использует уже GetMessage и вне зависимости от того, какие сообщения проходят, ждет сообщения об активации приложения. И только после этого возвращает управление в цикл.
Наверно можно и так, но смотри чтобы не наткнутся на баг из ссылки очень неприятная вещь.
FR>>??
A>Правильны ли следующие утверждения?
A>1. Граф сцены (блин, звучит как очень "не очень" ) — способ хранения объектов, и придуман для оптимизации всяких там поворотов и переключения состояний рисовальщика.
да, хотя не только рисовальщика, но еще и бывает проверки пересечений и физики
A>2. Размещение узлов в дереве может производиться с учетом их пространственного положения для оптимизации и отсечения каких-либо объектов.
Не всегда, иногда используется некторое логическое родство, хотя пространственность тоже всегда учитывается.
A>3. В процессе выполнения, связи между узлами могут разрушаться и создаваться новые.
Обычно да. Но бывают и статические варианты и варианты с двумя графами в одном статика в другом динамика.
Здравствуйте, alx771103, Вы писали:
FF>>пробегает по всем и просит рисоваться.. кто хочет, тот рисуется.. каждый отвечает за себя.. A>А как? A>3.1. В основном цикле пробегаем все объекты и просим посчитать физику, отрисоваться, подать голос, потом к следующему и т.д.?
если есть возможность, то можно и так.. только вроде возможность такую создать немного проблематично..
A>3.2. В основном цикле говорим физике: "Пробегись по объектам и посчитай!", а она, в свою очередь к объектам: "Вы посчитаться не хотите?" и те, если надо, считаются... Потом также с рисовальщиком, пищалкой и т.д.?
угу.. только тут надо всё это синхронизировать..
A>А что делать, если завтра нужно будет какой-то класс объекта новый добавить? — А он ведь и будет знать, что ему делать... A>А что делать, если измениться, допустим, звуковая платформа? — А у нее по-любому прокладочка есть высокоуровневая... A>Вот оно: а что, если завтра появится некая фича, позволяющая эмулировать запахи... Как функциональность добавлять будешь?
добавлю в базовый класс для всех метод virtual void Smell(); и переопределю у тех, кому надо..
Здравствуйте, Георгиевич, Вы писали:
A>>Я в этом деле новенький, но хотел бы (чиста, хобби) написать свой игровой движок... А идеи как это сделать — закончились...
Г>3D Engines List
Г>Source Forge 3D Engine Search
Г>
За ссылки спасибо, но при чем здесь трехмерная графика?
Здравствуйте, Erik_, Вы писали:
E_>Здравствуйте, alx771103, Вы писали:
A>>Как бы так разбить движок на модули, чтобы при переходе на другую платформу не пришлось переписывать почти всё с нуля?..
E_>Прежде всего нужно полностью абстрагироваться от операционной системы. Это можно сделать с помощью специальных библиотек, у которых есть порты на многие операционные системы. Например, стандартная библиотека С++, Boost и пр.
абстрагироваться не получиться. абстракция на уровне файлов — явно не достаточно
можно, конечно, юзать коммерческие специализированные библиотеки, но все равно платформозависимые вещи обязательно вылезут
для тетриса, конечно, вряд ли, а вот большой проект...
на вскидку — многопоточность на тех или иных платформах (те же PС,XBOX, PS3), или UI на консолях.
в этом деле главное — грамотно выделить платформозависимую часть, чтобы при переносе переписывать не всю игру, а только отдельные модули.
(вряд ли вам это надо, но boost стараются не использовать в реальных игровых проектах)
Не все в этом мире можно выразить с помощью нулей и единиц...
Здравствуйте, neFFy, Вы писали:
FF>Здравствуйте, FR, Вы писали:
A>>>По-моему, с этого начинать и не надо: Платформазависим — налево, независим — направо... От того, на какой платформе реализуется, платформонезависимый код не становиться зависимым... FR>>Я не понял ты хочешь писать платформонезависимый код только под одну платформу? Если так то сразу скажу ничего кроме потери времени не получишь, при реальном портировании всплывут такие проблемы которые ты и представить не мог, и в тоже время многие вещи будут неоправданно усложнены.
FF>+1 FF>хорошо бы еще создать проектик, реализующий работу с платформой по минимуму, и прописать его под несколько доступных платформ.. от результата и идти..
ну, тут человек явно не ставит целью одти от результата, — скорее теоритезировать о сферических конях...
Не все в этом мире можно выразить с помощью нулей и единиц...
) (подсказка для поиска software.engineering.and.computer.games.chm), другой пример более ограниченный и конкретный "Strategy Game Programming with DirectX 9.0" Todd Barron (Wordware Publishing — Strategy Game Programming With Directx 9.0 2003.chm).
как платформа может влиять на работу ядра, если все низкоуровневые вещи вынесены в отдельные модули?. 
... Мне хочется знать, стоит ли оборачивать во что-то свое дисковый ввод-вывод?
