TI-83 Assembly Logs Vol. 6

Basics	Archives	Community	Services	Programming
Hardware	Help	About	Search	Your Account

Home :: Programming :: Columns and Tutorials :: TI-83 Assembly Logs Vol. 6

by Phil

Editor's note: The information contained in this article may be outdated and/or inaccurate.

Introduction

Greetings all, once again. I'm sorry that I have not been able to produce another log in a while, but that's because I have been working too hard on my finals in school that I disregarded my calculator for a long time. I may be rusty in my ASM now, so, if I mess up in this log, I'm sure that will be totally acceptable, right?

Right. Now, I'm going to talk primarally about sprites in this log. I hope those who have been reading my logs have cross-referenced this with other ASM guides and have learned the very few things I have left out. Here we go with sprites. I'm not going to get in too much detail because I don't want this to be a 2 Meg. file.

Sprites

Let me explain a sprite to you really fast. Ever play Super Mario Brothers for the old Nintendo, or any of the Zelda series (published to date)? If you have, you have probibly noticed that Mario or Link always look relitivly the same, and they seem to ! reverse if you look left to right. This is because the characters are sprites. A sprite is simply a graphic that the precessor treats like a character. For example, let's say that this following graphic is a sword:

	   #
	  # #
	  # #
	  # #
	 #####
	  ###
	  ###

If I wanted to move that sword, I could clear the image pixel by pixel and then re-draw it pixel by pixel one space to the right, which would take up a lot of space and time. Then again, I could just clear the sprite and move the sprite over one to the right. So, basicly, instead of doing this:

	#   #
	#  # #
	#  # #
	#  # #
	# #####
	#  ###
	#  ###
	#

to:	 #   #
	 #  # #
	 #  # #
	 #  # #
	 # #####
	 #  ###
	 #  ###
	 #

I could do this:

	#   #
	#  # #
	#  # #
	#  # #
	# #####
	#  ###
	#  ###
	#

to:	#    #
	#   # #
	#   # #
	#   # #
	#  #####
	#   ###
	#   ###
	#

If you can see the difference, in the first, the entire picture (including the line drawn on the edge for reference) is moved to the left. In the second, only the sprite of the sword is moved. Got it?

Now, the problem comes when trying to program these sprites to tell the processor what it is. The basic format of a sprite is 8x8. Let's look at this.

Look familiar? Maybe, like eight bytes? Remember, a byte is eight bits, or eight 1's and/or 0's. If you have eight of them stacked on top of eachother, you have a sprite. This is a blank sprite:

And this is the sprite of that sword I just drew:

Pretty cool, eh?

Now, here's the tough part. You need some way for the processor to call the sprites you make. The only reliable way I have found to do this is to use a program (really, a set of routines) by Movax called sprite.z80. This set of routines, if you hack into it, will tell you exactally how to use the sprites and call them.

To make things simple, I won't tell you how these routines run, but I will tell you this: the program gets the sprite from a label. You just name the label what you want to name the sprite, make the lines following the eight bytes that define the sprit! call the label into 'hl', call the x- and y-coordinates into 'b' and 'c', and then call one of the many sub-routines in the program which either clear the sprite, draw the sprite, or do both at the same time (I will explain later). The process is simple! .<

Now, what about that 'XOR' command? Here's the deal. In logic circutry, 'XOR' means 'exclusive-or'. This means that it will follow through with the circut only if one variable is true; not both, and not neither. How does this relate to sprites? Well! , the 'XOR' command will only display the bits, or the pixels, of two sprites layed on top of eachother that apear only in one sprite. For example, let's take the sword that I drew:

	   #
	  # #
	  # #
	  # #
	 #####
	  ###
	  ###

If I were to just draw another full sprite (a block, or a sprite which all it's bits are 1's) over this sprite, I would get this:

	########
	########
	########
	########
	########
	########
	########
	########

Just the full sprite would show up. But, if I were to 'XOR' draw the full sprite over the sword sprite, I would get this:

	### ####
	## # ###
	## # ###
	## # ###
	#     ##
	##   ###
	##   ###
	########

You see, the only pixels that showed up were the ones were the ones that were in the possitions that only one bit occured in both sprites. With this routine that Movax created, the processor checks the bytes like this:

XOR
(1: 0+0=0  2: 1+0=1  3: 1+1=0)

bit 1, sprite 1: 0
bit 1, sprite 2: 0
opperation:      1
calculation:     0+0=0
result:          0
display? (y/n):  n

...and so on. Please remember that this is just a representation of what the precessor does, and it is not the EXACT function of the processor. This is for demonstartion only.

There, I hope that answers most of your questions on the matter. If not, contact me by using the links below. If you want a quicker answer, use the ICQ UIN. It will page my ICQ, and I will read that a lot quicker then my eMail. The problem is, you can only send a message up to 450 charicters in length, so make it short. ICQ: 1385910

Thanks for your time, and I'll see you (hopefully) in my next ASM Log! -Phil