Придумать алгоритм пересечения игрока с пулей в игре

@Nik_33 · Регистрация: 24.02.2017

Всем привет! Если в кратце то нужно придумать алгоритм пересечения игрока с пулей. Существует массив PictureBox Игроков и аналогично пуль для каждого игрока. Вот пример этого алгоритма.

C#

        public void Shoting(Player[] player, int plCount, Player[] bot, int btCount)
        {
            for(int i = 0; i < plCount;i++)//Кол-во игроков
                for (int j = player[i].gun.CountBullet; j > player[i].gun.Collar; j--)//Обойма
                {
                    for (int k = 0; k < plCount; k++)
                    {
                        if (player[i].gun.bullet[j] != null)
                        {
                            Rectangle Rect = new Rectangle(player[k].pbplayer.Location, player[k].pbplayer.Size);
                            Rectangle Rect1 = new Rectangle(player[i].gun.bullet[j].pbBullet.Location, player[i].gun.bullet[j].pbBullet.Size);
                            Random dmg = new Random();
                            if ((Rect1.IntersectsWith(Rect)) && (i != k) && (player[k].live))
                            {
                                player[i].gun.bullet[j].Bullet_Delete(); player[k].health -= (dmg.Next(player[i].gun.Crit) + player[i].gun.Damage);
                            }
                        }
 
                    }
}

Этот алгоритм правильный, он работает, но он не рациональный. Дело в том что он зависит от количества игроков и постоянно в цикле бегает по всем игрокам. Игра тормозит когда игроков много. Нужно придумать что-то рациональней чтобы не бегать по всему массиву.Как вообще делаются подобные алгоритмы в играх? Очень интересно. Много искал на просторах интернета, но увы( В C# новичок - самоучка, очень жду помощи, вся надежда на вас. Всем добра

@Fulcrum_013 · 07.04.2017, 01:13

Nik_33, Тормозит скорее всего не алгоритм а шарп. распределение кучи и потом ее уборка сборщиком мусора довольно тормозные операции. у вас же в каждом проходе распределяется на куче 3 объекта. На плюсах в 3D при 100+ целях и 2000+ активных пуль у подобного алгоритма ни малейшего намека на тормоза. При этом пули и цели создаются один раз к примеру при выстреле и один же раз удаляются при попадании/вылете за пределы моделируемой области/взрыве и т.п. А координаты коллайдеров и пуль апдейтятся во время движения а не пересаздаются постоянно.

@Nik_33 · 07.04.2017, 20:41 **[ТС]**

Сообщение от Fulcrum_013

Тормозит скорее всего не алгоритм а шарп. распределение кучи и потом ее уборка сборщиком мусора довольно тормозные операции. у вас же в каждом проходе распределяется на куче 3 объекта. На плюсах в 3D при 100+ целях и 2000+ активных пуль у подобного алгоритма ни малейшего намека на тормоза. При этом пули и цели создаются один раз к примеру при выстреле и один же раз удаляются при попадании/вылете за пределы моделируемой области/взрыве и т.п. А координаты коллайдеров и пуль апдейтятся во время движения а не пересаздаются постоянно.

Такие проекты думаете лучше делать на c++?

Добавлено через 1 минуту

Сообщение от Fulcrum_013

При этом пули и цели создаются один раз к примеру при выстреле и один же раз удаляются при попадании/вылете за пределы моделируемой области/взрыве и т.п. А координаты коллайдеров и пуль апдейтятся во время движения а не пересаздаются постоянно.

Эту часть вообще не понял..

@TopLayer · 07.04.2017, 21:18

Сообщение от Fulcrum_013

в каждом проходе распределяется на куче 3 объекта

Я вижу только 1: Random. Причём он должен один раз создаваться до цикла или даже в начале программы, а у ТС ошибка.

Сообщение от Nik_33

Такие проекты думаете лучше делать на c++?

Лучше хорошо изучить хотя бы 1 язык программирования.

@Fulcrum_013 · 07.04.2017, 21:38

Сообщение от Nik_33

Такие проекты думаете лучше делать на c++?

C++ и DirectX. Ну по началу можно на какой то готовый движок взглянуть. К примеру на тот же юнити.
Кстати одна из причин тормозов может крыться в отрисовке через PictureBox. Далеко не самый быстрый способ отрисовки.

Сообщение от Nik_33

Эту часть вообще не понял..

Ну схема в кратце
такая:

C++

vector <TBullet> Bullets; 
vector <TCharacter> Player;
 
void TGun::Fire(){  // вызывается при выстреле;
       Bullets.emplace_back(BulletType,Dir*Speed,PlayerId);
}
void DynamicObject::Move(Time t){ // Object базовый класс для игрока и для пули и вообще для всех подвижных объектов.
      Position+=t*Velocity;
      CollisionBox+=t*Velocity;// считаем что есть перегруженный оператор который умеет сместить прямоугольник на заданный вектор
}
 
TPlayer::Collide(TBullet &Bullet){
      if (Collider.Intersect(Bullet.Collider)) Health-=Players[Bullet.PlayerId].Strength + // ну в общем как там жизня отнимается
}
 
TGame::Move(Time t){
       for(auto &Bullet:Bullets) Bullet.Move(t);
       for(auto &Player:Players) Player.Move(t);
 
       for(auto &Bullet:Bullets) 
            for(auto &Player:Players) Player.Collide(Bullet);
 
}

А вообще коллизии с пулями лучше считать как минимум рейкастом. А то при таких раскладах существует вероятность что они будут пролетать тонкие препятствия даже неподвижные насквозь.
Опять же многое зависит от того как игра организована. Если карта тайловая то можно в тайлах помечать какие персонажи/подвижные объекты в нем находятся и при полете просчитывать через какие тайлы она прошла и проверять пересечеия только с объектами зарегистрироваными в этих тайлах. Плюсы метода - очень быстрый отсев того с кем не пересечется. Минусы - фактически дробление шага по времени, плюс есть сложность что если объект занимает тайл не полностью при этом объект большой и пуля с ним не пересеклась сложно отсеять проверку с ним в следующем тайле, т.е возможен вариант когда с большми объектами пересечение будет проверяться неколько раз.
Строить же ннеравномерную сетку индексации имеет смысл только для неподвижных объектов. Для подвижных перестроение сетки скорее всего будет не быстрее чем перебор каждого с каждым. При этом пользуемый у вас алгоритм AABB коллизий настолько быстр что его пользуют для предотсечения - т.е. сначала сравнивая каждого с каждым таким алгоритмом а потом уже только для песекшихся проводят более сложные расчеты пересечения их геометрии.

Добавлено через 2 минуты
Опять же многое зависит от того насколько предсказуемо поведение цели. Если цель не управляется игроком и/или ИИ , т.е. не может самопроизвольно менять параметры своей траектории то попадет или нет и в какой момент времени попадет можно вычислить в момент выстрела.

Добавлено через 3 минуты
Если может но не существенно по отношению к скорости пули то можно вычислить с какого по какой момент времени (интервал в котором вероятно попадание)нужна проверка.

Добавлено через 2 минуты
Вообще задача столкновения подвижных объектов корректно решается только в 4D пространстве. Ну для 2D игры соответсвенно в 3D

Добавлено через 8 минут

Сообщение от TopLayer

Я вижу только 1: Random

А 2 Rectangle над ним?

Сообщение от TopLayer

Лучше хорошо изучить хотя бы 1 язык программирования

Да действительно. При этом хорошо чтобы и язык тебя ни в чем не ограничивал. Особенно для геймдева. А такой язык и существует только один. С++ называется.

@TopLayer · 07.04.2017, 21:52

Сообщение от Fulcrum_013

А 2 Rectangle над ним?

Это же структуры.

@Nik_33 · 07.04.2017, 21:53 **[ТС]**

Сообщение от Fulcrum_013

C++ и DirectX. Ну по началу можно на какой то готовый движок взглянуть. К примеру на тот же юнити.

Шарпом месяца 2-3 балуюсь какой юнити ребят) Опыта в таких проектах 0.0

Добавлено через 40 секунд

Сообщение от Fulcrum_013

Кстати одна из причин тормозов может крыться в отрисовке через PictureBox.

Есть способ обойтись без picturebox'а?

@TopLayer · 07.04.2017, 22:08

Не по теме:

Fulcrum_013, а вы, кстати, знаете почему эта программа на C# работает быстрее аналогичной программы на С++?

@Fulcrum_013 · 07.04.2017, 22:10

Сообщение от Nik_33

Есть способ обойтись без picturebox'а?

Unity, SFML. Хотя лучше сырые DirectX и OpenGL в них новичку разобраться проще будет. Матана меньше знать ннадо чтобы понять что там и зачем. Достаточно векторной алгебры и вычислительной геометрии. Но всю физику придется самому физичить. Ну зато придет понимание что там в принципе может быть под капотом оных юнитей. Вообще знание языка это не более 1% знаний нужных программисту особенно в плане геймдева, при этом все языки очень похожи (в любом случае все строится на вычислениях и условном переходе). все остальное - матан матфизика теомех сопромат гидрогазодинамика и т.д и т.п. Но язык нужно знать до такой степени чтобы на нем думать. Самому после двух лет работы на паскале включая два коммерческих проекта в свое время перейти на С++ было довольно сложно. Полная перестройка мышления заняла лет 5 не меньше.
Поэтому и говорю - чем раньше на плюсы переключитесь тем лучше, это именно так дикая огнедышущая кобылица которая нужна в геймдейве, при это освоить любой другой промышленный язык зная плюсы - вопрос прочтения мануала. Правда неумелых наездников сбросит затопчет и съест. Посему привыкать мыслить категориями этой штуки лучше чем раньше тем лучше.
Вообще игры это как ни крути а реалтаймовая задача. Ну скажем в следствие никакой ответсвенности расчетов околореалтаймовая (таки не станом прокатным крутить и не реактор ядерный качегарить), но тем не менее винда а особенно .Net для реалтаймовых задач не предназначены что у майкрософта чуть ли не на каждом заборе написано.

@Nik_33 · 07.04.2017, 22:14 **[ТС]**

Сообщение от Fulcrum_013

Unity, SFML. Хотя лучше сырые DirectX и OpenGL в них новичку разобраться проще будет. Матана меньше знать ннадо чтобы понять что там и зачем. Достаточно векторной алгебры и вычислительной геометрии. Но всю физику придется самому физичить. Ну зато придет понимание что там в принципе может быть под капотом оных юнитей. Вообще знание языка это не более 1% знаний нужных программисту особенно в плане геймдева, при этом все языки очень похожи (в любом случае все строится на вычислениях и условном переходе). все остальное - матан матфизика теомех сопромат гидрогазодинамика и т.д и т.п. Но язык нужно знать до такой степени чтобы на нем думать. Самому после двух лет работы на паскале включая два коммерческих проекта в свое время перейти на С++ было довольно сложно. Полная перестройка мышления заняла лет 5 не меньше.
Поэтому и говорю - чем раньше на плюсы переключитесь тем лучше, это именно так дикая огнедышущая кобылица которая нужна в геймдейве, при это освоить любой другой промышленный язык зная плюсы - вопрос прочтения мануала. Правда неумелых наездников сбросит затопчет и съест. Посему привыкать мыслить категориями этой штуки лучше чем раньше тем лучше.
Вообще игры это как ни крути а реалтаймовая задача. Ну скажем в следствие никакой ответсвенности расчетов околореалтаймовая (таки не станом прокатным крутить и не реактор ядерный качегарить), но тем не менее винда а особенно .Net для реалтаймовых задач не предназначены что у майкрософта чуть ли не на каждом заборе написано.

Спасибо за информацию, буду знать)

