Переехал на другой сайт Developing Games and Game Engine on Delphi, OpenGL, OpenAL и форум Общение о разработке игр и игровых движков на Delphi и OpenGL
Идёт неспешный процесс. Текущая версия - 0.13:)
Объём кода превысил 2.5 Мега. Освоил SVN
Понимая, что в любом уважающем себя редакторе есть "progressive mesh" и с ручной правкой он красивее, всё равно сделал автоматическое создание progressive mesh. Получил небольшой плюс: один буфер вершин (данные в буфере вершин не меняются).
Сделал пока безшейдерный SkyDome


Объём кода превысил 2.5 Мега. Освоил SVN
Понимая, что в любом уважающем себя редакторе есть "progressive mesh" и с ручной правкой он красивее, всё равно сделал автоматическое создание progressive mesh. Получил небольшой плюс: один буфер вершин (данные в буфере вершин не меняются).
Сделал пока безшейдерный SkyDome
Это творчество ЖЖ: "Запрещаю воспроизводить в какой-либо форме", а не моё:)
IMHO
Я - не волшебник, я только учусь:) В связи с этим технологии глобального стриминга (грузим копию всей оперативки и потом расставляем указатели) для меня пока недоступны и решение я ищу без их использования.
Я - "язычник". Пишу на Delphi и так как это типизированный язык, где тип должен быть определён в момент compile time, то некоторые красивые решения для нетипизированных языков для меня тоже неприемлемы.
( Ничего нового ниже нет, всё это рассказывали aruslan, ddima, Plakhov и IronPeter. )
Ну не надо считать ссылки в любом варианте.
Я - не волшебник, я только учусь:) В связи с этим технологии глобального стриминга (грузим копию всей оперативки и потом расставляем указатели) для меня пока недоступны и решение я ищу без их использования.
Я - "язычник". Пишу на Delphi и так как это типизированный язык, где тип должен быть определён в момент compile time, то некоторые красивые решения для нетипизированных языков для меня тоже неприемлемы.
( Ничего нового ниже нет, всё это рассказывали aruslan, ddima, Plakhov и IronPeter. )
Ну не надо считать ссылки в любом варианте.
Текущую версию движка выложил на ... , в svn залита более старая версия.
Обсуждение здесь.
Алгоритм обучения стал более красивым, и кажется удаётся добиться почти линейности и при обучении и при эксплуатации.
Обсуждение здесь.
Алгоритм обучения стал более красивым, и кажется удаётся добиться почти линейности и при обучении и при эксплуатации.
Текущий билд http://webfile.ru/2027684
+ sound from Duncon
+ sound from Duncon
Купил сразу как вышла, а время прочитать нашёл намного позже, а жалко. Ожидал красивых лозунгов, оказалось с точностью наоборот. Будет моей настольной книгой. Понятно и доходчиво, с выводами и примерами.
И это тоже не помешает знать Опечатки в книге Саймона Хайкина "Нейронные сети: полный курс". С одной опечаткой сам разбирался:)
Искусственный интеллект в компьютерных играх. Как обучить виртуальные персонажи реагировать на внешние воздействия
Прочитал, после предыдущей было просто смешно. Интересно было только про конечный автомат для эмоций.
Прочитал статью http://blog.gamedeff.com/?p=62 на gamedeff.com, пришёл в восхищение, давно планировал реализовать хеширование в своём двиге и вот гуру рассказали оптимальный алгоритм. Поскольку я - «язычник», то писать самому, вот я и написал…
К сожалению, я не представляю, как это запостить здесь, поэтому в pdf - http://webfile.ru/2022461 , все исходники тестов: http://webfile.ru/2022472
Вывод:
- для работы с алгоритмом Cuckoo hash необходимо две хорошие хеш-функции, без них метод не работает;
- лучшей реализацией является Noline hash. Код реализации приведён в приложении.
К сожалению, я не представляю, как это запостить здесь, поэтому в pdf - http://webfile.ru/2022461 , все исходники тестов: http://webfile.ru/2022472
Вывод:
- для работы с алгоритмом Cuckoo hash необходимо две хорошие хеш-функции, без них метод не работает;
- лучшей реализацией является Noline hash. Код реализации приведён в приложении.
После длинных и для меня плодотворных обсуждений в Cайт разработчиков игр покинул данное сообщество.
Случайно обнаружил что русские буквы в моём блоге популярнее английских (статьи против кода движка), решил добавить русских букв. В связи с этим поднял старые заметки, добавил ещё столько же - результат перед Вами: Общая концепция Game Engine (проект статьи). В случае если я нарушаю чьи-то авторские права, то прошу сообщить, внесу изменения.
В статье рассмотрены основные принципы создания игровых движков.
Общая концепция Game Engine - http://webfile.ru/1945556
В статье рассмотрены основные принципы создания игровых движков.
Общая концепция Game Engine - http://webfile.ru/1945556
Сделал GUI. Так что, теперь реализовал и Immediate Mode GUI и Retained Mode GUI (в первой версии и без редактора)

