Undead Core

[andwhyisit]

Sue doesn't drop into place in front of Misery, she just hovers in midair.

Sue's frenzied form has over half of its sprites wrong. It seems to alternate between one of the frenzied Sue sprites and a regular Sue sprite. She also has the wrong transformation sprite.

Undead Core's face doesn't quite line up with its body.

The mini cores are using the open state sprite for their closed sprite and the circling mini core open sprite for their open sprite.

Misery's spawned enemies like to phase through the floor.

I can't stand still on top of a mini core.

Misery has the wrong defeated sprite. In fact her current defeated sprite is actually the sprite that should be used during her transformation.

Misery hovers in midair after being defeated and then she still takes damage anyway.

Sue will happily fall off the map during her defeat sequence.

A mini core pushed me into the ceiling.

[Leo40Git]

The player can inexplicably fly now? For some reason, the player floats up in Black Space, even before the boss battle begins. The "floaty point" seems to start after the 4 mini cores at the start.

[andwhyisit]

That's part of a broader bug by the looks rather than anything specific to this boss fight. I've made a separate issue (#162) regarding it.

[andwn]

Ironically it was because of me trying to fix the player falling off of the minicores

[Leo40Git]

And now the healthbar isn't appearing.

[andwhyisit]

Animated gifs ahoy.

Sue considers the ground to be higher than it is: http://andwhyisit.bugsiteguardian.com/csmd/imfinefloatingherethanks_zpsufkioqga.gif

Misery has no sprite now: http://andwhyisit.bugsiteguardian.com/csmd/whereintheworldismiserysandiago_zpsygrijnph.gif

Sue recklessly ignoring gravity and absorbing damage after being knocked out: http://andwhyisit.bugsiteguardian.com/csmd/zombiesue_zpsczn8v0nr.gif

Wrong mini core sprites, and the mino cores no longer register when you are no longer standing on them: http://andwhyisit.bugsiteguardian.com/csmd/thecoreoftheproblem_zpsldek5gl8.gif

Aaaaand I've been pushed off the map: http://andwhyisit.bugsiteguardian.com/csmd/offtohogsworth_zpslgtwoabe.gif

All in the ntsc build.

[andwhyisit]

The non-background mini cores should have the closed eyes sprite by default unless you are standing on them, in which case they have the open eyes sprite, then when you are no longer standing on the mini core it reverts back to the closed eyes sprite. In the md version they currently have the open eyes sprite all the time.

[andwhyisit]

The only things left are (to my knowledge):

1. The face not aligning with the core.
2. Misery's defeat sequence is missing her collapsed sprite.
3. After being defeated Misery's x position will slowly migrate leftwards until she falls off the map.
4. Red particle related slowdown during the intro sequence while holding A.

[andwn]

The Minicores that revolve around the core, but I'm saving that for last

[andwhyisit]

Would it be any better performance-wise to abuse the background layer for rendering both the core body and revolving minicores?

[andwn]

I could do it for the core body, but not the rotators (backgrounds just don't work that way). This introduces a problem with layering though. Every other entity in the room needs to be drawn over all of this, but the rotators need to be drawn underneath when they circle in the front. I would need to change the priority of all the entities that exist on the map to be over the core (they would be over the map too which is not usually the case).

The only real reason to do it would be to get around the sprite limit which may be hit once the rotators are introduced. It'll probably waste more cpu cycles than it saves.

[andwhyisit]

Nevermind on the background idea then.

What about having each rotator mini core move on a 90 degree axis then reset to its original position? This is so it looks like the next mini core is moving around rather than the same mini core from last time. If it is done this way then sprite layering can be consistent.

So RMC (rotator mini core) 1 would arc from 270 to 359 degrees and be in front of the core, RMC 2 would arc from 0 to 89 degrees and be in front of the core, RMC 3 would arc from 90 to 179 degrees and be behind the core, and RMC 4 would arc from 180 to 269 degrees and be behind the core.

As long as they all keep time with each other then it will look like 4 RMCs doing a full 360 degree arc.

[andwn]

I think NXEngine does something similar to avoid worrying about reordering them in front/behind the core. Somewhere in the hundreds of commented lines... I haven't given it a good read so could be wrong. Worst case some sprites are gonna flicker.

[andwhyisit]

You could reduce the flicker occurrences by half if you have all four RMCs do 180 degree arcs (90 to 269 for the back and 270 to 89 for the front) and just have one front RMC and one back RMC start mid arc.

This way any flicker will be limited to the front to back and back to front transitions.

[andwn]

I should really get those rotators in, huh