Actually you'll have to make sure the collision is properly set on your tiles—You're using the right swappers though. 03 91 00 and 03 12 00 (12 is bigger than 11, I usually use it)
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.
Ok, quick question: In my game, I want to change a specific color in the palette without touching the others. However, I don't know how to modify specific positions in the CRAM without touching anything else, so right now I can only do this by cheating myself to the position I want, which looks like this: Code (ASM): 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": Code (Text): 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.
Quickly did some testing in s2.asm and this should do the job: Go to TitleScreen in the disassembly, find these lines (they should be the in their own "paragraph"), and remove them: Code (ASM): move.l #$60000002,(VDP_control_port).l lea (ArtNem_CreditText).l,a0 bsr.w NemDec lea (off_B2B0).l,a1 jsr (loc_B272).l
I have a completely random question that I started to ponder today about frames per second. Some games run at 60 fps, some at 30 fps. This may be completely incorrect but I thought today. From what I gather is that each time a screen is drawn, that is a frame. So is the reason some games are limited to 30 fps because there is more code leading to a longer screen draw time which leads to an overall slowdown if they were attempting 60 fps? This may be completely wrong but feel free to correct me.
No, that's basically right. If you're doing more you can draw less in a given second - if your code is less optimised you're going to have less time to render frames. Limiting to 30fps in a lot of examples is the only way to keep a steady frame rate - one that flicks between 30 and 60 can be infinitely more distracting than just sticking to 30 the whole way.
Does anyone have experience with PlaneED? I'm trying to figure out how to write the dimentions and coding to show sprites and text files. Does anyone know what specifics would be needed to show Sonic 2's special stage results screen on the program? I tried a savestate but it still came up blank.
I believe Sonic 2's Special Stage Results screen needs to be edited via mappings like any other object. Use SonMapEd instead. You may need to dump VRAM from an emulator (I would recommend DebuGens for this) because I think the mappings start address is at 0. Although I guess you could change that....
How would I go about that exactly? (Sorry if that sounds dumb, I've never really worked with dumping and such).
Recently I have come back into hacking and am once again having a problem. Earlier this year I attempted to import custom level art into SonLVL which resulted in it not displaying correctly in the editor or in game. Tonight, I came back and tried again. This time, I have managed to get my art to display in the editor but it appears garbled with random collisions in game. Edit: Should probably mention the part that Sonic and Tails are meant to stand on (I.e solid) is the horizontal line above their heads. Edit 2: It appears that it is corrupting the majority of the tiles. Hmmm. I'm going to have to look at a way to save the file properly as it seems that it is over-running and damaging other data.
^ The problem probably isn't SonLVL as much as importing into Hill Top Zone. The nature of the shared art between Emerald Hill and Hill Top makes some chunk IDs unusable. Make a backup and attempt the same practice in Emerald Hill will Hill Top's palette file; this will tell you where the problem is. That, or edit the ASM file to completely separate the two zones.
Random question, how would I get rings in Sonic 1 (Hivebrain if that helps) to use Sonic's palette rather than the zone's? I have no clue how the palette loading routine works.
In routine "loc_9BBA:" the line "move.w #$27B2,2(a1)", change the first number 2 to a 0 so you end up with "move.w #$07B2,2(a1)", for rings that spawn when you get hurt, there's another one in routine "Obj37_MakeRings:", again, change the 2 to a 0.
Since retro's SVN server is down, anyone have the last (or any) SVN copy? I want to get into hacking again and want to try out the SVN disassembly. Thanks in advance
So erm, I was trying to add an extra letter to the Sonic 1 Title Cards art, but each time I did there would be random tiles at the top of the screen. How do I add more art to the title cards art without this happening? I used to resort to overwriting U but while testing changes to Sonic's Sprites, I realised the Continue screen obviously needs it! :specialed:
I want to change some yes, but that's not all, I want to add a letter to the art itself, as it lacks some letters (J, W, etc). And I can't overwrite any of the others due to being in use, though whenever I add any extra art random tiles show themselves on each result screen.