@Fulcrum_013 · 07.04.2017, 22:18

Сообщение от TopLayer

Не по теме:
Fulcrum_013, а вы, кстати, знаете почему эта программа на C# работает быстрее аналогичной программы на С++?

Не знаю и знать не хочу

потому как вот эта программа https://ideone.com/H18WBR работает в огромное количество раз быстрее. А все потому что распределение/уборка кучи даже в пуле все равно на порядки медленнее чем распределение/откат стека. А это именно то что пытался сделать в своем алгоритме ТС

@TopLayer · 07.04.2017, 22:35

Сообщение от Fulcrum_013

чем распределение/откат стека

Тут нет никакого стека, компилятор оптимизирует всё до одной инструкции.

Добавлено через 4 минуты

Сообщение от Fulcrum_013

Не знаю и знать не хочу

Ну тогда не гоните на сборщик мусора по поводу и без.

@Fulcrum_013 · 07.04.2017, 23:02

Сообщение от TopLayer

Тут нет никакого стека, компилятор оптимизирует всё до одной инструкции.

Память он где берет под временные данные которые так шустро кидает в кучу? Вообще что касается реалтаймовых задач то к примеру реаллокация буферов это нечто чему лучше остаться на этапе пусконаладки. А промежуточные данные таких размеров и в таких количествах распределяемые в куче это все равно что поставить таймер на спуск минигана и акуратненько прицелиться себе в ногу.

@TopLayer · 07.04.2017, 23:07

Сообщение от Fulcrum_013

Память он где берет под временные данные которые так шустро кидает в кучу?

Не понял вас. Какие данные он кидает в кучу?
Я всего лишь сказал, что весь цикл заменяется компилятором на одну инструкцию присваивания и поэтому программа работает мгновенно.

@Fulcrum_013 · 07.04.2017, 23:12

Сообщение от TopLayer

Тут нет никакого стека, компилятор оптимизирует всё до одной инструкции.

Ну давайте тогда более близкий к жизни пример попробуем. попробуйте за вот этим угнаться на шарпе с такой вот распределялкой как у вас https://ideone.com/H18WBR

Сообщение от TopLayer

Ну тогда не гоните на сборщик мусора по поводу и без.

А в шарпе яве и т.п. сборщика мусора вообще нет. Есть лечильщик висячих ссылок временной утечкой памяти. Для серьезных задач такая концепция как в шарпе а тем более без возможности принудительного удаления абсолютно непригодна.

Добавлено через 2 минуты

Сообщение от TopLayer

Я всего лишь сказал, что весь цикл заменяется компилятором на одну инструкцию присваивания и поэтому программа работает мгновенно.

Почему шарп так же не оптимизит? Потому что на куче временные данные распределяет. В результате там где у плюсов таймер тикнуть не успел у шарпа пол секунды прошло.

