Stupid question about zero padding around sprites

[ForceInfinity]

So I was reverse engineering Vanguard and noticed that they were zero padding a bunch of lines above the player sprite.  I'm assuming from when I was looking at the code that they used the scanline (Y register) along with RAM 84 indirect basically draw the sprite at the correct point in time.  Many of the enemies seem to have 14 byte gaps between the graphics as well and it seems like it's a waste of ROM.  Was this common practice?   I'm presuming they did it this way to preserve a register, but still learning the ropes.  

 

Still bugs me to this day that they couldn't have figured out a way to assemble at least a passable sprite object for the Gond in the city of mystery.    I also had a couple  of other little tricks I wanted to try with the game once I have a better grasp on how its RAM is getting used and how the main game loop behaves

[azure]

On 9/18/2019 at 1:39 AM, ForceInfinity said:

Many of the enemies seem to have 14 byte gaps between the graphics as well and it seems like it's a waste of ROM.

The sprites use blank space above and below their graphics, because it saves cycles on vertical positioning. It lets you move calculations from inside the kernel to outside the kernel, because Y maps directly onto the sprite graphics. It's a trade off between ROM and CPU cycles. As far as I know, it's a commonly known technique. If you look at the HMOVE lines on the left it reveals where the game splits the screen into multiple horizontal bands where the ships reside in. When the enemy ship does its wiggle, it takes up two bands.

 

On 9/18/2019 at 1:39 AM, ForceInfinity said:

Still bugs me to this day that they couldn't have figured out a way to assemble at least a passable sprite object for the Gond in the city of mystery.

I think a better Gond could have been made using player graphics, but I don't know the context the game was developed under. I think the most likely explanation is Dave ran out of ROM space. Looking at the ROM as a hex dump, I don't see much blank space other than the buffers between sprites, which was required for using this render technique. These are the trade offs 2600 developers had to make. You can't have everything. It's why the platform is so interesting.

[Rastignac]

Vanguard's final boss is lame: one hit and he's dead. It would have been far better to have a longer and more challeging boss battle, wiith multiple hits needed, while dodging his attacks.

[ForceInfinity]

azure  (greetings from another fellow Puget Sound resident),

 

Thanks for taking the time to reply.  Despite being a software engineer, when you've done nothing but higher level languages all your career, when you step into assembly as a newbie and try to reverse engineer something for the Atari... Well it's been an interesting endeavor.   

 

Part of the challenge is trying to map out what is going on in memory.   So far the only area of RAM I've not fully accounted for with some measure of confidence:

9A - 9F

AF - B9

C5

C7 - E9

F6

 

There were a couple of things I would've loved to have done with this game, which would be pretty tricky to do with the available RAM space.  20 bytes for the lower horizontal scroll, 18 for the upper, 6 for the two player scores, another 6 for the player score sprite pointers, 6 for stack space, and that's nearly half the RAM out the window.

 

The other interesting insight was that the enemy bullets are using the Ball graphic (which is why the bullets tend to take on the color of the landscape color layer)

 

One of the things I do want to see if its possible to do is hack the game to do the City of Mystery the way that's closer to the arcade; first to make it harder to get that shot through to the Gond; maybe seeing if its possible to use two GRP1 graphics that are horizontal lines with a gap.  The sprite size would be set to maybe 4x and use LSR and LSL operations to scroll the openings.

The final part would be far more tricky and that's to do the bottom barriers in the same way the arcade did, and with RAM space being at a premium, I may have to use lookups in ROM to pull that trick off (and that may likely mean trying to do this game in a 16kb space rather than the current 8kb)

It is fun trying to dig into the mind of the engineer, because I can already see that in some ways, he had to devise some pretty clever tricks and some strategic byte packing to pull this game off.  

 

 

PS - regarding the boss being too trivial, I can say that in the arcade, the city of mystery was also pretty trivial if you're ready for it and you're centered on the screen as the Gond is scrolling in.  If you're mashing that up button, you'll take him out almost immediately.  

 

Edited September 20, 2019 by ForceInfinity

[+SpiceWare]

Not a stupid question - it makes it possible to do more TIA updates in the kernel, resulting in better visuals for the game.

 

A typical draw sprite routine would be something like this:

  lda #SPRITEHEIGHT
  dcp SpriteTemp
  bcs DoDraw
  lda #0
  .byte $2C
DoDraw
  lda (GfxPtr),Y
  sta GRP0  ;+18 cycles

 

which takes 18 cycles. If you're drawing two players with single-line resolution, as is done in Vanguard, you'd use 36 cycles which leaves just 40 cycles on the scanline for everything else.  For Vanguard that'd be the scrolling playfield, playfield color changes, lots of shots flying around, etc. which is not enough.

 

By doing this:

  lda (gfxply1),y  ;5
  tax              ;2  7
  lda (gfxply0),Y  ;5 12
  sta GRP0         ;3 15
  stx GRP1         ;3 18

 

the time required to draw both players is cut in half, leaving more time for other things.