Crash Bandicoot, или как разработчики упаковывали целые игры в 2MB RAM

Перевод:

Вот вам анекдот из конца 90-ых. Я (Dave Baggett) был одним из двух программистов (вместе с Andy Gavin), разрабатывающих CrashBandicoot для PlayStation 1. 

Crash Bandicoot, или как разработчики упаковывали целые игры в 2MB RAM Crash Bandicoot, Геймеры, Перевод, Длиннопост

Оперативная память была главной проблемой даже в те времена. У PS1 было всего 2MB RAM, и нам приходилось совершать безумные вещи, чтобы уместить в них игру. У нас были уровни, содержащие более 10MB чистых данных, и эти 10 мегабайт должны были постранично загружаться и выгружаться в память динамически, без каких-либо видимых задержек для игрока, при фреймрейте в 30 кадров в секунду.

Crash Bandicoot, или как разработчики упаковывали целые игры в 2MB RAM Crash Bandicoot, Геймеры, Перевод, Длиннопост

В основном это работало за счёт того, что Andy написал потрясную систему подкачки, которая должна была подгружать и выгружать страницы в память размером 64K, по мере того как Crash проходил уровень. Эта система была настоящим произведением искусства, задействовавшая весь диапазон доступных инструментов, начиная от высокоуровневного менеджмента памятью, заканчивая прямой работой с памятью и программированием в опкодах. Andy также пришлось контроллировать расположение байтов на CD-ROM, чтобы даже при скорости 300KB/сек PS1 могла успеть загрузить данные для всех деталей уровня к тому времени как Crash добирался до него.

Я же написал упаковщик, который брал ресурсы игры — звуки, арт, код на lisp для управления существами, и т.д. и упаковывал их в страницы по 64К для системы подкачки, написанной Andy. (Между прочим, задача упаковки в страницы фиксированного размера набора произвольных размеров данных — NP-полная, и, почти не поддающаяся решению за полиномиальное, т.е. сколь либо приемлемое время. Задача о ранце.).

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

Crash Bandicoot, или как разработчики упаковывали целые игры в 2MB RAM Crash Bandicoot, Геймеры, Перевод, Длиннопост

Проблема использования случайного направленного поиска заключалась в том, что ты никогда не мог быть уверен, что сможешь ещё раз получить точно такой же результат. Некоторые уровни Crash Bandicoot умещались в максимально допустимое количество страниц (21, если не ошибаюсь) только лишь из-за того, что упаковщику повезло и он нашёл этот вариант. Так же, это означало, что как только ты получил упакованный уровень, ты мог поменять код для какой-нибудь черепашки и уже никогда не получить упаковку, помещающуюся в 21 страницу. Были случаи, когда дизайнер хотел что-нибудь поменять и это раздувало количество страниц, и нам приходилось менять что-нибудь в других, почти случайных, местах, до тех пор, пока упаковщик снова не найдёт рабочий вариант. Попробуй объяснить это раздражительным дизайнерам в 3 часа утра :)

Crash Bandicoot, или как разработчики упаковывали целые игры в 2MB RAM Crash Bandicoot, Геймеры, Перевод, Длиннопост

Самым лучшим эпизодом этой ретроспективы и самым худшим периодом времени тогда была упаковка кода ядра на С и ассемблере. У нас было буквально пару дней чтобы выпусть «gold master» версию — наш последний шанс успеть к сезону праздников, до того, как мы потеряем ещё один год. И мы сидели, переставляя C код в семантически одинаковые, но синтаксически разные конструкции, чтобы заставить компилятор выдать код, который был на 200, 125, 50, а потом и 8 байт меньше. Переставляли, например: «for (i=0; i < x; i++)» — а давайте попробуем переписать это в while-цикл и используем для итерации переменную, которая уже использовалась где-то ранее? Это всё делалось уже после того как мы перепробовали стандартные трюки, такие как помещение данных в два последних бита указателя (и это работало только благодаря тому, что адреса R3000 были выровнены по 4 байта).

В конечном счёте, Crash yместился в память PS1, и даже осталось свободных 4 байта! Да, 4 байта из 2097152. Удачи. 

Crash Bandicoot, или как разработчики упаковывали целые игры в 2MB RAM Crash Bandicoot, Геймеры, Перевод, Длиннопост

Оригинал: https://www.quora.com/How-did-game-developers-pack-entire-ga...

Лига Геймеров

45.4K поста89.2K подписчиков

Добавить пост

Правила сообщества

Ничто не истинно, все дозволено, кроме политоты, за нее пермач, идите на ютуб
Помни!
- Новостные/информационные публикации постим в pikabu GAMES
- Развлекательный контент в Лигу Геймеров



Нельзя:

Попрошайничать;

Рекламировать;

Оскорблять участников сообщества;

Нельзя оценивать Toki Tori ниже чем на 10 баллов из 10;

Выкладывать ваши кулвидосы с только что зареганных акков - пермач

Вы смотрите срез комментариев. Показать все
653
Автор поста оценил этот комментарий

Когда-то давно играл в 3д шутер весом 100Кб (по моему даже статья была на пикабу), вот это программисты.

А сейчас инет-страницы по 500Мб...

раскрыть ветку (200)
раскрыть ветку (2)
6
Автор поста оценил этот комментарий

Это прекрасно :)

раскрыть ветку (7)
126
Автор поста оценил этот комментарий
Уаааааа, мне все ещё стыдно за оформление
раскрыть ветку (4)
40
Автор поста оценил этот комментарий

Главное, что ты еще жив! А то за эти годы мог стать черствым сухарем и лежать незнамо где заплесневевшим.

34
Автор поста оценил этот комментарий

И мы всё ещё следим за тобой!

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

До сих пор следим

Иллюстрация к комментарию
4
Автор поста оценил этот комментарий
По-моему, эти же ребята в 90е музыку в технодемки пилили.
Я про Фарбрауш
1
Автор поста оценил этот комментарий
Отморозки))))
545
Автор поста оценил этот комментарий
Раньше были программисты, а сейчас - кодеры :(
раскрыть ветку (92)
290
Автор поста оценил этот комментарий

Просто раньше не было возможности - теперь есть. Куча библиотек на все случаи жизни, возможность хранить большие объемы памяти и.т.д. Когда ты пишешь что-то для себя - можешь писать на опкодах, вылизывать все основательно заодно теша свое самолюбие. Но если это коммерческий проект - ни кто не будет тратить лишнее время, если этого можно избежать. Хотя в вебе меня это и бесит - простой сайт: давай за*уярим туда фреймворк с тысячей зависимостей. Фронтенд? - npm загрузил 300-400 мегабайт. А давайте еще докер зах*ярим. И все это для сайта, который чуть сложнее визитки. Поддерживать все это будет сложнее, но мы ведь хотим быть в тренде. А потом хоп - сервер полетел, развернули новый, стали устанавливать зависимости "мы же в тренде - храним в своем гите только ядро". Оппа, а пакета, который нам нужен уже нет: удалили, затерли, еще что - не важно. И теперь в режиме аврала - нужно писать самим. Хорошо, если есть контракт, а если нет - всю остальную тонну кода нужно будет просмотреть на необходимость этой зависимости. Еще смешнее будет, если окажется, что из этой библиотеки используется всего пара методов, а сама она тянула еще сотню зависимостей.

раскрыть ветку (31)
43
Автор поста оценил этот комментарий

Это все менеджится, просто надо этим заняться.

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

В базовый образ можно зависимости положить и хранить в гите только ядро (ага-ага). Собирать удобнее и т.п.

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

раскрыть ветку (19)
29
Автор поста оценил этот комментарий

Первоначально docker нужен для того, чтобы было удобно разворачивать приложения на множестве серверов, для изоляции, ну и для того, чтобы не было "рассинхрона" с dev средой, хотя для меня это странно - ни когда не было таких проблем. Да и есть сайт с 500-1500rps и 4-8млн просмотров в день, со сложной логикой, а не просто статикой. Все работает на 1 сервере. Следующее же будет - вынос базы на отдельный сервер. Докер мне тут не сдался от слова - совсем. Прокинуть шаред, отдельный контейнер для сервера, отдельный для интерпритатора, отдельный для бд, прокинуть бд, все связать. Оптимизация для оптимизации как-то не круто. Сайтов же с такой и больше посещяемостью и выше менее 10%. Ага, есть у меня composer. Сложил я все зависимости себе в гит. Потом захотел обновить их через update. В гите уже другое будет лежать. Делать зеркало каждой зависимости для себя, просто для того, чтобы хранить копию. Или поднять свой composer репозиторий - по мне также, сомнительные телодвижения.

Мое мнение - оптимизация и лишние телодвижения нужны, когда они нужны, а не так - чтобы сразу было. У меня в проекте только свой гит, с тройкой главных зависимостей. Загрузил на сервер, composer update, все работает. Запушил в dev ветку, на тестовом скрипт через хук все развернул, установил зависимости - заказчик может посмотреть. С мастера на прод только в ручную - береженого бог бережет, да и для 1 сервера это не смертельно. Появится необходимость - появится докер, варгант, свои репозитории или еще что. Вы не уловили суть моих строк - все хорошо к месту. Зачем мне делать 80% работы, чтобы получить 20% результата? Когда эти цифры начинают смещаться, тогда и начинаю думать над этим. Просто надоел этот Xzibit - мы поставим вам линукс в линукс, просто потому, что это клево.

раскрыть ветку (17)
20
Автор поста оценил этот комментарий

Храните и дальше только ядро в гите - имхо правильно.


Тоже был случай, когда один автор залили на npm.org пакет очень важный для нас, не изменив версию. В итоге пришли к своему корпоративному хранилищу артефактов (nugets, npm, yum, pypi e.t.c.)


Да и правильном хорошего тона для такого случая является мастер-слев реплика хранилища.

P.S. Ещё могу поделиться опытом, как отдельно только nuget хранилище организовали:

1. два хранилища мастер-слейв (мастер в интранете, слейв в облаке)

2. папка с нугетами в мастер хранилище под git auto commit watcher

3. при получении нового гит коммита в гитлаб репозиторий отрабатывали скрипты, которые пушили этот коммит в slave хранилище.


В итоге получили отказоустойчивую систему хранения с историчностью.

раскрыть ветку (5)
56
Автор поста оценил этот комментарий

Сейчас скажу немного не в тему, но: настал тот момент, когда на  развлекательном портале "пикабу" я прочитал комментарий об ит, более информативный, полезный и познавательный, чем в большинстве сегодняшних статей на хабре, о комментариях вообще молчу.

раскрыть ветку (4)
22
Автор поста оценил этот комментарий

Ну я всё никак не получу туда инвайт (хабр) - откровенно лень.

Порекомендую тогда уж хранилище  артифактов - nexus sonatype - мне нравится, правда немного сыровато + полный список фич доступен только в платной версии.


Да и ещё про докер. Если у вас технологический стэк содержит несколько разных бэкенд языков (я например на C# (.net core), Java, Python пишу), то использовать контейнерезацию очень полезно. Плюс есть системы управления докер кластером (swarm, kubernetes).

Выглядит это так:

1. Создаёте бойлерплейт проект

2. Внутри папки проекта делаете два файла и конфигурируете их (Dockerfile and docker-compose.yml).

3. Прочесть\посмотреть видео про то, как это делается занимает максимум один выходной.

4. Подключаете в IDE плагин, который очередной сборке проекта запускает команду docker-compose build & docker-compose push

5. Настраиваете CI раннер на ориджн этого проекта.

6. Когда приходит новый коммит, то раннер деплоит на тест nexus.domain.ru/yourprojectname:latest докер контейнер автоматом


Больно будет первый раз, но потом сэкономите кучу времени, которое можно потратить на что-то полезное (саморазвитие например).

4
Автор поста оценил этот комментарий
Эта статья утащена с Хабра, а была она там уже несколько месяцев назад : )
раскрыть ветку (2)
4
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

Эта и ещё одна статья занимали лучшие места в топе за неделю. Времена когда Хабр был "торт" я к сожалению не застал.. Но конкретно оскорблений в комментариях нету, либо они в минусах/удалены.


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

Ощущение что всё захватили сервисы TM, а политика того же Тостера категорически не приветствует любые споры и альтернативные точки зрения.


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

Т.е. по факту даже вопросы типа "Какую CMS выбрать для ... сайта с ... требованиями?" нарушают правила

14
Автор поста оценил этот комментарий
Да и есть сайт с 500-1500rps и 4-8млн просмотров в день, со сложной логикой, а не просто статикой. Все работает на 1 сервере.

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

Прокинуть шаред, отдельный контейнер для сервера, отдельный для интерпритатора, отдельный для бд, прокинуть бд, все связать.

Для "все связать" придуманы решения типа Kubernetes.  Остальное не так страшно, на самом деле.

чтобы не было "рассинхрона" с dev средой, хотя для меня это странно - ни когда не было таких проблем

Вот я бы сказал по Станиславскому "Не верю!", но единственное что мне в голову приходит - вы просто на проде теститесь:) Даже на суперпростом проекте надо прилагать сознательные усилия, чтобы окружение не разъехались. Ну или вы просто не осознаете что окружения на самом деле разные:)

Или поднять свой composer репозиторий - по мне также, сомнительные телодвижения.

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

Запушил в dev ветку, на тестовом скрипт через хук все развернул, установил зависимости - заказчик может посмотреть. С мастера на прод только в ручную - береженого бог бережет, да и для 1 сервера это не смертельно.

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

Вы не уловили суть моих строк - все хорошо к месту. Зачем мне делать 80% работы, чтобы получить 20% результата? Когда эти цифры начинают смещаться, тогда и начинаю думать над этим.

Мы просто живем вероятно в разных мирах. В моем мире просто нет проектов которые можно бросить на 1 сервер "как есть" с мыслью "ну надо будет - переделаю" и деплоить их руками. Потому что этот момент настанет через пару дней-недель-месяцев и мне будет очень сложно объяснить и себе, и бизнесу, почему я сразу нормально все не сделал.

Я за много лет (больше 10 уже только официально) эксплуатации самых разных систем, от маленький портальчиков для локального бизнеса до кластеров в 1000+ серверов с десятками сервисов для миллиардных корпораций сделал достаточно предположений и ошибок, чтобы теперь сразу делать нормально, а не объяснять потом почему так было можно, но в текущий момент резко стало нельзя и все развалилось.

раскрыть ветку (9)
8
Автор поста оценил этот комментарий

Да, мы, скорее всего, мы живем в разных мирах, так как в вашем мире не существует kiss. Не существует понятия времени, ибо если заказчик увидит какую-то нишу, а вы начнете сразу развивать инфраструктуру и архитектуру до уровня "oh my god" - проект просто не выстрелит, так как его нишу займут люди из нашего мира. Или просто проект не выстрелит, или, что скорее всего - не выстрелит заказчик и/или найдет кого-то другого. Ну и самое главное - в вашем мире читают между строк и каверкают смысл: видите то, что хотите видеть. Я не против всего, о чем мы говорим, я за использование инструмента по мере необходимости. Вы не будете покупать паяльную станцию, для того, чтобы поменять конденсаторы в старой материнке - зачем это для одного раза? Легче купить простой паяльник в разы дешевле и не париться, он справится с текущими потребностями с лихвой. Возможно, потом вы захотите заняться этой сферой основательно, да - тогда уже можно начинать думать - какой инструмент вам необходим. Вы же видите в моих сообщениях, что я предлагаю вместо паяльника гвоздь трехсотку - расколенный на газовой плите для того, чтобы залудить шлейф тачскрина айфона.

Можно забивать гвозди микроскопом, но зачем?

раскрыть ветку (7)
9
Автор поста оценил этот комментарий
Да все проще на самом деле. Мне быстрее сделать как надо, чем костылить. По времени выигрыш от ручных решений не факт что вообще будет, зато проблем он них будет гораздо больше.
Мне просто не надо покупать "паяльную станцию". Она у меня уже есть.
И мне быстрее один раз сделать все это нормально, чем возвращаться к этому каждый раз, когда что то изменится или надо будет что то на прод выкатить. У меня просто мало времени и оно дорогое, мне есть чем заняться и кроме ручных деплоев.
раскрыть ветку (6)
5
Автор поста оценил этот комментарий

Я не собираюсь с вами спорить - это бесполезно.

Просто оставлю это здесь: https://habr.com/post/332450/

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

раскрыть ветку (5)
8
Автор поста оценил этот комментарий

Там вся статья устарела чуть менее чем полностью. На конец 16 года она была хоть как то актуальной.

А местами там и совсем лютый бред, типа "Например, не пытайтесь запустить Kubernetes ни на чем, кроме CoreOS". Это даже в 16 году было совершенной неправдой.

Советую вам внимательно перечитать ВСЕ комменты к этой статье.

Но, если вы опираетесь только на статьи в интернете - нам с вами и правда разговаривать не о чем:)

К тому же, это даже хорошо, что у вас такое мнение.

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

Автор поста оценил этот комментарий

Просто почитайте еще раз про докер, докер не хайп, он реально решает проблемы без оверхеда. Конечно все зависит от задачей но если мы говорим про какой то средненький проект с командой из нескольких человек то докер зайдет.

раскрыть ветку (3)
Автор поста оценил этот комментарий
Ну оверхед там есть, но он настолько незначительный что им можно тупо пренебречь. Мы когда у себя начали докер использовать - очень много проблем закрыли. Особенно чего только переезд на новый сервак стоил. Было все в разы проще чем если бы у нас не было докера.
раскрыть ветку (2)
4
Автор поста оценил этот комментарий

Согласен. Видимо, у вашего оппонента только один средний проект с некоей длительно не обслуживаемой логикой. Он потыкал Docker, не нашёл его полезным. О флоу речи нет. Только о разрозненных инструментах. В этом разрезе, разумеется, Docker не нужен.

3
Автор поста оценил этот комментарий
Да блять на каком языке вы говорите?) 0_о
Автор поста оценил этот комментарий

Можно использовать Nexus OSS как прокси для кэширования NPM модулей.  Но вообще после истории с left-pad команда NPM пересмотрела порядок удаление пакетов. Фактически сейчас невозможно сразу удалить пакет даже через обращение в support - они его пометят как deprecated и удалят спустя большое кол-во времени, если пакет никто не скачивает.

3
Автор поста оценил этот комментарий

Как-раз, хранить зависимости npm - в тренде. С тех пор, как из репы стали пакеты исчезать. Но, в общем случае, проще упаковать среду в образ (того же докера) и хранить отдельно. Не совсем представляю, как это поможет сайту-визитке, но от описанных проблем с деплоем избавляет. А в общем случае, компания или программист, которые перешли на описанные инструменты, не будут делать сайты-визитки. Слишком дорого. Хотя, тот же докер, ну или Ansible можно использовать для автоматизации деплоймента мелких сайтов. Полагаю, так сейчас и делают. Это, как-минимум, разумно, если у тебя много заказов в месяц. Одна студия будет работать по-старинке, поднимать CMS с нуля (ну, ладно, там не так долго), потом заводить аккаунт на сервере, создавать БД, настраивать FTP. Другая - будет хранить болванку в Docker Image. Поставил, разработал, развернул одной кнопкой. В случае доработки - одной командой развернул локальную копию, воткнул кнопку, запустил тесты, одной командой развернул результат.

Выбор тяжёлого фреймворка для визиток - спорный вопрос. С одной стороны, это лишние зависимости. С другой - высокая скорость разработки и стандартизация. Плюс, если раньше прикручивание свистелки, которую хочет заказчик, оборачивалось длительными переговорами и вознёй с jQuery-based legacy code, то сейчас всё просто. Хочет? Ок! Ставим зависимость, прикручиваем код, запускаем тесты, продакшен. Если смартфон пользователя спокойно открывает сайт и исполняет JS, то какая нафиг разница, сколько там зависимостей?! К тому же, зачастую, legacy код на JS работает хуже, чем код, написанный на фрэймворке. Даже, если это сто ванильных строк. А всё потому, что общий уровень скриптописателей программистов на JS  - достаточно низкий. При наличии фрэймворка, зачастую, функционал будет написан через абстракцию, а у неё под капотом - неплохо отлаженный код. Пяток приятных строк, которые рядовой JS-разраб, как-раз и уместит в сто строк своего кода.

1
Автор поста оценил этот комментарий

Для фронта 300-400 мб из npm -- это, в основном, devDependencies, фактически -- инструменты разработки. В сборку они не идут. Но в целом, да, проблема с зависимостями есть, хотя от неё страдают чаще разработчики, чем пользователи.

раскрыть ветку (6)
2
Автор поста оценил этот комментарий

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

Иллюстрация к комментарию
раскрыть ветку (5)
1
Автор поста оценил этот комментарий

Я же говорю, devDependencies. Основной зоопарк приходит с вебпаком, тестами и прочим барахлом, которое в сборку не пойдёт. На размер готового продукта все это счастье не влияет. Боль с питоном -- это если под виндой работать, в основном, но это редко надо.

раскрыть ветку (4)
Автор поста оценил этот комментарий

Но это не отменяет этого зоопарка) Крутите вы 10 проектов на dev машине, и у вас 10 зоопарков. В php тоже самое, хотя, если зависимости не пересекаются по версиям, то можно для dev и все в один vendor скинуть. Но есть одно отличие - размер: есть сайт с фронтендом на vue+axios+vuex+vue router ну и еще пара мелочей. 200 метров. Весь бакенд на php - кроме фреймворка установлены десятки библиотек - работа с платежными системами, с облаком, с изображениями и.т.д. 50 метров. Я понимаю - сборщики и т.д. Но есть у меня проекты на wp 2/3/4, если поставить в глобал один - все проекты не соберутся) На самом деле я рад, хоть и php'шник, что nodeJS бурно развивается как сам, так и его сообщество, но это все происходит за короткий срок и часто ломает совместимость.

раскрыть ветку (3)
1
Автор поста оценил этот комментарий

У меня на dev-машине 10 виртуалок и WebStorm с авто-деплоем по ssh. И голова у меня не болит насчёт глобальных зависимостей, потому что они друг от друга изолированы.

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

У меня все тоже самое, только без 10 виртуалок, они используются только для специфичных проектов, где важно окружение и деплой стоит из гит при пуше. Только прослойки в виде виртуалки - тяжелее в сотню раз. И раз мы говорили о размерах - смысл, наоборот, теряется. Все-таки лучше 400мб, чем 4гб. А для тех, кто работает только с фронтендом - смысла в виртуалках, вообще, не вижу.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Имеет смысл размер конечного продукта. 4Гб дискового пространства на машине разработчика стоят копейки. Плюс, я сам больше по бэку, мне реально проще поднять виртуалку. Только с фронтендом, наверное, смысла особого нет, если бэк крутится где-то ещё.

Автор поста оценил этот комментарий

Мне знакомый рассказывал про использование блокчейна в софте умного дома. После этого визитка на джанго вызывает максимум улыбку.

31
Автор поста оценил этот комментарий

Раньше авторы были оригинальные, а сейчас - воришки.

Вы нагло скопипастили мой перевод отсюда: https://habr.com/post/260637/ и нигде не указали ссылку на мой перевод.

раскрыть ветку (2)
4
DELETED
Автор поста оценил этот комментарий

@moderator,  можно ссылку в пост положить?

раскрыть ветку (1)
3
Автор поста оценил этот комментарий

Здравствуйте.
Пост без маркера "моё", контент взять из открытого источника, правил Pikabu не нарушает.
Если @nokfromthefuture не возражает, то ссылку можно добавить.

59
Автор поста оценил этот комментарий

Были же люди, как люди и вдруг все сразу стали кретины, парадокс...

Иллюстрация к комментарию
15
Автор поста оценил этот комментарий

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

ещё комментарии
68
Автор поста оценил этот комментарий

Да да, конечно. Раньше и дома лучше строили, и трава была зеленее и еда вкуснее. Все предки умели, а мы деградируем.


Вот только на одного Crash Bandicootа, который реально был прорывом и шедевром своего времени выходило куча другого шлака, про который в статье не расскажешь. Ведь раньше было лучше.

раскрыть ветку (16)
24
Автор поста оценил этот комментарий
Впрочем, как и сейчас. Только эти игры помимо ущербного геймплея и визуального вида на раз забивают 8 гигов оперативы
раскрыть ветку (8)
40
Автор поста оценил этот комментарий

Собственно вся история описаная в посте, это борьба с тем, как забить максимум оперативной памяти сосноли и не обосраться. Перечитайте)


Что касается ущербного геймплея, я до сих пор вспоминаю те вариации игр на деньди, которые шли со старой Нес.


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


Собственно тот же Бандикут всего лишь 3д платформер с загадками. Сколько потом после него появилось штампованных пародий? Сколько до сих пор. И люди играют и радуются.


Так что претензии к текущему положению, когда ГеймДизы создают просто невероятные по своим масштабам и наполненности миры и игры в которые проводишь по 100 часов не потому что других игр нет, а потому чтотам реально интересно находится, на мой взгляд несправедливы.


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


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

ещё комментарии
ещё комментарии
11
Автор поста оценил этот комментарий

Эк ты всех под одну гребенку.


Разве не очевидно, что всё определяется инструментарием языков и вычислительной мощностью ЭВМ текущего момента времени?


Или ты жалеешь, что тебе не надо сейчас заниматься байтоёбством и писать код местами прямо на асм, чтобы тратить не полтора гига оперативки, а на 100 байтов меньше?

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

раскрыть ветку (1)
6
Автор поста оценил этот комментарий

Тише, тише, тут собрались олдфаги, не привлекай их внимани... АааААААваАААаАааа!

29
Автор поста оценил этот комментарий

Манки-кодеры

раскрыть ветку (19)
8
DELETED
Автор поста оценил этот комментарий
Индусы
раскрыть ветку (17)
5
Автор поста оценил этот комментарий

Работал с индусами из NY - много очень толковых чуваков

раскрыть ветку (16)
8
Автор поста оценил этот комментарий

Что составляет 0.0001% индусов, оставшихся в Индии. Поработав с ними, перестанешь ненавидеть цыган.

раскрыть ветку (3)
Автор поста оценил этот комментарий

Но ведь цыгане - это выходцы из Индии...

раскрыть ветку (1)
Автор поста оценил этот комментарий

Хоть кто-то знает. Кстати, они не так чтобы все вышли

2
DELETED
Автор поста оценил этот комментарий

Вот-вот))) Вся боль в новых разработках Microsoft)))

3
DELETED
Автор поста оценил этот комментарий
Что не мешает им на родине "дуть" код там, где можно было обойтись 3 строчками. А все потому что платят им за количество строк. Именно оттуда и пошло это)))
раскрыть ветку (11)
11
Автор поста оценил этот комментарий

Вообще-то нет. Платить за количество строк придумали американы. Они же придумали  как это наипать: переносить каждую скобку на новую строчку. Разумеется, оплату за строки давно отменили (хотя в очень недоразвитых странах ещё дрочат на сей показатель). Но традиция переносить скобки и размазывать говно по тарелке - осталась.

раскрыть ветку (10)
4
Автор поста оценил этот комментарий

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

раскрыть ветку (2)
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
Автор поста оценил этот комментарий
Это же стандартная практика любой серьёзной разработки, что программирование, что схемотехника, что конструирование.
1
Автор поста оценил этот комментарий
переносить каждую скобку на новую строчку

Ну если не нравится читабельность, тогда хуярь все в одну строку, хули.

раскрыть ветку (3)
3
Автор поста оценил этот комментарий

Ну
если
{
ты считаешь (
это == читаемость
)
{
тогда
{
try
{
желаю тебе читать только такой чужой код
}
catch
(
Exception жопа
)
{
/*
аниипёт
*/
}
finally
{
выпий триацилглицериду
}

}

}

}

раскрыть ветку (2)
1
Автор поста оценил этот комментарий
Если при этом отступы правильные делать, то не так уж и плохо.
Особенно если в круглых скобках после если несколько условий.
А без отступов это конечно мешанина....
раскрыть ветку (1)
Автор поста оценил этот комментарий

Это здесь отступы не пропускает

1
Автор поста оценил этот комментарий

А как же Маяковский?

раскрыть ветку (2)
4
Автор поста оценил этот комментарий

Товарищч, ты нервы зажми в узду
if ( кодером звёшься) { не ахай }
Строк захотели? while (TRUE) go ("фпизду");
finally {
  НахуйFactory.getInstance().go(100500);
}

раскрыть ветку (1)
Автор поста оценил этот комментарий
Вам, сударь, для общего развития: прародителем этого четверостишия был не Маяковский, а Есенин.
DELETED
Автор поста оценил этот комментарий

Мамкины-кодеры.

2
Автор поста оценил этот комментарий

И сейчас никуда не делись. Есть такая вещь, как "демосцена". Люди создают различные программы с музыкой и графикой, и выступают с ними на "соревнованиях". Там есть различные номинации, в т.ч. с ограничением по размеру. Например 4Кб, 64Кб. Да, в 4Кб файлик .exe умудряются впихивать и 3D графику и музыку. Вот например, меньше 8Кб: https://files.scene.org/view/parties/2017/assembly17/64k/dow...


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

3
Автор поста оценил этот комментарий

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

7
Автор поста оценил этот комментарий

Раньше изъёбывались вместо работы,а теперь работу делают, негоже так, да?

раскрыть ветку (1)
DELETED
Автор поста оценил этот комментарий

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

Автор поста оценил этот комментарий

И уроки соответствующие)
https://www.youtube.com/watch?v=dlrjDvS7wxo

Автор поста оценил этот комментарий
Не могу поиграть в эту игрулю на компе. Такое ощущение, смог у меня меньше 2х МБ оперативы. Подскажите выход, а?
Автор поста оценил этот комментарий

Ничего что там текстуры и звуки формулами генерируется? Этим и объясним такой вес, а не каким то там чистым кодом.

2
Автор поста оценил этот комментарий

Звучит как частушка

Раньше хуй вставал в постели, а теперь в автобусе

1
Автор поста оценил этот комментарий
Они были и есть. Просто эти говнокодеры потом делают индюшатину с графонием 2011-го года, лагающую на нормальных компах
раскрыть ветку (3)
1
Автор поста оценил этот комментарий

2011? Это же совсем неда... Ой.

Автор поста оценил этот комментарий

Когда был слабый комп я удивлялся как у игры с графикой 10 летней давности такие высокие системные требования, а Race Driver GRID такие низкие и графика на высоком уровне.

раскрыть ветку (1)
Автор поста оценил этот комментарий

У самого так)

1
Автор поста оценил этот комментарий

Профессионалы и мартышки есть и сейчас, были и тогда, просто о шедеврах помнят, через года. Да и сейчас бывает приходится изъебываться так, что раньше и представить не могли, просто системы стали гораздо сложнее


P.s. проблеммы с нехваткой памяти никуда не делись и сейчас, но есть вещи гораздо проблемнее чем память, просто людям далеким от всего этого проще показать, мол вот как приходится изголяться

раскрыть ветку (1)
3
Автор поста оценил этот комментарий

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

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

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

1
Автор поста оценил этот комментарий

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

9
Автор поста оценил этот комментарий
Не 100, а 96кб. Игра kkrieger.
раскрыть ветку (1)
Автор поста оценил этот комментарий

кстати, от части хардкорная.

39
Автор поста оценил этот комментарий

.kkrieger называется

шикарная штука

ещё комментарии
5
Автор поста оценил этот комментарий
А я про elite вспомнил, процедурная генерация, 3d графон и это в 84 году, 8 галактик по 256 планет в каждой, все это упаковано в 22 кб.
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

символично звучало бы если б было так:

8 галактик, 256 планет в каждой с 16 спутниками при каждой планете, 32 системы ну и в таком духе))

41
Автор поста оценил этот комментарий

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

раскрыть ветку (38)
27
Автор поста оценил этот комментарий
А при чем тут веб дизайнеры? Это версталы виноваты, сохраняют все в PNG-24 и не удосуживаются разобраться в том, какой формат наиболее хорошо подходит для хранения того или иного типа картинки.

Исходя из своей практики могу сказать, что уложиться в +/- 3мб можно даже в случае, когда вся страница состоит полностью из графики.
раскрыть ветку (36)
25
Автор поста оценил этот комментарий
Верстал недавно сайт, аккуратно покропал фото, заказчик пишет, что на их пидарском маке картинки хуевые, требуют оригинал(7000*5000 размеры), поставил, заказчик пишет, что долго грузится. Два часа пытался объяснить, что сайт с картинками стал 400мб, даже lazyload не помог. В итоге уговорил на компромисс пойти.
раскрыть ветку (22)
57
Автор поста оценил этот комментарий

400 мб...за такие страницы надо в жопу поленом ебать

раскрыть ветку (8)
7
Автор поста оценил этот комментарий

Если это портфолио фотографа - ничего плохого не вижу. Но динамическая подгрузка все таки решает некоторые проблемы.

раскрыть ветку (5)
33
Автор поста оценил этот комментарий
да что угодно. нахрена сразу грузить многомегабайтные фото? сделайте превью  с подгрузкой по клику, кому надо - откроют
4
Автор поста оценил этот комментарий

Ну тогда проще сделать старый добрый переход к фулсайзу

раскрыть ветку (3)
4
Автор поста оценил этот комментарий

Зачем повторять то, что я и так написал в своем комменте? Причем ты не только повторил моё предложение другими словами, но еще и повторил за другим таким же комментарием про превью, который был отвечен мне до тебя.

раскрыть ветку (2)
4
Автор поста оценил этот комментарий

И все таки надо сделать превьюшки

раскрыть ветку (1)
3
Автор поста оценил этот комментарий

Ну, хоть кто-то правильное решение предложил.

3
Автор поста оценил этот комментарий
На live версию пошли уже подправленные фото, srcset, плюсом пошел lazyload, и страница стала грузиться за 2 секунды. Изначально фото только на баннере было около 20мб.
раскрыть ветку (1)
12
Автор поста оценил этот комментарий

Изначально фото только на баннере было около 20мб

жееесть

3
Автор поста оценил этот комментарий
Достаточно увеличить разрешение в 2 раза (при чем при созранении фоткам вовсе не обязстально ставить качетво в 100%, достаточно и 65%, вследствие чего при увеличении разрешения в 2 раза, фактический вес картинок вырастет всего на 20-35%) и тогда на ретинах все картинки будут четкими.

Хз зачем вы оригинальные хайрезы в дизайн вставляли.
раскрыть ветку (1)
5
Автор поста оценил этот комментарий
Это ты им расскажи, я заебался доказывать. В итоге пришли к варианту, который вы описали. Правда пришлось поиграться с размерами, чтоб всем угодить.
3
Автор поста оценил этот комментарий

И какой был компромисс?

раскрыть ветку (8)
19
Автор поста оценил этот комментарий
Классический трёхбуевенный.
6
Автор поста оценил этот комментарий
Нашел оптимальное качество, при котором заказчику было норм на ретине, и чтоб грузилось достаточно быстро
раскрыть ветку (6)
6
Автор поста оценил этот комментарий

А про @media вы не слышали?
Про разные виды подгрузки изображения (прогрессивный для jpg, например)?
Про thumbnail'ы? Чтобы не грузить основную полноразмерную картинку на главную страницу, а подгружать ее при детальном просмотре в всплывающем окне?
Про загрузку-предзагрузку в фоне?
Последовательная загрузка изображений по высоте?
В общем, есть десяток способов, как сделать так, чтобы сайт и грузился быстро с кучей больших картинок и выглядел конфеткой при этом.

раскрыть ветку (5)
17
Автор поста оценил этот комментарий

Если дизайнер нарисовал резиновый макет с картинкой в полном размере, а заказчик хочет, чтобы при высоком dpi сразу загружалась хорошая картинка без предзагрузки, но быстро - хоть в ж*пу  себя поленом вы*би, но вариант выхода один - объяснять заказчику, что это не реально.

Это уже не из сферы кривых рук, а из сферы заказчиков-идиотов:

Иллюстрация к комментарию
раскрыть ветку (2)
2
Автор поста оценил этот комментарий

Да это к любой работе применимо. Что, дизайнеры - особенные какие-то?

1
Автор поста оценил этот комментарий

Нелогично выстроенная последовательность усложнения примеров. Капс. Сокращения там, где они не нужны. Нули перед числами, которые тоже нахуй не нужны, ибо пунктов менее 10. Цвета...
Картинку эту рисовал не дизайнер, а хрен пойми кто. Следовательно и использовать эту памятку надо не с дизайнерами, а с хрен пойми кем.

Автор поста оценил этот комментарий

Я вообще-то в курсе, но если заказчик требует поставить оригинальные фото 7000*5000 по 15-20 мб штука, а если ставишь подрезанные версии, то плачет, что на сраном маке фото хуёвого качества, ставишь оригинал - плачет, что долго грузится. Притом все вами перечисленные методы были использованы. Но удалось уговорить заказчика и вроде стало гут.

раскрыть ветку (1)
Автор поста оценил этот комментарий

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

DELETED
Автор поста оценил этот комментарий

гугли srcset

раскрыть ветку (1)
Автор поста оценил этот комментарий

Бля, каждый второй советует как быть, но я в первом же сообщении написал, что все проблемы решены, сайт сдан заказчику, но каждый советует, хотя все эти советы были применены, тем более, что сайт в итоге натягивали на вордпресс с twig и там srcset используется повсеместно.

5
Автор поста оценил этот комментарий

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

раскрыть ветку (12)
4
Автор поста оценил этот комментарий
С жиквари и бутстрапом нет никаких особых проблем. Они не так много и весят. Недавно собирал проект, в котором был довольно большой шаблон на бутстрапе, с кучей плагинов и прочего. Вычистил говно все и вместе с ангуляром и самим кодом приложения весь проект уместился в 800 килобайт. Учитывая то, что это сервис, а не лендинг, более чем хорошо.
3
Автор поста оценил этот комментарий

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

раскрыть ветку (2)
3
Автор поста оценил этот комментарий

О да, из совсем недавнего:  в процессе борьбы РКН с телегой и блокировкой миллионов айпишников некоторые проекты испытывали, мягко скажем, неудобства от того, что всего-то грузили woff с серверов гугля. Так что хз, но я предпочитаю по-старинке класть всё на хостинг.

раскрыть ветку (1)
Автор поста оценил этот комментарий

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

Автор поста оценил этот комментарий
А чем в том бутстрапе такого, чтоб его подгружать только ради кнопочек? Возможности стилизации кнопок в html ограничиваются такими состояниями, как: обычное состояние, при нааедении, при клике, уже ранее нажатая кнопка, неактивная кнопка ну и + анимации. Вродь все это и без бутстрапа можно оформить.
раскрыть ветку (7)
2
DELETED
Автор поста оценил этот комментарий
Так он про это и говорит, алё
раскрыть ветку (1)
Автор поста оценил этот комментарий
А, окай.
2
Автор поста оценил этот комментарий

Можно, но зачем, когда есть уже все настроенное красивое адаптивное на бутстрапе в CDN?

раскрыть ветку (4)
Автор поста оценил этот комментарий

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

раскрыть ветку (3)
2
Автор поста оценил этот комментарий

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

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

CDN тоже не панацея, сколько версий jquery? Да больше сотни, в итоге вероятность попасть на кэш минимальная. Сколько разных cdnов? Да тоже десятки всяких разных. На хабре кажется статья была мол юзайте сдн яндекса, угадаете с версией, т.к. она будет в кэше, ага, на главной - 2.1.4, на почте 1.12.4, на яндекс музыке - 1.10.1. Вот и стреляй в небо какая же наиболее используемая в рунете и от какого сдна. С бутстрапом попроще конечно, 3.3.5 очень долгий был и вероятно наиболее распространен сейчас, даже больше чем 3.3.6, но опять же угадай с сдном. Короче споры эти ни о чем, нет тут истины, и так, и так правильно и неправильно, вопрос религии. Другое дело проекты с миллионной посещаемостью, тут да, нужен cdn, но и роль у него тут не попасть в кэш, а снизить нагрузку убрав статику

раскрыть ветку (1)
Автор поста оценил этот комментарий

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

4
Автор поста оценил этот комментарий
К Китайцам на сайты сходите, на Алиэкспресс какой-нибудь. Потом если они действительно станут ходить на ваши курсы, озолотитесь.
33
DELETED
Автор поста оценил этот комментарий
Комментарий удален. Причина: данный аккаунт был удалён
раскрыть ветку (8)
18
Автор поста оценил этот комментарий

Текстуры можно и оптимизировать, а не ужатые в релиз пихать. Так же и звук... Щас что не ремастер, то тупо текстуры оверпиксельные, нахуй не нужные. И весь от 30-110...Беги мол покупай новый хард, а лучше ссд на терабайт.

раскрыть ветку (5)
6
DELETED
Автор поста оценил этот комментарий

Текстуры в любом случае в игре на комп будут ужатые и уже в самой игре они расжимаются. А вот например на телефоне из-за слабой мощности принято запихивать практически не сжатые текстуры из-за чего каждая 1024х1024 текстура дает 2-3 мегабайта веса в лучшем случае.

раскрыть ветку (4)
9
Автор поста оценил этот комментарий
Всякий раз вспоминаю hearthstone, который на телефоне занимал, вроде, 1,5 Гб и, сука, тормозил.
раскрыть ветку (1)
8
DELETED
Автор поста оценил этот комментарий

Близзарды все делают текстурами и шейдерами. Живые камны это чуть чуть 3д, а все остальное текстуры и эффекты местами сложные.

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

Автор поста оценил этот комментарий

Что за брюжжение слюнями

https://software.intel.com/ru-ru/articles/android-texture-co...

ETC1 универсальный "базовый" алгоритм сжатия android

DXT1-5 для PC

PNG-3.7 mb, ETC - 1.1 DXT - 1.1

раскрыть ветку (1)
DELETED
Автор поста оценил этот комментарий

В юнити например есть много всяких реализованных алгоритмов, но везде качество усирается. Что ты будешь делать когда тебе нужно запустить на красочных экранах (с высокой плотностью пикселей)? Там будет мыло из-за сжатия. Можно увеличить размеры текстур, но это шило на мыло. Или все не так?

1
Автор поста оценил этот комментарий

https://ru.m.wikipedia.org/wiki/.kkrieger

И это ещё много... В 4к demo спокойно запихивали и 3d модели, и музыку

раскрыть ветку (1)
4
Автор поста оценил этот комментарий

На запихивали, а генерировали 3D модели.

2
Автор поста оценил этот комментарий

А сейчас вы играете в 4К шутеры с 60фпс в виртуальной реальности. Глупо жаловаться, что фотографии раньше весили 30 килобайт, а сейчас 5 мегабайт. Вам никто не мешает сжимать фотографии до тех же 30 килобайт (но вы же не станете, верно?). Раньше инет-страница была документов в три абзаца, а сейчас инет-страница может позволять вам удалено управлять CRM-системой в 50 тысяч клиентов. Порог вхождения уменьшается, но программирование развивается все равно. Это прогресс и он будет независимо от того нравится это кому-то или нет.. Спектр задач меняется, повышается уровень абстракции, но это и позволяет иметь сейчас то, что мы имеем.

1
Автор поста оценил этот комментарий

.kkreiger
Это название той игры. Вот как она выглядит

https://www.youtube.com/watch?v=2NBG-sKFaB0

1
Автор поста оценил этот комментарий
Zero tolerance нпа сеге?)
1
Автор поста оценил этот комментарий
Вообще не понял при чем тут 3д шутер в 100Кб.
По-моему такой камент все равно что написать в посте про съёмки фильма "чужие" примерно следующее: "да не умеют они снимать, я фильм за 300 долларов видел"
раскрыть ветку (5)
Автор поста оценил этот комментарий

Ну, насколько я понял, статья написана про то как люди РЕШАЛИ проблемы/ограничения с которыми они сталкивались. А сейчас никто особо с этим не морочится, типа: "пошли все нахер, пусть покупают компьютер лучше"...

Я не понимаю какого органа игра в которую я играю на XBOX 360, тормозит на і5???

К сожалению, это проблема не только в сфере игр/софта.

Я занимаюсь написанием программ для ЧПУ станков (в основном раскрой листового материала) и иногда консультирую людей в этом вопросе. Приезжаешь к клиенту смотрю на задание для станка и вижу дичь - говорю оператору можно оптимизировать и будет выполнятся в два-три раза быстрее, а он мне: "нахуя?, я скорость подниму на 20-30% и норм!". И увеличенный износ расходников и станка его не ебет(((. А когда поднять скорость/увеличить нагрузку нет возможности - начинаются сказки про необходимость апгрейта оборудования.

раскрыть ветку (4)
Автор поста оценил этот комментарий
При чем здесь статья? Я возмущён комментарием к статье в которой говорится, что программисты какого-то говна в 100Кб могут называться программистами, а авторы шедевра - нет.
И да, может я ошибаюсь, но коробокс апскейлит графон из 640х480 до фуллхд. Запустите те же игры на этом разрешении и они у вас полетят
раскрыть ветку (3)
Автор поста оценил этот комментарий

Пошутил? Запусти ради интереса Масс Эффект1,2,3 на 640х480 и попробуй поиграть...

О каких авторах шедевра идет речь?

раскрыть ветку (2)
Автор поста оценил этот комментарий
Не шучу, коробокс, на сколько мне известно, из 640 делай фуллхд замыливая разницу.
Об авторах крэш бандикут, вестимо
раскрыть ветку (1)
Автор поста оценил этот комментарий

Ну хз! Я прошел весь Масс Эффект, на компе 2 раза и на коробке 2 или больше, сильной разницы не заметил. Хотя видео в 480 выкупаю сразу...

1
Автор поста оценил этот комментарий
Это демосценеры и это был челлендж, если не ошибаюсь то вы про kkrieger, сейчас если пишется игра и кто-то будет ни с того ни с сего браться за такое байтодрочерство то ему уши оторвут и правильно сделают, у всего должна быть целесообразность, поскольку процесс написания кода ни разу не дешевый. Ну а насчет сайтов, то погружение в современные тенденции вебдева может с легкостью сорвать кукушку, тут как в анекдоте про молоток и все вокруг как гвозди. Почему-то именно в этой среде (ну и мобильный дев тоже) очень сильна идея взять фреймворк поновороченее и использовать его для всего.
1
Автор поста оценил этот комментарий
kkrieger
Компьютерная игра в жанре шутера от первого лица, разработанная компанией .theprodukkt GmbH, бывшим коммерческим подразделением Farbrausch. Презентация проекта состоялась на демопати Breakpoint в апреле 2004 года, где .kkrieger занял 1-е место в категории 96-килобайтных игр. Впоследствии игра завоевала 2 премии на церемонии «German Game Developer Award 2006».
3
Автор поста оценил этот комментарий

Это шутер полностью рисуется процессором. На ПС1 такое бы не прокатило, если ты не хотел бы играть в 0.00001 кадр в день

раскрыть ветку (6)
Автор поста оценил этот комментарий

Не совсем. Процессором рисуются текстуры и распаковываются/генерируются модели, после этого они висят в ОП так же, как загруженные с диска и игра работает примерно как обычная. Я не говорю, что тут не нужен талант, но все же.
Если иметь в виду качество 3д под PS1, то наверняка на нее можно было бы так же сгенерить текстуры/создать модели и поиграть в шутер. Понятно, что качество было бы не таким, ну так и на генерацию меньше бы ресурсов понадобилось. Но на старте могло бы висеть довольно долго

раскрыть ветку (5)
8
Автор поста оценил этот комментарий

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

раскрыть ветку (4)
Автор поста оценил этот комментарий

ты прав. и именно эта игра действительно бы не смогла пойти на пс1. Но можно было бы упростить. Все работает приблизительно как визаулизация в винампе. Это формулы и формулы...

раскрыть ветку (2)
Автор поста оценил этот комментарий

нет не можно было
даже если представить что 33 мегагерца смогут все отрисовать как в Crash Bandicut , то на все остальное просто не хватит процессорного времени, а еще ведь нужно 30 фпс стабильно держать + все противники и другие скрипты + безостановочная подгрузка кода с диска ( в оригинале можно был загрузить уровень/мультиплеерную карту в том же Q2 и спокойно играть без диска пока не дойдешь до места загрузки, там в салоне на 10 приставок все играли мультиплеер с 1 диска, просто ставили фраг и тайм лимиты на бесконечность)

раскрыть ветку (1)
Автор поста оценил этот комментарий

А если битность цветов всего для 16 цветов и использовать это пл максимуму? В свое время roller coaster tycoon / transport tycoon были всего по 256 цветов. И это было уже в те времена когда нужно было гораздо больше. Как минимум для карусельного магната. Но я могу быть не прав. Надо все сидеть считать. Хотя смотри. 33 мегагерца. 30 фпс. То есть около 1 мегагерца га 1 кадр. 320 на 240   16 цветов. Итого 76800*16=1228800 /8 = 153600 байт в 1 кадре. Это растр в полном экране где занят каждый пиксель


Короче как с вектором посчитать я не знаю... Запутался. Ну соответственно это максимальная нагрузка при 16 цветах. Исправьте меня если я не прав

Автор поста оценил этот комментарий

Тут ты противоречишь сам себе - в kkrieger есть и текстуры, и модели, и звуки. Они просто не загружаются в память с диска, а генерируются во время долгой загрузки или на ходу в оперативной памяти, после этого загружаются в видеопамять (в случае текстур и моделек).
И отрисовывается все, соответственно не процессором, а видеокартой, как и в обычных играх.
Многие модели или звуки в демосценах таки хранятся как ресурсы или прямо в коде и тупо загружаются/распаковываются/перетесселируются. За кригера не уверен, но речь то шла про принцип.

Я прекрасно понимаю, что Я "несу".

Более того, Я даже в теме, как все делается в демосценах. Я их писал. Не кригер, но всеж.


Дальше, по поводу ПС1 - разумеется он не может сделать это своими силами. Как и отрисовать подобную картинку.
Именно поэтому Я по русски написал - "Если иметь в виду качество 3д под PS1".
Если иметь в виду гораздо менее детальные текстуры, без множества каналов, гораздо более простую сетку мешей, более простые методы генерации всего этого добра. Банально меньше оперативной памяти, в которую это добро можно генерировать и загружать.
Можно было бы точно так же сделать очень маленькую игру с генерируемыми ресурсами и она бы прекрасно работала.
И разумеется, на это все ушло бы больше времени, чем с диска грузить. У кригера тоже уходило бы времени на загрузку больше, чем если бы он был сохранен как набор моделек и текстур и грузился бы с диска.

Автор поста оценил этот комментарий
Что за шутер?
Автор поста оценил этот комментарий
.kkrieger называется
Автор поста оценил этот комментарий
kkreiger
Автор поста оценил этот комментарий
Сега, зеро толерансе , 3д шутер на картридже
раскрыть ветку (1)
Автор поста оценил этот комментарий

Кстати есть канал одного разработчика, который рассказывает на какие ухищрения пошёл ради всяких клёвых эффектов в играх на сегу. GameHut называется. Требуется знание инглиша.

Автор поста оценил этот комментарий
Kkrieger 96kb
Автор поста оценил этот комментарий

Считаете, они жались из-за характера, а не ограничений железа?

Автор поста оценил этот комментарий

Ремастер краша занимает 919 мб ОЗУ.

Сколько видеопамяти жрет - это уже другой вопрос.

Автор поста оценил этот комментарий

Это интерактивная демосцена.

Автор поста оценил этот комментарий

http://virtuallab.by/load/igry/raznoe/kkrieger_samyj_malenki...

95 кб, да) Там насколько я знаю уровни генерятся и сделано всё на ассемблере.

В посте лисп-жирно так-то.

Автор поста оценил этот комментарий
https://youtu.be/fnNK5xV2_P4
вот видос на эту тему.
1
Автор поста оценил этот комментарий

kkreiger называется

Автор поста оценил этот комментарий

Оптимизацию придумали те, кто не умеет делать мощное железо )

Автор поста оценил этот комментарий
Жаль к нему дополнений не было. Вполне была годнота. До сих пор на диске валяется. Только он был 96кб- помещался на одну дискету. kkrieger beta
ещё комментарий
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку