Editing Sprites in the Editor

T

his week made a return with Darren and me implementing game characters from the Sprite Pad tool.  Siggy was taking a break at this time. So our goals were to take the binary sprites Darren created and add them to the current running project, which includes their animation frames as well.

Using the Sprite Editor tool in CBM Prg Studio, we had previously imported the sprites binary data so we could begin editing the sprites generated in Sprite Pad in this environment.  The sprites are 12 x 21 in the Editor. Each sprite frame can be viewed by clicking on the button arrows on the right in the category called Current Sprite. We noticed that the sprite multicolors had not copied to the Sprite Editor, so we started this session updating the sprites.  Multicolors are activated by clicked on the checkbox on the right called Multicolor.

Darren explained next that he used two types of sprites. One was for the shell around the sprite making up the head, arms, and legs. The other sprites created the clothes.  This was done to add extra colors around the sprite.

We wanted to find a way to copy colors across the sprite. Otherwise we would be forced to set the colors for each individual frame. Under the Sprites menu there is a item called Globalize Colours.  To control all the colors the checkbox for All colours was activated. So after we set this option, the Multicolour checkbox had to be set for each sprite frame.  With some of the sprites, we had to set individual colors to prevent copying over them with the globalize option.

Adding the Sprites to the Project

After setting all the colors, I closed the Sprite Editor window to begin adding the sprites to our current game project.  The command incbin is used to load in binary files. So in Siggy’s project he set it up for the current sprites in use, so we had to modify this to incbin “Sprites.spt”,1,59,true to accommodate the 59 sprites that were edited earlier in this session. There were some issues loading the sprites, so close to an hour into the  video, we commented out the incbin that loaded Siggy’s sprites to get ours on the screen.

The top sprite was controlled by the joystick (gamepad controller) and the bottom sprite was set to an animation sequence. So our goal was figured out how to control the sprite animation frames at the top so we could create an animated sprite as the controller was moved.

We were trying to understand the logic that Siggy developed, so Darren created a side project in his spare time to learn from it. The screenshot seen here extracted the sprites from Siggy’s Trump jump. Darren explained by saying, “There are 3 sprites. The body is 2 sprites, the tie and shirt are one sprite, and blue suit, hands, and feet were another sprite. They are laid on top of one another. The head is also one sprite.”

For the animation, he had the sprite shifting positions from the right to the left, depending on which way the player was moved.  The idle animation made the sprite bounced up and down looking to the left or right. Again this is dependent upon the last sprite position that was retained.  He clarified that the LAST_LOOK verified recalled the last direction the sprite was looking toward. If you study the code sample below, you can gain more of a grip on the logic.

If the LAST_LOOK variable is set to 1, then the sprite is looking to the right. Otherwise a zero value placed here, sets the sprite looking to the left.

Sometime later we began working on the animation frames code from Siggy’s project.  Our goal was to figure out which sprite frames moved in the left versus the right direction. Closer examination of the Sprite Editor “killbot.spr” showed that the right frames occupied values 13-16 and left contained the values 17-20. The code below controls the range of movement between these frames. So we changed it to fit our new animation sequence.

There was still a problem with some of the frames so we examined the code further down for movingLeft to make some new changes.

After an hour and 45 minutes into the video, we started changing the updateAnimation area to reflect the sprite frames updating in the correct order. Earlier we noticed that frames were being skipped, so now we were covering our tracks and patching up this section. Eventually after some trial and error, we got the idle animation working, but were still left with one frame deviating the norm, which involved further evaluation of the code.

We decided to comment out the lines below to see if that would stop the wrong frame from showing up when the sprite was left idle (no controller movement). At this time we were still in the early learning stages of grasping Siggy’s logic and putting into practice.

How to create Sprite Pad Animations

Darren setup Sprite Pad to automatically animate the sprites by individual frames. This is done by clicking on a sprite in the bottom window in clicking on the play (right arrow) button in the editor. To add an additional animation you have to increase the Quantity category to make room for more. This will insert blank spaces in the bottom window. It was set to 32 so I increased it to 35. Next it I selected a range of sprites in the top right. Then also in top window he stated to click the last icon with the description of Send range to Animator. That feeds the sprites frames into the empty square and allows the frames to be set in an increased motion, which resulted in animation.

Our next primary goal was to add in our second overlay sprite. The sprite frame pointers are identified by the variables below.

• SCREEN_MEM $4000 ; Bank 1 screen 0

• SPRITE_POINTER_BASE = SCREEN_MEM _ $3F8 ; last 8 bytes of screen mem

• SPRITE_0_PTR = SPRITE_POINTER_BASE + 0

• SPRITE_0_PTR = SPRITE_POINTER_BASE + 1

• SPRITE_0_PTR = SPRITE_POINTER_BASE + 2

• SPRITE_0_PTR = SPRITE_POINTER_BASE + 3

• SPRITE_0_PTR = SPRITE_POINTER_BASE + 4

• SPRITE_0_PTR = SPRITE_POINTER_BASE + 5

• SPRITE_0_PTR = SPRITE_POINTER_BASE + 6

• SPRITE_0_PTR = SPRITE_POINTER_BASE + 7

After this, we began modifying the sprite pointers that existed before. Darren stated that since we didn’t have a need for SPRITE 1_PTR since it was tied to the running sprite, which gets overwritten since the sprite moves backward and forward at the bottom automatically. On primary focus was to change the data for the top sprite. So commented out some code and added the SPRITE_2_PTR statements below.

Working on the Sprite Overlay

In order to determine the exact placement of the overlay sprite, Darren suggested to enable SPRITE 2. The code below accepts those new changes. The change was made in the binary values from 00000011 to 00000111. This tracks the active display for sprite 2 (counting 3 from the right to left).

We added some more code to the moveUp routine to accommodate for our overlay sprite. This works by setting a table for the sprite x location. I have included the lines for the MoveSpriteUp routine so you can also see what the subroutine jump is doing. Essentially it maps the sprite x table to the correct location.

So all we had to do was add more statements in the moveLeft subroutine. This allows the second (overlay) sprite to occupy the same position as the sprite moved with the controller (the sprite that starts at the top).  We appended new lines in the code to track the movement for right and left movement to position sprite 2 in place.

Our changes resulted in adding a third sprite to the running sprite at the bottom (appearing in blue). We realized our mistake and went back to investigating the code to see where the change the correct code segments to accomplish our goal. However, time constraints preventing us from reaching any milestones beyond this point and we called it a day.