cjayho, Да пофик кто там что считает. Но это так и есть, естественно писать на суржике идея не очень, когда можно на великом и могучим. Смысл писать на английском, когда вся команда говорит и думает на русском, тоже не понятна. Чтобы какой-то залётный амер что-то понял. Если ему сильно интересно, и комменты написаны на грамотном русском, то разберётся с помощью гугла или яндекса. Какие проблемы.

Вот это бомбит из за моих коммитов на русском
Хорошо что репозиторий прикрыли, а гит я использовать не хочу.

Раз на то пошло то программист не должен и не обязан знать какой то конкретный язык, язык это всего лишь инструмент. Мне вот абсолютно фиолетово на каком языке будет написана инструкция к обычному молотку для забивания гвоздей. Кроме того скажу больше, опять же касательно ЯП и коментов них, мне фиолетово на каких языках они если есть исходник, мне в миллиард раз проще глянуть исходник и более менее понять логику кода\класса\метода быстрым взглядом или более пристальным для полного понимая, при этом ни один комент не даст такого представления логики функции\класса\участка кода.
Если конечно залезть в дебри, то они станут сугубо алфавитные. Да я не пойму какой нибудь ЯП на китайско\японском\арабском аналоге 1С и в сотни раз быстрее пойму комментарий на буржуйском. Но в своей основе, все языки используют примитивнейший и единообразный синтаксис, понятия , базовые слова.
А по второму вопросу, вижу ты вообще не видел мир дальше своего носа. Это вот вообще ни разу не так, хотя есть масса индивидов которые пишут комментарии из разряда "прибавить вчера значение по ссылке из мастер луна" только на буржуйском.
Ну и на закуску, английский, как таковой, имеет тонну разновидностей и далеко не все слова\фразы\предложения\произношения\написания имеют одинаковый смысл. Возьми для примера USA\Brit\любой другой ENG, тонны слов и произношений имеют совершенно иной смысл как и тонна других моментов языка. Носители языка в том или ином смысле будут понимать друг друга Теперь возьми для примера кирилицу и наши языки, так же УКР\РУС\БЕЛ\другие языки. Есть масса слов одинаковых, носители так или иначе через смех поймут друг друга, тот кто не является носителем ахереет от такого.

Так вот я к чему все это, возвращаясь к коментариям, да насрать на уровни знания языков, это инструмент. Могу привести аналогию, если я приеду в любую страну
славянскую я так или иначе смогу сказать что ищу обычный сортир, аналогично с любыми странами где так или иначе фигурирует буржуйский я смогу понять и меня смогут понять что я ищу сортир, вот в странах азии\арабских стран(считай асемблер для меня так как даже алфавита их не видел) будут проблемы но просто потому что я не изучал их алфавит а буковки у них иные как и самые базовые слова.

Анализируя посты в этой теме, я вижу, что программисты делятся на два вида:
1) те, кто пишет код. Эти люди без особого труда переключаются с одного ЯП на другой, создают полезные вещи для сталкира и выкладывают их исходники в открытый доступ.
2) те, кто пишет комменты. Эти люди освоили intermediate english и книгу "C++ за 21 день"; пытаются понять чужие исходники, но понимают их в основном по комментам и названиям сущностей; их кода никто не видел.

Что за бред у людей в голове...

Бред, не бред, а нормально выучить энглиш это не просто.
Вот зачем переспрашивать, ты что тупой?
Кому-то например пихтон кажется нууу очень простым ЯП, но у меня другое мнение!
ЗЫ
Короче, энгиш учить не буду, комменты только на русском. И это уже из принципа!!!

А я тебе и не говорил выучить нормально, я говорил выучить для пользования технической документации.

Нет, я не тупой, скорее всего поумнее тебя буду, и даже понимаю, зачем ты такое спросил - огрызнулся, почуяв дискомфорт.

Назло маме отморожу уши, ясно. Можешь из принципа еще себе пару пальцев отрезать или на лице партаки наколоть.

Как хорошо сидеть дома и писать целый день русские коммиты. Ухх, спасибо Сергей Семенович

Привет всем.
Я не курю и как бы не программист, но тем не менее я зашёл именно сюда скоротать с вами время и поделиться частицей из своей жизни. И это отчасти касается данной темы.

Наверное вы знаете, что я работаю на заводе оператором токарных станков с ЧПУ. При этом можно сказать сам себе технолог, программист и наладчик.
Работа слегка пыльная, слегка грязная и слегка оплачиваемая, но я её люблю и мне нравится делать из безобразия пифагорийскую красоту.

