LINUX.ORG.RU

PPSSPP 1.6.0

 , ,


0

2

Состоялся релиз эмулятора портативной игровой консоли Sony PSP - PPSSPP 1.6.0. Эмулятор доступен для платформ GNU/Linux, Windows, macOS, iOS, и Android, существуют неофициальные порты на множество других платформ. Эмулятор использует высокоуровневую эмуляцию (HLE), поэтому для работы не требует Bios оригинальной консоли.

В новом выпуске:

  • OpenGL бэкенд отныне поддерживает мультипоточный рендеринг, что позволило очень сильно повысить производительность;
  • Обеспечена поддержка Vulkan-бэкенда в Linux, в сборках на базе SDL (поддержка в сборках на базе Qt5 будет добавлена позднее);
  • Обеспечена поддержка Wayland для Vulkan-бэкенда;
  • Для Vulkan включено по умолчанию кеширование шейдеров;
  • Добавлена поддержка RetroArch, посредством библиотеки libretro-ppsspp, которая ранее существовала отдельно от основного проекта;
  • Многочисленные улучшения производительности в командном интерпрететоре GPU;
  • Различные улучшения в работе мультиплеера;
  • Многочисленные оптимизации и исправления багов в JIT-компиляторе для ARM64;
  • Многочисленные улучшения производительности в версии для iOS, улучшена совместимость с новыми версиями macOS;
  • Эмулятор отныне использует OpenGL Core Profile на Linux и macOS, что обеспечило совместимость с OpenGL 3.x;
  • Многочисленные улучшения в версии для Android;
  • Улучшена совместимость: 1016 игр признаны полностью рабочими, проходимыми на 100% и лишёнными графических артефактов; 477 игр содержат графические или физические баги, но в целом играбельны; 279 игры запускаются и работают, но зависают или вылетают в разных местах (непроходимы); 130 игр показывают только начальный экран; 259 игр не загружаются вообще; 2202 остаются непротестированными.

Страница загрузки

PPA со стабильными версиями

PPA с нестабильными версиями

Flatpak

Исходный код

>>> Подробности

Vulkan

Это надо отметить хорошей игрой. Какую вы посоветуете?

a1batross ★★★★★ ()

Для яблочных операционок не видно что-то версии. Или 1.6.0 таки научилась в них?

PaRuSoft ★★★ ()
Ответ на: комментарий от Sunderland93

Эх. На мобильнике тормозит. Но с Vulkan дело обстоит хотя бы получше — аж на 5 кадров выше.

a1batross ★★★★★ ()
Ответ на: комментарий от a1batross

Эх. На мобильнике тормозит.

Играть. В. Кнопочную. Игру. На. Сенсоре.

anonymous ()
Ответ на: комментарий от anonymous

У меня есть геймпад с крепежом для мобильника. :)

a1batross ★★★★★ ()

Кстати, неплохо эмулирует. Но гонял только на ПК.

Valeg ★★★ ()

Здорово, отличный эмулятор. На оригинальных ЗЫЗах экраны плохие, а тут хоть в full hd пройти можно.

karton1 ★★★★ ()
Ответ на: комментарий от a1batross

Fate/Extra
Хотя ты наверное уже, судя по картинке.

d_a ★★★★★ ()

The 3rd Birthday можно играть на андроиде кто нибудь запускал?

jester-666 ()

вроде работает шустро ,а где игры брать
написано версия 1.6.0 а скачивается v1.0.1-769-gc4ea4e3

zoloz ()

Исходный код

А исходники субмодулей тарболом кто выкладывать будет? Всё приходится самому делать... Вот они: https://yadi.sk/d/xUNYpLfu3WbdiE

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

А исходники субмодулей тарболом кто выкладывать будет?

Научись в git

Sunderland93 ★★★★★ ()
Ответ на: комментарий от Sunderland93

При чём тут git? Сборочный процесс автоматизируется таким образом, чтобы он успешно проходил хоть на Альфа-Центавре, где нет земных интернетов. Поэтому до запуска сборочного скрипта рядом с ним должны лежать все 100% исходников. А то, что Вы предлагаете, больше похоже на путь сборки на коленке руками. Когда юзер сам извлекает основную часть исходников, руками докачивает субмодули, а затем делает "./configure && make && make install". Это не путь серьёзных дистрибутивов. И тот же слакбилд ppsspp ожидает именно два тарбола. Второй до меня никто не выложил, и потому мне пришлось делать его самому.

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Это не путь серьёзных дистрибутивов.

Серьёзные дистрибутивы именно так и делают - выкачивают из гита код, вместе с подмодулями, переходят на нужный коммит/тэг, и затем кидают сборочные скрипты и всё это дело опакечивается. Хотя жителям 90-х с их диал-апами этого не понять

Sunderland93 ★★★★★ ()
Ответ на: комментарий от Sunderland93

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

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

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

Мейнтейнер качает все сорцы и готовит их для сборки. Во время самой сборки пакета никакого скачивания не происходит

