Double Sized Sprites?

[youki]

Hi,

 

so i have figured out my problem with sprites.

 

Now, i have one more question. Is it possible to double size a given sprite and not the other? (reading documentation i 'd say no , but i prefer have confirmation ).

 

Thanks

[Pixelboy]

Hi,

 

so i have figured out my problem with sprites.

 

Now, i have one more question. Is it possible to double size a given sprite and not the other? (reading documentation i 'd say no , but i prefer have confirmation ).

 

Thanks

Nope. It's either all 32x32, or all 16x16, but not both simultaneously. I'm not aware of any commercial CV games that ever used double-sized sprites, but I do know that the SG-1000 game "Girl's Garden" used it in the bonus rounds, so if anyone was to port that game, it would be the first and only CV game to make use of 32x32 sprites.

[youki]

Hi,

 

so i have figured out my problem with sprites.

 

Now, i have one more question. Is it possible to double size a given sprite and not the other? (reading documentation i 'd say no , but i prefer have confirmation ).

 

Thanks

Nope. It's either all 32x32, or all 16x16, but not both simultaneously. I'm not aware of any commercial CV games that ever used double-sized sprites, but I do know that the SG-1000 game "Girl's Garden" used it in the bonus rounds, so if anyone was to port that game, it would be the first and only CV game to make use of 32x32 sprites.

 

 

thanks for your confirmation. I thought i could double size for my ends level' s big bosses!. i wanted to have a big boss counpounded of 4 double sized sprite and using other sprites (not double sized) above it for details. But anyway , it is not a problem if i can i will use more sprites , and if not i will find another solution or my big bosses will be smaller ...

[Pixelboy]

thanks for your confirmation. I thought i could double size for my ends level' s big bosses!. i wanted to have a big boss counpounded of 4 double sized sprite and using other sprites (not double sized) above it for details. But anyway , it is not a problem if i can i will use more sprites , and if not i will find another solution or my big bosses will be smaller ...

I don't know what your "big bosses" will look like or how they will behave on-screen, but have you considered just using background tiles instead of sprites? If you're using screen mode 2, you'd have a greater range of control over pixel colors, but if your bosses move around the screen, you'll have to move them in increments of 8 pixels, which is not such a terrible drawback...

[youki]

thanks for your confirmation. I thought i could double size for my ends level' s big bosses!. i wanted to have a big boss counpounded of 4 double sized sprite and using other sprites (not double sized) above it for details. But anyway , it is not a problem if i can i will use more sprites , and if not i will find another solution or my big bosses will be smaller ...

I don't know what your "big bosses" will look like or how they will behave on-screen, but have you considered just using background tiles instead of sprites? If you're using screen mode 2, you'd have a greater range of control over pixel colors, but if your bosses move around the screen, you'll have to move them in increments of 8 pixels, which is not such a terrible drawback...

 

Yes, i already thought about that. but my bosses need to move smoothly , so i 'd prefer avoid to use chars. And i don't want waste char pattern for monsters and keep it for backgrounds and other elements.

[Gorf]

thanks for your confirmation. I thought i could double size for my ends level' s big bosses!. i wanted to have a big boss counpounded of 4 double sized sprite and using other sprites (not double sized) above it for details. But anyway , it is not a problem if i can i will use more sprites , and if not i will find another solution or my big bosses will be smaller ...

I don't know what your "big bosses" will look like or how they will behave on-screen, but have you considered just using background tiles instead of sprites? If you're using screen mode 2, you'd have a greater range of control over pixel colors, but if your bosses move around the screen, you'll have to move them in increments of 8 pixels, which is not such a terrible drawback...

 

 

This is not at all a horibble way to do it but one other twist...make copies of the boss shifted a pixel or two at a time

to smoothen the animation. I think its one bit per pixel?

 

So what you can do is make 8 bosses, each shifted over one pixel from

the last. Assuming a 256 horizontal screen using 32 characters across:

 

x>>3 = the X position character location

x & 7 = the boss to place onscreen at that position.

 

 

Of course you can skimp and go 2 pixels jumps and save some memory

 

x>>3= the X position character location

(x & 7)>>1 = the boss to place onscreen.

 

I think the later would be fine and you can save yourself 4 bosses worth of memory not to mention

be able to use 16x 16 sprites.

[youki]

thanks for your confirmation. I thought i could double size for my ends level' s big bosses!. i wanted to have a big boss counpounded of 4 double sized sprite and using other sprites (not double sized) above it for details. But anyway , it is not a problem if i can i will use more sprites , and if not i will find another solution or my big bosses will be smaller ...

I don't know what your "big bosses" will look like or how they will behave on-screen, but have you considered just using background tiles instead of sprites? If you're using screen mode 2, you'd have a greater range of control over pixel colors, but if your bosses move around the screen, you'll have to move them in increments of 8 pixels, which is not such a terrible drawback...

 

 

This is not at all a horibble way to do it but one other twist...make copies of the boss shifted a pixel or two at a time

to smoothen the animation. I think its one bit per pixel?

 

So what you can do is make 8 bosses, each shifted over one pixel from

the last. Assuming a 256 horizontal screen using 32 characters across:

 

x>>3 = the X position character location

x & 7 = the boss to place onscreen at that position.

 

 

Of course you can skimp and go 2 pixels jumps and save some memory

 

x>>3= the X position character location

(x & 7)>>1 = the boss to place onscreen.

 

I think the later would be fine and you can save yourself 4 bosses worth of memory not to mention

be able to use 16x 16 sprites.

 

 

I know this technic , i used the same kind of trick to do smooth scrolling in some test i did. But here in my case it would consume too much memory.

My game should have minimum 30 screens (more depending if i still have memory) .

[newcoleco]

30 screens? It's more than the number of screens I did with Miss Space Fury.

[youki]

30 screens? It's more than the number of screens I did with Miss Space Fury.

 

it could be even more, depending if i have free space left at the end.

[Kiwi]

Mr. Do Castle and Defender uses double size sprite I believe.

[Tursi]

So what you can do is make 8 bosses, each shifted over one pixel from the last. Assuming a 256 horizontal screen using 32 characters across:

 

Only thing you have to watch out for here, is that color resolution is still 8 pixels horizontally, so you can only do this if your colors are consistent horizontally (ie: no more than two colors including, unfortunately, the background). Of course, if you're using sprites, that's true anyway.

 

If you have a little time at the beginning of the stage, you could always do the pre-shift in software, so that the ROM stores only one boss image. There's plenty of VDP RAM free in most applications so it's really a time constraint. It's one of the approaches I'm toying with for my own shooter.

 

Technically, the VDP resamples all memory and registers every scanline, so you can change things on the fly - you /could/ have double-size sprites and single-sized sprites on the same screen. However, there's no reliable way to determine WHEN to make the change, and a number of unpredictable timings meant that even if you somehow get the CPU to write the register at exactly the right time, you may still experience a few scanlines of unreliability. So although TECHNICALLY, it can be done, PRACTICALLY there are severe difficulties in doing it.