vladikcomper

К сожалению, эта версия была утеряна. Все что осталось - вот этот скрин. Сохранилась более поздняя версия, но она неиграбельна: битая графика, отдаленно напоминающая скриншот, и испорченные уровни. Показывать ее бессмысленно. Хорошо, что нарисованная мной графика сохранилась. Так что думаю, когда-нибудь я снова сделаю этот уровень и выпущу его публично. Speed Buster'ы я тоже планирую использовать, наверное даже в SQWA.

Да, объект 85 очень сложен и нестандартен. Кстати, графика их в любом случае загружена, так что очищать ее неразумно. Может, ты имел ввиду не отображать спрайты? Мне было нечего делать, так что я решил разобрать и откомментировать нужную часть кода Obj85 ^_^ Обожаю читать и разбирать хороший код, ведь так можно многому научиться, особенно если речь про объекты и использование ими движка игры. http://pastebin.com/E5BnAAA8 Здесь ситуация сложная. За все, связанное с Эггманом, включая нахождения в капсулах, ответ на удары, побег и даже полет на Eggman's Ship, отвечает одна роутина "Obj85_Eggman". В ней, в свою очередь, вызываются другие роутины, кстати примечательно, что счетчик вторичной роутины там байт $34, а не $25. Список роутин в off_19E80. То, что тебе нужно - loc_1A02A, именно отсюда начинается побег, там же я начал подробно комментировать код. Эта роутина отвечает за выпадение Эггмана из капсулы (не знаю как точно ее назвать) справа. Код падения можно удалить, тогда Эггман останется внутри капсулы - что и требуется. Теперь можно написать новый код, который и будет двигать камерой и завершать уровень. Итак, камера. Да, этот именно этот объект начинает двигать камеру вправо при побеге, впрочем, как и все боссы в игре. Ключевые моменты в управлении камерой: 1) В loc_1A02A, когда Эггман приземлился: addq.b #2,($FFFFF742).w ; increase dyn resize routine Увеличивает счетчик роутин в Dynamic Screen Resizing (или Dynamic Level Events по версии SVN), меняет роутину в Resize_FZ с "Resize_FZboss" на "Resize_FZend". 2) В loc_1A166: addq.w #2,($FFFFF72A).w ; move camera right Собственно, двигает камеру вправо со скоростью 2 пикселя за кадр. Кстати, здесь все сделано весьма своеобразно, меняется значение правой границы камеры - $FFFFF72A, а в Resize_FZ выполняется код "move.w ($FFFFF700).w,($FFFFF728).w", который задает левой границе текущее положение камеры, т.е. сдвинулась камера чуть-чуть и сразу зафиксировалась на этой позиции, назад никак. Гениальное решение. Последняя проблема - переход к концовке. С этим я думаю, ты справишься, можно просто сделать проверку на определенную позицию камеры и переходить в этом случае к концовке.

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

Великолепные изменения арта на уровнях, все лучше и лучше =) Только странная вещь - на первом скрине Ice Magma 3 время 0:04, а на втором, когда Соник уже убежал от лавы - 0:03. На дебаг не похоже, как же так? =Р

Я допустил опечатку, во втором примере написано: move.w #2,$24(a1) ;++ set routine to #2 (Obj37_Bounce) А должно быть move.b #2,$24(a1) ;++ set routine to #2 (Obj37_Bounce) В первом примере давался этот же кусок кода, где эта строчка написана верно. Должно быть, ты сразу скопировал взял второй, где есть опечатка. Поэтому получается глюк. UPD: Опечатка в примере уже исправлена.

