nesdev.com

Sound effects are working now. But I have the feeling that every effect shows up a bit late.
Is that the expected behaviour with famitone2-effects?

Sound effects should begin immediately.

In an emulator, sound latency of ~100ms or more is normal.

If you want to verify, you could try using FCEUX and step frame by frame (use the backslash \ key to step) you can hear each frame's sound as it steps.

Make sure you main song volume isn't overpowering the sound fx. Sound effects should be as loud, or louder than the music (in famitone2) or they won't play.

I modified my vrsion of famitone, to avoid this.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

weekly update: 7 weeks to go


Zolionline has finished the 1st enemy, there's a mini end sequence and the NES low level code seems to be stable: The game is fully playable now!!
(but there're only two rooms - lot's of work ahead...)

@FrankenGraphics: Nice ideas... I guess there's not enough time to improve the gameplay significytly, though.
@rainwarrior: Hm... ok, after examining everything, I think only a few effects are a bit late. The problem should be the effect itself, I guess.

update: 6 wees to go...
There're 18 new rooms! (and 20 new bugs)
And I just recognised that my code is too slow to move more than 2 enemies at the same time. How could that happen? It's time for optimizations!

describe "too slow".

are you getting dropped frames? (lag)

try moving to a 30 frames per second animation change system.

that would be, like, do all ppu changes (buffering) in even frames, do all game logic and sprite changes on odd frames.

music should be tied to NMI to stay consistent.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

Similarly, but maybe less drastic, you can also often get away with updating different enemies on alternating frames. Half the enemies one frame, half the next.

_________________
My games: http://www.bitethechili.com

Also *if* the problem is mainly moving them (maybe i'm reading it to literally?) as opposed to updating them in general, it seems to suggest they have a bit more complex movement code than needed be. Some enemies might not even need hit detection routines, and else, they can sometimes be kept simple; unlike the player character.

_________________
http://www.frankengraphics.com - personal NES blog

Enemies can often be given simpler physics and collision detection than the player. It's not uncommon to see enemies using a single point of contact with the floor, ignoring ceilings, lacking slope physics, and so on. Some enemies may even not require any interactions with the level map at all if all they do is fly or patrol a plain surface.

Update: 5 weeks to go...

@dougeff: Ok, that should work. But as I would like to retain the 60 fps movements, the movement code will still be called in 60 fps and I only lowered the call frequency of the control code to 30 fps. Now the program code is fast enough to move whopping 3 enemies at a time, but only if there's no scrolling.

@gauauu: Yes, that's an old C64 trick. I tried to call the player control in all odd frames, and the enemy control in all even frames. Now 3 enemies can be moved even with scrolling. Seems like querying the joypad with 30 fps is fast enough. hopefully...

@frankengraphics: Ok, I can skip the gravity and BG collision calculations on some enemies if they only walk left and right. If I only use these simple enemies, then I can handle 4 enemies instead of 3.

@tokumaru: I cannot skip the collision detetion, but I converted the collision routine to assembler and now I can move 5 simple enemies or 3 sophisticated enemies.

That's enough for now. Thanks for the hints!

I have also recognised that the NMI code waits ca. 24 scanlines for the SPR0-hit, doing nothing. Any ideas how I could use this time? (I'm already calling the famitone2 handling there)

more on enemies: Some of them can be BG based and stationary (if you have bits for ”hurting” and ”destructible” in your map system, maybe represented as ”structures” placed on top of the more mundane map) which would more or less be ”for free” as they’re part of the player characters’ bg detection. Enemies like castlevania’s twin dragon skulls would be possible this way, for example.

nmi: any timers you’d like to tick, maybe, can go there

_________________
http://www.frankengraphics.com - personal NES blog

Clearing the OAM buffer, maybe? You really only need to set the Y coordinates, but still. Reading the controller(s) and calculating the newly pressed and released buttons is another thing you can do.

3 is not as bad as you think (for the NES).

My Honey game was only fast enough to handle 5 enemies without slowdown. (Also 4 enemy projectiles, and 2 hero projectiles).

Other games I'm aware of had a max of about 5. 3 is close.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

@tokumaru: Hm... Yes, resetting Y pos OAM entries in NMI would result in a small speed boost. Didn't think of that one.

Another thing: After switching to PAL, the game runs with 50 fps... But there seems to be less CPU time available for the main code (outside the NMI).
Shouldn't there be more CPU time available on PAL? Where's that lost time? Maybe in the busy-wait for the SPR0 hit?

PAL should have more CPU time.
It may be your sprite 0 waiting loop indeed.