diff options
| author | Miquel Sabaté Solà <mssola@mssola.com> | 2026-07-22 16:50:48 +0200 |
|---|---|---|
| committer | Miquel Sabaté Solà <mssola@mssola.com> | 2026-07-22 16:50:48 +0200 |
| commit | 7af0538816193be7c88c76a556b908bedf1585df (patch) | |
| tree | dbb6a058a64e245210cc057ecdadf24e8daa99e3 /basics | |
| parent | 28a5ff3295ae8c80a6ac973fb94697bd445019f3 (diff) | |
| download | code.nes-main.tar.gz code.nes-main.zip | |
Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
Diffstat (limited to 'basics')
| -rw-r--r-- | basics/README.md | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/basics/README.md b/basics/README.md index 3ffb285..61f33a8 100644 --- a/basics/README.md +++ b/basics/README.md @@ -54,7 +54,7 @@ aware about the priorities of your game: the player's convenience. 2. Is there a way to lay out the OAM memory in a way in which we always get the proper results without having to re-arrange objects on the OAM? Imagine a - very simple game such as [jetpac.nes](https://github.com/mssola/jetpac.nes), + very simple game such as [jetpac.nes](https://git.mssola.com/nes/jetpac.nes), in which we know in advance the slots for enemies, bonuses, etc. ## Showing a sprite through CHR-RAM instead of CHR-ROM @@ -84,7 +84,7 @@ have the foundations for `chr-ram.s`, which will use one of the banks for the assets, and then upon initialization move it to RAM. The result is the same as with `sprite.s`, but the goal of this example is to appreciate the technique and understand when it's useful. - + ## Persisting memory Another area explored here is a way to persist data across runs. This was |