Ey, so you know the term "programmer art"? The kind of art usually to explain a concept or as placeholder that sometimes ends up in the final as is anyway?
Welcome to "artist code" where things don't line up but somehow it all still works???
(also will be posting explanations of intricate dumb things here some time from past and current works so I don't have to spam Discord servers with it)
So here's an effect anyone can do at home (click to see animation):
Don't fade the bright colours and swap sprites, easy.
She/Her
I still really like that fadeout effect, it's quite nice
In the original game, there is 1 frame of movement lag every time you jump.
This isn't because jumping is a heavy task, but because it skips over the rest of the player's code on a successful jump via a "addq.l #4,sp" (add to stack pointer, essencially forgetting the return point).
I decided to change the line to a "move.l #SpeedToPos,(sp)" so that it applies momentum the same frame, removing the stutter.
(More accurately, it should've been #ObjectFall to apply gravity, but I'm keeping it this way. Enjoy the extra jump height~)
So one thing I had happen to me was this funny little happenstance:
As you can see... everything went horribly wrong... and it wasn't entirely my fault!
Two things happened :
My fix? Made an alternate routine for longer animations and checked for frame 0 in the DPLC code.
So I was bored one day and decided to look into S&K's Lock-on feature and looked into how KtEiS2 communicates with S2
Here's how it all works:
However, during that initialization part, the game does something interesting: It jumps directly to the S2 ROM to load the Sound Driver
So I had the following idea:
Guess what, it works
It just comes with one problem :
Since $A130F1 is also used for switching to SRAM, it can potentially make the exploit not function at all, but this depends on how the cartridge developer does SRAM (unfortunately there's no good way to test this since no good modern cartridges with SRAM support exist that work with S&K)
My plan is to have this as an extra when Gatoslip is attached and naturally, an RPG benefits from a save feature, meaning this can potentially be a problem.
There is a different exploit found by Hachelle-Bee that instead exploits how S3&K loads S3's SEGA screen:
instead of it just decompressing the art to RAM, one can simply have it continuously write to RAM until it reaches the Stack, where one can add a jump to the arbitrary code they want to execute.
This is a less elegant solution and costs some extra space for the compressed part but is in theory more compatible since $A130F1 isn't messed with at all.
Now, I'm absolutely stupid when it comes to menu stuff but one thing I've managed to get right is the cursor moving to a new position smoothly.
The gif is from S1Mousealog but it's a simplified copy from Gatoslip's battle menu with an added second X position parameter.
Here's the silly pre-calculated set of positions. Each row has 3 values with 2 bytes each (6 bytes per row, 30 bytes in total)
And here is that wacky 68k code, the commented part at the top would've defaulted the position to the bottom left corner of the screen, which isn't necessary for this case.
First we load the position table at address register a1.
We'll want to offset this table to the correct position of the menu, so we fetch the value of the internal vertical option (which is a number between 0 and 2) and store it on data register d2.
Since the instruction messes with the condition code register (CCR), we won't have to add a compare or test instruction, we can have a conditional branch right after (this happens a lot on the 68k for optimal code). In this case we use it to check if we're on position 0 on the menu and only branch to a later part of the code if it's not 0.
If the position is 0, then we use the internal horizontal option instead, overwritting what was previously on d2. On top of that, we add 3*6 to the position so we start at the 3rd row on the table.
Now theoretically (and this is the case in Gatoslip's version of the code!) I could've just used one value to represent the current menu position rather than 2 for horizontal and vertical positions... honestly I don't got any excuse for why I did it this way, like I'd said, I'm stupid with menu stuff.
Next we have an unreasonable ammount of instructions just to multiply d2 by 6, but as it turns out, the M68k's multiplication and division instructions are super costly so we want to avoid those.
We now add d2 to a1, which'll offset the address to the correct row of position values from the table, from there we wastefully move the values to data registers d0 through d5 (we could've avoided using so many data registers by fetching them later in the code when necessary and maybe even do a simple loop with another table to make the code smaller, didn't think of that at the time x.x)
We then have what's essentially the following code three times in a row for each axis :
MenuPosition = MenuPosition + (NewMenuPosition - MenuPosition / 4)
if "MenuPosition>>2" happens to be 0, then it'll snap to the final position.
.... dang it I should've made a post about the mouse peripheral instead, this tangent is stupid.
https://chitter.xyz/@VAdaPEGA/112264114876971292
So as it turns out, the entirity of the sound driver is loaded in Z80 RAM, which makes it almost trivial to add custom songs to S&K while locked on to a different game.
It's a little silly but essentially, we have to write the offset within the Z80 address space and ROM bank of the Music to Z80 RAM... and that's it, it already supported this from the get go due to the need to read music from S3's cartridge for S3&K and generally because of how little the Z80 can see at a time (only 0x8000 / 32KBytes without switching)
Imagine a box of cookies and two hungry kids, one can just devour everything at once but the other can only nibble one cookie at a time and will take some time to take another.
M68k can read the whole ROM as it pleases, Z80 is picky and needs bank switching.
Sound effects won't be possible without rewriting the Sound Driver since there's no bank switching involved for those, so I won't bother (KtEiS2 didn't bother either, Knuckles's land and wall snap are silent), but in theory one could add or replace them if a full copy of S&K's sfx were to exist within Gatoslip's ROM.