@TopLayer · 08.04.2017, 05:12

Сообщение от Fulcrum_013

попробуйте за вот этим угнаться на шарпе

Во-первых, основное время вашей программы занимает генерация случайных чисел, предлагаете сравнивать их стандартные реализации?
Во-вторых, мне вполне известно, что C++ работает быстрее C#, а сравнение программ, которое я привёл, было сделано с целью показать, что выделение мелких недолгоживущих объектов в куче происходит весьма шустро.

Сообщение от Fulcrum_013

Для серьезных задач

Получается, все .NET разработчики априори создают несерьёзные программы?

Сообщение от Fulcrum_013

без возможности принудительного удаления

Занулил все строгие ссылки и вызвал GC.Collect. Только зачем это нужно?

Сообщение от Fulcrum_013

Потому что на куче временные данные распределяет.

При чём тут куча? Компилятор имел право оптимизировать код, но не сделал этого. Значит такая фича просто не реализована. С другой стороны, компилятор C++ тоже не обязан оптимизировать подобные штуки, хоть и делает это в некоторых ситуациях. В любом случае, полагаться на компилятор в таких случаях не стоит, нужно самому явно оптимизировать алгоритм.

@Fulcrum_013 · 08.04.2017, 15:26

Сообщение от TopLayer

было сделано с целью показать, что выделение мелких недолгоживущих объектов в куче происходит весьма шустро.

В С++ их можно просо не выделять а пользовать промежуточные данные на стеке что по любому во много раз быстрее

Сообщение от TopLayer

При чём тут куча?

При надежности. Игры это задачи реального (ну или околореального в следствии никакой ответственности расчетов) времени. Но при этом все свойства реалтайм систем им присущи, соответсвенно и использовать лучше практики из серьезного реалтайма. Ну а в серьезном реалтайме реаллокация даже долгоживущих буферов это нечто чему лучше остаться на этапе пусконаладки. А подобные постоянные перевыделения кучи под всякую мелочь - это все равно что поставить таймер на спуск минигана и аккуратно прицелиться себе в ногу. Фрагментация кучи которая буде в результате на этот спуск нажмет однозначно через какое то время.
Для игрового клиента это может и не очень критично, но для игрового сервера уже критично.

Добавлено через 4 минуты

Сообщение от TopLayer

Занулил все строгие ссылки и вызвал GC.Collect. Только зачем это нужно?

Для того чтобы их занулить их нужно знать. А зачем - удаление объекта продолжение работы которого по логике модели невозможно.

Добавлено через 2 минуты

Сообщение от TopLayer

Получается, все .NET разработчики априори создают несерьёзные программы?

Скажем так - максимум для чего .Net предназначен - конторский софт.

@TopLayer · 08.04.2017, 15:46

Сообщение от Fulcrum_013

В С++ их можно просо не выделять

В C# тоже, если использовать структуры.

Сообщение от Fulcrum_013

А подобные постоянные перевыделения кучи под всякую мелочь - это все равно что поставить таймер на спуск минигана и аккуратно прицелиться себе в ногу.

Создание мелких короткоживущих объектов в C# не фрагментирует кучу, а их удаление сводится к смещению указателя.

Сообщение от Fulcrum_013

Для того чтобы их занулить их нужно знать.

А знать, какие указатели в С++ стали ссылаться на удалённый объект не нужно?

Сообщение от Fulcrum_013

А зачем - удаление объекта продолжение работы которого по логике модели невозможно.

А наличие висячих указателей вписывается в логику этой модели? Если можно, приведите небольшой пример (хотя бы абстрактный), который демонстрирует сие преимущество.

@Fulcrum_013 · 08.04.2017, 16:47

Сообщение от TopLayer

было сделано с целью показать, что выделение мелких недолгоживущих объектов в куче происходит весьма шустро.

Давайте попробуем пример максимально приближенный к боевому:https://ideone.com/K3C6IR
Из него четко видно что распределение памяти под промежуточные данные в шарпе требует в 10 раз больше времени чем сам расчет.

Добавлено через 4 минуты

Сообщение от TopLayer

А знать, какие указатели в С++ стали ссылаться на удалённый объект не нужно?

