nesdev.com

Hi, I am now trying to write a mini game like "Dr. Robotnik's Mean Bean Machine" or "Diamond" tetris-liked puzzle game.

I am now struggling on how to detect if the blocks of the same type are connected in an efficiency way.

Followings are what i have done:
1. When the blocks cannot drop further, the sprite will be replaced by a background pattern.
2. The layer of the blocks represented by the background pattern set to $01

Therefore, once the sprite cannot drop further and turned to background. I will check if the background pattern of the neighbour block is the same.

If yes, then the neighbours of the "checked-neighbour" will be checked... until no more blocks with the same background pattern.

During the checking, a counter will log the number of the blocks with the same background pattern are connected together. Once the number of connected blocks are more than or equal to 4, cancellation will be processed.

However, I do think that the method I described in the above is not efficient ...

Is anyone can give me some hints?

Regards,
Sunny

Hmm, I had given this same problem a lot of thought before. When I was planning out a similar game (I never implemented it, tho).

My plan was pretty similar to yours, I'd be surprised if there could be a better way to do it. In my game plan, the matching blocks would meld together, so there'd have to be delays for nametable updates with mine. It would take longer, but would look nice.

Once some blocks disappear and the ones above it fall, it's possible it'll have to recheck practically every block on the screen. So I think it'd be best to optimize for that kind of situation, the worst case one.

Just put all your frame-based stuff (music, animations, etc.) in the NMI routine, so if it ever overflows a frame or two, the player wouldn't know the difference.

A puyo clone.


Go look up flood fill on Wikipedia. Essentially, whenever you add blocks to the background (either new blocks or blocks that fell), you'll want to flood-fill the areas where they are with a unique identifier. Scan from left to right, doing one column in each frame, and you should be able to fit it easily into the draw period.

Hi, thank you for your suggestion. However, would you mind to give me more information onf NMI (non-masking interrupt). Would you mind telling me the benifit of using it?

Thanks,
Sunny

Thanks very much, I do think the information is very useful ^_^

Regards,
Sunny

In the NES, it's the heartbeat of the PPU.

It triggers during vblank, which is the only time you can freely write to video and sprite memory while the screen is on. Very convenient, though IRQs from some cartridges can be even more useful.

Without any interrupts, you'd have to wait for vblank (or sprite zero) in the main program. The problem there is when the main loop runs longer than one frame (I think it would have to sometimes, with a game like this). Everything would slow down, most noticably the music and sound effects.

An NMI routine could at least give stability to the music, and anything else that's independant enough from the main code.