Разработчик, реверс-инженер, фрилансер. Пишу на Rust, С/С++. Интересуюсь Linux, сетями, графикой.
Контакты

Достижения

Все достижения (27)

Наибольший вклад в теги

Все теги (147)

Лучшие ответы пользователя

Все ответы (284)
  • Хочу стать программистом. Какой факультет выбрать(Санкт-Петербург)?

    TrueBers
    @TrueBers
    Гуглю за еду
    Знаю пару отличных факультетов:

    Вот оф сайт главного https://www.google.ru
    Ещё есть у них филиал — https://stackoverflow.com/

    Бесплатно и без СМС!
    Ответ написан
    2 комментария
  • Opengl 4.* или vulkan?

    TrueBers
    @TrueBers
    Гуглю за еду
    Это вообще разные вещи.
    Нужно отличать изучение API, от изучения технологии. Если вы хотите выучить просто API, учите что угодно, ибо разницу заметите только, когда поймёте основы, базу.

    OpenGL проектировался когда были другие архитектуры железа. Мультипроцессорность была только в теории, и считалась уделом суперкомпьютеров и ненужной для пользовательских ПК.
    Можно привести аналогию: OpenGL == C++, Vulkan == асинхронный Assembler + hardware threads. Например, в C++ сейчас довольно много архитектурных косяков, которые пытаются решить новыми стандартами, объявляют какие вещи устаревшими, потому что они концептуально неверны и не подходят под современные реалии.
    Но, при этом, вы можете всё то же самое написать на ассемблере, но нужно намного лучше понимать, как работает процессор и ОС, самому писать примитивы синхронизации, и т. п.

    Для этих же целей и создавался вулкан. Для программирования на нём, нужно знать все тонкости железки, читать кучи пейперов от той же НВидии, исследовать, придумывать новые фичи для современных архитектур с нуля, которые изначально были придуманы в OpenGL, но для старого железа.
    Т. е. на Вулкане нужно делать больше руками, больше оптимизировать. Вместо одного вызова функции OpenGL, на вулкане придётся несколько сотен строк написать. При этом, если вы не понимаете какой-то одной тонкости, вы сделаете менее эффективнее то, что изначально было хорошо реализовано в OpenGL. К тому же, OpenGL умеет выбрасывать ошибки, в случае, когда вы где-то накосячили. Вулкан же их не выбрасывает, он полагается на то, что вы уже знаете как этим пользоваться. Точно так же, как ассемблер просто меняет состояние регистров, у него нет понятия ошибки. Как интерпретировать эти регистры, зависит от того, насколько хорошо разработчик читал мануал к процессору.

    В итоге, я бы ответил так:

    Если вы будете заниматься графикой как наукой, дико задротить а-ля Кармак в студенчестве с его движками, что-то исследовать, писать какие-то гениальные алгоритмы, защищать на этом диссертации, публиковать их, рассказывать потом на конференции, как вы круто справились с какой-то насущной задачей, повысили производительность, то тогда учите Vulkan. Vulkan — это именно про графику как технологию, про производительность, про инжиниринг и архитектурный дизайн, а не про API и само программирование. С вулканом придётся больше сидеть с диаграммами, документациями и строить архитектуру, придумывать методы взаимодействия частей этой архитектуры, синхронизации состояний, нежели писать код.

    Если же вы пишете простые прикладные вещи, которым нужно показать какую-то графику, то учите OpenGL. Здесь вы учите только API, соглашаясь с уже готовым, слегка устаревшим, архитектурным дизайном.

    Если хотите писать игры не мирового класса, то учите готовые движки, Unity или Unreal. Они уже поддерживают за вас Vulkan, продумали за вас API и архитектуру.
    Ответ написан
    2 комментария
  • Для чего нужен ассемблер?

    TrueBers
    @TrueBers
    Гуглю за еду
    Скажем так: зачем уметь собирать-разбирать двигатель от машины и понимать как он работает?
    99% людей это не нужно в принципе. Но если вы это знаете, вы можете легко диагностировать какую-то проблему, понять как её решить. При этом, каждый день вы не производите двигатели на станке.

    То же самое с ассемблером: чтобы понимать как работает программа, как её отладить, диагностировать, понять, что не работает — для этого и нужен ассемблер. Писать на нём что-то конкретное и большое сейчас абсолютно бессмысленно. Его надо знать и понимать, этого достаточно.
    Ответ написан
    Комментировать
  • Как определять ответственность функций?

    TrueBers
    @TrueBers
    Гуглю за еду
    По своему опыту могу сказать:
    Всё это бесполезный треш, все эти описания как надо, как правильно, как делают гуру, как делают в НАСА, солиды, банды четырёх, десяти, трёхсот спартанцев и т. д. Но, ровно до того времени, пока вы сами до этого не дойдёте. А дойти до этого можно только с опытом. Когда вы пишете что-то относительно не крупное, эти все вещи можно опускать. А когда приходите к огромному проекту, всё идёт само по себе, ибо иначе вы просто не можете с этим взаимодействовать, либо если система уже достаточно хорошо спроектирована, вам приходится писать правильно, т. к. по-другому либо не получится, либо вам дадут по шапке ревьюверы.

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

    Рецепт прост: пробовать, делать, строить, ломать, перестраивать, ошибаться, снова перестраивать. Тупо взять и прочитать, как кто-то там сделал и у него получилось, не прокатит. У него звёзды сошлись, а у вас, у меня, или у неё не сойдутся точно в такой же последовательности. Используйте разные языки программирования, разные парадигмы, фреймворки. Это даёт прекрасное понимание о существовании различных архитектурных решений, которое не даст ни однин теоретический паттерн.

    Я не хочу сказать, что все эти гофы и солиды не имеют смысла, они созданы для того, чтобы для начала просто с ними ознакомиться, отложить в подсознание и... благополучно забыть! Но потом, когда вдруг что-то писал и внезапно осенило: Да это же паттерн медиатор/обсервер/репозиторий/anyPattern! Вот тут и пригодится та самая книга трёх танкистов и собаки, которая просто направит в нужное русло, объяснит остальное, что не успел понять сам, и т. п.

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

    Но, я пока что таких людей не видел...
    Ответ написан
    3 комментария
  • Какую дорогу в GameDev лучше выбрать?

    TrueBers
    @TrueBers
    Гуглю за еду
    Да не слушай ты этот бред, который пишут: "То бросай, это бросай, вакансий нету, всё пропало!".
    Всё есть, если есть интерес.
    Учить не важно какой движок, они все используют одни и те же концепции, паттерны примерно одинаковые.

    Внезапно(!), но везде есть и текстуры, и спрайты, и шейдеры. И игровой цикл даже есть!
    Изучив один движок, и написав пару игрушек, потом сам поймёшь, когда стоит перейти на что-то более функциональное и удобное. Придёт осознание, каких фич не хватает, и в каких движках они есть, и т. п.

    А все эти анрилы и юнити только ключевыми словами, по сути, отличаются. Ну, и общий дизайн у них чуть более удобен в плане декомпозиции кода, грамотной архитектуры. Но, пока сам не дойдёшь до необходимости использовать эту декомпозицию, ничего особо не выиграешь, только запутаешься. При переходе достаточно будет ознакомиться с паттернами Gang of Four и всё станет ясно более-менее.

    ПС Знаю разработчиков Юнити, которые начинали геймдев с этого движка и в шоке от того, что кто-то программирует не мышкой. Азы оптимизации им просто недоступны, ибо они даже понятия не имеют о нижележащем уровне API. Они искренне удивляются, как это знать чистый OpenGL и писать всё самому, а разве так можно? Точно так же, кстати, удивляются многие кодеры на плюсах: "А зачем мне знать ассемблер? Я с ним не сталкиваюсь никогда..."

    ППС Вот ещё можно почитать чуть позже, самая крутая книга по геймдеву, которую я видел. Правда, она для тех, уже, кто нашёл в своих движках какие-то изъяны и ищет решения. Но и основы игрового цикла есть там, обработки ввода, множество примеров декомпозиции.

    А уж, если хочется просто изучить полезный скилл зарабатывания денег и как зомби рубить бабки, то тут, как описали выше, 2 варианта по сути: Unity (C#), Unreal (C++). По ним вакансий немерено.
    Ответ написан
    4 комментария

Лучшие вопросы пользователя

Все вопросы (9)