Пятница, 19 Апреля 2024, 12:24

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 2 из 2
  • «
  • 1
  • 2
Форум игроделов » Программирование » C/C++ » Написание простого игрового движка (C++;DirectX)
Написание простого игрового движка
AkopovДата: Воскресенье, 18 Мая 2014, 01:27 | Сообщение # 21
заслуженный участник
Сейчас нет на сайте
Цитата Saitei ()
mlpmmo, ну, если себе поставить чётко цель то всё возможно. Года 4 назад я считал идею "своего движка" проигрышной, думал что написать свой невозможно. Ошибался. Теперь мне куда удобнее писать и использовать "своё"
Хотя если человек не хочет прокачивать скилл программиста по-максимуму, а хочет игру, тогда да, надо брать готовые движки\конструкторы)

Saitei, не сочти за оскорбление (а возможно я просто чего-то не знаю про твой двиг), но единственный твой двиг который я заметил (а тонее даже не двиг, а исходник), это двиг под змейку. Заранее пршу прощения если я не прав.
З.Ы. Сам много раз пытался выучить яп, а не пользваться конструкторами, но я- лошара, не имеющая терпения. потому я уважаю любой труд программиста, и любое его стремление, так что Cazza144, удачи тебе smile
RostakaGmfunДата: Воскресенье, 08 Июня 2014, 20:00 | Сообщение # 22
был не раз
Сейчас нет на сайте
Посмотри здесь

GitHub
Блог
XakepДата: Понедельник, 09 Июня 2014, 01:00 | Сообщение # 23
めちゃくちゃちゃ
Сейчас нет на сайте
Цитата Akopov ()
Saitei, не сочти за оскорбление (а возможно я просто чего-то не знаю про твой двиг), но единственный твой двиг который я заметил (а тонее даже не двиг, а исходник), это двиг под змейку. Заранее пршу прощения если я не прав.

змейку он писал для изучения ассемблера, потому и в консоли, подобные знания очень пригодятся в будущем, без разницы что писать будешь, свой двиг, или просто программу, хорошее понимание того, как работает память в компьютере и в принципе как работает программа, дают программисту новый взгляд на все что он пишет, и код становится естественно намного чище, правда бывает и доходит до фанатизма, типа пишут свои аллокаторы памяти и прочее ))
antonyvolkoffДата: Понедельник, 09 Июня 2014, 01:43 | Сообщение # 24
был не раз
Сейчас нет на сайте
Цитата Xakep ()
доходит до фанатизма, типа пишут свои аллокаторы памяти и прочее

Аллокаторы не только фанатики пишут, но и те, которым скорость malloc/new мала.
По теме, простой движок это не движок, а больше фреймворк или большой костыль.
SFML, HGE, Angel2D, WindMill, DGLE - они, вроде, с открытыми исходными кодами.
Хотя они больше фреймворки, чем игровые движки.


Сообщение отредактировал antonyvolkoff - Понедельник, 09 Июня 2014, 01:51
OrdanДата: Понедельник, 09 Июня 2014, 02:38 | Сообщение # 25
Главный зомби
Сейчас нет на сайте
Гораздо больше профита изучая все самому без исходников + гугл, еслиб ты хотел писать на опенГл яб мог скинуть немного кода вывода графики.

Цитата недели: Из-за леса, из-за гор, кишки, месиво, хардкор. (Берсерк ТВ-2)

Мои проекты ТЫК
Мои видяхи на ютубэ ТЫК

Если ты споришь с идиотом, вероятно тоже самое делает и он.
XakepДата: Понедельник, 09 Июня 2014, 03:05 | Сообщение # 26
めちゃくちゃちゃ
Сейчас нет на сайте
Цитата antonyvolkoff ()
Аллокаторы не только фанатики пишут, но и те, которым скорость malloc/new мала.

а ты думаешь как выделается память когда пишутся свои аллокаторы? все тем же malloc/new, только выделяется сразу болльшой блок памяти, и уже его используют для быстрого "выделения". В большенстве случаев, производительность зависит от алгоритма, если уж мало производительности от malloc, то просто напросто нужно подумать как организовать правильно выделение, а не страдать ерундой, и писать свои аллокаторы памяти. В последнем случае, скорее всего будет очень много ошибок и утечек памяти, из-за малейшей ошибки в коде, и потом думай гадай, где же ты допустил ошибку, а конце концов оказывается, что это вообще из-за собственного аллокатора памяти.
ArchidoДата: Вторник, 10 Июня 2014, 20:53 | Сообщение # 27
Сэнсэй
Сейчас нет на сайте
Цитата Xakep ()
а ты думаешь как выделается память когда пишутся свои аллокаторы? все тем же malloc/new, только выделяется сразу болльшой блок памяти, и уже его используют для быстрого "выделения". В большенстве случаев, производительность зависит от алгоритма, если уж мало производительности от malloc, то просто напросто нужно подумать как организовать правильно выделение, а не страдать ерундой, и писать свои аллокаторы памяти. В последнем случае, скорее всего будет очень много ошибок и утечек памяти, из-за малейшей ошибки в коде, и потом думай гадай, где же ты допустил ошибку, а конце концов оказывается, что это вообще из-за собственного аллокатора памяти.

Ну как же ты так - взял все ерундой обозвал smile

В винде, например, вызов malloc \ new дергает HeapAlloc, а тот в свою очередь VirtualAlloc и "выделение памяти" делается в kernel mode, происходит переключение т.н. контекстов, что не бесплатно совсем. Т.е. переключать контекст на каждый чих при необходимости выделить память - это полнейший rock'n'roll, так делать не красиво. Многие делают пулы и правильно делают, правда они и представляет собой вообщем-то простейший локальный аллокатор (а группа таких пулов представляет собой некий децентрализованный глобальный аллокатор).

Глобальные аллокаторы делают в основном не из-за проблем со скоростью выделения памяти (т.к. это можно и без них решить, локально), а из-за проблем с чрезмерной фрагментацией. ОС аллокатор будет тупо выделять блок за блоком (большой после маленького и наоборот), в результате через какое-то время после циклов выделения \ удаления: памяти не останется совсем, точнее она то будет, но сильно фрагментированная и размазанная по всему возможному диапазону.
Свой аллокатор позволяет сделать несколько различных стратегий выделения памяти (для маленьких и больших объектов, частого \ нечастого выделения, раз в кадр, etc) и выбирать конкретную стратегию на основе определенных факторов, вроде размера или некоего доп. флажка, где вы явно подсказываете аллокатору что выбрать, т.к. знаете что лучше будет работать для объектов данного типа, и т.д. В добавок, в критических местах, можно использовать двойные указатели и научить аллокатор делать дефрагментацию в отдельном потоке. Правда это все, скорее уже менеджер памяти, а не просто какой-то там аллокатор smile
Как бонус - инфа (статистика) о кол-ве используемой, выделенной, фрагментированной памяти, о размерах выделенных блоков (или объектов), etc. Что весьма полезно и позволяет в дальнейшем производить коррекцию.

Само собой все это - не панацея и делать такое имеет смысл только тогда, когда это реально нужно. Скажем, для "тетриса" и ПК с 12ГБ ОЗУ можно и забить, а вот например все крупные игры для Xbox 360 без своего менеджера памяти не обходятся, ибо с 512мб шибко с фрагментацией там не разгуляешься. К мобильным платформам это тоже относится.

P.S. А еще часто пригождаются т.н. "выравнивающие" аллокаторы smile


C++ - он особенный. С помощью него можно не только выстрелить себе в ногу, но и повеситься в пустой комнате:)
OrdanДата: Среда, 11 Июня 2014, 02:24 | Сообщение # 28
Главный зомби
Сейчас нет на сайте
Эй эй эй, а ну прекратили флудерастить в теме smile лучшеб помогли кодом или советом ТСу.

Цитата недели: Из-за леса, из-за гор, кишки, месиво, хардкор. (Берсерк ТВ-2)

Мои проекты ТЫК
Мои видяхи на ютубэ ТЫК

Если ты споришь с идиотом, вероятно тоже самое делает и он.
-l33t-h4xx-Дата: Среда, 11 Июня 2014, 11:09 | Сообщение # 29
участник
Сейчас нет на сайте
А что ему помогать, он создал тему месяц назад и смылся.

Как правильно задавать вопросы
Форум игроделов » Программирование » C/C++ » Написание простого игрового движка (C++;DirectX)
  • Страница 2 из 2
  • «
  • 1
  • 2
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг