DreamShell 4.0 RC 3

[SuperClaw]

а без пересборки - любым конвертером?
Второй вариант - как узнать LBA? И пересобирать придется уже не iso make-ом?

[SWAT]

Попробуй просто через any2iso.bat в iso make.

[SuperClaw]

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

[SWAT]

Играть в Shenmue 2 с CDI образа на SD крайне печально, там чистый ISO то кое как шевелится.
Попробуй каким нибудь другим конвертером это сделать ну или как то узнать какой там LBA. Можно конечно методом тыка попробовать 11700 и 11702, но не факт что они там использовались, так как у пираток бывают (часто натыкаюсь последнее время) совершенно немыслимые LBA и утверждение что используется всегда 11702 мягко говоря не верно.
Но попробовать стоит сделать пару образов.

Код:

mkisofs -V GAMENAME -C 0,11700 -G data_directory_name/IP.BIN -joliet -rock -l -o game.iso data_directory_name
mkisofs -V GAMENAME -C 0,11702 -G data_directory_name/IP.BIN -joliet -rock -l -o game.iso data_directory_name

А вообще что за ошибка то была?

[megavolt85]

LBA определить не сложно, потребуется Daemon Tools и IsoBuster, монтируем CDI образ в Daemon Tools, открываем IsoBuster, остальное понятно из картинки.



P.S SILENT_Pavel добавь в FAQ

[SuperClaw]

да вы не поняли, игра то у меня запустилась без конвертации) и идет нормально - чуть чуть фпс проседает (а он и с диска проседает). Проблема то в сохранении пресетов. Когда выделяешь образ с сохраненным пресетом - черный экран, огромный набор слов и в конце reboot after 10 seconds, или как то так

---

и еще, на dynamite cop знает кто-нибудь настройки?

---

и еще, на dynamite cop знает кто-нибудь настройки?

[megavolt85]

у меня с HDD такое тоже бывает, причем сохранил пресет, закрыл iso loader снова открыл, всё работает, перезагрузил дрим и на этом пресете начинает вылетать

[SuperClaw]

А можно ли в скрипте прописать эти настройки, чтобы без пресета?

[PVS]

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

(17.03.2015 15:06)SWAT писал(а):  Проблема с пресетами похоже кроется в библиотеке fatfs, там были какие то баги, посмотрим пройдет ли это после обновления. Ошибка эта не постоянная, похоже зависит от фрагментированности файловой системы. Попробуй отформатировать SD, размер кластера выбирай максимальный.

Вот это, вполне может оказаться в стороне проблемы, с оговоркой - на мой взгляд, начинающего пользователя Дримшел. Тут хотя-бы нужно технически представлять, что делает ISOloader, когда находит свой пресет для конкретного образа, у меня такой информации нет. Если имеется ввиду - фрагментированность конкретного образа на SD например, то такой зависимости я не нашел. Записывал образ на SD, проверял, что он "лёг" без фрагментов (да и вообще - на SD не было ни одного фрагментированного файла) - вылеты из-за пресета для такого образа случались так же - рандомно. Проверял на 2-х SD (4 и 16 Гб), для разных размеров кластера на них - вылеты оставались. А может это быть не программной, а железной проблемой? Например, качества и методов исполнения мода для HDD или SD?

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

(19.03.2015 15:17)SuperClaw писал(а):  А можно ли в скрипте прописать эти настройки, чтобы без пресета?

Вместо пресетов для ISOloader - использую ярлыки на рабочий стол, посмотри эту тему:
http://www.dc-swat.ru/forum/thread-2157.html

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

SuperClaw, подскажи особые настройки в ISOloader для запуска Шэнму2, если используешь. Я когда-то пробовал - не смог запустить пиратку с SD, игра начинает запускаться и виснет на черном экране, после запуска исполняемого файла.

[SuperClaw]

я про ярлыки и говорил. Как в скрипте ярлыка прописать эти особые настройки?
Я ставил предпоследний адрес, как на видео. А эмуляция асинхронной передачт на запуск не влияет. Едиственное, я заметил, что со значением 16 похоже идет лучше, чем со значением 1+

[megavolt85]

SuperClaw писал(а):Как в скрипте ярлыка прописать эти особые настройки?

Этот пост и следующий

[SuperClaw]

спасибо) а есть ли вообще хоть одна игра, которая запускается через IP.BIN?

[SWAT]

SuperClaw, я понял что ты запустил CDI, но с ISO образа будет работать лучше. А эмуляцию лучше ставить 1+ чтобы как можно меньше проседал FPS, особенно на ISO, на нем будет максимально гладко. А то что грузится подольше при таком значении - это побочный эффект.

[megavolt85]

не задавался этим вопросом, практически всё запускаю через Direct

[SWAT]

(19.03.2015 20:31)SuperClaw писал(а):  спасибо) а есть ли вообще хоть одна игра, которая запускается через IP.BIN?

Запуск с IP.BIN был по большей части необходим для биоса sd_loader_with.bios.
С новыми биосами, а так же с оригинальным, можно запускать все напрямую (режим direct).

[PVS]

SWAT, хотел спросить - имеет ли смысл ставить в ISOloader большие значения Emulate async read при работе с SD-карты? У SD около 650-700Kb/s на чтение максимум, например для значения Emulate async read 16 - такой скорости хватит? Если ограничения для SD есть, то на какое значение Emulate async read ориентироваться примерно?