Так вот, года 3 назад ко мне подошел технолог и поинтересовался смогу ли я сделать на типа говностанке со старой стойкой винтовую канавку радиусного профиля по внутренней сферической поверхности. Загвоздка была конечно в том , что такое не делали ещё , а он не такой уж и опытный. Поэтому подобные спецы спускаются к обычным рабочим посоветоваться. А ещё эта деталь конечно термообработана и обладает приличной твердостью , что намекает нам мол за один проход хрен обработаешь.
Поскольку я обожаю всякие задачки с наверное лет десяти, то конечно я взялся подумать. Это как вызов. Через пару часов я его обрадовал. Да, получилось теоретически решить - это во-первых. А во-вторых , что в этой ситуации главное, отработать практически, т.е. станок из прошлого не подвёл.
Для архива и просто так закину сюда те мои записи :


Вы знаете, в следующей жизни я буду разрабатывать игры. Я даже по хорошему завидую вам. Но я на данном этапе жизни уже выдохся в этом смысле и новое чувствую не поместится.

Удачи вам.
Пусть у вас хватит сил для решения любых задач.

PS.
Опять сайт перевернул фотографию. А вот вам и первая задача !!!

Mechanical, примерно по такой же схеме делали врезки в движок в проекте xray extensions

Пыльная и дофига грязная, нифига не оплачиваемая работка. Через говноправки и говнотулзы делали интерфейсы доступа во внутридвижковые объекты и в скриптах уже наводили красоту. Тем не менее, от этого какой-то кайф ловили .__.

Если открыть, то норм)

Немного книг по программирования на Humble Bundle.

https://www.humblebundle.com/books/data-ai-...?partner=gameru
https://www.humblebundle.com/books/learn-to...?partner=gameru

Ссылки с нашей рефкой. Система начисления такая же как у всех партнеров хамбла. Т.е. можно выбрать сколько закинуть нам на чай с покупки

Я что то не понимать: у меня Мегафон в игнор занёс гитхаб ( еще и Мега облако не работает), но это всё работает через vpn.
Это наши мутят или нас за Навального дрючат?

Ура Мегу я поборол. Почему она в фаервол упоролась непонятно.

В хосте прописал и зафуричилась

154.53.224.162 https://mega.nz
154.53.224.166 https://mega.nz
154.53.224.158 https://mega.nz
154.53.224.158 https://mega.nz
154.53.224.162 https://mega.nz
154.53.224.166 https://mega.nz
93.184.220.188 https://mega.nz
154.53.224.130 https://mega.nz
154.53.224.134 https://mega.nz

Странно и ГитХаб заработал, хотя я ничего не писал. Только хост очистил. Может сбои были у Мегафона?

Я помню, как-то jamakasi спрашивает.
А как у вас пограмистаф возникают крутые пограмисткие идеи.
Ладно рассказываю. Гранаты, Просто гранаты с РГН и РГО. Надо придумать алгоритм коллизии, ну чтобы отслеживать факт встречи с препятствием.
Le ска так и было.
Ну я так решаю задачу. Скорость гранаты, минус скорость гранаты, на прошлом апдейте, делим на время апдейта... хм разумно.
Но если граната отскочила ровно, то есть было 5 м/с отскочила и стало равно 5 м/с... Эээ значит этот алгоритм, не сработает как надо.
А если вектор скорости гранаты на прошлом апдейте просто вычесть. И подсчитать его длину.....
self.vLastLvel:distance_to(lvel) > self.fVelThreshold
ЭЭЭЭЭ это же гениально...
Ну вот как то так я придумал самый гениальный алгоритм.
Да. Гранаты с ударным взрывателем.
А вы можете сделать лучше?
Увы это не возможно...

FMOD Studio - Free for indies (again!).

Firelight Technologies is happy to announce that FMOD Studio is now free without yearly limits.
To make things simpler, the ‘1 title per year’ rule has been removed.

Developers are now encouraged to release as many games as they want commercially, as long as the developer’s overall yearly revenue is less than $200k USD.
For more information go to www.fmod.com/legal or www.fmod.com/licensing.

Remember to register your project at www.fmod.com/profile#projects to take advantage of the free license!
Too much info? Manage your subscription to only receive big news.

Источник

Скачал для Юнити:
https://drive.google.com/drive/folders/183m...dR3?usp=sharing

Едрить, у вчёра набирал пост уже хороший.

Тут как то jamakasi спрашивает, а что если видосики как создаётся код тоже делать, ну там всякие операторы 3ds max'ов делают видосики.
Ну а почему бы и пограммистам это не делать.
Ага, ну значит как я додумался до кода про "гранаты с ударном взрывателем".
По началу код был таким. То есть был взят из код гравигана за авторством кирага и маландринуса. То есть реальный говнокод, говкодее просто не придумаешь.