Full - http://webfile.ru/1920766
Src, data - http://webfile.ru/1920767
Full - http://webfile.ru/1920766
Src, data - http://webfile.ru/1920767
Есть три варианта:
1. Загрузка и предварительная подготовка объекта в объекте
2. Загрузка и предварительная подготовка объекта в менеджере
3. Загрузка и предварительная подготовка объекта в отдельном классе
( Read more... )
Сравнение вариантов:
1 вариант
+ Самый простой. Создаём универсальный класс всё
+ Менеджер можем даже и не создавать.
- При любом изменении загрузчика или создания нового необходимо лезть в основной класс
2 вариант
- класс может работать только в паре с менеджером.
- на каждый класс надо делать свой класс-менеджер и затем создавать данный объект-менеджер.
- При любом изменении загрузчика или создания нового необходимо лезть в менеджер
3 вариант
- сложность понимания концепции
+ разделение функциональности по классам
+ При любом изменении загрузчика или создания нового не изменяются базовые классы
+ Менеджер можно и не создавать либо сделать один на всё универсальный
Поэтому, мой вывод: если делаем учебную программу, то первый вариант (всё сваливаем в один класс), а если универсальный пакет, то третий вариант.
1. Загрузка и предварительная подготовка объекта в объекте
2. Загрузка и предварительная подготовка объекта в менеджере
3. Загрузка и предварительная подготовка объекта в отдельном классе
( Read more... )
Сравнение вариантов:
1 вариант
+ Самый простой. Создаём универсальный класс всё
+ Менеджер можем даже и не создавать.
- При любом изменении загрузчика или создания нового необходимо лезть в основной класс
2 вариант
- класс может работать только в паре с менеджером.
- на каждый класс надо делать свой класс-менеджер и затем создавать данный объект-менеджер.
- При любом изменении загрузчика или создания нового необходимо лезть в менеджер
3 вариант
- сложность понимания концепции
+ разделение функциональности по классам
+ При любом изменении загрузчика или создания нового не изменяются базовые классы
+ Менеджер можно и не создавать либо сделать один на всё универсальный
Поэтому, мой вывод: если делаем учебную программу, то первый вариант (всё сваливаем в один класс), а если универсальный пакет, то третий вариант.
Цель данной статьи рассказать об одном возможном подходе к созданию самообучающихся персонажей (NPC) в играх. В статье рассмотрена теоретическая основа для создания самообучающихся персонажей и предложен вариант реализации.
Статья - http://webfile.ru/1829984
Демо - http://webfile.ru/1829991
Статья - http://webfile.ru/1829984
Демо - http://webfile.ru/1829991
Закончил demo6. Синий (обучаемый) выиграл!!!
Стандартные алгоритмы аппроксимации для данного типа задач не применимы.
Стандартные алгоритмы аппроксимации для данного типа задач не применимы.
http://webfile.ru/1749849
Алгоритм красного везде одинаковый. Бежим к мячу, не тормозим, из-за дискретности направлений можем промазать, потом вернёмся.
0. Алгоритм синего = алгоритму красного
1. Размерность пространства - 2. Кусочно-постоянная аппроксимация. Разбиение на два участка по каждой оси. Достаточно часто застревает в локальном оптимуме, не достигая глобального для данной аппроксимации.
2. Для синего жёстко зашито одно из решений синего из демо1. Можно написать другой алгоритм и сравнить с красным.
3. Размерность пространства - 10, 12. Кусочно-постоянная аппроксимация. Разбиение на десять участков по каждой оси. Тупая реализация полиномиально сложной задачи. Решение не может быть найдено за разумное время.
4. Размерность пространства -2. Линейная аппроксимация. Так как решение нелинейное (резкий скачёк в районе мяча), то лобовая реализация на всё пространство находит решение – стоять на месте. Сделано разбиение на четверти и решение ищется в каждой четверти. Ожидал, что будет найдена технология красного, но ожидания не сбылись.
5. Размерность пространства - 10, 12. Линейная аппроксимация в четырёх зонах. Решение существенно не отличается. В процессе поиска видны области разных направлений.
6. Размерность пространства -2. Аппроксимация радиально-базисными функциями (машина опорных векторов) http://en.wikipedia.org/wiki/Radial_bas is_function . Пока демо незакончено. Решение вероятнее всего будет хуже чем в линейной демо, но объём вычислений при увеличении размерности практически не увеличивается.
Выводы:
1. На тестируемом примере алгоритм показал возможность поиска оптимума.
2. На тестируемом примере качество найденных решений низкое.
Todo: с RBF продолжить. Должно быть лучше.
Алгоритм красного везде одинаковый. Бежим к мячу, не тормозим, из-за дискретности направлений можем промазать, потом вернёмся.
0. Алгоритм синего = алгоритму красного
1. Размерность пространства - 2. Кусочно-постоянная аппроксимация. Разбиение на два участка по каждой оси. Достаточно часто застревает в локальном оптимуме, не достигая глобального для данной аппроксимации.
2. Для синего жёстко зашито одно из решений синего из демо1. Можно написать другой алгоритм и сравнить с красным.
3. Размерность пространства - 10, 12. Кусочно-постоянная аппроксимация. Разбиение на десять участков по каждой оси. Тупая реализация полиномиально сложной задачи. Решение не может быть найдено за разумное время.
4. Размерность пространства -2. Линейная аппроксимация. Так как решение нелинейное (резкий скачёк в районе мяча), то лобовая реализация на всё пространство находит решение – стоять на месте. Сделано разбиение на четверти и решение ищется в каждой четверти. Ожидал, что будет найдена технология красного, но ожидания не сбылись.
5. Размерность пространства - 10, 12. Линейная аппроксимация в четырёх зонах. Решение существенно не отличается. В процессе поиска видны области разных направлений.
6. Размерность пространства -2. Аппроксимация радиально-базисными функциями (машина опорных векторов) http://en.wikipedia.org/wiki/Radial_bas
Выводы:
1. На тестируемом примере алгоритм показал возможность поиска оптимума.
2. На тестируемом примере качество найденных решений низкое.
Todo: с RBF продолжить. Должно быть лучше.
Справочник по теории автоматического управления. Под редакцией А. А. Красовского.
http://www.toroid.ru/krasovskiyAA.html
Круто. Если из этого справочника убрать все доказательства, 2/3 методов и поменять терминологию, то получится теория ИИ.
XProger, я нахожусь в процессе описания, того, что напрогил:)
http://www.toroid.ru/krasovskiyAA.html
Круто. Если из этого справочника убрать все доказательства, 2/3 методов и поменять терминологию, то получится теория ИИ.
XProger, я нахожусь в процессе описания, того, что напрогил:)