Нужно. Но это решается просто. Обычно частичной реализацией двунаправленных указателей и слабо владеющими контейнерами на их базе. (полная в большинстве случаев оверкил)

Сообщение от TopLayer

В C# тоже, если использовать структуры.

Но при этом все стандартные вектора кватернионы и т.д. классы.

Добавлено через 3 минуты

Сообщение от TopLayer

Создание мелких короткоживущих объектов в C# не фрагментирует кучу, а их удаление сводится к смещению указателя.

Операция смещения указателя может занимать несколько сот тактов и блокировать все ядра. Операция же смещения указателя стека всегда один такт без всяких блокировок.

Добавлено через 8 минут

Сообщение от TopLayer

А наличие висячих указателей вписывается в логику этой модели?

Вот как раз о висячих указателях и идет речь. GC это по большому счету средство лечения проблемы висячих ссылок путем их превращения в утечки памяти в надежде что такие утечки временные и небольшие. Но такой подход сильно усложняет вычестку ссылок при необходимости принудительного удаления объекта.

Добавлено через 38 минут

Сообщение от TopLayer

А наличие висячих указателей вписывается в логику этой модели? Если можно, приведите небольшой пример (хотя бы абстрактный), который демонстрирует сие преимущество.

Серьезный пример к сожалению многословен. Но суть такая к примеру имеем компонент и владеющую им модель. Модель имеет список всех компонентов. Компонент аргументом конструктора имеет указатель на модель запоминает его и оповещает модель о своем создании. модель добавляет его в список владения. В деструкторе все с точностью до наоборот. Т.е. компонент оповещает модель о своем удалении, модель убирает его из списка владения. При удалении самой модели удаляется и все что осталось в списке владения. Дальнейшее поведение определяется шаблонными методами компонентов, модель только дережирует их вызовами. В результате можно свести модель к тому что ссылки на компоненты есть только в списке владения модели, и вполне возможно в дополнительных списках обработки содержащихся в той же модели, а соответсвенно ссылки из которых тоже можно вычищать используя тоже оповещение об удалении. При этом компоненту достаточно хранить только один обратный указатель - на саму модель, который в любом случае нужен для сервисов предоставляемым компонентам моделью. При этом сами компоненты получаются абсолютно автономными, такими что внешние ссылки на них из за пределов модели просто не нужны, по сему не нужен ни GC ни даже полная реализация системы двунаправленных указателей.
При этом потомок такого компонента может иметь примерно такое поведение:

C++

void TMissile::ChekCollision(){
  if (Hit()){
      new TExplosion(Owner, Pos, Strength);//Owner - ссылка на модель живущая в каждом компоненте;
      delete this; 
  }
}

Добавлено через 4 минуты

Сообщение от TopLayer

а их удаление сводится к смещению указателя

Для такого подхода высвобождение должно быть в порядке строго обратном распределению. Для этого существует стек.

@TopLayer · 08.04.2017, 17:55

Сообщение от Fulcrum_013

максимум для чего .Net предназначен - конторский софт.

Чтобы определять максимум, надо сначала ввести отношение. Чисто субъективно: конторский софт > gamedev.

Сообщение от Fulcrum_013

Операция смещения указателя может занимать несколько сот тактов и блокировать все ядра.

Да вроде при частичной коллекции ничего не блокируется.
Ещё раз повторю, я не спорю, что C++ быстрее C#.

А что ваш пример демонстрирует? Деструктор это тот же метод, можно аналогичный Dispose в C# написать. А то, что память не переиспользуется пока не возникнет необходимость, мне лично глаз не режет.

Если объектов Tmissile планируется очень много, то лучше будет создать пул этих объектов. И тогда никакого delete this не будет, что в С++, что в C# объекты будут удаляться пачками.

@Fulcrum_013 2055 / 1533 / 167 Регистрация: 14.12.2014 Сообщений: 13,326
	07.04.2017, 22:18	11
	Сообщение от TopLayer Не по теме: Fulcrum_013, а вы, кстати, знаете почему эта программа на C# работает быстрее аналогичной программы на С++? Не знаю и знать не хочу потому как вот эта программа https://ideone.com/H18WBR работает в огромное количество раз быстрее. А все потому что распределение/уборка кучи даже в пуле все равно на порядки медленнее чем распределение/откат стека. А это именно то что пытался сделать в своем алгоритме ТС 0

@Fulcrum_013 2055 / 1533 / 167 Регистрация: 14.12.2014 Сообщений: 13,326
	07.04.2017, 01:13	2
	Nik_33, Тормозит скорее всего не алгоритм а шарп. распределение кучи и потом ее уборка сборщиком мусора довольно тормозные операции. у вас же в каждом проходе распределяется на куче 3 объекта. На плюсах в 3D при 100+ целях и 2000+ активных пуль у подобного алгоритма ни малейшего намека на тормоза. При этом пули и цели создаются один раз к примеру при выстреле и один же раз удаляются при попадании/вылете за пределы моделируемой области/взрыве и т.п. А координаты коллайдеров и пуль апдейтятся во время движения а не пересаздаются постоянно. 1

@Nik_33 0 / 0 / 1 Регистрация: 24.02.2017 Сообщений: 62
	07.04.2017, 20:41 [ТС]	3
	Сообщение от Fulcrum_013 Тормозит скорее всего не алгоритм а шарп. распределение кучи и потом ее уборка сборщиком мусора довольно тормозные операции. у вас же в каждом проходе распределяется на куче 3 объекта. На плюсах в 3D при 100+ целях и 2000+ активных пуль у подобного алгоритма ни малейшего намека на тормоза. При этом пули и цели создаются один раз к примеру при выстреле и один же раз удаляются при попадании/вылете за пределы моделируемой области/взрыве и т.п. А координаты коллайдеров и пуль апдейтятся во время движения а не пересаздаются постоянно. Такие проекты думаете лучше делать на c++? Добавлено через 1 минуту Сообщение от Fulcrum_013 При этом пули и цели создаются один раз к примеру при выстреле и один же раз удаляются при попадании/вылете за пределы моделируемой области/взрыве и т.п. А координаты коллайдеров и пуль апдейтятся во время движения а не пересаздаются постоянно. Эту часть вообще не понял.. 0

@TopLayer 904 / 661 / 318 Регистрация: 23.10.2016 Сообщений: 1,538
	07.04.2017, 21:18	4
	Сообщение от Fulcrum_013 в каждом проходе распределяется на куче 3 объекта Я вижу только 1: Random. Причём он должен один раз создаваться до цикла или даже в начале программы, а у ТС ошибка. Сообщение от Nik_33 Такие проекты думаете лучше делать на c++? Лучше хорошо изучить хотя бы 1 язык программирования. 0

@TopLayer 904 / 661 / 318 Регистрация: 23.10.2016 Сообщений: 1,538
	07.04.2017, 21:52	6
	Сообщение от Fulcrum_013 А 2 Rectangle над ним? Это же структуры. 0

@Nik_33 0 / 0 / 1 Регистрация: 24.02.2017 Сообщений: 62
	07.04.2017, 21:53 [ТС]	7
	Сообщение от Fulcrum_013 C++ и DirectX. Ну по началу можно на какой то готовый движок взглянуть. К примеру на тот же юнити. Шарпом месяца 2-3 балуюсь какой юнити ребят) Опыта в таких проектах 0.0 Добавлено через 40 секунд Сообщение от Fulcrum_013 Кстати одна из причин тормозов может крыться в отрисовке через PictureBox. Есть способ обойтись без picturebox'а? 0

@TopLayer
	07.04.2017, 22:08 #8
	Не по теме: Fulcrum_013, а вы, кстати, знаете почему эта программа на C# работает быстрее аналогичной программы на С++? 0

@Fulcrum_013 2055 / 1533 / 167 Регистрация: 14.12.2014 Сообщений: 13,326
	07.04.2017, 22:10	9
	Сообщение от Nik_33 Есть способ обойтись без picturebox'а? Unity, SFML. Хотя лучше сырые DirectX и OpenGL в них новичку разобраться проще будет. Матана меньше знать ннадо чтобы понять что там и зачем. Достаточно векторной алгебры и вычислительной геометрии. Но всю физику придется самому физичить. Ну зато придет понимание что там в принципе может быть под капотом оных юнитей. Вообще знание языка это не более 1% знаний нужных программисту особенно в плане геймдева, при этом все языки очень похожи (в любом случае все строится на вычислениях и условном переходе). все остальное - матан матфизика теомех сопромат гидрогазодинамика и т.д и т.п. Но язык нужно знать до такой степени чтобы на нем думать. Самому после двух лет работы на паскале включая два коммерческих проекта в свое время перейти на С++ было довольно сложно. Полная перестройка мышления заняла лет 5 не меньше. Поэтому и говорю - чем раньше на плюсы переключитесь тем лучше, это именно так дикая огнедышущая кобылица которая нужна в геймдейве, при это освоить любой другой промышленный язык зная плюсы - вопрос прочтения мануала. Правда неумелых наездников сбросит затопчет и съест. Посему привыкать мыслить категориями этой штуки лучше чем раньше тем лучше. Вообще игры это как ни крути а реалтаймовая задача. Ну скажем в следствие никакой ответсвенности расчетов околореалтаймовая (таки не станом прокатным крутить и не реактор ядерный качегарить), но тем не менее винда а особенно .Net для реалтаймовых задач не предназначены что у майкрософта чуть ли не на каждом заборе написано. 1

