Commander X16

Are sprites scalable? Or do they have to be displayed in their native resolution? What does a 16×16 sprite look like when scaled to 3x? Is it ridiculously pixelated, or can careful design mitigate the problem?

VERA scaling is done for the whole display, not just for a layer or sprite. The current sprite dimensions go up to 64x64, so if you want something bigger, use more sprites. You have 128! And if you want 16x48, you can make the sprite 16x64 and have empty space on the vertical margins. Sprite asset addresses must be aligned to 32-byte blocks, but you can use some of this margin area to have overlapping sprites. A 4bpp 16x48 sprite means you have a total margin of 256 bytes within a 16x64 bitmap. Split that in half, and you can have 128 byte margins between each sprite, which means 8 rows of transparent pixels at 4bpp. The alignment still works because 128 % 32 == 0. So you're only "wasting" half of the VRAM that you're fearing, and it's only 128 bytes per sprite for 4bpp.

On 10/5/2022 at 6:58 AM, SlithyMatt said:

Sprite asset addresses must be aligned to 32-byte blocks, but you can use some of this margin area to have overlapping sprites.

Excellent point, I haven't thought of that! This means we have a virtual 64x48 dimension so for 8bpp it's 3072 bytes instead of 2304. So 768 bytes would be "wasted" compared to a 48x48 dimension. I think that's a good compromise.

On 10/5/2022 at 12:58 AM, SlithyMatt said:

... And if you want 16x48, you can make the sprite 16x64 and have empty space on the vertical margins. ...

Also, if VRAM is very tight, if you can design a 48x48 asset so that the top left hand and right hand 8 wide by 16 high is empty, it can be composed of one 32x32, one 16x32 to complete the base, and one 32x16 to fill out the top. Indeed, part of the visual story telling here might be that most of your antagonist characters are designed to fit into 16x16 sprites, and you have faced bosses that fit into 32x32 sprites, but now you are facing a "super boss", who visually fills even more of the screen ... so the top 48x16 space could well be a 16x16 head of a character sprite, saving even more space. Or you've faced a series of 16x16 fighter ships, and some 32x16 space frigates, and now you are facing the space destroyer ... where, again, it doesn't have to occupy all the extremes of a box to be visually bigger, and you have the  top and bottom of the "drive tail" as 16x16 sprites above and below the "back" edge of a 64x16 rectangular sprite. It's the size to fit into a single 64x48 asset, but since it's long and sleek with a tall tail, there's two 48x16 rectangles that are empty space and simply not required to be defined as part of the set of sprites that make up the asset.

On 10/4/2022 at 4:34 PM, Fabio said:

I agree with @ZeroByte if we could add a flag to upscale a sprite the sprite best suited to be upscaled is the 32 bit one.



I have a thought : looking at the sprite registers: is anyone using the palette offset at its full potentiality? maybe we could have 3 bits for sprite width and height such as



8 12 16 24 32 48 64 (7 in total) and still have 2 bits of palette offset to display the same sprite in  4 different hues.

Sprites only come in 4bpp and 8bpp color depths. Palette offset is essentially meaningless in 8bpp mode (although it does affect the colors, and I'm sure there's some clever schema in arranging the palette and sprite assets to get some kind of effect from it, but that's going into mad science / demoscene territory). The palette offset value is designed such that you should think of the master palette as being divided into 16 different 16-color palettes. Palette offset selects which of these 16 palettes a 4bpp asset uses. I.e. palette_offset = row, pixel value = column.

 

On 10/5/2022 at 1:48 PM, ZeroByte said:

Sprites only come in 4bpp and 8bpp color depths. Palette offset is essentially meaningless in 8bpp mode (although it does affect the colors, and I'm sure there's some clever schema in arranging the palette and sprite assets to get some kind of effect from it, but that's going into mad science / demoscene territory). The palette offset value is designed such that you should think of the master palette as being divided into 16 different 16-color palettes. Palette offset selects which of these 16 palettes a 4bpp asset uses. I.e. palette_offset = row, pixel value = column.

One really cool palette offset effects at 4bpp would be some colors are repeated in the base palette and then they progressive change as a sprite "takes on damage". Another would be cycling through a sequence of palettes to "reflect the light" at greater and less intensity when there is an explosion toward the front side of a sprite.

Then a possible solution is to draw an enemy in the upper part of the 64*64 sprite and another in the lower part: of another 64*64 sprite and to overlap the tail of sprite 1 on the head of sprite 2.

Still we could consider this solution.

orizzontal width 8 16 32 48

vertical height 8 16 32 64

with this arrangement if 48*48 is needed I can overlap the sprites while if 64*64 is needed i can align two 32*64 sprites.

does it sound like a good compromise?

Hi Everyone, sorry I haven't responded in a bit. I've been letting this gel in my brain a bit.

If this were to become part of VERA, the extra sprite height/width bits would need to go in byte 5 of the sprite attribute structure. Making the VERA change to have this feature doesn't look like it will be difficult. For this to have a chance of getting seriously considered however, I need some sort of demo program that sets the new bits and renders 24- and 48-pixel wide/tall sprites in 4 and 8 bpp color. For practical reasons, the best place for this speculative feature development to happen is on Discord. I don't mind discussing the results here, but the development cycle when prototyping new candidate features needs a collaboration environment with lower latency. Ping me over on the Hardware / Video channel and we can discuss what a demo/proof of concept for this should look like.

(Standard disclaimer: I haven't promised anybody a pony; I'm not saying this definitely will be a thing, just that we will have to establish the risk is low and it doesn't burn too many of our remaining gates.)

I will contact you on discord @Wavicle.

On 10/6/2022 at 2:55 PM, Wavicle said:

Hi Everyone, sorry I haven't responded in a bit. I've been letting this gel in my brain a bit.



If this were to become part of VERA, the extra sprite height/width bits would need to go in byte 5 of the sprite attribute structure. Making the VERA change to have this feature doesn't look like it will be difficult. For this to have a chance of getting seriously considered however, I need some sort of demo program that sets the new bits and renders 24- and 48-pixel wide/tall sprites in 4 and 8 bpp color. For practical reasons, the best place for this speculative feature development to happen is on Discord. I don't mind discussing the results here, but the development cycle when prototyping new candidate features needs a collaboration environment with lower latency. Ping me over on the Hardware / Video channel and we can discuss what a demo/proof of concept for this should look like.



(Standard disclaimer: I haven't promised anybody a pony; I'm not saying this definitely will be a thing, just that we will have to establish the risk is low and it doesn't burn too many of our remaining gates.)

Waidaminute, 24 bits? Now THAT is intriguing. There's only so many of the bigger assets that you want or need to have on screen at the same time, so cobbling 48 bits out of squares and rectangles with 32 and 16 bits is fine, but an 8 / 16 / 24 / 32 ladder, that's interesting.

Good luck all.