Но потом я подумал, а что если просто отслеживать ускорения гранаты.
ускорение=скорость_текущая-скорость_прошлая/апдейт
Но потом подумал, а если граната ровно отскочит, а скорость не поменяется, тогда удар не будет замечен.
Так, а если отслеживать сам вектор скорости?

Это первый оптимизированный код, грязный.
Который затем стал таким.

Вот как то так.

Интересно, вытеснят ли ARM процессоры когда нибудь х86?
Ещё неделю назад я бы с пеной у рта доказывал что НЕТ.
Но потом начал изучать архитектуру АРМа, и понял что это очень даже перспективная архитектура.
Например, скорость вычисления хэшей(hash), что быстрей ARM или x86?
При попытке создать быстрый код на ассемблере CRC32, MD5, sha256, я понял, что на арме я бы сделал быстрей! И это даже на старых армах, 3 инструкции на такт. Хотя кортексы могут и поболее 5 инс/такт.
Хотя на самом деле, современные процессоры внутри именно армы, т.е. RISC архитектура!
Вот так бывает, неделю назад хейтил ARM.
https://wasm.in/threads/arxitektura-arm-vs-...-luchshe.33591/
Но потом, поменял мнение на противоположное. И я, это, ещё толком не изучил ARM.

После запиливания Apple M1 вполне возможно.

Винда и макось уже есть под АРМ, правда у первой нет программ Так что всё зависит от того, как быстро запилят эмуляторы х86.

У AMD очень Risc-подобная Архитектура.
С памятью работает как-бы быстрее.
Х64 ARM в общих чертах проэкт AMD.

Нвидиа недавно купила ARM, нужно ждать
Новые платы со встроенными Нвидиевскими видяхами.

Вытеснят, если популярные софты, прежде всего Windows, напишут и оптимизируют под ARM.

Так уже есть под планшеты Surface Win 8.1. Там есть офисс, многозадачность, даже неплохие игрульки.

Apple сделали свою крутую хрень, которая при установке х86 приложения на ARM устроиство перелопачивает весь код под ARM, и потом это приложение запускается нативно под ARM. Т.е. вместо эмуляции x86 под ARM, происходит перекомпиляция бинарника. Поэтому у яблочников это быстрее и лучше, чем в ARM винде.

Что-то сомнительно. Интел считает crc32 за такт, sha256 за два такта(нет).


Злые языки в интернетах клевещут, что у современных армов VLIW архитектура


Еще поизучаешь, передумаешь обратно.


Так-то еще пентиум мог 32 микроинструкции за такт выполнять. И что в этом хорошего? Опять только компилятор сумеет инструкции укладывать, чтобы пучок за такт выполнялся. VLIW как он есть. Почитай про эльбрус, может сразу за него взяться?

У меня Athlon II X4 640
CRC32 - 5 тактов, MD5 - 6.3 тактов, she256 - 27.7 и это всё на ассемблере (инструкции не выше 686, но как правило 486), и С подсчитал she256 за 24.2 такта. За байт.
На суперскалярном АРМе можно быстрей, главное, чтобы процессор считал за один такт.
А во обще АРМ, это RISC, а RISC упрощенная кодировка команд, именно кодировка команд имеется ввиду, хотя сами команды достаточно сложные, и могут сразу несколько действий сделать.
a += (j << 2);
ADD Ra, Ra, Rj, LSL #2
Надо потом нормальный ассемблер для АРМ сделать, что сейчас есть, полная фигня, только усложняет разработку и понимания кода на ровном месте.

Тут наверное надо пояснить, что современные процы AMD и Intel используют декодер инструкций, чтобы преобразовывать х86 инструеции в несколько небольших RISC- подобных команд, которые уже непосредственно летят в кеш, очередь выполнени и в вычислительные блоки.

Не знаю точно, когда умерли нативные х86 процессоры, но они стали чудовищно неэффективными уже давно.

Я предполагаю, что на AMD процах может быть достаточно заменить фронтенд ядер на ARM совместимые, чтобы почти целиком переделать Zen под ARM. Но фронтенд в современных процах очень большой и сложный - именно там куча оптимизаций очерёдности выполнения инструкций (и дырок безопасности у ынтол). Сами вычислительные блоки занимают очень мало места, а кеш по сути - матрица из одинаковых ячеек. Так что самое сложное в быстром процессоре - это не создать эффективные вычислительные блоки, а обеспечение эффективной подачи данных и инструкций этим блокам.