@Nik_33 0 / 0 / 1 Регистрация: 24.02.2017 Сообщений: 62
	07.04.2017, 22:14 [ТС]	10
	Сообщение от Fulcrum_013 Unity, SFML. Хотя лучше сырые DirectX и OpenGL в них новичку разобраться проще будет. Матана меньше знать ннадо чтобы понять что там и зачем. Достаточно векторной алгебры и вычислительной геометрии. Но всю физику придется самому физичить. Ну зато придет понимание что там в принципе может быть под капотом оных юнитей. Вообще знание языка это не более 1% знаний нужных программисту особенно в плане геймдева, при этом все языки очень похожи (в любом случае все строится на вычислениях и условном переходе). все остальное - матан матфизика теомех сопромат гидрогазодинамика и т.д и т.п. Но язык нужно знать до такой степени чтобы на нем думать. Самому после двух лет работы на паскале включая два коммерческих проекта в свое время перейти на С++ было довольно сложно. Полная перестройка мышления заняла лет 5 не меньше. Поэтому и говорю - чем раньше на плюсы переключитесь тем лучше, это именно так дикая огнедышущая кобылица которая нужна в геймдейве, при это освоить любой другой промышленный язык зная плюсы - вопрос прочтения мануала. Правда неумелых наездников сбросит затопчет и съест. Посему привыкать мыслить категориями этой штуки лучше чем раньше тем лучше. Вообще игры это как ни крути а реалтаймовая задача. Ну скажем в следствие никакой ответсвенности расчетов околореалтаймовая (таки не станом прокатным крутить и не реактор ядерный качегарить), но тем не менее винда а особенно .Net для реалтаймовых задач не предназначены что у майкрософта чуть ли не на каждом заборе написано. Спасибо за информацию, буду знать) 0

@TopLayer 904 / 661 / 318 Регистрация: 23.10.2016 Сообщений: 1,538
	07.04.2017, 22:35	12
	Сообщение от Fulcrum_013 чем распределение/откат стека Тут нет никакого стека, компилятор оптимизирует всё до одной инструкции. Добавлено через 4 минуты Сообщение от Fulcrum_013 Не знаю и знать не хочу Ну тогда не гоните на сборщик мусора по поводу и без. 0

@Fulcrum_013 2055 / 1533 / 167 Регистрация: 14.12.2014 Сообщений: 13,326
	07.04.2017, 23:02	13
	Сообщение от TopLayer Тут нет никакого стека, компилятор оптимизирует всё до одной инструкции. Память он где берет под временные данные которые так шустро кидает в кучу? Вообще что касается реалтаймовых задач то к примеру реаллокация буферов это нечто чему лучше остаться на этапе пусконаладки. А промежуточные данные таких размеров и в таких количествах распределяемые в куче это все равно что поставить таймер на спуск минигана и акуратненько прицелиться себе в ногу. 0

@TopLayer 904 / 661 / 318 Регистрация: 23.10.2016 Сообщений: 1,538
	07.04.2017, 23:07	14
	Сообщение от Fulcrum_013 Память он где берет под временные данные которые так шустро кидает в кучу? Не понял вас. Какие данные он кидает в кучу? Я всего лишь сказал, что весь цикл заменяется компилятором на одну инструкцию присваивания и поэтому программа работает мгновенно. 0

@Fulcrum_013 2055 / 1533 / 167 Регистрация: 14.12.2014 Сообщений: 13,326
	07.04.2017, 23:12	15
	Сообщение от TopLayer Тут нет никакого стека, компилятор оптимизирует всё до одной инструкции. Ну давайте тогда более близкий к жизни пример попробуем. попробуйте за вот этим угнаться на шарпе с такой вот распределялкой как у вас https://ideone.com/H18WBR Сообщение от TopLayer Ну тогда не гоните на сборщик мусора по поводу и без. А в шарпе яве и т.п. сборщика мусора вообще нет. Есть лечильщик висячих ссылок временной утечкой памяти. Для серьезных задач такая концепция как в шарпе а тем более без возможности принудительного удаления абсолютно непригодна. Добавлено через 2 минуты Сообщение от TopLayer Я всего лишь сказал, что весь цикл заменяется компилятором на одну инструкцию присваивания и поэтому программа работает мгновенно. Почему шарп так же не оптимизит? Потому что на куче временные данные распределяет. В результате там где у плюсов таймер тикнуть не успел у шарпа пол секунды прошло. 0

@TopLayer 904 / 661 / 318 Регистрация: 23.10.2016 Сообщений: 1,538
	08.04.2017, 05:12	16
	Сообщение от Fulcrum_013 попробуйте за вот этим угнаться на шарпе Во-первых, основное время вашей программы занимает генерация случайных чисел, предлагаете сравнивать их стандартные реализации? Во-вторых, мне вполне известно, что C++ работает быстрее C#, а сравнение программ, которое я привёл, было сделано с целью показать, что выделение мелких недолгоживущих объектов в куче происходит весьма шустро. Сообщение от Fulcrum_013 Для серьезных задач Получается, все .NET разработчики априори создают несерьёзные программы? Сообщение от Fulcrum_013 без возможности принудительного удаления Занулил все строгие ссылки и вызвал GC.Collect. Только зачем это нужно? Сообщение от Fulcrum_013 Потому что на куче временные данные распределяет. При чём тут куча? Компилятор имел право оптимизировать код, но не сделал этого. Значит такая фича просто не реализована. С другой стороны, компилятор C++ тоже не обязан оптимизировать подобные штуки, хоть и делает это в некоторых ситуациях. В любом случае, полагаться на компилятор в таких случаях не стоит, нужно самому явно оптимизировать алгоритм. 0

@Fulcrum_013 2055 / 1533 / 167 Регистрация: 14.12.2014 Сообщений: 13,326
	08.04.2017, 15:26	17
	Сообщение от TopLayer было сделано с целью показать, что выделение мелких недолгоживущих объектов в куче происходит весьма шустро. В С++ их можно просо не выделять а пользовать промежуточные данные на стеке что по любому во много раз быстрее Сообщение от TopLayer При чём тут куча? При надежности. Игры это задачи реального (ну или околореального в следствии никакой ответственности расчетов) времени. Но при этом все свойства реалтайм систем им присущи, соответсвенно и использовать лучше практики из серьезного реалтайма. Ну а в серьезном реалтайме реаллокация даже долгоживущих буферов это нечто чему лучше остаться на этапе пусконаладки. А подобные постоянные перевыделения кучи под всякую мелочь - это все равно что поставить таймер на спуск минигана и аккуратно прицелиться себе в ногу. Фрагментация кучи которая буде в результате на этот спуск нажмет однозначно через какое то время. Для игрового клиента это может и не очень критично, но для игрового сервера уже критично. Добавлено через 4 минуты Сообщение от TopLayer Занулил все строгие ссылки и вызвал GC.Collect. Только зачем это нужно? Для того чтобы их занулить их нужно знать. А зачем - удаление объекта продолжение работы которого по логике модели невозможно. Добавлено через 2 минуты Сообщение от TopLayer Получается, все .NET разработчики априори создают несерьёзные программы? Скажем так - максимум для чего .Net предназначен - конторский софт. 0

@TopLayer 904 / 661 / 318 Регистрация: 23.10.2016 Сообщений: 1,538
	08.04.2017, 15:46	18
	Сообщение от Fulcrum_013 В С++ их можно просо не выделять В C# тоже, если использовать структуры. Сообщение от Fulcrum_013 А подобные постоянные перевыделения кучи под всякую мелочь - это все равно что поставить таймер на спуск минигана и аккуратно прицелиться себе в ногу. Создание мелких короткоживущих объектов в C# не фрагментирует кучу, а их удаление сводится к смещению указателя. Сообщение от Fulcrum_013 Для того чтобы их занулить их нужно знать. А знать, какие указатели в С++ стали ссылаться на удалённый объект не нужно? Сообщение от Fulcrum_013 А зачем - удаление объекта продолжение работы которого по логике модели невозможно. А наличие висячих указателей вписывается в логику этой модели? Если можно, приведите небольшой пример (хотя бы абстрактный), который демонстрирует сие преимущество. 0

@TopLayer 904 / 661 / 318 Регистрация: 23.10.2016 Сообщений: 1,538
	08.04.2017, 17:55	20
	Сообщение от Fulcrum_013 максимум для чего .Net предназначен - конторский софт. Чтобы определять максимум, надо сначала ввести отношение. Чисто субъективно: конторский софт > gamedev. Сообщение от Fulcrum_013 Операция смещения указателя может занимать несколько сот тактов и блокировать все ядра. Да вроде при частичной коллекции ничего не блокируется. Ещё раз повторю, я не спорю, что C++ быстрее C#. А что ваш пример демонстрирует? Деструктор это тот же метод, можно аналогичный Dispose в C# написать. А то, что память не переиспользуется пока не возникнет необходимость, мне лично глаз не режет. Если объектов Tmissile планируется очень много, то лучше будет создать пул этих объектов. И тогда никакого `delete this` не будет, что в С++, что в C# объекты будут удаляться пачками. 0