People are complaining that an addition to a game mode ripped off directly from Dragonball Z is "too anime"? Keep it.
There's a big difference between Super Sonic and "THIS IS MY ULTIMATE POWER LEVEL RAAAAAAAAAARGH" animations. Toss it.
I really like that animation. Yes, it might be a bit flashy and anime-ish, but it kinda suits the S3 look... I say keep it, since it looks cool.
I've followed various hacking communities and it's rare to see a hack of this caliber. I can't wait to see what you come up with next flamewing.
This. Sonic passionately displaying his power in such an angry fashion is a bit out of character, especially for his Sonic 1-3K persona. Sonic is more of a 'look how awesome I am' show-off, not a 'witness my ultimate power!' type.
you're going to get (and also have gotten) a lot of mixed opinion on the Super Sonic animation; whether or not it's fitting for sonic, whether or not it works as an act-clear animation, etc.; here's something a little more useful: it doesn't look good. it's hard for me to exactly pinpoint why the shading irks me; it looks like you started with an outline, shaded a thicker line below it with yellow, and then filled the rest with white, instead of taking advantage of your shades to give it a fuller shape. the spots where you tried to antialias the yellow shade with the darker yellow shade don't make it smoother; it actually makes it more jaggy. on that note, it's weird that you don't use that darker shade of yellow for the outer edges of the glow. that lighter shade of yellow is also indistinguishable and doesn't add anything to the sprite. the piece would feel more unified if the "power glow" used only Super Sonic's colors. lastly, the animation for the glow is... limited. some bits flicker, but it's mostly shortening certain pieces or moving them around. it would make more sense to have the spikes slowly move from the bottom to the top, in a 1-2-3-1-2-3 frame pattern to make the animation smoother. also, why doesn't the glow reach farther than his arms? is the "power" emanating from there?
So, I got a report that SRAM in SCH does not work in real hardware with an Everdrive; the source is not the most trustworthy one, so: can anyone confirm? And would you be willing to be my guinea pig in this matter if it really does not work?
Working fine for me - ran up to Marble, turned it off, ran another game with SRAM, turned it off, ran SCH again, and there's my game at Marble Zone. That's on an original Everdrive, apparently OS version 32 and firmware 14, on an (acting) NTSC-US MD. The menu is quite busy with (what I assume to be) CRAM write spots on hardware, but they're not too distracting on the default colour scheme. My favourite Retro brown one is a bit painful though!
Yes, there are a lot of writes to CRAM (several palette changes at several points); can you PM me a few pictures? Maybe I can take some measures to reduce/eliminate the spots, but it would be useful to see were they are.
I've had this sitting here for a little while now, havent' gotten around to posting it... But I've got some stuff to report... complete with Save states. SAVE STATES IN THE PACK ARE BOLDED. HERE is the pack. * (State 0) Glided into an Orbinaut with a Water Shield. I lost the water shield, but the spike balls would continue to be reflected away by seemingly nothing. * (State 1) Another graphical glitch with SS results. I wanted to point out that this may have seen a fix recently, thanks to MarkeyJester. It's on the QA forum, maybe last page before current. * (State 2) Whenever you hit escape during the S1 end sequence, the pink flowers turn darkgreen. * (State 3) Occasional shadow drawing error in Special Stage. * (State 5) MZ Cog in Act 2, against the wall, can hurt you only if jump is timed correctly in between the cog and the wall. * (State 6) Reaction to OOZ pressure springs is incorrect. * (State 8) Occasionally in the menu, you can access "Emerald 8" in the Special Stages. IT ultimately sends you to "Emerald 1"
That one was fun: the spikeball was technically been reflected already by the shield, but the orbinaut forced them around him until the point of release. I made the orbs bounce away when hit by the shield. I haven't fixed it yet, I have been waiting to confirm it was that. Anyway, I added the code (modified for the fact I have two different special stages) and now I need to see if it still happens. Try hitting escape in the start of LZ with water on-screen (but not full-screen water) and see what happens; same thing. Nothing I can do except pester developers to have pause include the effects of h-int. I am surprised it took this long for someone to notice; the last character is far enough from "infinity" that the shadow's position computation can overflow and change sign when it shouldn't. And since that computation was there since the first revision I ever released with all 3 characters in special stages, no one noticed it since then. Anyway, fixed. There is a set of spikes inside that wall to prevent the cog from pushing the player into the wall; for some reason, they never harm the player in the original game. I can swap it for an invisible block, which will probably have the effect of killing the player instead (by crushing). I suppose you mean what happens in the wall? If so, this is an unacceptable side-effect of the fix I had for the SYZ3 start; I reverted it, and made another fix that should be side-effect free. I had this reported already, and it is fixed (just not released). Anyway, thanks for the reports.
I dunno if this has been reported already, but when Super Knuckles gets an Invincibility, or "S" box underwater, then the palette changes from pink to red. In Chemical Plant, anyways. Speaking of underwater, Sonic's life HUD looks black when it's underwater when you run out of Super. I've gotten crushed in the earthquake part in Hill Top more than I'd like to admit. EDITED for moar bugs
On the first bullet, the first part happens by design: palette cycles for hyper forms are not affected by water. The second part, on the other hand, happens by mistake: a premature optimization was causing Sonic's underwater palette to be incorrectly reverted. The second bullet is not a bug.
Thanks. I know the second wasn't a bug, but I get so frustrated at that part. It's worst than the ones in Marble Zone 2. =P Also, what were you "prematurely" optimising in the first place? I mean, nothing's too premature in a beta, let alone a free product.
What I was optimizing was the level-dependent super/hyper underwater palette cycles. The super cycling loads a pointer to a pointer table with the corresponding underwater palette cycles, which is dereferenced for each character. The code to revert from super state was loading the pointer only on the branch for Tails and Knuckles;since the block in question would run every frame until Sonic finished fading back, I removed the code to load the pointer in Sonic's branch. Later, I changed/fixed it to run the Tails/Knuckles branch only once at the right time, but forgot to undo the optimization on Sonic's code, and the pointer was left essentially undefined. It is only by sheer luck that address errors didn't happen more often on Regen/real hardware.
In the end you decided not to use the once-to-curl, twice-to-use-shield approach for Sonic walking off the end of a platform?
