Easy Player Width

[KevKelley]

I was curious if there was an easy (or simpler) way to adjust a sprite width similar to using player0height rather then creating numerous sprites, each with one less column. 

 

 

[+Karl G]

Nothing that simple, but if you can e.g. set a ball or missile to the background color, you can use it to cover the portion of the sprite that you don't wish to display. 

[KevKelley]

9 hours ago, Karl G said:

Nothing that simple, but if you can e.g. set a ball or missile to the background color, you can use it to cover the portion of the sprite that you don't wish to display. 

Thanks. I had a free moment and was revisiting some ideas I had that involved the sprites moving off screen but I didn't want to shorten the playfield with black bars on the side. 

 

Previously I was playing around with an extra wide sprite and as it moved towards the border I quickly shrunk it's size and then tried to mask it with a ball or missile. 

 

The game idea I was working on didn't really need too much space so I had considered just making several sprites and as it got closer to the border it would just change the sprite but then that got me thinking about player height. 

 

I'll still play around with this. Just figured I'd ask. 

[+SpiceWare]

If you know how to modify the bB kernels its easy to do in assembly, would cost 3 cycles per scan line and a byte of RAM.

 

 

[+Karl G]

40 minutes ago, SpiceWare said:

If you know how to modify the bB kernels its easy to do in assembly, would cost 3 cycles per scan line and a byte of RAM.

 

 

That's pretty cool. I could do such a mod to the standard kernel if anyone wanted this, but since every cycle is spoken for, I'd have to do it at the expense of the corresponding missile. Or - I could probably piggyback it on a kernel option that already requires losing the missile, as there are some spare cycles to be found if you enable the player1colors option.

[KevKelley]

I don't know much about those things (although it would be an eventual goal of mine to learn) but would something like this work with DPC+?

[+SpiceWare]

Easiest to see what's going on if you use binary to define the mask value.  Any mask bit that's a 1 means "show this part of the image" while a 0 means "remove this part of the image". For a sprite moving onscreen from the left and exiting to the right you'd use these mask values:

 

MASK
%00000001 - coming onscreen from the left, only rightmost pixel is shown
%00000011 - coming onscreen from the left, right 2 pixels of sprite are shown
%00000111 - coming onscreen from the left, right 3 pixels of sprite are shown
%00001111 - coming onscreen from the left, right 4 pixels of sprite are shown
%00011111 - coming onscreen from the left, right 5 pixels of sprite are shown
%00111111 - coming onscreen from the left, right 6 pixels of sprite are shown
%01111111 - coming onscreen from the left, right 7 pixels of sprite are shown

%11111111 - fully onscreen, all pixels shown

%11111110 - going offscreen to the right, left 7 pixels of sprite are shown
%11111100 - going offscreen to the right, left 6 pixels of sprite are shown
%11111000 - going offscreen to the right, left 5 pixels of sprite are shown
%11110000 - going offscreen to the right, left 4 pixels of sprite are shown
%11100000 - going offscreen to the right, left 3 pixels of sprite are shown
%11000000 - going offscreen to the right, left 2 pixels of sprite are shown
%10000000 - going offscreen to the right, left 1 pixels of sprite are shown

 

It should be easier to do in DPC+ as the masking would occur when the C routines copy the image data into the datastreams, eliminating the 3 cycle requirement in the time critical kernel. I'm not familiar enough with bB to know how you'd pass the mask values from bB to the C routines.

 

I used this masking technique in the C routines in Space Rocks, Stay Frosty 2, and Draconian. You can see an example of the boss fireball moving onscreen in reply #8.

[+Karl G]

7 hours ago, KevKelley said:

I don't know much about those things (although it would be an eventual goal of mine to learn) but would something like this work with DPC+?

For DPC+, virtual Sprite masking is done for virtual Sprites if you set the appropriate bits in the virtual NUSIZ registers:

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_sprite_masking

 

[KevKelley]

I've probably read RT's site hundreds of times and sometimes I never put two and two together.