Для этого в памяти и остается ядро, а графическая оболочка - XMB, по идее, выгружается. Именно поэтому во время игры нельзя даже по меню полазить, только выйти сначала
Если я не ошибаюсь, R4000 в ней действительно два - один как основной CPU, а другой для мультимедии.
Но интереснее всего, конечно, то, что Sony умудрилась воткнуть в нее не только очень мощное железо (как на время выхода, так и лет на 5 вперед), так и настоящий физический дисковод! Который еще и умудрялся работать от батарейки вполне себе приемлемое время.
А ещё, тоже если правильно помню, при запуске игр основная ОС выгружалась из памяти практически полностью - всё для того, чтобы играм больше RAM доставалось.
Про сами игры молчу - полноценные PC порты, самостоятельные тайтлы эксклюзивно для PSP, эмулятор PS1 из коробки, эмуляторы других платформ (даже J2ME) от сообщества... Да даже сейчас на PPSSPP в 1080P многие PSP игры выглядят очень и очень неплохо.
Кажется, не взлетит. На Windows уже есть очень и очень приятный C#.
Кто и зачем будет писать под неё на Swift, причем страдая как от неполной поддержки стандартной библиотеки (привет, первые годы Server Side Swift), так и от того, что всё равно надо будет разбираться с UI винды?
Чем больше раз в статье упомянуть слово «фундаментальный», тем страшнее должно стать?
Проверка контрольных сумм при скачивании - это же не репозиторий линукса. Тут и в самом первом варианте кряка может быть что угодно. Зато с правильной суммой? :)
В целом было бы интересно во второй части статьи увидеть не рекламу, а мини исследование - реально ли, например, действительно подменить сертификат так, чтобы тот же системный браузер позволил сделать MITM на практике.
Я как раз уже был готов все доказать, используя самую обычную математику. И математика меня спасла, когда я увидел заявленные 40 пачек:
Размер купюры - 157×69 мм. Толщина купюры - около 0.1 мм. Пачка из 100 купюр, соответственно - 1 сантиметр толщиной.
Объем одной пачки (посчитаем сразу в сантиметрах) - 15.7 x 6.9 x 1 = 108.33 кубических сантиметра.
Банка 3 литра - очевидно, вмещает 3000 кубических сантиметров.
Делим 3000 на 108.33 - получаем 27.69 пачек.
Есть довольно большой запас как на то, что часть купюр будет неидеально новой (что увеличит толщину пачек), так и на то, что пачки не будут идеально плотно лежать друг рядом с другом (но все равно в целом это не кирпичи и их можно будет как минимум немного сгибать).
Ну и даже если совсем плохо будет влазить - пачки можно разделить на отдельные купюры, которые уже точно лягут максимально компактно.
Так что насчет 40 пачек полностью признаю вашу победу, а вот насчет 20 все-таки склоняюсь к тому, что я бы пари выиграл (:
А, я понял, где моя ошибка. Я написал «на порядок», думая про 2 пачки, а не про 2 миллиона. И утверждал, что 20 пачек вполне влезет. 20 миллионов (40 пачек) - скорее всего, уже не влезут, тут признаю вашу правду.
Да, вполне поместятся. Пари мы можем заключить, но что получит победитель? И каком виде вы хотите получить от меня доказательство? Если, к примеру, это должно было видео, то у меня просто-напросто нет в наличии такого количества рублей для чистого эксперимента.
Как-то вы плохо себе представляете стандартную трехлитровую банку. 2 миллиона рублей (4 пачки по 100 банкнот) туда поместятся ну совершенно без проблем. Да и на порядок больше тоже влезет.
Спасибо, плюсую. Вообще от macOS 26 / iOS 26 какой-то несогласованностью так и сквозит.
Если раньше был понятно, что у дизайнеров есть единая система и любое приложение использует только ее без вариантов, то теперь, похоже, каждый делает так, как видит.
Вы серьезно думаете, что если у вас код без комметариев, без нормальной архитектуры, с одной гигантской функцией main и переменными с именами a,b,c, без строгой типизации и с размазанной по всех кодовой базе логикой, то нейронка сможет так же легко читать и поддерживать этот код?
На самом деле - читать вполне сможет, правда. Ради интереса скармливал исходники Java игр и приложений, восстановленные из class-файлов. То есть это как раз огромные функции, с кучей переменных aa, bb, cc, с проблемами типизации (в Java int a и double a - разные переменные и в выводе такого - дофига). Сходу человеком это не читается вообще никак.
И съев эту мешанину она радостно говорит - вот, функция aB() это обработка выстрела, а переменная bC хранит здоровье, а вот в c и d - хранятся координаты блоков уровня.
Можно даже в бесплатном DeepSeek попробовать, реально работает.
Кодингом я занимаюсь давно. Не 30 лет, конечно, но 15 уже скоро будет. И из этих 15-ти лет я постоянно читал чужой код - начиная с примеров в книгах/документации, и заканчивая ревью кода: раньше - коллег в команде, а теперь - подчиненных. И везде приходилось разбираться, что код делает, отлавливать ошибки, корректировать архитектурные проблемы.
Возможно, вы все свои проекты делаете один? Так даже в пет проекте мне проще и быстрее перенести модель из головы в чат с LLM, а потом проверить, что получилось (я молчу про то, что можно сначала тесты написать и ещё меньше проверять руками, само проверит), чем нудно писать код, конструкции которого я писал уже сотни раз
У меня есть пример того, как кожаные синьоры сломали хорошо организованный проект. Тут дело ну вообще не обязательно в LLM. Ещё раз: посыл в том, что для профи - это ускорение и избавление от рутины. Для новичка - нет
Честно говоря, не очень понял посыл. Я могу сделать код-ревью правок LLM, могу скорректировать до такого вида, как написал бы сам. В чем именно проблема? Для этого нужен опыт 30 лет?
Для этого в памяти и остается ядро, а графическая оболочка - XMB, по идее, выгружается. Именно поэтому во время игры нельзя даже по меню полазить, только выйти сначала
PSP крутая.
Если я не ошибаюсь, R4000 в ней действительно два - один как основной CPU, а другой для мультимедии.
Но интереснее всего, конечно, то, что Sony умудрилась воткнуть в нее не только очень мощное железо (как на время выхода, так и лет на 5 вперед), так и настоящий физический дисковод! Который еще и умудрялся работать от батарейки вполне себе приемлемое время.
А ещё, тоже если правильно помню, при запуске игр основная ОС выгружалась из памяти практически полностью - всё для того, чтобы играм больше RAM доставалось.
Про сами игры молчу - полноценные PC порты, самостоятельные тайтлы эксклюзивно для PSP, эмулятор PS1 из коробки, эмуляторы других платформ (даже J2ME) от сообщества... Да даже сейчас на PPSSPP в 1080P многие PSP игры выглядят очень и очень неплохо.
Шо, опять? Эксперименты с Australis достаточно подзабыты?
Спасибо за статью про ИИ, написанную без ИИ :) Странно, что так много времени ушло на промпты. Каждый раз было прям мини ТЗ?
Так им ИИ направление почти на порядок больше профита приносит, чем игровое подразделение. Смысл распылять ресурсы?
Ещё и вернуться в игры в целом не так уж сложно будет, Intel не конкурент, AMD, все-таки, слабее.
Очень круто. Да, надо валидировать. Да, надо направлять и контролировать. Но сам факт того, что так можно, уже о многом говорит.
Кажется, не взлетит. На Windows уже есть очень и очень приятный C#.
Кто и зачем будет писать под неё на Swift, причем страдая как от неполной поддержки стандартной библиотеки (привет, первые годы Server Side Swift), так и от того, что всё равно надо будет разбираться с UI винды?
Чем больше раз в статье упомянуть слово «фундаментальный», тем страшнее должно стать?
Проверка контрольных сумм при скачивании - это же не репозиторий линукса. Тут и в самом первом варианте кряка может быть что угодно. Зато с правильной суммой? :)
В целом было бы интересно во второй части статьи увидеть не рекламу, а мини исследование - реально ли, например, действительно подменить сертификат так, чтобы тот же системный браузер позволил сделать MITM на практике.
Я как раз уже был готов все доказать, используя самую обычную математику. И математика меня спасла, когда я увидел заявленные 40 пачек:
Размер купюры - 157×69 мм. Толщина купюры - около 0.1 мм. Пачка из 100 купюр, соответственно - 1 сантиметр толщиной.
Объем одной пачки (посчитаем сразу в сантиметрах) - 15.7 x 6.9 x 1 = 108.33 кубических сантиметра.
Банка 3 литра - очевидно, вмещает 3000 кубических сантиметров.
Делим 3000 на 108.33 - получаем 27.69 пачек.
Есть довольно большой запас как на то, что часть купюр будет неидеально новой (что увеличит толщину пачек), так и на то, что пачки не будут идеально плотно лежать друг рядом с другом (но все равно в целом это не кирпичи и их можно будет как минимум немного сгибать).
Ну и даже если совсем плохо будет влазить - пачки можно разделить на отдельные купюры, которые уже точно лягут максимально компактно.
Так что насчет 40 пачек полностью признаю вашу победу, а вот насчет 20 все-таки склоняюсь к тому, что я бы пари выиграл (:
А, я понял, где моя ошибка. Я написал «на порядок», думая про 2 пачки, а не про 2 миллиона. И утверждал, что 20 пачек вполне влезет. 20 миллионов (40 пачек) - скорее всего, уже не влезут, тут признаю вашу правду.
Да, вполне поместятся. Пари мы можем заключить, но что получит победитель? И каком виде вы хотите получить от меня доказательство? Если, к примеру, это должно было видео, то у меня просто-напросто нет в наличии такого количества рублей для чистого эксперимента.
Как-то вы плохо себе представляете стандартную трехлитровую банку. 2 миллиона рублей (4 пачки по 100 банкнот) туда поместятся ну совершенно без проблем. Да и на порядок больше тоже влезет.
Спасибо, плюсую. Вообще от macOS 26 / iOS 26 какой-то несогласованностью так и сквозит.
Если раньше был понятно, что у дизайнеров есть единая система и любое приложение использует только ее без вариантов, то теперь, похоже, каждый делает так, как видит.
Вот сам репозиторий: https://github.com/wilsonzlin/fastrender
Прикольно, конечно, задача более чем масштабная выбрана.
Для глубоко интересующихся - есть ещё пост на мотофане про эту диковинку: https://forum.motofan.ru/index.php?showtopic=175329&st=40&p=1796404&#entry1796404
Очень жаль, что в реальности мы так и не увидели E399. А с E2 уже получилась совсем другая история…
Оффтоп, но КДПВ неактуальная. Линус в 2025
вот такой
На самом деле - читать вполне сможет, правда. Ради интереса скармливал исходники Java игр и приложений, восстановленные из class-файлов. То есть это как раз огромные функции, с кучей переменных
aa,bb,cc, с проблемами типизации (в Javaint aиdouble a- разные переменные и в выводе такого - дофига). Сходу человеком это не читается вообще никак.И съев эту мешанину она радостно говорит - вот, функция aB() это обработка выстрела, а переменная bC хранит здоровье, а вот в c и d - хранятся координаты блоков уровня.
Можно даже в бесплатном DeepSeek попробовать, реально работает.
Кодингом я занимаюсь давно. Не 30 лет, конечно, но 15 уже скоро будет. И из этих 15-ти лет я постоянно читал чужой код - начиная с примеров в книгах/документации, и заканчивая ревью кода: раньше - коллег в команде, а теперь - подчиненных. И везде приходилось разбираться, что код делает, отлавливать ошибки, корректировать архитектурные проблемы.
Возможно, вы все свои проекты делаете один? Так даже в пет проекте мне проще и быстрее перенести модель из головы в чат с LLM, а потом проверить, что получилось (я молчу про то, что можно сначала тесты написать и ещё меньше проверять руками, само проверит), чем нудно писать код, конструкции которого я писал уже сотни раз
У меня есть пример того, как кожаные синьоры сломали хорошо организованный проект. Тут дело ну вообще не обязательно в LLM. Ещё раз: посыл в том, что для профи - это ускорение и избавление от рутины. Для новичка - нет
Честно говоря, не очень понял посыл. Я могу сделать код-ревью правок LLM, могу скорректировать до такого вида, как написал бы сам. В чем именно проблема? Для этого нужен опыт 30 лет?