Не хочу x86, не хочу ARM, хочу MIPS.

Или Motorola 68000, вот там то удобно на ассемблере кодить, можно даже операции с двумя операндами в памяти производить, а не только регистр-регистр и регистр-память как на x86. То есть грубо говоря x86 код

на мотороллере валидный, а отличии от x86.

MIPS прост и офигенен, m68k наворочен и невероятен, всё остальное не нужно.

Перейди по ссылке. Там CRC32 0.145 такта за байт

А на ARM сколько?

Это где 0.145 т/б? Это аппаратный ускоритель? С ним, старому процессору тягаться не возможно. У меня старый процессор и только по базовый набор инструкций. Никаких AVX у меня нет! И мой проц может только 3 инструкции/такт, и он не умеет сливать сложные команды.

Вот здесь. Да, добавили спец. команду в процессор десять лет назад. Так что может и в твоем атлоне есть. И позже добавили спец. команды для sha.

Команда есть в наборе SSE4.2, но её нет в SSE4A. Так что нету её у меня.
А вообще, говорилось реализация хэшей с помощью базовых наборов, х86 и АРМ. Так вот, АРМ рвёт х86 только так, в точности по скорости работы хэшей. Там где х86 3 инструкции использует, АРМ использует одну, и как правило на суперскалярных АРМах эта инструкция вычисляется за один такт. А х86 тем временем потратит 3 такта. И лишь благодаря волшебному слиянию команд, может выполнить код быстрей, но это только новые процессоры, вроде райзена. Т.е. происходит процедура замены этих команд на одну АРМ подобную.

NanoBot-AMK, а результаты арма есть или он рвет в теории?
Кроме того не очень понятно, зачем сравнивать современные армы с x86 двадцатилетней(а то и тридцатилетней) давности. Наверное да, современные армы должны быть эффективней старинных х86, но это не точно. Почему не сравнить нынешние армы хотя бы с десятилетним интелом?


У всех процессоров сейчас есть волшебное слияние. Ты же сам упоминал 3 операции за такт на арме. На х86 "слияние" появилось в пентиумах(1992г). С тех пор все х86 с "волшебным слиянием".

По моим расчётом на hash MD5, ARM типа Cortex, должен тратить 4 такта на байт.
Тем временем современные процессоры х86 дают около 5 т/б, а мой как я говорил 6.36 т/б.
Слияние могут только самые последние процы делать. Об этом Кошак упомянул, и при чем не так эффективно, как если бы код сразу в RISC код переделать.

Не хочу начать очередную срач дискуссию, но такой вопрос: чем JavaScript плох перед Lua при применении в играх?

Не знаю. Как по мне, оба одинаково плохи.

Это не ответ. Ладно, чем оба языка одинаково плохи?

Динамическая типизация.

Бенчмарки скриптовых языков: https://github.com/r-lyeh-archived/scriptorium

С точки зрения интеграции в движек lua лучше, он изначально для этого создан и весьма широко применяется. Хотя и с интеграцией js были вроде движки, как минимум помню игру crome но не помню там была java или javascript а это разные языки.
Тут надо понимать принципиальные разницу. LUA был изначально придуман как нечто что интегрируется в другое приложение, и собственно там и застолбился. JS же изначально был уродцем который берет синтаксис Java который сильно в свое время всем зашел, но при этом типа без ниши как таковой, типа куда пойдет. Пошел он в веб, набрал критическую массу и сейчас изза этого костылями шагает назад в виде nodejs. К слову как человек пишущий на java иногда могу сказать что в ней есть встроенная поддержка ecmascript(js) в каждой версии, но ниразу не видел чтобы хоть гдето применялся на серьезных щщах.


Не соглашусь, все в меру должно быть. Если в игре реализуют львиную долю логики в на скриптовых языках то это зло кровавое. Если это используют с умом, скажем используют чисто в квестах\катсценках и т.д. то это зачастую очень удобно для левелдизайнеров\квестописателей. Быстро въехали в язык и могут творить невероятные вещи. А вот когда в скрипты начинают тащить куски игры то это фейл в большинстве случаев, программисты движка страдают, дизайнеры страдают, все страдают и это всегда является тормозом разработки.

Ну тут сыглы. Насчет быстро въехать - хз, лично мне сами по себе скриптовые языки нифига не проще компилируемых. А простота достигается за счет хорошего АПИ/библиотеки с кучей удобных и полезных готовых функций и классов.

Каждый инструмент хорош для своей задачи. Говорить о том, хороша ли дин. типизация или плоха, это тоже самое что говорить о молотке и кувалде. Одно другое заменить не может.

Так динамическая типизация - это и есть отсутствие инструментов под разные задачи. Сидишь как дурак и документируешь что в какой переменной лежит, или вобще забываешь и умножаешь уток на милиграммы.

экономия времени написания кода. А время деньги. Если нужно производительное решение, то берутся ЯП со статической типизацией.


Это проблема программиста, а не ЯП. Смысл переменных при статической типизации также требует документирования.

Сколько времени примерно экономится в процентах?

Достаточно, чтобы люди для этого придумали больше 10-ка языков.

Вечнодерьмовые интерпретаторы. В нулевые годы они были либо кривыми (Mozilla, SpiderMonkey) либо закрытыми (Opera) либо кривыми и закрытыми (IE). Можно до сих пор скачать на сайте у мозиллы какие-нибудь древние spidermonkey типа 1.6 и испытать на своей шкуре.
Потом кривизна немного пофиксилась, но не исчезла, интерпретаторы JS стали очень тяжеловесными, и только после этого появились всякие фичи типа JIT-компиляции, которые для игр желательны.

LUA напротив был стабилен уже очень давно, LuaJit тоже существует очень давно, и он не тяжеловесный.

Никаких преимуществ JS перед луа как язык не имеет. Они вообще почти одинаковые, на самом деле, потому что JS был слизан с луа и отличается только синтаксисом.
Короче всё понятно должно быть, почему.

Достаточно это сколько?

Динамическая типизация - это как раз самый главный инструмент под разные задачи. В реальных программах большинство данных хранится в структурах и контейнерах, а не стековых переменных. И вот тут уже здорово упрощаются многие задачи.
К примеру если тебе нужна функция которая выводит в лог структуру в виде строки, тебе в JS понадобится одна универсальная функция, которая принимает любой объект, перебирает все поля объекта и записывает в виде строки. В статических языках тебе понадобится для каждого типа(структуры) писать отдельную функцию, а типов могут быть тысячи.

Контейнеры это вообще отдельная песня. Без динамической типизации они выливаются либо в кучи небезопасных кастов, как например в делфи TList*, либо в особо дурацких языках таких как C++ в шаблоны, которые ведут к ужасному code-bloat, если у тебя в проекте 10 DLL, и в каждой из них используется std::vector<int>, код его реализации будет содержаться в каждой ДЛЛ, и не надо петь что это совсем немного и оперативной памяти у тебя достаточно, нерезиновые кеши у процессоров никуда не делись до сих пор.
Кроме этого, шаблоны ещё увеличивают время компиляции, вплоть даже до нескольких часов, если проект большой. У программеров тогды возникает желание это время экономить, они вкручивают луа с динамической типизацией который компилируется на лету при запуске программы и выносят туда весь некритичный к производительности код... Ну ты понел.

Бывали ещё языки которые совмещали динамическую и статическую типизацию, например ActionScript, но чёт не взлетело. Вот даже ты флеш не любишь. Остался только TypeScript от корпорации майкрософт, это такой ActionScript, который компилируется в JavaScript без ограничений, и сводит на нет всю пользу от своей строготипости.

* Ради великой справедливости, в делфи уже тоже шаблоны добавили, только они не шаблоны, а дженерики, но эт не важно.

Тут вопрос в сторонних людях. Вот пишешь ты свой двиг, и ты хоть 1000 раз обмажся красивым и удобным api но не сможешь заставить этим пользоваться левелдизайнера. А вот тот же Lua который ты подключишь и вынесешь только нужные api и задокументируешь изучиться буквально за вечер, максимум два. В любом случае это тоже в какомто роде костыль т.к. ты как разработчик движка должен был сделать удобный инструментарий вместо скриптов.
Взять для примера двиг goldsrc\source\квековские шде для левелдизайнеров\мапперов инструмент в виде IO между сущностями. Это очень удобно, пока не перерастает в сложные скрипты и тогда это уже проблема. Был бы именно скриптовый язык типа js\lua\angelscript то такие штуки были бы в разы проще.

Короче, нужна золотая середина.

Так это разные кеши же: кеша данных и кеша инструкций.

И как раз 10 копий стдвектора это кэшфрендли. Код, использующий вектор, и код самого вектора лежат рядышком и в кэше. Процессор все инструкции достает из кэша, а не мотается по всей памяти при вызовах методов вектора

Шаблонность(дженеричность) - это предсказатель переходов-френдли. У тебя нет переходов в зависимости от типа элемента. Тупые безусловные переходы, которые процессор просматривает на 100 команд вперед и затягивает в кэш инструкций.