The ExtremeCode Times
39.9K subscribers
551 photos
47 videos
5 files
512 links
IT punks.

❤️ YouTube
https://youtube.com/ExtremeCode

💸 Реклама
@Mshvyag / eaa@extremecode.studio

Для РКН: № 5025353650
Download Telegram
Вайбкодинг - это просто форма говнокодинга. Когда кто-то в интернете говорит, что в говнокоде нет ничего страшного, в него летит говно, но стоит добавить немножко нейросетей, это уже "вайб". Ну и клоунярство.
А вот теперь экономике точно пиздец. Помните я говорил, что кризис айтишки можно прочитать по падению цены на медь? Это, так называемый, опережающий индикатор. Ловите график. ОБЪЯВЛЯЕТСЯ ПОГРУЖЕНИЕ. ВСЕМ ПРИСТЕГНУТЬ РЕМНИ, ЭТО НЕ ФЕЙК ОЧКО. ЭТО РЕАЛЬНОЕ ОЧКО. ААААААААААААААААА
Крч, решил по фану вкатиться в кодинг графики. Накатил хипстерский стек: .NET 8; Silk.NET; OpenGL, вся хуйня.

Ковырялся в духе вайбкодеров примерно 2 недельки во всем этом дерьме. Осталось неприятное послевкусие во рту. Собственно, ВСТАЛ ряд вопросиков:

1. Сука, в 2025-ом году серьезно никто не додумался сделать какой-нибудь современный API для OpenGL, хотя бы в виде адаптера. Ведь он, литерали, работает как стейт-машина из 1985-го года, где порядок вызова функций влияет напрямую. Т.е. одна ошибка и ты ошибся. Как это дебажить — я в принципе нихуя не понял и судя по всякмим исходникам на просторах гитхаба — не я один такой.

2. А ЧЕ ТАК СЛОЖНО?

Пиздец, я ковыряюсь чисто в два дэ, ладно, даже мельком 2.5 дэ затронул. В чистое три дэ даже близко не лезу.

Вот примерный порядок действий для отрисовки жпега на экране:

1. Инициализировать буфферы вершин и индексов (опционально для последних)

2. В буффере вершин методом тыка или гуглежки (у меня пространственный кретинизм, я не могу визуализировать в пространстве положение точек), нужно состряпать полигон, в форме прямоугольника/квадрата на котором будет отображаться этот сраный жпег.

Cюда еще может добавиться пару параметров, которые будут заюзаны при размещении сраной текстурки.

3. Создать этот сраный буфферный объект в памяти видюхи

4. Скопировать данные из оперативки в этот сраный объект в памяти видюхи

5. Написать сраный шейдер, который будет накладывать этот сраный жпег на сраный прямоугольник

6. Загрузить сраную текстуру в память (тут можно еще 10 подпунктов описать)

7. Создать сраную ортографическую проекцию

8. Переключить состояние рендера в СПЕЦИАЛЬНОЕ ХУЙ ПОЙМИ КАКОЕ ДЛЯ ОТРИСОВКИ 2D

9, Забиндить все объекты, текстурки, шейдеры в АКТИВНОЕ состояние

И лишь потом в конце вызывать простенький метод отрисовки жпега.

Имаджинируй ебало разработчика движка, которому нужно рендерить сцену из большего числа объектов. Вкусно пиздец 🥰
Please open Telegram to view this post
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Вот че смог накодить 🥰
Please open Telegram to view this post
VIEW IN TELEGRAM
Как истинный софтваре инженер, попробовал щас декодировать видеопоток ogg/Theora софтварно — получил уверенные 9 кадров в секунду.

Ожидаемый затык в конвертации YUV -> RGB

Пока растодрочеры делают это за ~3 наносекунды, у меня на один кадр уходит бесконечное количество времени.

Не хотелось, конечно, подрубать ffmpeg для аппаратного декодирования, но я хотя бы попытался. В честь этого, в качестве временной акции, возвращаю реакт клоуна 🥰
Please open Telegram to view this post
VIEW IN TELEGRAM
Позалипал вчера пару часиков с китайским Иван Иванычем, знатно накодили unsafe фигни, ну зато быстро. С учетом того, что оригинальное видео идет в 24 кадра.

ТРЕБУЮ отмены клоунов с предыдущего поста, а также письменных извинений в каментах 🥰

Крч, это вообще треш. Там, некий Ярик, (респект ему конечно за проделанную работу) переписал код Theora декодировщика с Java на C#. Оригинальный код прямиком из 2004-го года. Вот тут это дело можно заценить.

И вот тот участок кода [89-ая строка], который выдавал мне крепкие девять кадров.
Please open Telegram to view this post
VIEW IN TELEGRAM
> ИИ ОСТАВИТ ТЕБЯ БЕЗ РАБОТЫ
> ПРОФЕССИЯ ПРОГРАММИСТА — ВСЁ
> ТВОЯ БАБУШКА ЛЮБИТ ЧАТЖПТ БОЛЬШЕ, ЧЕМ ТЕБЯ
> ДЖУНЫ БОЛЬШЕ НЕ НУЖНЫ

Знаете, люди склонны преувеличивать или преуменьшать значимость открытий.
35 лет назад всерьёз думали, что сейчас все будут летать в отпуск в космос, вместо засраного оверпрайс трёхзвёздочного отеля в Анапе.
При этом один из создателей лазера в интервью даже не представлял, что тому найдут такое широкое практическое применение. Коллеги кекали с него, типа, делает какую-то шляпу.

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

А не переоцениваем ли мы Иван Иванычей?
This media is not supported in your browser
VIEW IN TELEGRAM
Навайбкодил движок за месяц до такого состояния. Я ввязался в это, не потому что это легко, а потому что я ДУМАЛ, что это будет легко.

Вообще, хотел позаморачиваться с рендерингом графики, а выяснилось, что в данном случае — рендеринг, это самая легкая часть.

Че, как на счет N-часового видоса в котором поэтапно раскрываются все нюансики производства такого движка?

P.S.
Но в любом случае, нужно сначала докодить, тут еще месяц на допиливание оставшихся функций и полировку, как минимум.
Специально для неслишком умных чуваков из каментов: Я воссоздаю движок уже готовой игры, а не пилю игру с нуля. Где вы тут смогли увидеть противоречие в принципе? Игра называется Scratches / Шорох.

1. Игра Abandonware; в правовом аду, она не может продаваться
2. Оригинальный движок игры максимально хреново сохранился:
2.1 SCream это скриптовый хост, который работает, как стейт машина, т.е. обрабатывает команды подающиеся в него последовательно, в зависимости от текущего стека состояний.
2.2 Вся игра написана на Lua, байткод легко декомпилируется — но он содержит в себе только игровую логику, а не стек состояний / рендеринг / звук / интеракцию с предметами / etc

Пример создания кубмапа на Lua в игре, который обрабатывает движок:
  scCreate(SC_ROOM, "house-guest")
scBegin(SC_ROOM)
scCreate(SC_NODE, "n1")
scBegin(SC_NODE)
scTexture(SC_FRONT, "hs-guest_n1f.jpg")
scTexture(SC_BACK, "hs-guest_n1b.jpg")
scTexture(SC_LEFT, "hs-guest_n1l.jpg")
scTexture(SC_RIGHT, "hs-guest_n1r.jpg")
scTexture(SC_UP, "hs-guest_n1u.jpg")
scTexture(SC_DOWN, "hs-guest_n1d.jpg")
scFootstep("fx-foot_hollow1.ogg")


И вот подобной хуйни там на 23к строк кода. Как воссоздать движок по таким наскальным рисункам? Загадка Жака Фреско. Очевидно по названию функции и передаваемым аргументам. Вот в инициализации кубамапа все очевидно. Но есть места и неочевидные, вроде
  scFXPlayEx(SC_3DD, "fx-hammer_hall.ogg", 0, 1)


2.3 Игра захардкожена в разрешении 1024х768, из-за оригинальной реализации движка она не может рендерить картинку в большем разрешении, т.к. все hotspot'ы (интерактивные области) имеют абсолютные координаты. В моей реализации я конвертирую все входные координаты в относительные, под любое разрешение.

1 скриншот — оригинальное разрешение
2 скриншот — оригинальная игра, растянутая на полный экран
3 скриншот — моя реализация двигла, с относительными хотспотами

Скриншоты мартовские, сейчас я уже далеко вперед продвинулся.
Please open Telegram to view this post
VIEW IN TELEGRAM
!string.IsNullOrEmpty(str)


Или

string.IsNullOrEmpty(str) == false


???

Встречаю популярное мнение, что АРЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯ МЕНЬШЕ БУКАВ ЛУЧШЕ, ПОТОМУ ЧТО МНОГА БУКАВ ЭТО ПЛОХА, БУКАВЫ ЧИТАТЬ ТЯЖЕЛО, а в первом варианте буковок меньше. Но ведь == false читается легче, потому что мы читаем сначала, а не с конца.

Первый вариант читается: "Не строка пустая или null".
Вторая читается: "Строка пустая или null - ложное утверждение"

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

!string.IsNullOrEmpty(str) - трахает по читаемости, если только ты читаешь справа налево.
Считаю == вообще не очевидным, что за двойное присваивание, кто это придумал вообще? Абсолютно не читабельно.

String.IsNullOrEmpty(str) is false


Единственно верный вариант.

P.S.
Если я что-то утверждаю, я не обязан представлять доказательства, если вы утверждаете обратное, опровергая меня, это вы должны доказательства представлять 🤯
Please open Telegram to view this post
VIEW IN TELEGRAM
Работа фронтендера сложнее и это математически доказуемо.

Сколько времени вам нужно чтобы написать свой фотошоп? Я полагаю, что где-то примерно X часов. Сколько времени вам нужно будет, чтобы написать АБСОЛЮТНО точно такой же фотошоп, но в условиях, когда вы ограничены ресурсами браузера + ваш код работает в разных браузерах по разному.

Это же будет X + ((организация кроссбраузерности + пердолинг по овероптимизации)/скилуха).

Как вы понимаете X + ((Y + Z) / S) > X. Чем меньше S(скилл), тем больше пердолинга, но при это насколько бы большой не был скилл, (Y + Z) / S Никогда не будет равен 0.

P.S. Я не говорю, что бекендеры хуже. Да и большинство фронтендеров не осилят написать фотошоп в браузере, потому что от фронтендеров в основном требуют делать margin-left:10px;. Просто во фронтенде на тех же задачах больше пердолинга.
Как попердолит IT в будущем?

Я предполагаю, что появятся люди-оркестры, которые будут решать задачи с помощью нейросетей. Если развитие нейросетей будет волнообразным (хотя нет гарантии, что оно останется таким же стремительным), они смогут заменить специалистов среднего уровня с узкими знаниями. Не тронутыми останутся лишь сеньоры-помидоры, которые создают новые знания.

Исходя из этой логики, мой план развития выглядит так:

> Становлюсь тестировщиком
> Осваиваю бэкенд
> Развиваюсь в фронтенд
> Дрочу PM
> Вырастаю в продакт-овнера
> Перекатываюсь в DevOps

Я хочу уметь обеспечивать полный цикл разработки приложения в одну ебучку. Возникающие пробелы буду закрывать с помощью нейросетей (пока они на это не способны, но к моменту их развития я уже буду готов).
А Я ВАМ ГОВОРИЛ, ГОВОРИЛ! Ну что, кто нибудь из хейтерков скажет Флёнову (пост ниже), что он дерьмовый программист? Просто намекаю: https://www.youtube.com/watch?v=RhLy26sZD_E&ab_channel=ExtremeCode

Когда нибудь вам с монитора и Линус Торвальдс скажет, что кодить пяткой это норма.
ВНИМАНИЕ! Не воспринимайте это видео, как призыв писать плохой код. Просто не стоит зацикливаться на чистом коде. Пишите так, чтобы вам было удобно, особенно в игровой индустрии. А потом всё легко переписывается, переделывается так, чтобы работало долго и без проблем.

Ютуб / ВК / Рутуб
Когда только начинал программировать, каждый раз удивлялся, почему во всех гайдах работа с файлами выглядит как херня из под коня.

Сначала открой поток. Потом оберни его в StreamReader. Потом какой-нибудь буфер добавь. Потом подумай о том, как всё это всё подиспоузить. А зачем? Есть же File.ReadAllLines — вызвал, прочитал, пошёл играть в варкрафт.

Прошло время. И до меня начало доходить, что работа с файлами — это целый сраный квест:

> Права доступа. Файл можно читать, но нельзя писать. Или наоборот. Или вообще ничего нельзя. Надо проверять, запрашивать, обрабатывать отказы.

> Платформозависимость. Windows, Linux, Android, холодильник, тапочек твоего бати — у всех свои приколы.

> Файл может быть занят. Какая-нибудь другая прога уже с ним работает. Всё, облом (или не облом 🤨).

> Файл может быть гигантским. Читать его целиком — ОЗУ не хватит. Надо по частям (подписчики из Питера на месте?).

> Кодировки. UTF-8, ANSI, CP1251, древний шумерский — угадай, попробуй, приятного аппетита.

> Параллельный доступ. Попробуй-ка из двух потоков одновременно туда что-то записать. Увидишь, что бывает 🚫.

И вот тогда ты понимаешь, почему нормальные люди делают эту всратую обёртку из стримов и ридеров. Это не из вредности, а из-за здравой анальности.
Please open Telegram to view this post
VIEW IN TELEGRAM