Так вполне можно сделать, но понадобятся дополнительные затраты, и это не самый хороший способ. Юджи Нака бы сделал по-другому... Для начала, изучим что делает этот Obj37. Вот его роутины: dc.w Obj37_CountRings-Obj37_Index; #0 - обнуление счетчика колец, создания выпадающих колец dc.w Obj37_Bounce-Obj37_Index ; #2 - физика единичного кольца: падение, подпрыгивание... dc.w Obj37_Collect-Obj37_Index ; #4 - кольцо собрано dc.w Obj37_Sparkle-Obj37_Index ; #6 - эффект после сбора кольца dc.w Obj37_Delete-Obj37_Index ; #8 - удаление объекта Здесь важно отметить такой момент, который встречается довольно часто в сложных объектах: каждое кольцо - отдельный экземпляр объекта $37. Вначале создается одна копия объекта, и при выполнении кода для нее запускается первая же роутина - Obj37_CountRings, она в свою очередь создает множество копий объекта, задает им, в какую сторону лететь и т.д. И разумеется, для копий объектов счетчик роутины (байт $24) увеличивается, чтобы выполнилась вторая роутина, Obj37_Bounce. Очевидно, код Obj37_CountRings в нашем случае совсем ни к месту, надо бы сделать так, чтобы он не выполнялся. Легко! jsr SingleObjLoad move.b #$37,0(a1) ; load bouncing multi rings object move.w 8(a0),8(a1) move.w $C(a0),$C(a1) move.b #2,$24(a1) ;++ set routine to #2 (Obj37_Bounce) Но возникает другая проблема - создаваемое колечко не настроено, не задается направление, куда лететь, не задаются маппинги, габариты и пр. Не беда, можно просто позаимствовать из Obj37_CountRings, где настраиваются колечки, то, что нам надо: jsr SingleObjLoad move.b #$37,0(a1) ; load bouncing multi rings object move.w 8(a0),8(a1) move.w $C(a0),$C(a1) move.b #2,$24(a1) ;++ set routine to #2 (Obj37_Bounce) move.b #8,$16(a1) ;++ height/2 move.b #8,$17(a1) ;++ width/2 move.l #Map_obj25,4(a1);++ mappings offset move.w #$27B2,2(a1);++ art ptr move.b #4,1(a1) ;++ render flags move.b #3,$18(a1) ;++ priority move.b #$47,$20(a1);++ touch response move.b #8,$19(a1) ;++ visible part move.b #-1,($FFFFFEC6).w;++ something to do with synchro ani move.w #0,$10(a1) ;+++++ X-vel move.w #-$300,$12(a1) ;+++++ Y-vel Колечко теперь настроено и должно вести себя подобающим образом, мало того, теперь можно с легкостью задавать его скорости и все это без лишних проверок и участия ненужного кода =)

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

Всегда пожалуйста =)

Была такая проблеммка недавно, вот ее решение: http://forum.sonic-world.ru/index.php?s=&a...amp;p=252418302

Скорее всего это происходит из-за бага в твоем коде, по причине которого при нахождении под водой не задается нужная скорость. move.w #$700,d0 ; d0 -> $700 neg.w d0 ; d0 -> -$700 clr.w $10(a0) move.w d0,$12(a0) ; $12(a0) -> set Y-vel to -$700 btst #6,$22(a0) ; is Sonic underwater? beq.s Sonic_DJ_ChkShoes; if not, branch move.w #$500,d0 ; d0 -> $500 Sonic_DJ_ChkShoes: Вначале ты записываешь в d0 значение -$700, скорость нормального прыжка. Потом применяешь эту скорость, т.е. сохраняешь ее в $12(a0). Если Соник под водой, ты записываешь в d0 значение $500, и на этом все заканчивается. Ты не сохраняешь измененную скорость в $12(a0), никак не используешь то, что ты записал в d0. Поэтому скорость прыжка под водой такая же, как и в воздухе, а учитывая что под водой "гравитация" меньше, полный прыжок получается выше. Полный прыжок - это когда ты зажимаешь кнопку прыжка и не отпускаешь ее до самого конца. В движке Соников предусмотрена замечательная вещь - регулируемая высота прыжка, чем раньше ты отпустишь кнопку прыжка, тем ниже будет прыжок. Работает это так: при отпускании кнопки прыжка проверяется вертикальная скорость Соника, если она меньше -$400 (например, -$500, это перемещение вверх со скорость 5 пикселей за кадр), она урезается до -$400. Поэтому, когда отпустишь кнопку, прыжок естественно будет не таким высоким. Чтобы исправить твою проблему, можно просто переместить комаду "move.w d0,$12(a0)" в начало Sonic_DJ_ChkShoes, чтобы она выполнялась когда все манипуляции со значением скорости завершены: clr.w $10(a0) ; clear X-vel to move sonic directly to up move.w #-$700,d0 ; set normal speed (-$700) btst #6,$22(a0) ; is Sonic underwater? beq.s Sonic_DJ_ChkShoes; if not, branch move.w #-$500,d0 ; set underwater speed (-$500) Sonic_DJ_ChkShoes: move.w d0,$12(a0) ; move d0 to Y-velocity

Спутся почти год, русские хакерские гиды возвращаются! :) Недавно я снова решил вернуться к переводу гидов, так как гидов на русском сейчас крайне мало и они не удовлетворяют растущим потребностям хакерского комьюнити. Я написал несколько несложных, но немаловажных гидов по образцу Ретровских: Как убрать Speed Cap в Соник 1 Как убрать Air Speed Cap в Соник 2 Кстати, всем очень советую убирать Speed Cap вместо увеличения максимальной скорости, так как это улучшает качество геймплея. Завышение максимальной скорости плохо сказывается на игре, делает геймплей быстрым, но "неуклюжим". Я давным-давно имел дурную привычку изменять максимальную скорость, даже добавил такую функцию в S1HS1, но потом открыл для себя такую замечательную вещь, как удаление Speed Cap'а. Так что S1HS2 завышение максимальной скорости заменено опцией "Убрать скоростной барьер". Помимо добавления новых гидов, исправлены старые: Как добавить Spin Dash - исправлен допущенный в гиде баг, приводящий к воспроизведению неправильной анимации. Как добавить Jump Dash в Соник 2 - теперь вместо увеличения скоростного барьера предлагается убрать Air Speed Cap, что намного правильней. Сейчас у меня в планах написать "вводный" гид для начинающих и переписать мой самый позорный и неккоректный гид по ассемблеру, надеюсь скоро заняться этим. Также хочется написать пару гидов специально для дизасебмла S1 Hacking Studio 2. Там очень много новых компонентов, и несмотря на то, что все бережно задокументировано, многие вещи нужно показать на примерах.

В LZ такой объект наверное не предусмотрен (хотя можно поиграться с подтипами существующих там "дверей", вдруг найдется что-то похожее). Если подходящих дверей в LZ нет, можно пойти несколькими путями: 1) Создать абсолютно новый объект. 2) Перепрограммировать существующие в LZ "двери", добавить в них новый подтип, при котором дверь и будет вести себя как тебе нужно. 3) Разместить на уровне дверь с таким же ID-ом, как у нужной тебе двери в SBZ. Этот способ самый легкий, причем все будет работать, единственное но: арт двери будет неправильный. Это можно изменить, добавив в код двери проверку на зону LZ и давать ей в этой случае другие маппинги.

Я не очень силен в SMPS, но вроде бы отличий между драйверами немного. Единственное принципиальное отличие SMPS Z80 от его M68K собрата - это то, что порядок байтов в словах Little Endian, а не Big Endian, ибо такова архитектура Z80. Впрочем насчет С3 не уверен, в гиде Music Hacking сказано только про Соник 2, в S3K же драйвер z80/mod (насколько помню), так что они вполне могли изменить это на то, что было в M68K. Ну и наверное z80 внесет свои премудрости (банки, например). xmXsmps делает музыку как бы под Соник 1, в то же время портинг S3->S1 давно возможен. Думаю, обратный портинг тоже реально сделать.

На самом деле откомментировано очень много, не говоря уже о том что было в прошлой доступной версии. Что особенно круто - использование констант, заменяющих адреса, одно это делает код в разы понятнее. К тому же кода в S&K как минимум в 2 раза больше чем в Соник 1 и в 1,5 раза больше Соника 2, но не смотря на это большинство массивов и довольно много роутин определены. Единственное, чего здесь может не хватать - это комментариев к командам, ими авторы занялись поверхностно, откомментировав только основные моменты, помогающие им понять смысл кода. Но все еще будет, это только начало, причем очень грандиозное. :)

Разумеется, перемещение происходит в Dynamic Screen Events, а именно в Resize_SBZ3, вот так он выглядит в дизасембле S1HS2: ; ============================================================ =============== ; Vladikcomper: Some code was changed to fit level order. Resize_SBZ3: cmpi.w #$D00,($FFFFF700).w bcs.s locret_6F8C cmpi.w #$18,($FFFFD00C).w; has Sonic reached the top of the level? bcc.s locret_6F8C ; if not, branch clr.b ($FFFFFE30).w move.b #1,($FFFFF7C8).w; freeze Sonic lea LevelOrder,a2 ; load level order array move.w $E(a2),d0 beq.s @GotoSegaScreen move.w d0,($FFFFFE10).w; set next level according level order move.w #1,($FFFFFE02).w; set restart level flag rts @GotoSegaScreen: move.b #0,($FFFFF600).w locret_6F8C: rts В обычном дизасембле отличий почти нет, кроме кода, отвечающего на установку номера следующего уровня. К счастью, роутина Ресайзинга у SBZ3 очень даже простая и приятная. Первые две команды проверяют X-позицию камеры, если она меньше $D00, остальной код не выполняется. Следующая пара команд проверят X-позицию Соника, если она больше или равна $18, остальной код тоже не выполняется. Формально, можно закоментировать первые две команды, тогда Соник будет перемещаться в FZ в любом месте уровня, но может появиться другая проблема - стартовая позиция Соника на уровне тоже у верхней границы, из-за этого он может немедленно переместиться в FZ, не успев уровень начаться. Чтобы все было гладко, тебе нужно посмотреть, какая позиция у камеры во втором пути и добавить проверку на нее в этот код. Например, у тебя второй проход в FZ начинается с позиции $200 (левее начала уровня), тогда проверка будет выглядеть примерно так: cmpi.w #$200,($FFFFF700).w; позиция камеры - левее $200? bcs @ChkSonicPos ; если да, Сонику вполне можно перемещаться cmpi.w #$D00,($FFFFF700).w; позиция камеры - правее $D00? bcs locret_6F8C ; если нет, нельзя никуда перемещаться @ChkSonicPos: cmpi.w #$18,($FFFFD00C).w; has Sonic reached the top of the level? bcc.s locret_6F8C ; if not, branch

Посмотри роутины LZWindTunnels и LZWaterSlides, в них создаются течения для всех уровней LZ, и по идее, для SBZ3 (так как он является четвертым актом LZ).

Да, вышла версия 11, до этого была 1.03. Новый SonED2 теперь поддерживает редактирование Sonic 3, Sonic & Knuckles, Sonic CD, Sonic Crackers и, наконец, Knuckles' Chaotix. С новой версией я ознакомился мало, из приятных вещей заметил измененный интерфейс, без мелких, режущих глаза стрелочек, новую консоль. И вообще, чувствуется, все было переделано и улучшено. Как-никак первое глобальное обновление с 2004 года, и то, что Stealth не забросил свой проект, очень радует.

Судя по всему, с PLC все в порядке. Но это лишь массив данных, важно то, как им управляет код. Если я правильно понял, ты создал новый блок в PLC - PLC_MMain, да? Каким образом ты загружаешь для нового перса новые блоки вместо стандартных? Скорее всего, проблема именно в этом и вместо твоего блока загружается стандартный.

Покажи, что именно ты делал в Pattern Load Cues и в коде, чтобы загрузить новый арт. Из твоего описания не понятно, каким способом ты пытался этого добиться и что пошло не так.

loc_C5CA в Obj3A - часть цикла, загружающего объекты для экрана SONIC HAS PASSED. Он состоит из нескольких объектов: "SONIC", "HAS PASSED", Овал, "Act X", "SCORE", "TIME BONUS" и "RING BONUS". Для каждого из этих объектов выполняется твой код, а так что маппинги меняются и у овала, "Act X" и пр. А поскольку в маппингах нового кадров для тех объектов видимо нет, получается каша. Если тебе нужно лишь заменять маппинги надписи "SONIC", можно пойти таким путем: loc_C5CA: move.l #Map_obj3A,4(a1) move.b d0,$1A(a1); кадр #0 (надпись "SONIC"/'имя перса')? bne @Skip ; если нет, значит это другой объект, не трогаем его tst.b $FFFFFFFE; игрок - Соник? beq @Skip ; если да, оставляем старые маппинги move.l #YourNewMaps,4(a1); использовать маппинги для второго перса @Skip: move.w #$8580,2(a1) move.b #0,1(a1) lea $40(a1),a1 dbf d1,Obj3A_Loop; repeat 6 times Хотя я бы просто добавил новый кадр в старые маппинги, так было бы проще и гибче.

Берешь код из гида и переделываешь команды, загружающие арты (ArtSonic и арт перса). Впрочем, я не удержался от небольшой оптимизации: move.l #ArtSonic,d6 tst.b $FFFFFFFE beq SPLC_ReadEntry move.l #АртТвоегоПерса,d6

Есть, только выглядит это дело по-другому: LoadSonicDynPLC: ; XREF: Obj01_Control; et al moveq #0,d0 move.b $1A(a0),d0 ; load frame number cmp.b ($FFFFF766).w,d0; has Sonic frame changed? beq.s locret_13C96 ; if not, branch move.b d0,($FFFFF766).w; update frame number lea (SonicDynPLC).l,a2 add.w d0,d0 adda.w (a2,d0.w),a2 moveq #0,d5 move.b (a2)+,d5 subq.w #1,d5 bmi.s locret_13C96 move.w #$F000,d4 move.l #Art_Sonic,d6 ; <------------ В S1HS и в оригинальном дизасембле код LoadSonicDynPLC отличается. Дело в том, что в S1HS был изменен способ подгрузки арта Соника по гиду добавления Спин Дэша, части третьей. Это позволило освободить часть памяти, потому что раньше в память загружались целые тайлы для переброски в VRAM, а теперь лишь команды (DPLC). Все это делается через умную систему DMA-Transfer'а, портированную из Соник 2.

Это моя старая неумелая попытка портировать зону из Соник 1 в Соник 2 и замаскировать это под Соник 1. =Р Проходим только первый уровень.

Вот тоже один из моих первых хаков, который не был выпущен публично. Сделан в августе 2009-го. "ОМГ!!! ОМГ!!! Тейлз-помощник в Соник 1!!!!!1111" Не совсем. Скачайте, и увидете, что это на самом деле =Р Download

Эх, ностальгия =) Мой самый первый хак: Sonic High Force Вышел 22 июня 2009 года. 4 июля 2009 вышла обновленная, более акуратная версия, с небольшими улучшениями палитр и уровней. * Недоделанный Спин Дэш. Сейчас это звучит смешно, но тогда это вообще был первый русский хак со Спин Дэшем. * Полный перевод на русский язык * Изменена максимальная скорость Соника * Изменена палитра Соника, он стал более синим * Изменены первые пять уровней * Новая музыка. 2 мелодии были взяты из СониНеко, в последствии Нинеко разрешил мне их использовать. * Во втором акте каждой зоны можно найти изумруд хаоса, который сделает соника сверхбыстрым и неуязвимым до конца уровня. * Убраны Спец Этапы, поиграть в них можно только через меню выбора уровней. * Убраны уровни LZ и SBZ, по техническим причинам. В них можно сыграть через Выбор уровней. http://vladikcomper.narod.ru/download/Soni...hForce_v075.zip