Sunderland93 ★★★★★ ()
Ответ на: комментарий от Sunderland93

Во время самой сборки пакета никакого скачивания не происходит

Именно об этом я и говорю уже который пост.

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

Научись в git

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

А вот в рамках

качает все сорцы и готовит их для сборки

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

качает все сорцы и готовит их для сборки

лепить.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

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

Во время какого сборочного процесса? Перед сборкой. Не архивами, а просто гитом, с выкачиванием всех подмодулей. И превращения этого всего потом в один тарболл с кодом, который скармливается сборочной системе

Sunderland93 ★★★★★ ()
Ответ на: комментарий от Sunderland93

Во всех приличных дистрибутивах, включая Debian, Федору, Slackware, Магейю и тонны других, во-первых, никто не собирает код соответствующий рандомным обновлениям кода в git'е, а только конкретные релизные версии (по крайней мере, если есть возможность), а, во-вторых, везде рядом со сборочными скриптами все исходники находятся именно в тарболах. Исключая, разве что, например, патчи. А сами исходники именно в тарболах. Которых может быть сколько угодно.

Я даже и не знаю про какой такой дистрибутив Вы говорите.

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Мне можно не рассказывать, 3 года уже несколько репов для Убунты и Деба держу. Ещё раз - если релиз в тарболле, но при этом в дереве есть подмодули, то проще всего вытянуть это всё гитом, а потом просто отревертить изменения на коммит, соответствующий последнему релизу. А далее уже накладывать сборочные скрипты, паковать в тарболлы и собирать

Sunderland93 ★★★★★ ()
Последнее исправление: Sunderland93 (всего исправлений: 2)

поиграл в Dead or Alive - Paradise ,тормозит жутко на атоме n570 .

zoloz ()
Ответ на: комментарий от saahriktu

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

t184256 ★★★★★ ()
Ответ на: комментарий от saahriktu

Сборочный процесс автоматизируется таким образом

git clone blablabla && git submodule update && ./configure && make && make install

xDShot ★★★★ ()
Ответ на: комментарий от saahriktu

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

xDShot ★★★★ ()
Ответ на: комментарий от xDShot

git clone blablabla && git submodule update

git clone --recurse-submodules

make install

Не надо так делать

Radjah ★★★★★ ()
Ответ на: комментарий от Radjah

Не надо так делать

В процессе опакечивания же

xDShot ★★★★ ()

Когда-то давно на стабильной сборке с сайта не работала игра Danganronpa, с тех пор играю исключительно на dev-сборках.

Radjah ★★★★★ ()

А можно играть на ноуте/компе, используя джойстики?

kaafree ()
Ответ на: комментарий от anonymous

Ты еще не видел настоящих извращений :D

https://imgur.com/QacZ3mF

ЗЫ: на самом деле этот метод действительно удобен для курков. Да и для стиков китайцы выпускают похожие решения в виде присосок-накладок.

abcxy ()
Ответ на: комментарий от saahriktu

Альфа-Центавре

Так вот откуда ты такой уроненный.

anonymous ()
Ответ на: комментарий от zoloz

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

anonymous ()
Ответ на: комментарий от saahriktu

про OS/2 и SOM

по мотивам треда:

ну полуось вообще любопытная вешь. читаю подборку про SOM, например J.Hamilton-DirectToSOM-CXX.pdf , занятно. ( бложик по тегу SOM). у него там рядом ещё Copland лежит: MacOS9 Classic + SOM + C++ - ный фреймворк Taligent.

суть вопроса: обычное процедурное программирование прозрачно по ABI, то есть можно линковать *.o сгенерированное gcc, gfortran, gnat и т.п. прозрачно.

в С++ всё это не так: во-первых, Fragile Base Class problem, во-вторых, ABI (например, манглинг) завязан на особенности реализации отдельных компиляторов. в итоге объектный фреймворк написанный на С++, например — недоступен ниоткуда кроме С++, да и там проблемы: невозможно сохранить RRBC, то есть release-to-release binary compatibility: нужно нудно перекомпилять всех клиентов фреймворка (например, вышла новая Qt с новым ABI — нужно revdep-rebuild сделать), да и из какого нибудь кобола эти С++ объекты недоступны (в отличие от например GTK GObject или вот например, SOM).

в итоге, что сделали IBM: решили свою интимную проблему «как не отдавать исходники базового феймворка, например, SOM» и не перекомпилять при обновлении системы всех клиентов (например Workplace Shell WPS — объектно-ориентированный десктоп, расширяемый наследуемыми объектами, компонентами на SOM).

в книге Jenifer Hamilton, одного из авторов компилятора Visual Age C++ DirectToSOM compuler прослеживается логика построения архитектуры этой SOM:

1. выделить проблемы (ломается бинарная совместимость фреймворка и клиентов)

2. сформулировать инварианты и трансформации (класс можно передвигать вверх-вниз по иерархии, двигать метод в предка или вверх-вниз по иерархии, добавлять переменные члены, добавлять новые методы, вставлять классы в иерархию, переупорядочивать методы класса, переменные члены, изменять приватную часть класса, и т.п.) см. Release-to-Release Binary Compatibility in SOM.pdf где это выглядит умозрительно красиво в виде теории, стр. 8 для процедурного и стр. 9 для ООП.

3. построить транзитивное замыкание: объект (объект экземпляра)-метаобъект (объект класса)-метакласс (объект метакласса)-метакласс (=метакласс метакласса)

4. построить системную архитектуру SOM, реализующую в рантайме все эти инварианты и трансформации.

5. построить sc, som compiler IDL -> plain C SOM objects

6. допилить C++ компилятор : DirectToSOM : C++ *.hh -> SOM idl -> plain C (++) SOM objects

тащем-то, SOM объекты и не SOM, native C++ объекты визуально в исходниках отличаются на уровне VisualAge C++ DirectToSOM только тем, что наследуются от SOMObject. это конечно компилируется в какой-то рантайм оверхед, с thunks, marshalling, и шайтан-CORBA во все поля.

примерно как в Vala можно объект отнаследовать «от никто» или от GObject, и умный компилятор делает обёртки в рантайме.

далее абстрактные фабрики фабрик и SOM Object services: например, репликация,распределённые или персистентные объекты (сериализованные прозрачно в плоский файл, Btree или DB/2, или ещё куда)

в итоге получается: IBM фактически запилили отдельное ABI ( SOMLINK) и «объектный линкер».

далее любопытные примеры, например презентация про программирование на REXX и WPS: хотим сделать, например, пароль на папку в WPS. создаём SOM класс отнаследованный от SOM папки, перекрываем на Object REXX отнаследованный метод, проверяем паролю. этот класс можно использовать на любом другом языке, класс бинарный, хранится в DLL-ке.

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

так что в полуоси фактически не важно что процессы в LX EXE, а библиотеки в DLL. ибо SOM и можно запилить свой ООП линкер с подгрузкой общесистемных персистентных объектов.

или отнаследоваться от SOM объектов на какой-нибудь ADA или Object COBOL, ога.

идеальная ОС для системного интегратора :)

anonymous ()
Ответ на: про OS/2 и SOM от anonymous

Re: про OS/2 и SOM

хотя... IBM потратила ярд на свою уникальную архитектуру и уникальный компилятор. компилятор и C library не так уж и плох, по крайней мере fork и signal из коробки имеются.

в итоге таки решила свои половые трудности: как апгрейдить ООП базовый фреймворк, но исходников не отдавать.

правда, требуется свой уникальный компилятор и рантайм обвязка. правда реализация рантайма тормозит — thunks и marshaling.

правда, в линуксе (при наличии исподников, ога) — можно упал-отжался, перекомпилять ABI зависимости revdep-rebuild. неявно, кстати, они и на С имеются, например, когда glibc ABI меняется: linux ABI это фактически смесь сисколлов ядра и исходников этой версии ядра, glibc завязанного на сисколы, всего прочего, завязанного на версии glibc, gcc и /usr/src/linux.

правда, полюбому остаются базовые проблемы ядра полуоси:

* однопользовательность

* 32-битность

EXE + DLL здесь тоже, но это наименьшая из проблем.

теоретически можно запилить на базе L4, например Genode что-то микроядерное совместимое с OS/2 API, и частично, ABI.

но без исходников SOM и возможности перекомпилять её под новое ядро — OS/2 ABI остаётся невоспроизводимым полностью.

так что ядро Linux всё-таки лучше (меньше дурацких ограничений в POSIX), но с SOM ещё можно как-то побарахтаться, да.

хотя книжка Jeniffer Hamilton зело интересная, ога.

ещё рядом лежит про OPENSTEP 4.0 под Windows и полуось, и книжка Brad J. Cox. Object-oriented programming; an evolutionary approach. 1986-ого года про Objective C.

увлекательное чтиво же.

любопытно, как оно там будет в ArcaOS Blue Lion. вроде бы запилили нормальный дистрибутив полумуха.

anonymous ()

Хороший эмулятор, МеталГир немного поиграл. Кстати, для линукса версию 1.6 не нашёл, только 1.5.4, но и так работает.

Такой вот вопрос. У меня плохой джойстик, проблема с чувствительностью стиков. В МГС порог между «идти» и «бежать» слишком мал, нужно оооооочень немного подвинуть джойстик, чтобы персонаж медленно пошёл, но если только на полмилиметра больше надавить, персонаж уже бежит. Тоесть сила нажатия на стик, при которой персонаж идет медленно, слишком неуловима, он либо стоит, либо бежит. А в стелс-игре это критический момент!

Пробовал устанавливать «мертвую зону» где-то 15-20%, а также менять настройки чувствительности как в эмуляторе, так и в самой игре, но хороших результатов не добился. Понимаю, что это аппаратная проблема, был бы у меня нормальный иксбоксовский контролер, а не дешёвая поделка, всё было бы иначе.

Может, есть софтварное решение? Кто сталкивался?

rumly111 ()
Ответ на: комментарий от zoloz

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.