Войти
ФлеймФорумПрограммирование

YouTube-канал про геймдев и программирование. Критикуйте, господа и дамы (8 стр)

Страницы: 17 8 9 10 11 Следующая »
#105
20:25, 14 июля 2019

pahaa
> А читаем текст мы жопой?
Нет, я прочел твой плач про то, как в реальных проектах не инкапсулируют m_pos. Твоя позиция я так понимаю такая: "аааа, они не инкапсулируют m_pos, поэтому нужно инкапсулировать у вектора X и Y. Чтобы если вдруг объект улетит за экран, то я мог поставить conditional breakpoint в setX у вектора". Я правильно понял твою позицию?

totoro
> объектно-ориентированный язык используется там где инкапсуляция нужна,
> процедурный - там где не нужна.
ОО язык - это лишь возможность инкапсуляции. Это не значит, что абсолютно все поля надо инкапсулировать. Если бы это было так, то тебе на уровне языка запретили класть поля в паблик. Вот например возьмем С#. Он онли ОО. Однако разработчики библиотеки с вектором положили поля в паблик: https://docs.microsoft.com/en-us/dotnet/api/system.numerics.vecto… rk-4.8#fields
потому что им хватает разума и осознания, что инкапсуляция в данном месте - маразм чистейшей воды.


#106
23:25, 14 июля 2019

MrShoor
> Ты в коде покажи, потому я например не пойму нафига вот такое:
> t_space_for_r2c r2c;
> Заводить
ну у меня шансов доступно показать - около нуля, т.к я уже проиграл.
but anyway:

struct t_cd_sys_with_spaces{
  struct t_space_for_r2c{
    using t_cell=small_vector<t_rect*>;
    t_cd_sys_with_spaces&cd_sys;
    t_map_v2<t_cell> map;
    void solve(){
      for(auto&circle:cd_sys.mem.сarr){
        auto f=[&](t_rect&rect){cd_sys.solve(rect,circle);};
        map.foreach_from_nightbours(circle.pos,like_manhattan_distance::r2c,f);
      }
    }
  };
  t_space_for_rects r2r;
  t_space_for_circles c2c;
  t_space_for_r2c r2c;
  t_mem mem;
  ...
  void solve(vector<t_rect>&rarr,vector<t_circle>&carr){
    assert(&mem.rarr==&rarr);assert(&mem.carr==&carr);
    r2c.solve();
  }
};
struct t_game{
  void update_cd(){
    cd_sys.write_to_spaces(rects);
    cd_sys.write_to_spaces(circles);
    //
    cd_sys.solve(rects,circles); 
    cd_sys.solve(rects);
    cd_sys.solve(circles);
  }
};
как видишь, оно нафиг не нужно и можно всё в main затолкать.

MrShoor
> Код покажешь как это сделать на гриде?
не-а, т.к кол-во соседних ячеек которые надо проверять зависит от "максимального расстояния между rect`ами и circle`ами при котором ещё есть столкновение" и "размера ячейки".
причём "размер ячейки" и "кол-во соседних ячеек которые надо проверять" выбирается в результате оптимизации. если у нас какой-то простой мелкий проект то можно вручную во время разработки определиться с этими константами. если у нас обобщённый движок/редактор то это можно это делать в runtime...

#107
23:43, 14 июля 2019

MrShoor
> Вот например возьмем С#. Он онли ОО. Однако разработчики библиотеки с вектором
> положили поля в паблик:
> https://docs.microsoft.com/en-us/dotnet/api/system.numerics.vecto…
> rk-4.8#fields

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

Generally, you should use fields only for variables that have private or protected accessibility. Data that your class exposes to client code should be provided through methods, properties and indexers. By using these constructs for indirect access to internal fields, you can guard against invalid input values. A private field that stores the data exposed by a public property is called a backing store or backing field.

#108
23:43, 14 июля 2019

MrShoor
> Я правильно понял твою позицию?
Нет, неправильно.
Инкапсуляция нужна на всех уровнях, чтобы можно было легко диагностировать проблему. Но посыл не в этом.
Смысл в том, что не следует создавать искусственным образом потенциальные источники проблем.
Нет открытого поля - нет желания его использовать. Есть открытое поле - с вероятностью, близкой к "совершенно точно", какой-нибудь Вася сделает с ним что-нибудь не то. И это расползётся по всему проекту. И, нет, возможность не писать 2 лишние скобочки после имени переменной явно не является аргументом в пользу увеличения энтропии.
И, далее, ещё один нет: открытые поля надо использовать по назначению - там, где они нужны - в C-style кусках. Один из базовых классов всей программы явно не является локальной низкоуровневой структурой, используемой исключительно в процедурном коде.
Игнорирование этих двух простых правил позволит легко преобразовать любой проект в кучу low-level кода, в котором можно в любое место делать ассемблерные вставки, а модификации будут порождать совершенно неожиданные и трудновоспроизводимые ошибки.

#109
0:00, 15 июля 2019

Adler
> but anyway:
Какое-то мракобесие. У тебя есть 3 структуры:

  t_space_for_rects r2r;
  t_space_for_circles c2c;
  t_space_for_r2c r2c;
Внутри r2c ты хранишь какую-то map-у
struct t_space_for_r2c{
    t_map_v2<t_cell> map;
}
Внутри r2r и c2c у тебя тоже аналогичные мапы? А что в них хранится? Какая структура данных внутри этих мап? Как они делают foreach_from_nightbours ?
Пока твой псевдокод мало отличается от:
struct t_cd_sys_with_spaces{
  void solve(vector<t_rect>&rarr,vector<t_circle>&carr){
    do_it_well_baby(rarr, carr);
  }
}
Еще раз, я тебя прошу написать код, который покажет как от грида ты перейдешь к сравнению объект с объектом. Ты упорно навешиваешь "абстракций", а саму магию, за счет чего будет работать твой foreach_from_nightbours и какая же структура данных у тебя в map - тактично опускаешь.

