A simple sprite demo for teaching
Moderator: Moderators
A simple sprite demo for teaching
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).
A basic example (NROM-128) and a switching example (SGROM/SNROM/UOROM) can be found here (updated 2015-02-13).
Last edited by tepples on Sun Oct 16, 2011 3:39 pm, edited 3 times in total.
Re: A simple sprite demo for teaching
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.
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.
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...
- cpow
- NESICIDE developer
- Posts: 1097
- Joined: Mon Oct 13, 2008 7:55 pm
- Location: Minneapolis, MN
- Contact:
Re: A simple sprite demo for teaching
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!tepples wrote: The example
Thanks to all for the feedback.
I've added a few lines of comments to describe the clearing vs. anti-clearing holy war.Anders_A wrote:it's bad practice to clear memory on init
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.3gengames wrote:I think DEX is fine, X=X-1 is simple enough.
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.Also, on my computer the text files had no line breaks...?
It's not as much compressed as object-based: there's a floor, and there are two columns of blocks.Is the screen compressed in memory too?
Does the data match 'initial_palette' around line 207 of main.s?When I looked at the debugger with FCEUX, I saw a little data in the middle of nowhere. Wondered what it was...
Which goes back to an old discussion on gbadev.org about how to make a platformer with no jumping.cpow wrote:Seems a fine intro to sprite animation and not encumbered by jump physics.
It's very simple: all X values outside a certain range are solid.But you have collision detection.
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).tepples wrote: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.Also, on my computer the text files had no line breaks...?
I've released a new version with your suggested additions to comments and updated the link in the first post.
I too use Gedit on my Ubuntu laptop. Would you share your syntax highlighting file for Gedit?Hangin10 wrote: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).tepples wrote:Windows Notepad won't recognize a UNIX newline.
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
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
- Jarhmander
- Formerly ~J-@D!~
- Posts: 568
- Joined: Sun Mar 12, 2006 12:36 am
- Location: Rive nord de Montréal
Re: A simple sprite demo for teaching
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
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
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.