Users browsing this thread: 4 Guest(s)
Kirby Super Star Sprite Ripping Issues
#1
Recently, I've been attempting to rip the backgrounds of Kirby Super Star. As you can guess by the existence of this thread, though, there are issues occurring, specifically palette and graphical issues, and all of it seem to be connected to the game's HUD.

It appears that the game is displaying more colors than what I believe is the typical 256 (how it's accomplished, I have no clue), and when viewing the palette through debugging tools, it's either showing only the HUD's palette, or in the case of Mesen-S, it fluctuates between the HUD's colors and the ones for both the foreground and background. The same thing happens when viewing Layer 2 (which is where both the background and HUD are displayed) through these debugging tool as it fluctuates between displaying the bg and HUD in Mesen-S, and it only shows the HUD when using any other tool.

         

Now outsides of those brief moments when Mesen is fluctuating between what to display, there are a couple workarounds. For a brief moment after unpausing, both the background and it's palette will be displayed in the viewer, and these issues are nonexistent when the game is not displaying the HUD (such as the intro to each Spring Breeze level). These, however, only help so much as Super Star has a decent amount of animated backgrounds, and I know at least one that's bigger than the SNES is able to render.

All in all, my main question is how is the game accomplishing this, and what other workarounds are there (the latter question being the most important)?

Tools that were used are Mesen-S, no$sns, and Vsnes.
Reply
Thanked by:
#2
Can you provide a quicksave which is usable for vSNES? I would like to take a look.
Reply
Thanked by:
#3
Apologies for my ignorance if the answer is simple, but how do I do that?
Reply
Thanked by:
#4
I rip things by importing ZSNES quicksaves into vSNES. This gives me access to tiles, palette and what's currently on screen (MemViewer, PalViewer, SceneViewer).

Since you use a different emulator and some kind of debugger, I guess the only the thing in common would be not a quicksave, but the SRM savefile. Maybe you can upload it on mega.nz or mediafire?
Reply
Thanked by:
#5
I did use ZSNES files for vSNES, as a matter of fact.

Anyways, hope this works.

https://www.dropbox.com/s/1yab8m2yycdqkw...r.zs1?dl=0
Reply
Thanked by:
#6
I tried a bit around and for me, only sprites are visible in vSNES with the level foreground being corrupted. It shows the level tiles for an intro scene correctly, but playable levels just don't work anymore.

Btw I found this level editor for Kirby Super Star Ultra:
https://www.romhacking.net/utilities/1151/
Are the graphics identical? If yes, maybe the DS version could be better for background / level rips.
Reply
Thanked by:
#7
They are not the same, unfortunately.
Reply
Thanked by:
#8
This would explain why every level rip on the site is based on screenshots.
Right now, I don't see another option than using an accurate emulator like mesen-s or bsnes+ (ZSNES cuts off at least 1 pixel of the screen horizontally)
https://www.vg-resource.com/thread-41182.html
and
- screenshotting the levels / backgrounds
- assembling it on a sheet
- putting said sheet on a grid and making it loopable by erasing duplicate loops, etc.

Would be cooler just to make quicksaves and having vSNES spit out the backgrounds, but apparently this is not possible. I just tried it with the other modes and nothing came up. Intro backgrounds like the King Dedede smile from Gourmet Race seem to be unaffected, though. Could be some internal compression to make the game fit on a smaller cardridge.
Reply
Thanked by:
#9
I checked this game in my ripping emulator of choice (bsnes+) and found that only the background shows up and not the status bar. Not sure if that's a good or a bad thing.

Edit: Nevermind, it kept switching between the hud and background as well for me.
Reply
Thanked by:
#10
I seemed to have found some form of workaround. On Mesen-S, setting the "refresh on scanline" to zero stops the fluctuating from occurring unless you pause emulation. Then you just gotta slow the emulation speed to 1%. Granted, you still have to make sure to save fast enough before the background updates, but it can be worked with.
Reply
Thanked by:


Forum Jump: