That's because even in 1 Player mode, Tails always loads his art to the player 2 VRAM slot. (Normally, he does this so he can appear alongside Sonic.) Meanwhile, both Sonic and Knuckles load their art to the player 1 slot, which means their base VDP pattern is the same, which means their art address isn't corrupted when you swap between them.
Random question, but it's about the Sonic Jam ports. What's the nature of the Saturn optimisations done? Edit: I answered some of this myself but any more info would be great. I know the devs used VDP1 for sprites and VDP2 for all background and foreground art. I don't know anything else beyond that. Surely the game isn't running off of the Saturn's sound chip, right? I know it's a 68k but...
Okay, I was going to try patching the line that loads the saved VDP pattern so it doesn't run over the player's art address, but it turns out that code actually runs before the player object is even initialized, so uh. This isn't ideal, but try using the code FFB00B:00A0 when switching to Tails, and FFB00B:0080 for everyone else. Either code can be left enabled to no ill effect, except it'll mess up the preview sprite in debug placement mode.
wow yes!!! thank you!!!! i just have to enable them once they have gone into the bonus stage, if i do it before they turn into lines of text, haha it looks like its the copyright info. i didn't think of this till now, but can you use a code that makes it so the bonus stage doesn't load?
the closest i could get was with FFFE2A:0001.... i am going into the bonus stage from the 1st checkpoint in angel island, and its super weird, it teleports me under a random large ring in mushroom hill 2 with no bonus stage in between (which is what i want, i just want to spawn at the same checkpoint), the only other thing i can get with messing with the value is doing the bonus level and then spawning at the beginning of the level
I'm asking this not for help in hacking myself, but just out of random curiosity. I'm well aware not many people hack Sonic 3 and Knuckles because the whole lock-on thing makes things a chore, but is there a reason people don't often mod either of the two games themselves? I get it would be redundant if you could just edit the full game, but it just confuses me. Sorry if this question comes off as dumb.
Your confusion arises from this false belief: Since that statement is completely false, a wrong conclusion logically follows. The reason not many people hack S3K is the lack of knowledge of how the game works, which is fueled by a stigma about the higher quantity of hardcoded level events in that game relative to Sonic 1 and Sonic 2. Between the three given options, hacking Sonic 3 alone would actually be the biggest chore, since a full disassembly of Sonic 3 has yet to be made.
The current S&K disassembly makes working with S3K as a full game totally effortless. The disassembly includes all the necessary code and data from S3, just run buildS3Complete.bat and you get a standalone S3K ROM. You are partially correct in that building a ROM hack with lock-on support would be complicated, but there's really no reason why you would need to do that.
I have minor trouble, how I can edit S1 HUD art properly in S1 Retro GitHub disassembly? I've tried this tutorial, but the only result I could got with artnem/HUD.bin was this: Is it different in GitHub disasm case? Did I've missed something in tutorial? Was that method completely wrong? I've also tried SonMapED an Flex 2 in order to extract/edit sprites and mappings, but in this case I've got completely broken images to edit (in SonMapED case) or after editing HUD sprites inside Flex 2 and saving it I couldn't generate new built in GitHub disasm (only ASM-related errors, like it was changed by Flex 2, idk).
The art in "artnem" folder is compressed in a huffman/entropy RLE compresison format created by SEGA, known as Nemesis (named after Nemesis, the one who cracked the compression format), hence the reason it's called "artnem". You will need to decompress the art before you can open it with Fatilety, and once you have edited the HUD tile art, you will need to re-compress it again back into the Nemesis format. A link to the description of the format (though I think it could perhaps be explained better): https://segaretro.org/Nemesis_compression A few links to help you (tools which can compress/decompress data for you): https://segaretro.org/The_Sega_Data_Compressor https://segaretro.org/KENSSharp Here's a link to a compression/decompression series of tools which adds the functionality to your right click menu (I highly recommend this): https://forums.sonicretro.org/index.php?showtopic=24573&view=findpost&p=923716
Never use TSDC, it uses the old, buggy compressors. There's also a shell extension for FW-KENSC which has better compression than KENSSharp. There's also a set of command line tools for FW-KENSC but I don't know where those would be, you might have to build them yourself.
Thanks for help! It worked and got the results I've wanted... Well, except that "e" letter issue: It's pretty nitpicky issue, but I would like to know how to fix that. (checked HUD Sonic Icon.bin and searched for other ones, but couldn't find that one piece I've wanted to edit)
Sorry for my late reply but I apologize for my big dumb, I'm not sure where I got this misconception from
I recently added the Sonic 3 pose to Sonic 2, but also wanted to add walls that would not let the player through. Example:
If I understand correctly, you're looking for is the screen-locking code, correct? I don't have the code off-hand at the moment, but I suggest checking out how Act 2 locks the screen after bosses.
I am trying to work with the background deformation, but I am having problems with the background. Note:I used Parallax Editor from Selbi. [media]https://imgur.com/a/wZseu2e[/media] here is the code: Spoiler SwScrl_EHZ: move.w ($FFFFEEB0).w,d4 ext.l d4 asl.l #5,d4 move.w ($FFFFEEB2).w,d5 ext.l d5 asl.l #6,d5 bsr.w SetHorizVertiScrollFlagsBG move.w #$800,($FFFFEE0C).w ; lock the background vertically in place move.w ($FFFFEE0C).w,($FFFFF618).w lea ($FFFFE000).w,a1 ; load beginning address of horizontal scroll buffer to a1 move.w ($FFFFEE00).w,d0 ; load FG screen's X position neg.w d0 ; negate (positive to negative) swap d0 ; send to the left side of d0 move.w ($FFFFEE08).w,d0 ; load BG screen's X position neg.w d0 ; negate (positive to negative) asl.w #8,d0 ; multiply by 256 (Speed up the scroll position) move.w #96-1,d1 ; set number of scan lines to dump (minus 1 for dbf) EHZ_DeformLoop_1: move.l d0,(a1)+ ; dump both the FG and BG scanline position to buffer dbf d1,EHZ_DeformLoop_1 ; repeat d1 number of scanlines move.w ($FFFFEE00).w,d0 ; load FG screen's X position neg.w d0 ; negate (positive to negative) swap d0 ; send to the left side of d0 move.w ($FFFFEE08).w,d0 ; load BG screen's X position neg.w d0 ; negate (positive to negative) asr.w #1,d0 ; divide by 2 (Slow down the scroll position) move.w #129-1,d1 ; set number of scan lines to dump (minus 1 for dbf) EHZ_DeformLoop_2: move.l d0,(a1)+ ; dump both the FG and BG scanline position to buffer dbf d1,EHZ_DeformLoop_2 ; repeat d1 number of scanlines rts
