The flipping looks fantastic with the only suggestion being that it could be a bit faster...(maybe don't draw every frame, or something. Maybe you can just change a value somewhere...I don't know how that transition works )

As Shannon Monroe, one of the Senior Production Managers of Disney Interactive, once told me when looking at some animation and video that I did a while ago (No, seriously. He was really cool about it all...)

Quote from: Shannon Monroe

Something to always keep in mind when creating transitions is what we call the "DVD Title Rule":
No matter how fantastic your animation looks the first time, there is no denying that there is an inverse relationship between the wow factor and the just-open-the-damn-menu factor of the transition.

Hearing that made me realize just how correct he was, and has led me to cut down on transition times in a lot of things I've made. Please don't take this as me saying, "It's boring. Get it over with faster," but rather that I'm saying, "This transition looks fabulous, but don't let it eat up your gameplay!" There's a point where you know the solution already and you just want to get through to the next level as fast as possible, without having to wait for shift transitions.

Either way, the whole thing looks fantastic. I especially like the effectiveness of that sprite! It works much better than I'd have imagined it would.

I plan on putting in an option to enable/disable the effects, i.e. flipping and the death animation.  Same for the splash screen, it will be possible to just jump straight to the menu. EDIT: and the door opening/closing

I hardly have an idea how it works either except for theory, it's runer-optimized
I can look for a var that counts the frame or something, then put If V^2 and End around the DispGraph....that might be plausible

You can make the flipping animation twice as fast by changing this line:
-128-2→θ
To this:
-128-4→θ

I think that would look better. IMO

Personally I like it slowed down a bit, gives a bit more of the actual shift feel. But that's IMO, change it however you like.

Perhaps an option as to which animation to use?

I had it working, then got a RAM clear and was set back to the source that the last screenie was recorded from

For L3→DispGraph, wouldn't that show nothing but the char?  Also, I kind of have to use pt-change unless I used DrawInv (unless there's some other method for it)

What I had for a bit before was either drawinv just before and after dispgraph or pause 50.  Slowed it down quite a bit
Also I learned my lesson from TWHG, if you preserve the buffer rather than re-draw it's >9000 times faster (in twhg it was all pixel-testing, and the buffer was drawn and redrawn something like 5 times per frame, and those were 96-byte levels)

EDIT:

Perhaps an option to choose the skip rate.  i.e, choose 0, 1, 2, 3, or 4 for the -128-#→θ code.

I think for it to be stable it has to be a power of 2.

EDIT2: Fixed the bug when shifting from row 14.  Turns out it was the block-above-head detection, the if statement had something like "and (Y/32=0)" instead of "and (Y<<0)"

Ok, it's been 11 days so far, and it's almost a full-blown game.  Just need to add options and menus.
Since a simple port plainly won't keep me busy long enough (while actually turning out some output), I'll probably go a lot further with this.
I'm thinking of adding another, completely different dimension to this.  Literally, a Dimension.
Remember this?
That's what I plan on adding to this, but instead of reading from wherever in the RAM, there would be two levels developed to work together.
Only downside is, I'll have to come up with a more all-encompassing title