гитхаб показать?

Если у них есть гитхаб с открытым кодм телеги, тогда не надо.

А пруфы то есть ?

Глянул сорсы. С++ код хороший. Ты посмотри на какой-нибудь CRYEngine. Вот там плакать захочется

Глянул сорсы. С++ код хороший. Ты посмотри на какой-нибудь CRYEngine. Вот там плакать захочется

Глянул сорсы. С++ код хороший. Ты посмотри на какой-нибудь CRYEngine. Вот там плакать захочется

пойдешь мейнтенить его для федоры например, тогда?

я если что не в теме - никогда не следил за телегой :) P.s - а десктопчег версия, Виталик на которую ты скинул пруф, она official ? Если нет, так и претензий к телег никаких нету, как таковых - остальное, это уже те кому нужно пилят

У меня генту

А что его мейнтейнить? УМВР

> Вот там плакать захочется они так в названии и написали

Ты так говоришь, как будто это плохо. Мы вот выпускаем игру под линукс и тоже распространяем его блобом со статически слинкованным openssl. Это удобно и везде работает

Не надо так делать. Это ставит пользователей под угрозу. Дыры в OpenSSL находят постоянно.

Не надо так делать. Это ставит пользователей под угрозу. Дыры в OpenSSL находят постоянно.

Не надо так делать. Это ставит пользователей под угрозу. Дыры в OpenSSL находят постоянно.

А вот зачем они для критичной либы bsd лицензию выбрали? Была бы LGPL, проблем бы не было

вот мой :D

https://t.me/pogromisty

Не надо так делать. Это ставит пользователей под угрозу. Дыры в OpenSSL находят постоянно.

Пишу, конечно может и хуйню. Но какое мне дело, главное это ... $

На самом деле, у меня один из самых быстрых SHA_1 хешей, с интринсиками и т.п :)

Нет ну а что ты хочешь, беркус - если нужно будет, я конечно выложу. Это не проблема - это тебе не Пуассона минимизировать на CUDA. Но все равно, я скидывал скрин не для того чтобы рассказать о скорости, а чтобы сравнить свой код с ТГ

Ну это его заливать надо на GH - мне реально в лом, но то что работает быстро, тестировал, проверял на том что отыскал в опенсорсе, например и еще с парой коммерческих версий тех мест где работал

о, нашёл консольный телеграм клиент. https://github.com/vysheng/tg QTшный не нужен

Добрый вечер, есть у меня вопрос архитектурный: Предыстория: пишу небольшой игровой движок, стараюсь построить красивую и безопасную компонентную систему, компоненты хранят только данные, обобщенная логика находится в системах движка, каждая из которых отвечает за свой круг задач (рендеринг/ввод/скриптовая система и тд). И так получается, что некотоые семейства компонентов тесно связаны с сопровождающими их системами, из которых компонентам в СТРОГО ОПРЕДЕЛЕННЫХ случаях нужно дергать часть интерфейса. Например, при создании компонента GLObject, описывающего объект, который может быть отрисован системой рендеринга, компоненту требуется "регистрация" в этой системе, при удалении компонента - наоборот. Для того, чтобы выборочно открывать интерфейсы некоторым компонентам, использую паттерн Attorney/Client: систему сопровождают friend-классы, которые через static-функции и friend могут выборочно открывать часть интерфейса компонентам. Вопрос: есть ли еще какие-нибудь стратегии для предоставления выборочного доступа к закрытому интерфейсу, кроме вышеописанной? Не хотелось бы плодить негибкике зависимости или открывать интерфейс полностью.

Мы тоже пилим свою ECS. Но у нас система получает события о создании или удалении энтити и уже может запросить у энтити компоненты, которые ей нужны. Если он есть, то они регистрируются.

Все таки продублирую и сюда:

А если компонент вешается на энтити не в момент создания, как вы поступаете? каждая система подписана на каждый энтити и должна при каждой итерации его вытягивать из энтити?

я с вами совершенно согласен Сделать систему отрисовки по совместительству фабрикой - неплохая идея, но проблема в том, что GLOjbect как компонент связан не только с самой системой, но и с Entity, на котором висит компонент. В любом случае требуется регистрация с двух сторон. Хотя, забудьте все, написанное выше. Пока печатал, придумал workaround : ) По поводу dto: предназначение компонента в контексте системы отрисовки - не передавать данные, а просто хранить их в четко определенном месте с четкой структурой. Это продиктовано устройстом графических API, обращение к данным для выставления состояния внутренней стэйт-машины должно происходить как можно меньшее количество раз. Обращения к драйверам для выставления состояния очень дорогие (в тесном цикле). Исхожу из того, что системе всегда лучше знать, когда ей стоит обращаться к стейт машине и стоит ли вообще. Компонент этого знать не может. Он, в общем-то, может узнать, но это снова потребует лишней переброски данных, а это недопустимо.