Вроде видел инфу на форуме, что Emulate async read 1+ - это 1х скорости GD-ROM и около 500Kb/s. Тогда выходит, что для SD-карты в значениях Emulate async read больше 2 - смысла уже не нет.

[SWAT]

Тут не все так просто. Объясню принцип действия.
Игры расчитывают что данные с привода летят в память по DMA и этим занимается DMAC (некая периферия в CPU), а не сам CPU.
В это время CPU занят просчетами в самой игре. Поэтому HDD/CF в режиме true async DMA это наиболее благоприятные условия для игры. Но такие условия могут дать только HDD/CF с ISO образами (или оптимизированные GDI) запущенными в DMA режиме.
В случаях же SD, HDD в PIO режиме, CDI и не оптимизированные GDI образы не могут работать в true async DMA режиме, а значит приходится блокировать процессор на время передачи данных ибо он участвует в этом процессе постоянно.

Эмуляция асинхронного чтения необходима для того, чтобы не блокировать процессор полностью чтением данных, которые игра запросила.
Она разбивает данные на части и каждый кадр в игре считывает 1 часть. Размер этой части задается как раз этой цифрой, о которой ты говоришь.
Чем меньше часть, тем меньше будет просадка FPS при подгрузке данных во время геймплея. Это особенно заметно в Shenmue 2 и Crazy Taxi 2, советую на них поиграться с эмуляцией асинха на ISO образах и поймешь что к чему.

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

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

Так вот, откуда взялась цифра 1+. На самом деле это означает 1.5 сектора и это используется только у SD при условии что используется ISO образ или оптимизированный GDI (как для true async dma). Эта та грань, за которую в играх переступать не рекомендуется, иначе данные не будут успевать. Для HDD меньше 2 ставить смысла нет, он эти 2 сектора очень быстро читает даже в PIO, поэтому я не делал для него таких изысков.
Если соблюдены условия с форматом образов, то SD может не только читать по 1.5 сектора, в этом случае эмуляция асинх работает несколько иначе в принципе. Я бы даже назвал это некой смесью true async и emu async. Конечно, это далеко от true async, так как SPI интерфейс для SD это априори тяжелая работа для CPU, но кое что удается все же выкинуть из циклов. Допустим при обычной эмуляции асинх, каждый кадр в игре делается запрос к устройству на чтение части данных через файловую систему. В случае же с true async или "особым" async у SD, запрос отправляется только 1 раз и потом уже каждый кадр делается опрос состояния, а в случае с SD так и еще считывание части данных с помощью CPU на низком уровне, которые контроллер SD подготовил для нас после запроса. Т.е. получается что мы не отправляем каждый раз новый запрос и не ждем пока контроллер SD ответит (блокируя CPU дольше чем хотелось бы), а отправляем его 1 раз (когда игра попросила) и потом просто дочитываем данные с каждым кадром, при этом минуя еще и часть кода файловой системы. Все это экономит ресурсы CPU, которые очень нужны при использовании SD.

Кстати в эмуляции асинх есть еще одна хитрость. Если игра запросила 100+ секторов за раз, то я предполагаю в коде что загружается либо сама игра на старте просто, либо уровень в ней, в общем геймплея нету, игрок тупо ждет загрузки. На этот случай я вообще выключаю эмуляцию асинх и гружу этот кусок максимально быстро. Без этой маленькой фишки, игры, с малыми значениями emu async грузились бы утомительно долго на старте и во время загрузки уровней. Конечно алгоритм не идеален, игра может разными частями грузить и во время старта, но тут уже ничего не поделаешь, часть загрузки ускоряется и то хорошо.

[SuperClaw]

выходит, мне только показалось, что игра стала плавнее после переключения с 1+ на 16? (я уже с ISO запускаю, снял его GD Riper-ом). Просто в месте у фонтана, где всегда ужасно подвисало с диска, меньше с SD со значением 1+, со значением 16 почти не подвисало. Но единственное я заметил на значении 16, после ролика в 19 часов начало ужасно лагать, пока не прошел в другую локацию.
И еще. Если я правильно понял, чем меньше значение асинх, тем больше шансов, что не будут успевать прогружаться люди, движущиеся объекты? (чем страдает игра с диска).

---

И еще, если запуск идет с CDI, значение 1+ бесполезно ставить?

[SWAT]

Просто в случае с 16 там не то чтобы FPS падает, игра просто подлагивать начинает, когда данные читаются. Т.е. она лагнула и дальше плавно, потом опять лагнула и опять плавно.
А когда значение меньше, то эти лаги как бы растворяются, точнее разбиваются по кадрам и вместо жесткого лага ты видишь падение FPS в некоторых местах.
Да, чем меньше значение асинх, тем меньше людей на улицах, но выше FPS. Чем больше значение, тем быстрее люди подгружаются, но лаги становятся сильнее и уже отличимы, нежели просто просадка FPS. В общем тут кому как я думаю, лично я бы выбрал отсутствие лагов, нежели большее количество людей

Если запуск будет с CDI, то 1+ будет работать как 1 сектор и этого крайне мало, улицы вообще пустыми будут К тому же сам CDI читается медленнее ISO, поэтому ему лучше 2 сектора ставить. Но такой плавности как на ISO тебе не видать в любом случае.

[SuperClaw]

ну это мне уже посчастливилось сравнить) а CSO может как то еще больше улучшить ситуацию?