nesdev.org

In your example with pong you may be able to keep it simple but in a more complex system, you will need to have a list of entity (player, enemy, bullet, whatever your system manage) that will contain information about the sprites they are using (usually a metasprite that contains a list of sprite about that specific animation frame).

On every frame, you will go trough the list of entity that requires to be shown. That list will contain the information regarding the metasprite to be shown and their world coordinate (the location on your currently displayed map). From that information, based on the current location of the camera, every sprite from that metasprite need to be either culled if outside the camera view or shown. The one shown will have to be converted to screen coordinate. The shown sprite will then be written at the OAM (commonly at $200).

If the current frame contains less sprite then the previous one, then the buffer (OAM) must be updated accordingly.

I simplified things a little bit but that is the basic of such a system. Every game will scrolling map will have to develop to manage such entities. A one screen game will have that too but won't have to worry about the camera since you are always on the same screen, making thing a little bit easier.

edit:

I explained about entity system but did not really answer you question. For this, I apologize.

If the system is simple then yes, you may be able to use the same buffer for managing your sprite then doing the DMA transfer to the PPU OAM. For a simple game, you don't have to worry that much about memory.

If it's your first game and learning from it, don't worry to much about how it must be "perfectly coded". You will make mistake and from those, learn what works or not

In most games, the OAM is not used to store your game state variables directly. It's filled up each frame, copying/transforming from the game state elsewhere.

One big reason for this is the 8 sprite per scanline limit, once you have too many tiles on a scanline the others will drop out. Many games have some way to shuffle the order sprites are placed in the OAM, creating the "flicker" effect that's frequently seen in NES games; if you can't shuffle the list like this basically one character will go invisible, which is much worse than flickering.

yaros wrote:...fill the rest of OAM with $FF.

You can save a bunch of cycles by just filling the Y coordinate with FF. Once it's offscreen the other 3 bytes don't matter.