Vulkan

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

God of War: Chains of Olympus

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

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

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

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

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

Просьба подтвердить

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

Возьми что-то из этого топчика, например.

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

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

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

Я и CCC умудрился пройти вслепую. :)

Valeg, спасибо!

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

Исходный код

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

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

Научись в git

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

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

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

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

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

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

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

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

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

Научись в git

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

А вот в рамках

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

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

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

лепить.

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

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

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

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

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

FF7:Crisis Core же.

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

Дураков. Нет.

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

MGS3: Peace Walker,FF7:Crisis Core

Нет, не так

Да, так

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

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

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

git clone blablabla && git submodule update

git clone --recurse-submodules

make install

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

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

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

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

Тогда ладно.

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

можно

Это однозначно ура

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

https://imgur.com/QacZ3mF

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

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

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

атом

Земля те пухом.

Хорощий штука, игры умеет.

в твоей psp мощнее железо ?

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

про 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, ога.

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

хотя... 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. вроде бы запилили нормальный дистрибутив полумуха.

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

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

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

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

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