Because it's actually part of the Sonic 3 alone data, not Sonic & Knuckles. See "Lockon S3/LockOn Data.asm"
Thanks. I think I did what you said correctly, but there's another error that has come up now. I checked the file, but it doesn't seem like anything is out of place. Could it be that the issue stems from what I did with the LockOn file, or something else? This has been more difficult than I thought it'd be. Here's the code I edited, incase you want to look at it. Code (Text): ArtUnc_SStageTails: binclude "General/Sprites/Tails/Art/SStage Tails.bin" even Map_SStageTails: include "General/Sprites/Tails/Map - SStage Tails.asm" PLC_SStageTails: include "General/Sprites/Tails/DPLC - SStage Tails.asm" ArtUnc_SStageTailstails: binclude "General/Sprites/Tails/Art/SStage Tails tails.bin" even Map_SStageTailstails: include "General/Sprites/Tails/Map - SStage Tails tails.asm" PLC_SStageTailstails: include "General/Sprites/Tails/DPLC - SStage Tails Tails.asm"
Judging from what you posted about PLC_SStageTailstails, it already has the "PLC_SStageTailstails" inside the DPLC file. So, you can remove label, or go into the DPLC file and change all instances of "PLC_SStageTailstails" into something else.
I had a questions: 1) How does works wall recoil animation in Sonic 2 betas? When you bonk to wall- you start a 2 animations; first- it's just a one sprite, but how does second animation is started? 2) I accidentally delete some animated tiles from EHZ (animated cave tiles), and now it looks incorrectly.. How I can restore it?
In the Nick Arcade disassembly, this is labeled as Code (Text): Sonic_WallRecoil . What it does is actually really simple: Code (Text): Sonic_WallRecoil: ; CODE XREF: Sonic_Move+180j ; Sonic_Move+1A0j move.b #4,$24(a0) ; set Sonic's routine to 4 bsr.w Sonic_ResetOnFloor ; call for Sonic's ResetOnFloor function bset #1,$22(a0) ; set in air status bit move.w #$FE00,d0 ; move $FE00 into destination 0 tst.w $10(a0) ; test for x velocity bpl.s Sonic_WallRecoil_Right ; if positive, the wall is to the right neg.w d0 ; otherwise, the wall is to the left Sonic_WallRecoil_Right: ; CODE XREF: Sonic_Move+1D2j move.w d0,$10(a0) ; move $FE00 from destination 0 into Sonic's x_vel, giving him some backwards momentum move.w #$FC00,$12(a0) ; set Sonic's y velocity to $FC00, moving him up move.w #0,$14(a0) ; set Sonic's inertia to 0 move.b #$A,$1C(a0) ; play Sonic's recoil animation move.b #1,$25(a0) ; set Sonic's secondary routine to 1 move.w #$A3,d0 ; '�' ; prepare sound effect jsr (PlaySound_Special).l ; play sound effect rts ; End of function Sonic_Move This code is called by Code (Text): Sonic_CheckWallsOnGround or, in the NA disassembly: Code (Text): loc_FE8E Code (Text): loc_FE8E: ; CODE XREF: Sonic_Move+14Cj move.b $26(a0),d0 add.b d1,d0 move.w d0,-(sp) bsr.w Sonic_WalkSpeed move.w (sp)+,d0 tst.w d1 bpl.s locret_FEF6 asl.w #8,d1 addi.b #$20,d0 ; ' ' andi.b #$C0,d0 beq.s loc_FEF2 cmpi.b #$40,d0 ; '@' beq.s loc_FED8 cmpi.b #$80,d0 beq.s loc_FED2 cmpi.w #$600,$10(a0) ; Is Sonic running fast enough to recoil off a wall? bge.s Sonic_WallRecoil ; if speed = $600 or greater, branch add.w d1,$10(a0) bset #5,$22(a0) move.w #0,$14(a0) rts Hopefully that helps you understand how it works. Easiest way is to reacquire the appropriate files, and replace the files you messed with. It's as simple as that.
No I already FIND the way to port code to final S2 in February. I need to find the way to port animation Hehe.. I change too much, for using not changed files. Anyway, thanks for responding EDIT: I find that guide, that I write about recoil: https://sonicresearch.org/community/index.php?threads/mini-tutorials-thread.6189/page-2#post-88164
Adding animations is simple. All you need is a sprite sheet, and knowledge on how to import sprites using Flex 2 or SonMapED. Then you need to add the animation to Sonic's animation script, and call for that new animation. The first animation being the knock back animation, which then goes to the next, which is the laying on floor in a daze animation. Such things are simple. As an example, you can see here in Sonic's "stop" animation: Code (Text): SonAni_Stop: dc.b 5,$D2,$D3,$D4,$D5,$FD, 0 ; halt/skidding animation Byte $FD is telling the script that the animation should change to animation 0 (walking/running) after it is complete. You can do the same thing for the recoil.
Hello! i am making another hack, which makes sonic not roll and not roll while jumping, but when jumping on an enemy it causes that enemy to no damage me, whats a fix to this? i removed the Touch_KillEnemy Function, using hivebrain disasm (sonic 1)
the easiest way is to delete the sonic_roll function you mean it doesn't damage you? i haven't touched a sonic game in a long time so idk the code anymore but probably (not 100% sure), this is why: pretty sure that you should have that label
Thank you! i managed to restore that label and add HurtSonic being executed when it launches, one thing i forgot to tell you is that rings are no longer collectable, so thats why i did that Also why is my SHC Expo Entry the only one? : https://shc.zone/entries/expo2022/699
Because the Contest/Expo isn't open yet to the public. You can only see and edit your own entries in the mean time.
I'm attempting to write a simple VRAM test for the Mega Drive/Genesis (more on that below), but while I have the results readout down, I need some help with the actual implementation. Code (Text): TestVRAM: dma_fill 0,$FFFF,0 ; clear VRAM .waitforDMA1: move.w (a5),d1 ; get status register (a5= vdp_control_port) btst #1,d1 ; is dma_fill still running? bne.s .waitforDMA1 ; if yes, branch dma_fill 1,$FFFF,0 ; fill entire VRAM with 1s .waitforDMA2: move.w (a5),d1 ; get status register btst #1,d1 ; is dma_fill still running? bne.s .waitforDMA2 ; if yes, branch move.l #$00000000,(a5) ; set VDP to VRAM read lea (startof_ram).l,a4 ; load start of RAM lea (vdp_data_port).l,a3 ; load VDP data port move.w #(sizeof_ram/2)-1,d0 ; set number of times to loop .readloop: move.w (a3),(a4)+ ; copy contents of VRAM to RAM dbf d0,.readloop ; repeat until done (if VRAM is good, RAM should be all 1s) .check: lea (startof_ram),a0 ; start checking bytes at the start of RAM lea (endof_ram),a1 ; stop at end of RAM move.l a1,d0 ; copy end address to d0 moveq #0,d1 ; clear d1 .loop: add.w (a0)+,d1 ; add words at current address to d1 and increment cmp.l a0,d0 ; have we reached the end? bne.s .loop ; if not, branch lea (psg_input).l,a4 ; load PSG input register move.w #cGreen,d2 ; make screen green cmpi.l #sizeof_ram,d1 ; is entire RAM 1s? (assuming RAM is not faulty, it will be if the VRAM is good) beq.s .passtone ; if it is, branch move.w #cRed,d2 ; if failed, make screen red ;.failtone: move.b #$8C,(a4) ; make PSG0 produce a 160hz tone; #%10001100 move.b #$2B,(a4) ; #%00101011 bra.s TestResultScreen .passtone: move.b #$8D,(a4) ; make PSG0 produce a 895hz tone; #%10001101 move.b #$7,(a4) ; #%00000111 TestResultScreen: move.b #$90,(a4) ; set PSG0 to maximum volume move.l #$C0000000,(a5) ; set VDP to CRAM write moveq #(sizeof_pal_all/2)-1,d7 ; set number of times to loop .fillpalette: move.w d2,(a3) ; fill palette with red if test failed, green if passed dbf d7,.fillpalette ; repeat $3F more times .endlessloop: bra.s .endlessloop The idea here is to fill the entire VRAM with 1s via DMA (the dma_fill macro is taken from the Sonic 1 Hivebrain 2022 disassembly), then copy the entire VRAM contents to RAM, sum the contents of the RAM into a data register, and compare to the sum of 64 KB of 1s. If the test passes, a green screen is displayed and a high tone is played on the PSG; if it fails, a red screen and a low tone. I don't know if that method will work, but I can't tell because the read from VRAM does not appear to be working! The intended usage I'm aiming for is to set a flashcart to run the last game on boot instead of going to the menu, run the test from said cart on a known good system, then place the flashcart into the system to be tested and power on, allowing the test to be run even if the console is unable to output coherent video.
The problem is that DMA fill fills in bytes, not words. Seems like neither the Sonic Retro or Hivebrain 2022 disassembly take that into account. It fills VRAM with the high byte in the word written to the VDP data port, and since it's only setting 0x0001, it's really just filling VRAM with 0. You can fix the macro to shift the value to fill 8 bits to the left, or set it to 0x0100. Also, before peforming your VRAM read, you need to reset the auto-increment back to 2. The DMA fill needs it set to 1, which the macro does do, but it doesn't reset it back to 2 after (honestly, the macro SHOULD include it along with the DMA wait loop, it wouldn't break bit-perfectness in the disassembly, and I think it's pretty obvious that the loop and auto-increment reset were part of whatever original macro they had, because it appears after EVERY DMA fill call). Even with that fixed, you're also performing the summation word by word, so you'd really be adding 0x0101 continuously, and that loops 0x8000 times since 2 bytes per word. On top of that, you're then checking for a longword result. With the size of RAM being 0x10000 bytes, even if it were just adding 1 every time, the summing process won't actually get to that ever. You'd wanna do something like this to get your desired result: Code (Text): moveq #0,d2 ; Read buffer .loop: move.b (a0)+,d2 ; Read byte into lower byte of d2 and increment add.l d2,d1 ; Add d2 as a longword to d1 cmp.l a0,d0 ; Have we reached the end? bne.s .loop ; If not, loop Also, last I recalled, passing the PSG control port into an address register and then writing to sequential data to it isn't a good idea, because apparently it's not quick enough to handle that. I remember having an issue with a sound driver that did that some years ago. It would, but it looks like it's not using the stack in this code (assuming interrupts are disabled), so they shouldn't be running into any issues. However... I can't really wrap my head around what you are trying to accomplish here. Could you elaborate further?
I noticed that my code was getting stuck in a seemingly infinite loop there. Figured there was something wrong with the summing logic. Thanks. But, even with the workaround to the flaw in the dma_fill macro, there seems to be another issue with it. If the VRAM editor in Exodus is to be believed, it's only writing the first word of VRAM instead of filling it! (That word is being written back to RAM correctly, though, so at least that part is working.) Bingo. Interrupts disabled, no stack usage at all, and no usage of RAM for anything other than the test. The only other code in the binary is the standard Mega Drive Setup library, which branches straight to the VRAM test after disabling interrupts. It's meant to take advantage of a feature of the Mega EverDrive where, instead of booting to the Everdrive's UI, you can set it to boot straight into whatever game was last played. This would allow the test to be easily run on a Genesis that, for whatever reason, is incapable of outputting video (and thus impossible to navigate the flashcart's UI): configure the flashcart to boot to the last played game, put the test binary on the flashcart, run the test on a known good unit, then put the flashcart in the unit to be tested, and power on. The PSG tones are meant to enable the test to be run on Model 1 units without the need for a video cable.
Please don't be mad that i keep posting here, i am a newbie and don't know a lot of stuff, i want to place the emerald hill background as the title screen one, how do i do that? Sonic 2 github disassembly
The simplest way would be to export the level's background as an image from SonLVL and then import it into SonPLN over the existing background.