A simple sprite demo for teaching

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
A simple sprite demo for teaching
by on (#81806)
I'm working on making a minimal functional NES program: initialize the hardware, clear the screen, load a palette, draw a background, let the player control a character using the Control Pad, and animate the walking with six frames plus flipping. It's intended largely as a teaching tool, and I want it to be both easy to understand and an example of good practice. If there are *any* bad practices in this program (other than possibly the fact that it's homebrew in the first place), or anything that an NES programming novice isn't likely to understand, please let me know.

A basic example (NROM-128) and a switching example (SGROM/SNROM/UOROM) can be found here (updated 2015-02-13).
Re: A simple sprite demo for teaching
by on (#81811)
Using dex instead of ldx #$FF to set the stack pointer is a bit unnecessary as you're aiming for clarity here.

Also, imo, it's bad practice to clear memory on init (as you do with the zeropage). The only reason to do it is so that you can assume it's set to 0 whenever you want to use memory on the zeropage. But that might not be true at a later stage in development since code might get moved around and whatever.

The zeropage locations you use with the assumption it's set to 0 is cur_keys, nmis, player_dxlo and player_frame_sub (from a quick skim through of the code, i might have missed something).

These should be individually initialized just as you do with the other player_* memory locations since that will make things alot more clear.

by on (#81812)
I think DEX is fine, X=X-1 is simple enough. And I see some CCstuff, right? I think he clears it because C wants it cleared on startup? I dunno what you compile with. Also, on my computer the text files had no line breaks...? Okay tutorial though, seems good to me. Is the screen compressed in memory too? When I looked at the debugger with FCEUX, I saw a little data in the middle of nowhere. Wondered what it was...
Re: A simple sprite demo for teaching
by on (#81822)
tepples wrote:

Awesome as usual, tepples. Seems a fine intro to sprite animation and not encumbered by jump physics. But you have collision detection. I need to study this! :D

by on (#81826)
Thanks to all for the feedback.

Anders_A wrote:
it's bad practice to clear memory on init

I've added a few lines of comments to describe the clearing vs. anti-clearing holy war.

3gengames wrote:
I think DEX is fine, X=X-1 is simple enough.

Although I guess it needs a comment because a newbie might not be familiar with how LDX #$00 DEX produces $FF. Added to next version.

Quote:
Also, on my computer the text files had no line breaks...?

Newline on Linux is $0A, just as on FreeBSD, Mac OS X, and other UNIX style operating systems. Newline in Windows Notepad is $0D $0A, and it appears Windows Notepad won't recognize a UNIX newline. Sometimes I forget about this because all Windows PCs that I regularly use have Notepad++ installed, and Notepad++ and Programmer's Notepad recognize both newline conventions. Or try dragging the .s files into an open web browser window. Added note at the top of README.txt.

Quote:
Is the screen compressed in memory too?

It's not as much compressed as object-based: there's a floor, and there are two columns of blocks.

Quote:
When I looked at the debugger with FCEUX, I saw a little data in the middle of nowhere. Wondered what it was...

Does the data match 'initial_palette' around line 207 of main.s?

cpow wrote:
Seems a fine intro to sprite animation and not encumbered by jump physics.

Which goes back to an old discussion on gbadev.org about how to make a platformer with no jumping.

Quote:
But you have collision detection.

It's very simple: all X values outside a certain range are solid.

by on (#81834)
Well done.

by on (#81855)
Nice work!

Very minor copy/paste typo: it still says 'NES controller reading code' in the header of the main.s file.

by on (#81858)
tepples wrote:
Quote:
Also, on my computer the text files had no line breaks...?

Newline on Linux is $0A, just as on FreeBSD, Mac OS X, and other UNIX style operating systems. Newline in Windows Notepad is $0D $0A, and it appears Windows Notepad won't recognize a UNIX newline. Sometimes I forget about this because all Windows PCs that I regularly use have Notepad++ installed, and Notepad++ and Programmer's Notepad recognize both newline conventions. Or try dragging the .s files into an open web browser window. Added note at the top of README.txt.


Gedit runs just fine on Windows (except for getting multiple tabs when opening from Explorer doesn't work). Also, when I see a file that fails in Notepad like that, I open it in Wordpad, CTRL+S, then open it again in Notepad. But then again most of the time I use Gedit (which has syntax hilighting).

by on (#81869)
I've released a new version with your suggested additions to comments and updated the link in the first post.

Hangin10 wrote:
tepples wrote:
Windows Notepad won't recognize a UNIX newline.

Gedit runs just fine on Windows (except for getting multiple tabs when opening from Explorer doesn't work). Also, when I see a file that fails in Notepad like that, I open it in Wordpad, CTRL+S, then open it again in Notepad. But then again most of the time I use Gedit (which has syntax hilighting).

I too use Gedit on my Ubuntu laptop. Would you share your syntax highlighting file for Gedit?

by on (#81922)
I have one here which is based on several syntax highlighting files I found either here or with a Google search.
It is not perfect, but it works for me.
You can give it a try if you want. I can't find the MIME-type file that goes with it anymore, but I'm sure one would be able to create that him- or herself very easily.
Here is a link:
http://www.cojobo.bonn.de/~t_unte/ASM/asm6502.lang

by on (#81936)
I've added an MMC1 example suitable for SGROM or SNROM boards. It demonstrates CHR RAM loading and bank-to-bank procedure calls.

by on (#81986)
Too bad Blargg isn't around, I feel she'd like the fact that more and more good documentation is now available for others.
Re: A simple sprite demo for teaching
by on (#105431)
Tip (requested by jwdonal on #nesdev): If you get ImportError: No module named PIL then you need to install Python Imaging Library.
Re: A simple sprite demo for teaching
by on (#128832)
It's about time I upgraded the projects to track minor changes to the assembly language syntax of ca65 and the command line syntax of ld65.
Re: A simple sprite demo for teaching
by on (#134181)
It has come to my attention that instructions for setting up a build environment for this demo are needed. That's being discussed in this topic.
Re: A simple sprite demo for teaching
by on (#135833)
I understand the logic of the inertia effect, but I'm having a real hard time understanding the use of signed numbers and fixed-point arithmetic. I haven't really found anything good about it from the POV of the 6502 on google, anyone here got anything good?

I can add/subtract 8n-bit unsigned numbers, and it would be great to know how to do it
with signed fixed-point numbers, so I could extend this to use 16-bit velocity.

I tried handling inertia with unsigned numbers, but that turned into an unholy mess pretty quick.

Thanks!
Re: A simple sprite demo for teaching
by on (#135837)
Addition and subtraction of signed numbers the exactly the same as unsigned numbers, on the 6502. The same set of instructions works for both.

The part that is significantly different is making comparisons. Here is a good article to read:
http://www.6502.org/tutorials/compare_beyond.html

Another thing that is different is the bitwise right shift. You will want to copy the sign bit as you shift, like instead of LSR, perhaps use CMP #$80, ROR.
Re: A simple sprite demo for teaching
by on (#135841)
rainwarrior wrote:
Addition and subtraction of signed numbers the exactly the same as unsigned numbers, on the 6502. The same set of instructions works for both.

The part that is significantly different is making comparisons. Here is a good article to read:
http://www.6502.org/tutorials/compare_beyond.html

Another thing that is different is the bitwise right shift. You will want to copy the sign bit as you shift, like instead of LSR, perhaps use CMP #$80, ROR.


Thanks!
I think the problem is the fixed-point part. I tried to edit a little more of tepples code, but it turned into another mess. I'm getting tierd, so I'm gonna give it another try tomorrow.
Re: A simple sprite demo for teaching
by on (#136245)
"tierd"? I thought tires don exits :p

In any case, version 4 is out with new build environment setup instructions courtesy of the Super NES version's thread.
Re: A simple sprite demo for teaching
by on (#141135)
I've released version 0.05 incorporating improvements based on the suggestions made by koitsu and Espozo. One new feature in the MMC1 template is a driver for UNROM/UOROM that's a drop-in replacement.
As if anybody gives a fork
by on (#182986)
I put the NROM version on GitHub so that you can create new NES projects by forking pinobatch/nrom-template. One change was made: PNG to CHR conversion was ported to Python 3.

EDIT (2016-11-16): UNROM, UOROM, SGROM, and SNROM version as well at pinobatch/snrom-template. I forked it from the nrom-template repository so that changes that I make in the NROM version can be reflected in this version.

If you cannot use GitHub's fork functionality for some reason, such as if you prefer Savannah, GitLab, or BitBucket for whatever reason, you can create an empty repository on your Git host of choice and then clone manually:
Code:
git clone https://github.com/pinobatch/nrom-template.git PROJECT
cd PROJECT
git remote rename origin upstream
git remote add origin https://github.com/USERNAME/PROJECT.git
git push -u origin master
Re: A simple sprite demo for teaching
by on (#213368)
Now ported to BNROM, so people can get started with the 32K PRG ROM bankswitching model of BNROM, AOROM, Color Dreams, and GTROM

pinobatch/bnrom-template