А буквально сегодня, хотя может по ввремени завтра, выходит уже NET 9! Ещё больше улучшений. Сам не вижу поводов сидеть на старых версиях, если новые версии хуже старых, надо вообще бежать от такой ссистемы, ведь она будет мертва со временем. Но таких не встречал, кроме стареющего тела... 😢 Сам пишу свой движок, глобально пока в самом начале, всегда перехожу на актуальную версию в первые дни, сейчас планирую оновляться прямо завтра утром.
В итоге, IDisposable вы использовали правильно, для освобождения ресурсов, которыми .NET не управляет, раз ресурс в OpenGL сам не убивался. В любом случае, сносный вариант. Также мы используем IDisposable с чтением файлов, потоков (Stream) и тп, что сидит в памяти и само не помрёт, если не прибить явно.
В .Net новых версий понадобавляли много возможностей для оптимизаций, те же например ArrayPool и Span/ReadOnlySpan. Даже сделали опцию компиляции в нативный бинарник, то есть при включенном NativeAot пользователям не нужно будет отдельно устанавливать рантайм и плюсом намного меньше потребление памяти. Короче, есть куда разгуляться. Единственное, что не ясно, так это насколько вообще генерация мусора влияет на производительнось (в некоторых случаях очень плохо, тому пример оригинальный майнкрафт). Но например короткоживущие объекты, допустим какой-нибудь итератор, по идее оптимизированы сборщиком под короткий срок жизни. Так вот вопрос: это маленький мусор создает фризы или большой, по типу выгруженных чанков. Или всё сразу?
Изначально фриза создавались из-за того, что данные чанка передаваемые по пакету из сервера к клиенту, тратили свыше 85 кб и попадали в LOH, а он чиститься очень медленно. Фриз вылетал из-за него. Текущие фризы бывают, только из-за так сказать нехватки оперативной памяти, т.е. на мои 16 гб, и запущенных приложений на 10+, когда я хочу использовать обзор 32, мне надо где-то около 5 гб, а это уже на пределе, и сборщик чаще и глубже пытается очистить. По этому он и просаживает. Когда на компе мало приложений, обзор 32 работает прекрасно. Ну понятно обзор 16, 20, 24 работаю прекрасно.
Странно он работает с графикой никто дальние объекты не отрисовывает полностью, по мере приближения объект обычно заменяется (если бродилки то можно взять объект со спины (перед его выгрузкой или уничтожением) ты его все рано уже не увидишь пока обратно по маршруту не пойдешь.
Level of Detail (Lod) и Frustum Culling называется. - Lod не реализовывал, сейчас есть мысль но надо определится, что упрощаться (блоки и так простые, а чанк это сложнее и затратнее), вообщем тестировать надо. - Frustum Culling, реализован.
@@SuperAnt2012 Меня просто добила скорость прорисовки на полигоне дальних объектов на виде с верху, зачем дальние объекты рисовать с низу , достаточно показать только верхнюю часть в зависимости от угла обзора.
@@Борода-ф9ъ Затем, что чанка запечатывает всего две сетки, одна для альфа блоков (полупрозрачных), а вторая сплошных. И вот после рендера, если чанк не меняется, где бы ты не был, ты просто прорисовываешь. А так если ты спустился вниз, тебе надо все чанка заново перерендерить, а это не быстро. Альфа чуть иначе работает, так-как её надо сортировать. На видео ещё нет альфы, там только одна сетка на чанк.
@@SuperAnt2012 Странный подход к графике, у тебя объекты все одинаковые были бы разные да пришлось делать как у вас , но тут то все проще, спустился вниз заменил на такой же. Тут надо выбирать или скорость игры без фризов в определенном объеме полигона или тормоза при загрузке всего полигона
@@Борода-ф9ъ Что подразумевается под словом объекты? Сетки как раз таки разные. Я что-то другого решения не вижу более быстрого. Все остальные решения это дополнительная нагрузка на CPU и оперативную память.
Дотнет для разработки движка - такое себе решение. Понятно что тут в качестве реализации рендеринга скорее всего используются биндиги к высокоуровневым API вулканов или дайректиксов, но всё же, один только GC создаст кучу проблем. Если же проект не большой и не требует высокой скорости, то почему бы и нет. Смотреть и вникать лень если честно. Автору удачи.
Его нет в фреймворке. По этому о его существовании не знал. Прочитав, покуда не придумал как его можно прикрутить. Проблемка зашита в сетевых пакетах, а не хранении данных чанка.
@@SuperAnt2012 Если использовать SocketAsyncEventArgs и обвязку вокруг него-то там пулирование памяти для отправки/получения задумано "из коробки". Но это уже забытая 99% разработчиками .NET технология. :) Но она по факту самая масштабируемая в .NET стеке для сетевых приложений, я много чего щупал, за почти уже 20 лет разработки сетевых приложений для .NET так ничего лучше и не придумали для большого онлайна. Минус только один-голый TCP(для меня это же плюс, у меня своих велосипедов за это время столько скопилось, что поддерживается все-начиная от авторизации, конвееризации, кластеризации, шифрования и много чего еще :) ). Кто конечно с нуля будет стартовать-тяжко.
@@_uralgo_37 кстати да реально, тут C# преобразуется в C++, правда разработка всё ещё ведётся на C#. С таким же успехом можно на python делать игры (не советую) и говорить, что они на C.
Только нюанс-самая большая ММО на планете в рамках одного игрового мира Eve Online имеет написанный на Python бекэнд :D Руки решают в итоге, и алгоритмы.
А буквально сегодня, хотя может по ввремени завтра, выходит уже NET 9!
Ещё больше улучшений.
Сам не вижу поводов сидеть на старых версиях, если новые версии хуже старых,
надо вообще бежать от такой ссистемы, ведь она будет мертва со временем.
Но таких не встречал, кроме стареющего тела... 😢
Сам пишу свой движок, глобально пока в самом начале, всегда перехожу на актуальную версию в первые дни, сейчас планирую оновляться прямо завтра утром.
В итоге, IDisposable вы использовали правильно, для освобождения ресурсов, которыми .NET не управляет, раз ресурс в OpenGL сам не убивался. В любом случае, сносный вариант.
Также мы используем IDisposable с чтением файлов, потоков (Stream) и тп, что сидит в памяти и само не помрёт, если не прибить явно.
В .Net новых версий понадобавляли много возможностей для оптимизаций, те же например ArrayPool и Span/ReadOnlySpan. Даже сделали опцию компиляции в нативный бинарник, то есть при включенном NativeAot пользователям не нужно будет отдельно устанавливать рантайм и плюсом намного меньше потребление памяти. Короче, есть куда разгуляться.
Единственное, что не ясно, так это насколько вообще генерация мусора влияет на производительнось (в некоторых случаях очень плохо, тому пример оригинальный майнкрафт). Но например короткоживущие объекты, допустим какой-нибудь итератор, по идее оптимизированы сборщиком под короткий срок жизни.
Так вот вопрос: это маленький мусор создает фризы или большой, по типу выгруженных чанков. Или всё сразу?
Изначально фриза создавались из-за того, что данные чанка передаваемые по пакету из сервера к клиенту, тратили свыше 85 кб и попадали в LOH, а он чиститься очень медленно. Фриз вылетал из-за него.
Текущие фризы бывают, только из-за так сказать нехватки оперативной памяти, т.е. на мои 16 гб, и запущенных приложений на 10+, когда я хочу использовать обзор 32, мне надо где-то около 5 гб, а это уже на пределе, и сборщик чаще и глубже пытается очистить. По этому он и просаживает. Когда на компе мало приложений, обзор 32 работает прекрасно. Ну понятно обзор 16, 20, 24 работаю прекрасно.
Странно он работает с графикой никто дальние объекты не отрисовывает полностью, по мере приближения объект обычно заменяется (если бродилки то можно взять объект со спины (перед его выгрузкой или уничтожением) ты его все рано уже не увидишь пока обратно по маршруту не пойдешь.
Level of Detail (Lod) и Frustum Culling называется.
- Lod не реализовывал, сейчас есть мысль но надо определится, что упрощаться (блоки и так простые, а чанк это сложнее и затратнее), вообщем тестировать надо.
- Frustum Culling, реализован.
@@SuperAnt2012 Меня просто добила скорость прорисовки на полигоне дальних объектов на виде с верху, зачем дальние объекты рисовать с низу , достаточно показать только верхнюю часть в зависимости от угла обзора.
@@Борода-ф9ъ Затем, что чанка запечатывает всего две сетки, одна для альфа блоков (полупрозрачных), а вторая сплошных. И вот после рендера, если чанк не меняется, где бы ты не был, ты просто прорисовываешь. А так если ты спустился вниз, тебе надо все чанка заново перерендерить, а это не быстро.
Альфа чуть иначе работает, так-как её надо сортировать. На видео ещё нет альфы, там только одна сетка на чанк.
@@SuperAnt2012 Странный подход к графике, у тебя объекты все одинаковые были бы разные да пришлось делать как у вас , но тут то все проще, спустился вниз заменил на такой же. Тут надо выбирать или скорость игры без фризов в определенном объеме полигона или тормоза при загрузке всего полигона
@@Борода-ф9ъ Что подразумевается под словом объекты? Сетки как раз таки разные. Я что-то другого решения не вижу более быстрого. Все остальные решения это дополнительная нагрузка на CPU и оперативную память.
Дотнет для разработки движка - такое себе решение. Понятно что тут в качестве реализации рендеринга скорее всего используются биндиги к высокоуровневым API вулканов или дайректиксов, но всё же, один только GC создаст кучу проблем. Если же проект не большой и не требует высокой скорости, то почему бы и нет. Смотреть и вникать лень если честно. Автору удачи.
Почему ArrayPool не используете?
Его нет в фреймворке. По этому о его существовании не знал.
Прочитав, покуда не придумал как его можно прикрутить. Проблемка зашита в сетевых пакетах, а не хранении данных чанка.
@@SuperAnt2012 Если использовать SocketAsyncEventArgs и обвязку вокруг него-то там пулирование памяти для отправки/получения задумано "из коробки". Но это уже забытая 99% разработчиками .NET технология. :) Но она по факту самая масштабируемая в .NET стеке для сетевых приложений, я много чего щупал, за почти уже 20 лет разработки сетевых приложений для .NET так ничего лучше и не придумали для большого онлайна. Минус только один-голый TCP(для меня это же плюс, у меня своих велосипедов за это время столько скопилось, что поддерживается все-начиная от авторизации, конвееризации, кластеризации, шифрования и много чего еще :) ). Кто конечно с нуля будет стартовать-тяжко.
Одна из причин почему с++ используется в созданий игр
Unity
Плюсы класные конечно, но не для всех и не всегда...
Неудачный пример, в большинстве случаев билд через il2cpp проходит
@@_uralgo_37 кстати да реально, тут C# преобразуется в C++, правда разработка всё ещё ведётся на C#. С таким же успехом можно на python делать игры (не советую) и говорить, что они на C.
Только нюанс-самая большая ММО на планете в рамках одного игрового мира Eve Online имеет написанный на Python бекэнд :D Руки решают в итоге, и алгоритмы.
тут уже 9 вышел)
Чуть-чуть подожду и перейду на 9-ку
@SuperAnt2012 да, я уже откатился)))