0 / 0 / 1
Регистрация: 24.02.2017
Сообщений: 62
|
||||||
1 | ||||||
Придумать алгоритм пересечения игрока с пулей в игре05.04.2017, 21:24. Показов 4351. Ответов 31
Метки нет Все метки)
(
Всем привет! Если в кратце то нужно придумать алгоритм пересечения игрока с пулей. Существует массив PictureBox Игроков и аналогично пуль для каждого игрока. Вот пример этого алгоритма.
![]()
__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь
0
|
|
05.04.2017, 21:24 | |
Ответы с готовыми решениями:
31
Получить id игрока во флеш-игре.
Панель игрока в игре русская рыбалка Перемещение игрока в сетевой игре пс использованием джойстика |
2057 / 1534 / 167
Регистрация: 14.12.2014
Сообщений: 13,348
|
|
07.04.2017, 01:13 | 2 |
Nik_33, Тормозит скорее всего не алгоритм а шарп. распределение кучи и потом ее уборка сборщиком мусора довольно тормозные операции. у вас же в каждом проходе распределяется на куче 3 объекта. На плюсах в 3D при 100+ целях и 2000+ активных пуль у подобного алгоритма ни малейшего намека на тормоза. При этом пули и цели создаются один раз к примеру при выстреле и один же раз удаляются при попадании/вылете за пределы моделируемой области/взрыве и т.п. А координаты коллайдеров и пуль апдейтятся во время движения а не пересаздаются постоянно.
1
|
0 / 0 / 1
Регистрация: 24.02.2017
Сообщений: 62
|
|
07.04.2017, 20:41 [ТС] | 3 |
Такие проекты думаете лучше делать на c++?
Добавлено через 1 минуту Эту часть вообще не понял..
0
|
906 / 663 / 318
Регистрация: 23.10.2016
Сообщений: 1,538
|
|
07.04.2017, 21:18 | 4 |
Я вижу только 1: Random. Причём он должен один раз создаваться до цикла или даже в начале программы, а у ТС ошибка.
Лучше хорошо изучить хотя бы 1 язык программирования.
0
|
2057 / 1534 / 167
Регистрация: 14.12.2014
Сообщений: 13,348
|
||||||
07.04.2017, 21:38 | 5 | |||||
C++ и DirectX. Ну по началу можно на какой то готовый движок взглянуть. К примеру на тот же юнити.
Кстати одна из причин тормозов может крыться в отрисовке через PictureBox. Далеко не самый быстрый способ отрисовки. Ну схема в кратце такая:
Опять же многое зависит от того как игра организована. Если карта тайловая то можно в тайлах помечать какие персонажи/подвижные объекты в нем находятся и при полете просчитывать через какие тайлы она прошла и проверять пересечеия только с объектами зарегистрироваными в этих тайлах. Плюсы метода - очень быстрый отсев того с кем не пересечется. Минусы - фактически дробление шага по времени, плюс есть сложность что если объект занимает тайл не полностью при этом объект большой и пуля с ним не пересеклась сложно отсеять проверку с ним в следующем тайле, т.е возможен вариант когда с большми объектами пересечение будет проверяться неколько раз. Строить же ннеравномерную сетку индексации имеет смысл только для неподвижных объектов. Для подвижных перестроение сетки скорее всего будет не быстрее чем перебор каждого с каждым. При этом пользуемый у вас алгоритм AABB коллизий настолько быстр что его пользуют для предотсечения - т.е. сначала сравнивая каждого с каждым таким алгоритмом а потом уже только для песекшихся проводят более сложные расчеты пересечения их геометрии. Добавлено через 2 минуты Опять же многое зависит от того насколько предсказуемо поведение цели. Если цель не управляется игроком и/или ИИ , т.е. не может самопроизвольно менять параметры своей траектории то попадет или нет и в какой момент времени попадет можно вычислить в момент выстрела. Добавлено через 3 минуты Если может но не существенно по отношению к скорости пули то можно вычислить с какого по какой момент времени (интервал в котором вероятно попадание)нужна проверка. Добавлено через 2 минуты Вообще задача столкновения подвижных объектов корректно решается только в 4D пространстве. Ну для 2D игры соответсвенно в 3D Добавлено через 8 минут А 2 Rectangle над ним? Да действительно. При этом хорошо чтобы и язык тебя ни в чем не ограничивал. Особенно для геймдева. А такой язык и существует только один. С++ называется.
1
|
906 / 663 / 318
Регистрация: 23.10.2016
Сообщений: 1,538
|
|
07.04.2017, 21:52 | 6 |
0
|
0 / 0 / 1
Регистрация: 24.02.2017
Сообщений: 62
|
|
07.04.2017, 21:53 [ТС] | 7 |
Шарпом месяца 2-3 балуюсь какой юнити ребят) Опыта в таких проектах 0.0
Добавлено через 40 секунд Есть способ обойтись без picturebox'а?
0
|
TopLayer
|
07.04.2017, 22:08
#8
|
Не по теме: Fulcrum_013, а вы, кстати, знаете почему эта программа на C# работает быстрее аналогичной программы на С++?
0
|
2057 / 1534 / 167
Регистрация: 14.12.2014
Сообщений: 13,348
|
|
07.04.2017, 22:10 | 9 |
Unity, SFML. Хотя лучше сырые DirectX и OpenGL в них новичку разобраться проще будет. Матана меньше знать ннадо чтобы понять что там и зачем. Достаточно векторной алгебры и вычислительной геометрии. Но всю физику придется самому физичить. Ну зато придет понимание что там в принципе может быть под капотом оных юнитей. Вообще знание языка это не более 1% знаний нужных программисту особенно в плане геймдева, при этом все языки очень похожи (в любом случае все строится на вычислениях и условном переходе). все остальное - матан матфизика теомех сопромат гидрогазодинамика и т.д и т.п. Но язык нужно знать до такой степени чтобы на нем думать. Самому после двух лет работы на паскале включая два коммерческих проекта в свое время перейти на С++ было довольно сложно. Полная перестройка мышления заняла лет 5 не меньше.
Поэтому и говорю - чем раньше на плюсы переключитесь тем лучше, это именно так дикая огнедышущая кобылица которая нужна в геймдейве, при это освоить любой другой промышленный язык зная плюсы - вопрос прочтения мануала. Правда неумелых наездников сбросит затопчет и съест. Посему привыкать мыслить категориями этой штуки лучше чем раньше тем лучше. Вообще игры это как ни крути а реалтаймовая задача. Ну скажем в следствие никакой ответсвенности расчетов околореалтаймовая (таки не станом прокатным крутить и не реактор ядерный качегарить), но тем не менее винда а особенно .Net для реалтаймовых задач не предназначены что у майкрософта чуть ли не на каждом заборе написано.
1
|
0 / 0 / 1
Регистрация: 24.02.2017
Сообщений: 62
|
|
07.04.2017, 22:14 [ТС] | 10 |
0
|
2057 / 1534 / 167
Регистрация: 14.12.2014
Сообщений: 13,348
|
|
07.04.2017, 22:18 | 11 |
Не знаю и знать не хочу
![]()
0
|
906 / 663 / 318
Регистрация: 23.10.2016
Сообщений: 1,538
|
|
07.04.2017, 22:35 | 12 |
Тут нет никакого стека, компилятор оптимизирует всё до одной инструкции.
Добавлено через 4 минуты Ну тогда не гоните на сборщик мусора по поводу и без.
0
|
2057 / 1534 / 167
Регистрация: 14.12.2014
Сообщений: 13,348
|
|
07.04.2017, 23:02 | 13 |
Память он где берет под временные данные которые так шустро кидает в кучу? Вообще что касается реалтаймовых задач то к примеру реаллокация буферов это нечто чему лучше остаться на этапе пусконаладки. А промежуточные данные таких размеров и в таких количествах распределяемые в куче это все равно что поставить таймер на спуск минигана и акуратненько прицелиться себе в ногу.
0
|
906 / 663 / 318
Регистрация: 23.10.2016
Сообщений: 1,538
|
|
07.04.2017, 23:07 | 14 |
Не понял вас. Какие данные он кидает в кучу?
Я всего лишь сказал, что весь цикл заменяется компилятором на одну инструкцию присваивания и поэтому программа работает мгновенно.
0
|
2057 / 1534 / 167
Регистрация: 14.12.2014
Сообщений: 13,348
|
|
07.04.2017, 23:12 | 15 |
Ну давайте тогда более близкий к жизни пример попробуем. попробуйте за вот этим угнаться на шарпе с такой вот распределялкой как у вас https://ideone.com/H18WBR
А в шарпе яве и т.п. сборщика мусора вообще нет. Есть лечильщик висячих ссылок временной утечкой памяти. Для серьезных задач такая концепция как в шарпе а тем более без возможности принудительного удаления абсолютно непригодна. Добавлено через 2 минуты Почему шарп так же не оптимизит? Потому что на куче временные данные распределяет. В результате там где у плюсов таймер тикнуть не успел у шарпа пол секунды прошло.
0
|
906 / 663 / 318
Регистрация: 23.10.2016
Сообщений: 1,538
|
|
08.04.2017, 05:12 | 16 |
Во-первых, основное время вашей программы занимает генерация случайных чисел, предлагаете сравнивать их стандартные реализации?
Во-вторых, мне вполне известно, что C++ работает быстрее C#, а сравнение программ, которое я привёл, было сделано с целью показать, что выделение мелких недолгоживущих объектов в куче происходит весьма шустро. Получается, все .NET разработчики априори создают несерьёзные программы? Занулил все строгие ссылки и вызвал GC.Collect. Только зачем это нужно? При чём тут куча? Компилятор имел право оптимизировать код, но не сделал этого. Значит такая фича просто не реализована. С другой стороны, компилятор C++ тоже не обязан оптимизировать подобные штуки, хоть и делает это в некоторых ситуациях. В любом случае, полагаться на компилятор в таких случаях не стоит, нужно самому явно оптимизировать алгоритм.
0
|
2057 / 1534 / 167
Регистрация: 14.12.2014
Сообщений: 13,348
|
|
08.04.2017, 15:26 | 17 |
В С++ их можно просо не выделять а пользовать промежуточные данные на стеке что по любому во много раз быстрее
При надежности. Игры это задачи реального (ну или околореального в следствии никакой ответственности расчетов) времени. Но при этом все свойства реалтайм систем им присущи, соответсвенно и использовать лучше практики из серьезного реалтайма. Ну а в серьезном реалтайме реаллокация даже долгоживущих буферов это нечто чему лучше остаться на этапе пусконаладки. А подобные постоянные перевыделения кучи под всякую мелочь - это все равно что поставить таймер на спуск минигана и аккуратно прицелиться себе в ногу. Фрагментация кучи которая буде в результате на этот спуск нажмет однозначно через какое то время. Для игрового клиента это может и не очень критично, но для игрового сервера уже критично. Добавлено через 4 минуты Для того чтобы их занулить их нужно знать. А зачем - удаление объекта продолжение работы которого по логике модели невозможно. Добавлено через 2 минуты Скажем так - максимум для чего .Net предназначен - конторский софт.
0
|
906 / 663 / 318
Регистрация: 23.10.2016
Сообщений: 1,538
|
|
08.04.2017, 15:46 | 18 |
В C# тоже, если использовать структуры.
Создание мелких короткоживущих объектов в C# не фрагментирует кучу, а их удаление сводится к смещению указателя. А знать, какие указатели в С++ стали ссылаться на удалённый объект не нужно? А наличие висячих указателей вписывается в логику этой модели? Если можно, приведите небольшой пример (хотя бы абстрактный), который демонстрирует сие преимущество.
0
|
2057 / 1534 / 167
Регистрация: 14.12.2014
Сообщений: 13,348
|
||||||
08.04.2017, 16:47 | 19 | |||||
Давайте попробуем пример максимально приближенный к боевому:https://ideone.com/K3C6IR
Из него четко видно что распределение памяти под промежуточные данные в шарпе требует в 10 раз больше времени чем сам расчет. Добавлено через 4 минуты Нужно. Но это решается просто. Обычно частичной реализацией двунаправленных указателей и слабо владеющими контейнерами на их базе. (полная в большинстве случаев оверкил) Но при этом все стандартные вектора кватернионы и т.д. классы. Добавлено через 3 минуты Операция смещения указателя может занимать несколько сот тактов и блокировать все ядра. Операция же смещения указателя стека всегда один такт без всяких блокировок. Добавлено через 8 минут Вот как раз о висячих указателях и идет речь. GC это по большому счету средство лечения проблемы висячих ссылок путем их превращения в утечки памяти в надежде что такие утечки временные и небольшие. Но такой подход сильно усложняет вычестку ссылок при необходимости принудительного удаления объекта. Добавлено через 38 минут Серьезный пример к сожалению многословен. Но суть такая к примеру имеем компонент и владеющую им модель. Модель имеет список всех компонентов. Компонент аргументом конструктора имеет указатель на модель запоминает его и оповещает модель о своем создании. модель добавляет его в список владения. В деструкторе все с точностью до наоборот. Т.е. компонент оповещает модель о своем удалении, модель убирает его из списка владения. При удалении самой модели удаляется и все что осталось в списке владения. Дальнейшее поведение определяется шаблонными методами компонентов, модель только дережирует их вызовами. В результате можно свести модель к тому что ссылки на компоненты есть только в списке владения модели, и вполне возможно в дополнительных списках обработки содержащихся в той же модели, а соответсвенно ссылки из которых тоже можно вычищать используя тоже оповещение об удалении. При этом компоненту достаточно хранить только один обратный указатель - на саму модель, который в любом случае нужен для сервисов предоставляемым компонентам моделью. При этом сами компоненты получаются абсолютно автономными, такими что внешние ссылки на них из за пределов модели просто не нужны, по сему не нужен ни GC ни даже полная реализация системы двунаправленных указателей. При этом потомок такого компонента может иметь примерно такое поведение:
Для такого подхода высвобождение должно быть в порядке строго обратном распределению. Для этого существует стек.
0
|
906 / 663 / 318
Регистрация: 23.10.2016
Сообщений: 1,538
|
|
08.04.2017, 17:55 | 20 |
Чтобы определять максимум, надо сначала ввести отношение. Чисто субъективно: конторский софт > gamedev.
Да вроде при частичной коллекции ничего не блокируется. Ещё раз повторю, я не спорю, что C++ быстрее C#. А что ваш пример демонстрирует? Деструктор это тот же метод, можно аналогичный Dispose в C# написать. А то, что память не переиспользуется пока не возникнет необходимость, мне лично глаз не режет. Если объектов Tmissile планируется очень много, то лучше будет создать пул этих объектов. И тогда никакого delete this не будет, что в С++, что в C# объекты будут удаляться пачками.
0
|
08.04.2017, 17:55 | |
Помогаю со студенческими работами здесь
20
Вывести ник игрока, одержавшего победу в игре
Всех тех противников в игре заменить на одного противника-игрока Задержка перед ходом Компьютера и Игрока в игре крести-нолики Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |