Портирование на dreamcast

[Rio]

Что ж, ясно, спасибо тебе большое за понятный и конкретный ответ!

[Lin]

Портаните Dreamchess 0.2.0 на дрим:
http://www.dreamchess.org/

[slavikmalo]

а толку? лухше бы нормальный эмулятор nintendo64

[Lin]

Эмуль надо писать. а тут все ресурсы есть Толькотграфон вроде надо взять из первой демки.

[SWAT]

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


Сообщений: 3333

[Lin]

Они писали что отказались от дрим версии и улучшили графику, поэтому я предположил, что можно взять из первой демки графику.
Попробуешь сделать?

[SWAT]

Ууу нее ты че, с DS дел завались.

[Rio]

Сват, а игрушки для Дрима используют MMU?
И что случается, если происходит выход (обращение) за пределы адресного пространства приложения? И когда такие ситуации возникают?

[SWAT]

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

[Rio]

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

[SWAT]

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

[Rio]

Ясно. А без MMU значит такой контроль просто физически невозможно осуществить? Ну я имею в виду аппаратными методами.

KOS тоже использует MMU?

[Lin]

Dreamshell использует MMU?

[SWAT]

Без MMU сложно контролировать то, что делает приложение, я бы даже сказал что это практически невозможно. Про какие аппаратные методы ты вообще говоришь?
Если в приложении есть утечка памяти (а такое часто бывает), то ОС не сможет это отследить и исправить после завершения работы приложения. Так же эта функция очень полезна если нужно ограничить доступ приложению к чему либо и для изоляции приложений друг от друга. Да и вообще это удобно, у каждого процесса память начинается как бы с нуля и по мере ее заполнения ОС либо выделяет больше памяти, либо если ее не осталось переносит эти данные на диск, а затем когда память освобождается переносит обратно. Все это было бы невозможно без MMU.

В KOS есть API для MMU, но он нигде не используется, так как по сути все что делают для дрима это одна единая программа, которая подминает под себя все ресурсы.
DreamShell тоже не использует MMU, но я серьезно об этом подумываю, может быть в следующих версиях я это прикручу, так как проблема с утечкой памяти в приложениях имеет место быть.

[Rio]

Ну да только ты забыл что на Дримкасте никакого диска нет.
Я хотел написать "программно". Ведь всегда можно отконтролить выделение массива в памяти, пускай и динамического. Просто запомнить адреса, где он начинается а где заканчивается, ну и плюс размер. Ну а со списками так вообще и того проще. Просто встроть метод удаления ненужного контейнера, и делов-то. Правда придется тогда писать прогу, которая за всем этим будет следить, а это отнимет время. ведь фактически, будет изобретаться велсипед, да и не нужно, когда есть поддержка этого на апп. уровне.
Но вот с утечками не совсем понял.
Например, есть программа, занимающая адреса, допустим, с 0x0000 по 0x03FF, а весь объем доступной физической памяти - 0xFFFF. Таким образом объем оставшейся памяти, для кучи, составляет FC00.
Вот эта прога создает от начала этой кучи массив из 100 интов, т.е. отжирает еще 400 байт памяти. Потом еще че-та создает, там же.
А потом так же свободно все это удаляет.
Так где же тут утечки тогда?

[SWAT]

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

[Rio]

-- про диск не забывал, я тебе обрисовал то, как работает ОС, а не дрим.
а я знаю как виртуальная память работает.
ну значит дураки разработчики библиотек))

[SWAT]

Гугл те в помощь

[Rio]

хрен те))

[SuperClaw]

(15.03.2011 17:54)slavikmalo писал(а):  а толку? лухше бы нормальный эмулятор nintendo64

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