> не-а, т.к кол-во соседних ячеек которые надо проверять зависит от
> "максимального расстояния между rect`ами и circle`ами при котором ещё есть
> столкновение" и "размера ячейки".
Если взять размер ячейки, который не меньше самого большого объекта в сцене, то проверять надо максимум 9 ячеек. На что я собственно и рассчитывал, когда писал тот свой код.

#110
0:05, 15 июля 2019

MrShoor
> а саму магию, за счет чего будет работать твой foreach_from_nightbours и какая
> же структура данных у тебя в map - тактично опускаешь.
foreach_from_nightbours:
https://github.com/adler3d/Adler3D_RAIC2017_CodeWars/blob/aa3c444… 194.cpp#L1293
t_map_v2:
https://github.com/adler3d/Adler3D_RAIC2017_CodeWars/blob/aa3c444… v194.cpp#L343

#111
0:28, 15 июля 2019

Adler
Посмотрел. Теперь я понял твою позицию. На каждую пару писать одинаковый бойлерплейт из подобного кода:

  struct t_space_for_r2c{
    using t_cell=small_vector<t_rect*>;
    t_cd_sys_with_spaces&cd_sys;
    t_map_v2<t_cell> map;
    void solve(){
      for(auto&circle:cd_sys.mem.сarr){
        auto f=[&](t_rect&rect){cd_sys.solve(rect,circle);};
        map.foreach_from_nightbours(circle.pos,like_manhattan_distance::r2c,f);
      }
    }
  };
Да, так сработает. И да, у тебя получилось ровно так как ты сказал:
если добавить оптимизацию которая использует "особенности пространства" то в результате получиться что-то очень похожее на не читаемое говно для роботов мазохистов.

Особое удовольствие для роботов мазахистов наверное тут:
https://github.com/adler3d/Adler3D_RAIC2017_CodeWars/blob/aa3c444… v194.cpp#L343
#112
0:55, 15 июля 2019

MrShoor
> Да, так сработает.
на самом деле держать/строить три grid`а - ну такое. возможно даже твой вариант с collider`ами и kind`ами может победить.

> Особое удовольствие
да, неудачно получилось. особенно бесит что нужно вручную vec2d в vec2i перегонять, когда надо сделать переход из мировых координат в координаты grid`а. терпеть это не могу.

> На каждую пару писать одинаковый бойлерплейт из подобного кода:
codegen всё стерпит, даже если там придётся продать все абстракции и обмазать каждую строку asm`ом вставками - мне пофигу, всё равно туда без спец.техники заглядывать не безопасно.
и вообще этого ничего не должно быть видно, я вроде не виноват что компиляторы как бы говно и ничего не могут сами по нормальному(продав все абстракции) оптимизировать.

MrShoor
> Если взять размер ячейки, который не меньше самого большого объекта в сцене, то
> проверять надо максимум 9 ячеек
ага, а потом может оказаться что самый большой - слишком большой и вообще размером с четверть карты, поэтому его придёться вручную принимать отдельно ото всех, попутно накидав туда багов.

#113
1:05, 15 июля 2019

Adler
> всё равно туда без спец.техники заглядывать не безопасно.
Туда нужно заглядывать, хотя бы чтобы понимать как это работает. Или у тебя документация на класс t_map_v2 есть, которую можно почитать? Я вот читал, что там происходит, чтобы понять как оно работает.

> я вроде не виноват что компиляторы как бы говно и ничего не могут сами по
> нормальному
Да нет, ты как раз и виноват :) Это и есть те самые преждевременные оптимизации, которые превращают код в говно.

#114
1:07, 15 июля 2019

Adler
> ага, а потом может оказаться что самый большой - слишком большой и вообще
> размером с четверть карты, поэтому его придраться вручную принимать отдельно
> ото всех, попутно накидав туда багов.
Ну у нас же есть конкретная задача, кримсонленд. Если нужно сделать универсально - то следующая оптимизация - это иерархия гридов. В каждом следующем гриде ячейка в 2 раза больше предыдущего. LOD грида выбираем в зависимости от размера объекта.

#115
13:00, 15 июля 2019

Попробую постримить, пока соседи затихли с ремонтом )

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры
#116
17:27, 22 июля 2019

Столкновения вроде бы определяются, но не понятно как избавится от туннелирования пули. Т.е. пуля сталкивает с объектами между кадрами, а в момент сравнения они не пересекаются.

Как это можно красиво отрезолвить?

#117
21:38, 22 июля 2019

Robotex
больше итераций & меньше шаг_времени & больше размер/длина пули & меньше скорость пули

#118
1:46, 26 июля 2019

Еееее, у меня получилось сделать quadtree partitioning.

QuadTree Spatial Partitioning | YouTube-канал про геймдев и программирование. Критикуйте, господа и дамы

Осталось приделать столкновения на основе импульсов

#119
7:50, 27 июля 2019

Robotex
> не понятно как избавится от туннелирования пули. Т.е. пуля сталкивает с
> объектами между кадрами, а в момент сравнения они не пересекаются.
Растягивай объект пули на пройденное ей между кадрами расстояние вдоль оси движения.

Страницы: 17 8 9 10 11 Следующая »
ФлеймФорумПрограммирование