EDIT: I just thought of a different idea on how to manage acts for my hack, so no further assistance is needed. Thanks for the advice anyway.
Basic Questions & Answers thread NEWBIES: Start here!
#3991
Posted 23 November 2011 - 05:00 PM
EDIT: I just thought of a different idea on how to manage acts for my hack, so no further assistance is needed. Thanks for the advice anyway.
#3992
Posted 23 November 2011 - 08:19 PM
#3993
Posted 24 November 2011 - 02:20 AM
FFEE12:0F20 - unlock bottom
FFEE14:0000 - unlock left
FFEE16:7EC0 - unlock right
FFEE18:0000 - unlock top
They won't work everywhere; a few places use a different locking mechanism, or constantly reset the lock in the event scripts. Also bear in mind that some events will not occur at all with these enabled as they depend on a specific screen lock (e.g. the LRZ boss).
#3996
Posted 27 November 2011 - 09:38 AM
#3997
Posted 28 November 2011 - 03:26 PM
1) I understand that porting objects doesn't mean just copy and pasting the code but what would I need to do to, say, port an object from S3K to S1 or S2?
2) How do you create a palette cycle or create an object that has a cycling palette in S2?
3) How do you create animations for an object? How do you ensure that when the object is present it cycles through the frames correctly and are the frames stored in a single file or split across multiple? (S2 again)
Also, I have literally no idea how to do music for hacks (porting or programming) so could someone give me a rough outline as how it is done.
I have a little ASM knowledge but I am in no way asking for anyone to hold my hand through every step, just kind of detailed roughness XD. I am honestly trying to learn my way around.
#3998
Posted 29 November 2011 - 12:50 AM
Elektro-Omega, on 28 November 2011 - 03:26 PM, said:
You'll have to find the equivalent of RAM addresses, SST offsets and subroutines in S1 or S2. If there's no equivalent for a subroutine, you'll have to port it yourself. If the object is trying to use a RAM area that's used for a feature that's not available in the target game, you'll have to either port the feature (if you have enough available RAM) or drop the feature from the object.
Elektro-Omega, on 28 November 2011 - 03:26 PM, said:
PalCycle_Load runs the palette cycles. Since there are only 4 palettes of 16 colors, you can't really make a palette cycle local to a specific object without risking affecting something else unless you plan ahead. PalCycle_Load is run once per frame and has code specific to each act to animate the palette. If you want an object to have a cycling palette, just reference the palette entries that are animated.
Elektro-Omega, on 28 November 2011 - 03:26 PM, said:
Many objects use a simple animation script to define what frames to use and the duration of each step. The format is very simple: the first byte is the duration in frames, minus 1, that each step will last; subsequent bytes are frame indices in the sprite mappings; the script ends with a command ($Fx) which describes what happens when the script ends (repeat, play a different animation, etc.). The AnimateSprite subroutine animates an object according to an animation script.
Elektro-Omega, on 28 November 2011 - 03:26 PM, said:
Porting music between MD games can be troublesome because each game has a different engine with different features. Even between games that use the same base engine (e.g. SMPS), you'll usually see more features in later games. There are tools that try to accommodate this fact, but it's not always perfect. If you want to import custom music, I think your best bet is to use a tool like xm4smps. Either way, you'll have to add/edit an entry in the music list to be able to use it in game.
#3999
Posted 30 November 2011 - 08:10 PM

Uploaded with ImageShack.us
Basically I'm trying to edit it so only the (former) Tails sprite appears. I've managed to code out Sonic's hand but can't figure out Sonic's coding. I've gotten to a similar level on the separate coding when you press the Start button.
#4000
Posted 01 December 2011 - 11:13 PM
The hack I'm making has loops, lots of loops, and unfortunately they're loops that end with different tiles or continue on with different ones. What I wanna know is if it's possible for a loop to work like this or like this, and if so, what Path Swapper would I use to make them work? I know for normal loops the Swapper in the center is 03 91 00 and the one on the outside is (I think) usually 03 11 00, but the latter doesn't work for my loops. Stupid Pathswappers, there's just so many.
#4001
Posted 03 December 2011 - 11:14 PM
#4002
Posted 04 December 2011 - 10:04 AM
BetaTwizzler, on 01 December 2011 - 11:13 PM, said:
The hack I'm making has loops, lots of loops, and unfortunately they're loops that end with different tiles or continue on with different ones. What I wanna know is if it's possible for a loop to work like this or like this, and if so, what Path Swapper would I use to make them work? I know for normal loops the Swapper in the center is 03 91 00 and the one on the outside is (I think) usually 03 11 00, but the latter doesn't work for my loops. Stupid Pathswappers, there's just so many.
If you're struggling with pathswappers, the absolute best thing you can do is to download Thorn's object definitions for SonED2 (thread), which will significantly demystify them. With the definitions installed, a sure fire way to test your collision and planes is to use the W and E keys to toggle between viewing Path 0 and Path 1 of collision and the Y and U keys to toggle the High and Low Planes. It is a pretty simple case of tracing along the level with your finger and toggling the view when you hit a pathswapper to confirm the correct change is being made.
Some examples -
00 will force Sonic into Path 0 and Below High plane no matter which way you pass through it
01 will change Sonic from Path 0 to Path 1 from left to right, but will force him into Below High no matter which way you pass through it
10 will change Sonic from Path 1 to Path 0 from left to right, but will force him into Below High no matter which way you pass through it
00 will force Sonic into Path 0 no matter which way he passes through it but will change Sonic from Below High to Above High from left to right
01 will change Sonic from Path 0 to Path 1 from left to right, and will move him from Above High to Below High from left to right.
11 will force Sonic into Path 1 and Above High plane no matter which way you pass through it
And so on...
As you can see it is fairly intuitive. Using the definitions you can see the size, orientation amd characteristics of a pathswapper at a glance. There are some other nuances to bear in mind - the list restarts at 03 80 00, but require sonic to be on the ground to activate them - ie: running, walking or rolling. More advanced tricks can be used too. If I recall correctly, mirroring the pathswapper causes it to act solely as a planeswapper and disables the path swapping aspect.
There is a more exhaustive reference guide which uses the proper object numbers can be found here.
#4003
Posted 04 December 2011 - 01:41 PM
lea ($C00000).l,a5 ; load VDP data port address to a5 lea ($C00004).l,a6 ; load VDP address port address to a6 move.l #$C0000000,(a6) ; set VDP address to C-Ram lea (Palette_Main).l,a1 ; load palette array in a1 move.w (a1)+,(a5) ; dump colors move.w (a1)+,(a5) ; dump colors .... move.w #$0EEE,(a5) ; finally dump color the color I want
And it's silly. How would I do this properly?
#4004
Posted 04 December 2011 - 02:29 PM
Selbi, on 04 December 2011 - 01:41 PM, said:
lea ($C00000).l,a5 ; load VDP data port address to a5 lea ($C00004).l,a6 ; load VDP address port address to a6 move.l #$C0000000,(a6) ; set VDP address to C-Ram lea (Palette_Main).l,a1 ; load palette array in a1 move.w (a1)+,(a5) ; dump colors move.w (a1)+,(a5) ; dump colors .... move.w #$0EEE,(a5) ; finally dump color the color I want
And it's silly. How would I do this properly?
The format of long commands is described in genvdp.txt, section 7, under "Accessing VDP RAM":
CD1 CD0 A13 A12 A11 A10 A09 A08 (D31-D24)
A07 A06 A05 A04 A03 A02 A01 A00 (D23-D16)
? ? ? ? ? ? ? ? (D15-D8)
CD5 CD4 CD3 CD2 ? ? A15 A14 (D7-D0)
CDx = VDP code (0-3F)
Axx = VDP address (00-FFFF)
This format is annoying, because related bits are not all consecutive. The Sonic 2 disassembly has a vdpComm function to help, but it only works with AS.
What you want to do is a CRAM write to some address. CRAM has 4 palettes of 16 colors, and each color takes a word, so addresses range from 0 to $7F; therefore, you can start with the base CRAM write command ($C0000000) and just change the A06-A00 bits, which are all consecutive. For example, to do a CRAM write to $3C, the command would be $C03C0000.
#4005
Posted 10 December 2011 - 08:53 PM
1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users
- Yandex
