ну он же не по умолчанию там стоит
Вид для печати
Вот тут, кстати, тоже интересное понимание монолоадера. Но мне все же больше нравится классическая трактовка - один склеенный файл с расширением B, который можно невозбранно копировать в любые коллекции. Собсна, современные релизы рассчитаны на использование образов в том виде, в котором их положил автор.
PS А мне как-то никогда не лень было сделать читалку каталога...
Тут вообще дикое понимание )) Одна строчка "HИКАКИХ СКЛЕИВАHИЙ. И ДОЗАГРУЗОК ЧЕРЕЗ ТР-ДОС. Программа прячется в REM строке программы ЦЕЛИКОМ" чего стоит )) ..Оно бы всё ничего, но есть куча игр которые никак не влезут в REM строку целиком. Это и 128-ые игры, и 48-ые с левелами. Интересно посмотреть на автора этих строк, как он будет целиком запихивать в REM например Last Ninja 2 или CHASE H.Q. :D
Опять-таки всё бы ничего, но в 255 секторов не всё влазит. Так то бы оно понятно, что один файл - завсегда лучше. Кстати скоко живу - ни разу не возникало ситуации, чтобы копировщик что-то скопировал в неправильном порядке.:oЦитата:
Но мне все же больше нравится классическая трактовка - один склеенный файл с расширением B, который можно невозбранно копировать в любые коллекции. Собсна, современные релизы рассчитаны на использование образов в том виде, в котором их положил автор.
PS А мне как-то никогда не лень было сделать читалку каталога...
Я тут подумал.. могу доработать свой релиз, так, чтобы по прежнему было два файла, но чтобы они работали в любом порядке)) это даже бейсиком делается)) вот только не могу понять, нафига оно надо. Разве что чисто из спортивного интереса.
Кстати, можно как-то все 3 части рекса всё-таки запихать в 255 секторов? Можно же склеить две части, а потом полученный файл пожать, там же дофига одинакового, должно хорошо пожаться. Или сначала пожать каждый отдельно, потом склеить и еще пожать?.. В случае успеха, можно всё это дело грузить по кусочкам и распихивать по 128-ым страницам, потом выбор части, потом склеиваем нужный кусок и запускаем его. Кто что думает?
если файлов много объединяют в моноблок то как правило между ними есть неиспользуемые байты. Например файл длиной 257 байт будет занимать 2 сектора (512 байт), т.е. имеем 255 свободных байтов на диске. Думаю принцип понятен. Дальше сам додумывай у тебя 4 файла плюс бэйсик так? но в 255 не уложишься похоже. Можно части рекса проанализировать на предмет одинаковых областей и их хранить отдельными секторами - если есть такой спортивный интерес.
---------- Post added at 17:26 ---------- Previous post was at 17:24 ----------
в общем это спорт чисто для себя, который никто не оценит.
---------- Post added at 17:29 ---------- Previous post was at 17:26 ----------
у каждой части свой депакер? делай один депакер и храни его в отдельном секторе.
---------- Post added at 17:31 ---------- Previous post was at 17:29 ----------
картинку прогони перед упаковкой через Screen optimizer.
---------- Post added at 17:33 ---------- Previous post was at 17:31 ----------
шрифт в частях одинаковый?
не, всякие там сектора и шрифты - не помогут, слишком сильный заступ за 255 секторов. Нужно что-то радикальное. Например я беру 1 часть и пакую хрумом, беру 2-ую и пакую хрумом. Потом эти два архива склеиваю риалкоммандером, полученный файл весит 202 сектора. Этот файл снова пакую хрумом и получается файл 115 секторов. Вот только к нему нужен какой-то заумный "распаковщик-распихивальщик в 128-ые страницы" . Интересно, этот файл 115 секторов вообще впринципе рабочий? В аттаче исходный файл 202 сектора и сжатый - 115 секторов.
Нет, htrum лучше справился.
это подтверждает теорию, что данные в частях повторяются (графика шрифты...), можно сделать вот что- разрезать каждую из 2 частей рекса кусками по напрмер 8 кб (8192 байта) и раскидать по страницам, а потом эти страницы паковать. например страница 0 будет выглядеть:
49152 - 57343 - 1 блок первого рекса
57344 - 65535 - 1 блок второго рекса
след странице будут вторые блоки по 8192 байта
затем третьи и .т.д.
потом страницы уже паковать-должно получиться.