Всё верно. Для решения этого потенциального краша можно добавить какой-нибудь бинарный флаг типа exit в структуру UploadData и обработать его соответственно.
Сжатие на видеокарте шакалит текстуру очень заметно, но и память экономит значительно, поэтому мне не вариант хранить только сжатое. Я даю пользователю выбор какие текстуры грузить — сжатые или не сжатые. Соответственно на винче хранятся PNG'шки без потери качества.
Я делал в потоке рендера glTexImage2D... если он загружает картинку из памяти видеокарты, не сжатую и после него нет генерации мипмапов, то да, скорость мгновенная... но стоит добавить ему флаг сжимать текстуру или генерировать мипмапу после него -- начинаются фризы в рендер цикле, играть становится не возможно. Я пытался сам генерировать мипмапы, но упёрся в странный баг кривой загрузки мипмапы размера 2*2, убил пару дней на него и сдался, пошел другим путём. Самостоятельно сжимать картинку на цпу я даже не стал пытаться.
glFinish я вызываю во втором потоке, скорость работы которого не критична. Я не знаю точно что оно такое и как оно работает, но без него последняя загруженная текстура с некоторой вероятностью не отобразится или отобразится не корректно.
Фишку с UploadData можно улучшить (особенно если вы пишете академический диплом), а можно оставить и так, память не течёт.
Блокировка второго потока, ответственного за загрузку текстур, в ситуации когда загружать нечего... желательна.
Когда пользователь хочет выйти из игры он жмет кнопку, основной поток завершается, все остальные потоки убиваются автоматически. Я точно не знаю как это работает, но оно работает!
Если из этого рецепта убрать glFinish, то последняя заказанная текстура с некоторой вероятностью не будет прогружаться или будет прогружаться визуально некорректно.
Теоретически да. Практически вылетают краши из апи OpenGL, которые невозможно понять, тем более пофиксить. Проще и надежнее опереться на "старый век". Но при желании вы просто можете проигнорировать блок этого кода.
Хотелось бы мне ответить: для простоты понимания рецепта! Но на самом деле я просто дилетант в мультипоточности. Да и просадки в производительности я не чувствую, там в очередь добавляются байтики из основного треда практически мгновенно и почти никогда не файтятся со вторым потоком.
Я не проверяю, сразу использую. Пока текстура не загружена отображается чёрный прямоугольник. Этот рецепт работает на 10+ разных компьютерах. Если очень хочется добавить в свой цикл рендера еще один if, можете проверять таблицу loaded_state.
Здорово что вы можете позволить себе тратить так много времени на анализ и критику чужого творчества в рамках одного проекта. Можно пофантазировать на тему "а что было бы если бы мы еще ревьювили бы соседние проекты тоже". Вот опыта то подкатило бы!
Если 50/50 уступает ревьюер.
И демократия у вас тоже интересная. Два человека не смогли договориться (их общего коммуникационного скилла не хватило), значит нужно привлечь всех вокруг, устроить "судилище" с "присяжными", да еще и после этого "проигравшему" делать вид что ему это не было неприятно ни капельки.
Мы вот больше фокусируемся в декомпозицию проекта на максимально независимые куски и изоляцию программистов между ними и жонглирование задачами таким образом, чтобы к отпуску конкретного программиста их поток ослабевал или вообще ставился на паузу. Конечно, не всегда получается, но и ситуация когда ключевой программист в отпуске — редкая и переживаемая с некоторыми трудностями: заменяющему программисту приходится читать чужой код "adhoc" в момент если есть срочная задача из чужой области ответственности. А не всегда, как у вас.
У меня не было подобной практики, моё предложение буквально высосано из пальца.
Однако однажды мне довелось поработать в фирме, процесс интеграции новых сотрудников в которой был оптимизирован лучше некуда:
— выдается инструкция на 3 листах А4 общекомпанейская куда подключаться и кому какие запросы слать в тех или иных случаях,
— тимлид заранее подготавливает и практически "выстреливает" все необходимые доступы к текущему проекту: гит, тестовый сервак, трекер задач; дополнительно закидывая FAQ или даже wiki, в которых раскрыто 90%+ вопросов,
В дальнейшем, конечно, многое зависит и от качества постановки задач и от уровня кандидата (многое — "время, убитое на разговоры"). Если задачи выставляются опытным тим-лидом, это вообще мёд, он сам их предварительно перечитывает из технической плоскости и сразу раскрывает почти те же самые вопросы, что возникли бы у кандидата.
"Здорово" когда ты делаешь вывод о том, что кто-то другой чего-то не понимает. Все ясно, понятно и думать больше не надо.
Если всё же желание развивать мышление еще есть, предлагаю подумать вот над какими примерами:
1) коллега-прямой-менеджер выслал фидбек, программист его не принял:
— это у программиста отсутствует софт-скилл?
— или это проблема коммуникации с обоих сторон?
одно дело — рассказать о себе, здесь действительно не нужен высокий коммуникативный навык,
другое дело — рассказать о себе так, чтобы с большой вероятностью произвести положительное впечатление на людей, о которых ты знаешь очень мало, вот тут требуется высокий коммуникативный навык,
И как раз поэтому нормальным является когда код ревью проводят все, а не один тимлид, как ТС предлагает. Потому что тогда все могут посмотреть и удостовериться что код удовлетворяет их стандартам качества.
Я всего лишь описал то вижн, что в текущий момент жизни кажется мне оптимальным. Понятие "нормы" субъективно, осторожней с ним.
Было бы здорово узнать поподробнее ваш вижн в котором код ревью проводят все.
Например, что происходит если условно старший кодер залил коммит, трое других его посмотрели, одному всё понравилось, а другим двум что-то непонравилось? Каков план в этой ситуации? Они собираются за круглый стол и обсуждают "как правильно" до тех пор пока не придут к общему? Или на самом деле пока кто-то из них не сдастся, полагая что так будет лучше: и времени меньше потрачено и нервов?
И вы знаете это потому что ваши коммуникационные скиллы на уровне чтения чужих мыслей? Или вам сам интервьюер нашептал после собеса что он оценивал?
Я знаю это потому что сам задавал подобные вопросы и "оценивал" ответы на них. В собеседовании невозможно толком оценить ни сервис ни скиллы, а оценить нечто необходимо, потому мозг спрыгивает с сути на мелочи, некоторые из которых я привел просто для примера.
Ага. А потом талантливый человек уйдёт и разбирайся с его творением. А поскольку он и двух слов связать не может, то никто ничего не знает. Bus factor = 1.
Все боссы об этом мечтают. (Нет.)
Вы кинулись в крайность "двух слов связать не может". Я обсуждаю разницу между высоким коммуникативным навыком и средним. Кажется что мало кто здесь представляет себе что такое высокий коммуникативный навык.
Ваша стратегия "нанять человека получше умеющего связывать слова" мне примерно понятна. Мне так же интуитивно понятно, что такой человек с большей вероятностью не справится со сложной задачей или справится с ней таким образом, что оно всё разъедется и сломается в какой-то момент.
А вот нанятый "гик" после уволенного "гика" спокойно разберется в любом чёрном ящике, читая код и наблюдая поведение системы, вместо того чтобы полагаться на человеческие слова: общение и документацию, часто ошибочную, часто вообще не соответствующую тому что было реализовано на самом деле.
Всё верно. Для решения этого потенциального краша можно добавить какой-нибудь бинарный флаг типа exit в структуру UploadData и обработать его соответственно.
Сжатие на видеокарте шакалит текстуру очень заметно, но и память экономит значительно, поэтому мне не вариант хранить только сжатое. Я даю пользователю выбор какие текстуры грузить — сжатые или не сжатые. Соответственно на винче хранятся PNG'шки без потери качества.
Я делал в потоке рендера glTexImage2D...
если он загружает картинку из памяти видеокарты, не сжатую и после него нет генерации мипмапов, то да, скорость мгновенная... но стоит добавить ему флаг сжимать текстуру или генерировать мипмапу после него -- начинаются фризы в рендер цикле, играть становится не возможно. Я пытался сам генерировать мипмапы, но упёрся в странный баг кривой загрузки мипмапы размера 2*2, убил пару дней на него и сдался, пошел другим путём. Самостоятельно сжимать картинку на цпу я даже не стал пытаться.
glFinish я вызываю во втором потоке, скорость работы которого не критична. Я не знаю точно что оно такое и как оно работает, но без него последняя загруженная текстура с некоторой вероятностью не отобразится или отобразится не корректно.
Фишку с UploadData можно улучшить (особенно если вы пишете академический диплом), а можно оставить и так, память не течёт.
Блокировка второго потока, ответственного за загрузку текстур, в ситуации когда загружать нечего... желательна.
Когда пользователь хочет выйти из игры он жмет кнопку, основной поток завершается, все остальные потоки убиваются автоматически. Я точно не знаю как это работает, но оно работает!
Не знаю. Тут решается не проблема скорости, а чтобы рендер игрового цикла не фризился когда понадобилась новая текстура.
Может быть glFlush лучше чем glFinish. Если кто-нибудь попробует затестит это, пусть отпишется тут о результатах =)
Если из этого рецепта убрать glFinish, то последняя заказанная текстура с некоторой вероятностью не будет прогружаться или будет прогружаться визуально некорректно.
Теоретически да. Практически вылетают краши из апи OpenGL, которые невозможно понять, тем более пофиксить. Проще и надежнее опереться на "старый век". Но при желании вы просто можете проигнорировать блок этого кода.
Хотелось бы мне ответить: для простоты понимания рецепта! Но на самом деле я просто дилетант в мультипоточности. Да и просадки в производительности я не чувствую, там в очередь добавляются байтики из основного треда практически мгновенно и почти никогда не файтятся со вторым потоком.
Я не проверяю, сразу использую. Пока текстура не загружена отображается чёрный прямоугольник. Этот рецепт работает на 10+ разных компьютерах.
Если очень хочется добавить в свой цикл рендера еще один if, можете проверять таблицу loaded_state.
Статью дополнил, спасибо.
Благодарю ;3
Здорово что вы можете позволить себе тратить так много времени на анализ и критику чужого творчества в рамках одного проекта. Можно пофантазировать на тему "а что было бы если бы мы еще ревьювили бы соседние проекты тоже". Вот опыта то подкатило бы!
И демократия у вас тоже интересная. Два человека не смогли договориться (их общего коммуникационного скилла не хватило), значит нужно привлечь всех вокруг, устроить "судилище" с "присяжными", да еще и после этого "проигравшему" делать вид что ему это не было неприятно ни капельки.
Мы вот больше фокусируемся в декомпозицию проекта на максимально независимые куски и изоляцию программистов между ними и жонглирование задачами таким образом, чтобы к отпуску конкретного программиста их поток ослабевал или вообще ставился на паузу. Конечно, не всегда получается, но и ситуация когда ключевой программист в отпуске — редкая и переживаемая с некоторыми трудностями: заменяющему программисту приходится читать чужой код "adhoc" в момент если есть срочная задача из чужой области ответственности. А не всегда, как у вас.
Гикам тяжело даются "ритуалы". Примерно так же тяжело как HR'у — программирование.
У меня не было подобной практики, моё предложение буквально высосано из пальца.
Однако однажды мне довелось поработать в фирме, процесс интеграции новых сотрудников в которой был оптимизирован лучше некуда:
— выдается инструкция на 3 листах А4 общекомпанейская куда подключаться и кому какие запросы слать в тех или иных случаях,
— тимлид заранее подготавливает и практически "выстреливает" все необходимые доступы к текущему проекту: гит, тестовый сервак, трекер задач; дополнительно закидывая FAQ или даже wiki, в которых раскрыто 90%+ вопросов,
В дальнейшем, конечно, многое зависит и от качества постановки задач и от уровня кандидата (многое — "время, убитое на разговоры"). Если задачи выставляются опытным тим-лидом, это вообще мёд, он сам их предварительно перечитывает из технической плоскости и сразу раскрывает почти те же самые вопросы, что возникли бы у кандидата.
"Здорово" когда ты делаешь вывод о том, что кто-то другой чего-то не понимает. Все ясно, понятно и думать больше не надо.
Если всё же желание развивать мышление еще есть, предлагаю подумать вот над какими примерами:
1) коллега-прямой-менеджер выслал фидбек, программист его не принял:
— это у программиста отсутствует софт-скилл?
— или это проблема коммуникации с обоих сторон?
Раскачиваю:
Я всего лишь описал то вижн, что в текущий момент жизни кажется мне оптимальным. Понятие "нормы" субъективно, осторожней с ним.
Было бы здорово узнать поподробнее ваш вижн в котором код ревью проводят все.
Например, что происходит если условно старший кодер залил коммит, трое других его посмотрели, одному всё понравилось, а другим двум что-то непонравилось? Каков план в этой ситуации? Они собираются за круглый стол и обсуждают "как правильно" до тех пор пока не придут к общему? Или на самом деле пока кто-то из них не сдастся, полагая что так будет лучше: и времени меньше потрачено и нервов?
Здорово, когда количество открытых позиций больше 1. В моём опыте открытая позиция всегда была одна, увы.
Я знаю это потому что сам задавал подобные вопросы и "оценивал" ответы на них. В собеседовании невозможно толком оценить ни сервис ни скиллы, а оценить нечто необходимо, потому мозг спрыгивает с сути на мелочи, некоторые из которых я привел просто для примера.
Вы кинулись в крайность "двух слов связать не может". Я обсуждаю разницу между высоким коммуникативным навыком и средним. Кажется что мало кто здесь представляет себе что такое высокий коммуникативный навык.
Ваша стратегия "нанять человека получше умеющего связывать слова" мне примерно понятна. Мне так же интуитивно понятно, что такой человек с большей вероятностью не справится со сложной задачей или справится с ней таким образом, что оно всё разъедется и сломается в какой-то момент.
А вот нанятый "гик" после уволенного "гика" спокойно разберется в любом чёрном ящике, читая код и наблюдая поведение системы, вместо того чтобы полагаться на человеческие слова: общение и документацию, часто ошибочную, часто вообще не соответствующую тому что было реализовано на самом деле.
Можете привести побольше примеров на эту тему, пожалуйста? Желательно поближе к шаблонам. А то пока-что не понятно.