nesdev.org

psycopathicteen wrote:

This is a screen of some of the enemies in the game, along with a pixel version of my ponytailed girl character.

I think I'll name her Alisha.

That face is nightmare fuel. She will eat me.

I know that I will be rude by saying so but I will tell it anyway. You lost my credibility when you said that it was a mix with Sailor moon. That's an animation for 4 years old ^^;;. I don't think it make sense unless this is your target audience.

Don't get in the same weirdo bangwaggon that I see from those freaks at Akihabara, please. The other sprites are nice though.

I fixed a few misplaced pixels on the right side of her hair.

That face is nightmare fuel. She will eat me.

You know it's incredibly similar to you avatar, do you ?

That's an animation for 4 years old ^^;;. I don't think it make sense unless this is your target audience.

The same could be said of Gimmick, Uforia, and maybe some other NES games I don't remember that quite a few people on this board seems fond of.

Will you make the game compensate for NTSC/PAL speed differences? Project MD does, mainly because otherwise people would yell at me because the game runs at a different speed.

Also why only update sprite graphics on even frames?

Sik wrote:Also why only update sprite graphics on even frames?

Because we don't pay the animators enough to draw 60 sprite cels per second

(See also sprite cel frame rate discussion.)

Sik wrote:Will you make the game compensate for NTSC/PAL speed differences?

I'm not sure about the SNES, but on the NES I think that would be kinda hard to do. If I had a lot of free CPU time, I'd first think of simply running an extra logic frame after 5 frames on a PAL console, but that would screw up the VRAM updates, which usually have RAM for only 1 frame worth of updates. Another option would be to use different physics constants for each type of console, but since we use fixed-point numbers, even the smallest rounding errors could result in the game behaving too differently.

Sik, if you don't mind me asking, what method did you use on the MD to compensate for the speed difference?

tokumaru wrote:If I had a lot of free CPU time, I'd first think of simply running an extra logic frame after 5 frames on a PAL console

That would create an effect similar to telecine judder.

Another option would be to use different physics constants for each type of console, but since we use fixed-point numbers, even the smallest rounding errors could result in the game behaving too differently.

On the NES, you sometimes have to reduce the precision of your fixed-point arithmetic to fit a world coordinate into 16 bits (two machine words). For example, one platformer uses quarter pixels as its fundamental unit (Q14.2). On the Super NES, two machine words are 32 bits, and you can use Q16.16 coordinates even if your map is 256 screens wide. But as you point out, the trouble would come from testing every jump in the game on both versions to see which ones the player can make or not make. I seem to remember this being noticeable in some Quake engine game, in which the player can make the most difficult rocket jumps only at specific frame rates. And you might have to accept the fact that character balance will differ.

I won't give my head on it, but Sik uses different values between 50/60Hz... on MD you can do 16.16 fixed point math in a much more easier way than anything else.

TmEE got it. It's that or people complain because the game runs too slow.

Tepples, his post implies that any animation not aligned to even frames will be impossible. Project MD has lots of animations with sprites lasting 3 frames, for example.

PAL version, odd frames are alowed.
NTSC version, no.

btw, coordinates can change on odd frames, just not animation cells.

I fail to see how that improves anything. I mean, in the end all tile updates have to happen in a single vblank, so why is there that limitation?

Presumably becaues on even frames the NTSC version is doing other updates during vblank, for which adding the character animation as well would go over the available time.

Sik wrote:I fail to see how that improves anything.

I don't think it's supposed to improve anything, it's just that apparently there is not enough VBlank time on the NTSC console to update the sprite patterns and perform other necessary tasks. I think he made a thread explaining his animation method recently.

I mean, in the end all tile updates have to happen in a single vblank, so why is there that limitation?

Because of other updates that also need VBlank time.

I don't think that this is a mandatory thing for the SNES, it's just his engine that was designed that way. I too have limitations like these in my CHR-RAM NES game. I even have to double buffer the main character's tiles, since they can only be updated all at once if no other VRAM update is necessary for a frame.

I'm now using a modified version of my old dynamic animation engine.

My old engine uploaded 64 16x16 sprite cells over 2 consecutive frames (32 cells each) with the other 64 sprites using permanant v-ram sprite patterns.

My new engine is a little bit simpler. It uploads 96 16x16 sprite cells over 2 consecutive frames (48 cells each) without using any permanant v-ram sprite patterns.

But they both rely on the same double buffer, 1-frame-oam-delay method that I came up with. Both versions have advantages and disadvantages, but the second method doesn't take as much thinking when you want to add in a new character or object.