Forums

I very much like the idea that everything is possible on an SMS, and that programmers should be on the lookout for ways to push the machine to its limits and beyond.

Still I often contemplate what it would imply to go with the grain (correct english?) of the SMS video hardware. In other words - what kind(s) of game(s) the vdp is specially well-suited to pull of. These considerations are in line with the sprite limitation discussions here: http://www.smspower.org/forums/15251-BubbleBobbleBadGraphicalDevelopmentDecisions and here: http://www.smspower.org/forums/15044-WorkingAroundTheSpriteLimitationsLookingForBestPracticeCases

I hereby claim that the SMS is made for vertical scrolling shoot 'em ups:

1. Vertical scrolling directly supported by the vdp.

2. Nice big area for scoring and status with the vertical scroll lock bit.

3. Large area for setting up new tiles below the screen, ready to scroll into the visible part of the screen. Dimensioned for 2x2 meta tiles.

4. When the bullets and other sprites line up vertically, they are not pushing the horizontal sprite limit. In theory you can have all the sprites in use, and still carefully plan the action so that sprite overflow is avoided, or at leat reduced drastically.

What do you think?

I came to the same answer a couple days ago, but the question was slightly different. Not 'what the SMS is made for' but 'given its features, which kind of games are less likely to find big limits?'.
The answer (or one good answer) of course is vertical scrollers, right because of the very same considerations you made about hardware scroll (which is available both directions) scroll lock (again both directions) and sprite limit on a scanline (which is a horizontal limit).

Anyway I would have loved to have a chance to lock a part of the screen ( the first 16 scanlines for instance) both horizontally and vertically. Given that the VPD can scroll both directions, I believe they didn't think anyone would use both scrolling together. Or they just decided it was too difficult or not worthy to lock both dirs.

In the game-techdemo I will post to this year competition you'll see I had to emulate such a feature using horizontal hardware scroll lock and vertical software 'unscroll'...

hang-on wrote

I hereby claim that the SMS is made for vertical scrolling shoot 'em ups:

It isn't. Because of this feature:
If the Y coordinate is set to $D0, then the sprite in question and all
remaining sprites of the 64 available will not be drawn.

Minor issue. But annoying. ;)

Vertical scrolling games can't take advantage of segmented scrolling via the horizontal line interrupt. Some special effects that are easy for horizontal games are difficult for vertical scrolling games. Having segments of the screen scroll at different rates to create the illusion of depth, say in a cave, or changing the horizontal scroll every scan line to make a wavy background like a rolling fire. You could re-write tile data to achieve a similar effect vertically, but it would be more work for the system.

You could put your TV on it's side...

Thanks for the feedback, guys! I'm entering a shoot 'em up phase in my life right now... That is, my screen-life, of course :)

hang-on wrote

I'm entering a shoot 'em up phase in my life right now... That is, my screen-life, of course :)

If you need inspiration, look no further than here. Most of the entries on that list are of the modern bullet hell variety while the SMS is quite certainly better suited to a more old-school approach.

Zipper wrote

It isn't. Because of this feature:
If the Y coordinate is set to $D0, then the sprite in question and all
remaining sprites of the 64 available will not be drawn.

You need to do sprite clipping anyway so I don't see the point...

dragonfeet wrote

... changing the horizontal scroll every scan line to make a wavy background like a rolling fire.

You can do this too while scrolling vertically :)

Kagesan wrote

If you need inspiration, look no further than here. Most of the entries on that list are of the modern bullet hell variety while the SMS is quite certainly better suited to a more old-school approach.

:) I have already been watching Garegga and Touhou project on youtube. Great list for further inspiration.

The Nes-guys have touched upon a similar topic: http://wiki.nesdev.com/w/index.php/Limitations

By the way: What is sprite clipping?

hang-on wrote

What is sprite clipping?

There is a bit in a register on the NES PPU where you can turn on and off "sprite clipping". It prevents sprites from appearing in the left most 8-pixel column of the screen. I guess it's so a sprite doesn't appear half on one side of the screen and half on the other side? You can also turn off displaying the left most 8-pixel column of the background ("background clipping").

The SMS VDP has bits in register $00 that perform "sprite clipping" and "background clipping", as described above.
http://www.smspower.org/Development/VDPRegisters

Sprite Clipping is there because an X-coordinate of 0 makes the sprite hug the left edge of the screen, while an X-coord of -1 makes it hang just on the right edge of the screen.

There is thus no way to make a sprite gradually come on-screen from the left; it just "pops" into position.

Sprite Clipping on the left column hides this popping.

Thanks for the clarification. I was not aware that it was called sprite clipping. I use the left column blanking technique in my Blockquest homebrew.

With horizontal scrolling games, we can use the vdp control bits to help cater to sprite clipping. But what about vertical scrolling games? Will a sprite with a vertical position of i.e. 254' wrap around' and thus smoothly appear on the top of the screen? It seems wrong to have vertical values completely outside the screen...

Edit: Silly me. Of course it will appear smoothly. Good night :)

uhm... well, actually saying 'sprite clipping' I simply meant 'not using any hardware sprite that would result completely offscreen (thus invisible)'...

when you convert your objects 'real world' coordinates into screen coordinates for your sprites, you can have some not in the "expected range". The problem is that say you've got an object which would generate a sprite at (280,20)... if you don't 'clip' the sprite you'll place it at (24,20) instead...

so I was saying that you have to perform clipping anyway.

Depending on the game, the sprite entity might be killed off once it was offscreen anyway. Certainly you would want to skip offscreen sprites (or rather, tiles within larger sprites) in your sprite table building code, rather than trying to use the sprite table directly and not being able to leave gaps.

I was objecting to Zipper's consideration

Quote

If the Y coordinate is set to $D0, then the sprite in question and all
remaining sprites of the 64 available will not be drawn.
Minor issue. But annoying. ;)

that if you perform clipping (and you should, to avoid what I said before) then this isn't surely a problem, you just shouldn't have any sprite at Y=208...

hang-on wrote

The Nes-guys have touched upon a similar topic: http://wiki.nesdev.com/w/index.php/Limitations

Very interesting reading, and almost everything applies to SMS too :)

sverx wrote

I was objecting to Zipper's consideration

Quote

If the Y coordinate is set to $D0, then the sprite in question and all
remaining sprites of the 64 available will not be drawn.
Minor issue. But annoying. ;)

that if you perform clipping (and you should, to avoid what I said before) then this isn't surely a problem, you just shouldn't have any sprite at Y=208...

Haha - this thread has made me realize my wrongdoings in my current project. I have 32 hardware sprites that travel vertically, and I treat them like they would wrap around with no problem. They sure seem to do this, but from time to time I experienced what I thought were graphic glitches due to sprite overdraw (overflow?) on some of the other sprites. I fixed it by rearranging the sprites in the sprite attribute table (thus changing sprite priority), but I'm sure the real problem is that some of these vertically travelling sprites sometimes hit the $d0 vertical position, and thus turns off all the remaining sprites... You live and learn.

Author	Message
hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	The SMS is meant for vertical scrolling shoot 'em ups! Posted: Sat Mar 07, 2015 10:53 am
	I very much like the idea that everything is possible on an SMS, and that programmers should be on the lookout for ways to push the machine to its limits and beyond. Still I often contemplate what it would imply to go with the grain (correct english?) of the SMS video hardware. In other words - what kind(s) of game(s) the vdp is specially well-suited to pull of. These considerations are in line with the sprite limitation discussions here: http://www.smspower.org/forums/15251-BubbleBobbleBadGraphicalDevelopmentDecisions and here: http://www.smspower.org/forums/15044-WorkingAroundTheSpriteLimitationsLookingForBestPracticeCases I hereby claim that the SMS is made for vertical scrolling shoot 'em ups: 1. Vertical scrolling directly supported by the vdp. 2. Nice big area for scoring and status with the vertical scroll lock bit. 3. Large area for setting up new tiles below the screen, ready to scroll into the visible part of the screen. Dimensioned for 2x2 meta tiles. 4. When the bullets and other sprites line up vertically, they are not pushing the horizontal sprite limit. In theory you can have all the sprites in use, and still carefully plan the action so that sprite overflow is avoided, or at leat reduced drastically. What do you think?

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Sat Mar 07, 2015 11:46 am
	I came to the same answer a couple days ago, but the question was slightly different. Not 'what the SMS is made for' but 'given its features, which kind of games are less likely to find big limits?'. The answer (or one good answer) of course is vertical scrollers, right because of the very same considerations you made about hardware scroll (which is available both directions) scroll lock (again both directions) and sprite limit on a scanline (which is a horizontal limit). Anyway I would have loved to have a chance to lock a part of the screen ( the first 16 scanlines for instance) both horizontally and vertically. Given that the VPD can scroll both directions, I believe they didn't think anyone would use both scrolling together. Or they just decided it was too difficult or not worthy to lock both dirs. In the game-techdemo I will post to this year competition you'll see I had to emulate such a feature using horizontal hardware scroll lock and vertical software 'unscroll'...

Zipper Joined: 06 Apr 2011 Posts: 250 Location: Netherlands	Posted: Sat Mar 07, 2015 12:09 pm
	hang-on wrote I hereby claim that the SMS is made for vertical scrolling shoot 'em ups: It isn't. Because of this feature: If the Y coordinate is set to $D0, then the sprite in question and all remaining sprites of the 64 available will not be drawn. Minor issue. But annoying. ;)

dragonfeet Joined: 08 Oct 2012 Posts: 108 Location: Colmar PA, United States	Posted: Sat Mar 07, 2015 12:24 pm
	Vertical scrolling games can't take advantage of segmented scrolling via the horizontal line interrupt. Some special effects that are easy for horizontal games are difficult for vertical scrolling games. Having segments of the screen scroll at different rates to create the illusion of depth, say in a cave, or changing the horizontal scroll every scan line to make a wavy background like a rolling fire. You could re-write tile data to achieve a similar effect vertically, but it would be more work for the system. You could put your TV on it's side...

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Sat Mar 07, 2015 9:26 pm
	Thanks for the feedback, guys! I'm entering a shoot 'em up phase in my life right now... That is, my screen-life, of course :)

Kagesan Joined: 01 Feb 2014 Posts: 877	Posted: Sun Mar 08, 2015 10:46 am
Kagesan Joined: 01 Feb 2014 Posts: 877	hang-on wrote I'm entering a shoot 'em up phase in my life right now... That is, my screen-life, of course :) If you need inspiration, look no further than here. Most of the entries on that list are of the modern bullet hell variety while the SMS is quite certainly better suited to a more old-school approach.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Sun Mar 08, 2015 11:39 am
	Zipper wrote It isn't. Because of this feature: If the Y coordinate is set to $D0, then the sprite in question and all remaining sprites of the 64 available will not be drawn. You need to do sprite clipping anyway so I don't see the point...

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Sun Mar 08, 2015 11:41 am
	dragonfeet wrote ... changing the horizontal scroll every scan line to make a wavy background like a rolling fire. You can do this too while scrolling vertically :)

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Sun Mar 08, 2015 11:48 am
	Kagesan wrote If you need inspiration, look no further than here. Most of the entries on that list are of the modern bullet hell variety while the SMS is quite certainly better suited to a more old-school approach. :) I have already been watching Garegga and Touhou project on youtube. Great list for further inspiration.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Wed Mar 11, 2015 7:22 pm Last edited by hang-on on Wed Mar 11, 2015 10:58 pm; edited 1 time in total
	The Nes-guys have touched upon a similar topic: http://wiki.nesdev.com/w/index.php/Limitations By the way: What is sprite clipping?

dragonfeet Joined: 08 Oct 2012 Posts: 108 Location: Colmar PA, United States	Posted: Wed Mar 11, 2015 10:05 pm
	hang-on wrote What is sprite clipping? There is a bit in a register on the NES PPU where you can turn on and off "sprite clipping". It prevents sprites from appearing in the left most 8-pixel column of the screen. I guess it's so a sprite doesn't appear half on one side of the screen and half on the other side? You can also turn off displaying the left most 8-pixel column of the background ("background clipping"). The SMS VDP has bits in register $00 that perform "sprite clipping" and "background clipping", as described above. http://www.smspower.org/Development/VDPRegisters

ccovell Joined: 26 Dec 2004 Posts: 374 Location: Japan	Posted: Wed Mar 11, 2015 10:39 pm
ccovell Joined: 26 Dec 2004 Posts: 374 Location: Japan	Sprite Clipping is there because an X-coordinate of 0 makes the sprite hug the left edge of the screen, while an X-coord of -1 makes it hang just on the right edge of the screen. There is thus no way to make a sprite gradually come on-screen from the left; it just "pops" into position. Sprite Clipping on the left column hides this popping.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Wed Mar 11, 2015 10:53 pm
	Thanks for the clarification. I was not aware that it was called sprite clipping. I use the left column blanking technique in my Blockquest homebrew. With horizontal scrolling games, we can use the vdp control bits to help cater to sprite clipping. But what about vertical scrolling games? Will a sprite with a vertical position of i.e. 254' wrap around' and thus smoothly appear on the top of the screen? It seems wrong to have vertical values completely outside the screen... Edit: Silly me. Of course it will appear smoothly. Good night :)

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Thu Mar 12, 2015 9:07 am
	uhm... well, actually saying 'sprite clipping' I simply meant 'not using any hardware sprite that would result completely offscreen (thus invisible)'... when you convert your objects 'real world' coordinates into screen coordinates for your sprites, you can have some not in the "expected range". The problem is that say you've got an object which would generate a sprite at (280,20)... if you don't 'clip' the sprite you'll place it at (24,20) instead... so I was saying that you have to perform clipping anyway.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Thu Mar 12, 2015 9:13 am
	Depending on the game, the sprite entity might be killed off once it was offscreen anyway. Certainly you would want to skip offscreen sprites (or rather, tiles within larger sprites) in your sprite table building code, rather than trying to use the sprite table directly and not being able to leave gaps.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Thu Mar 12, 2015 9:47 am
	I was objecting to Zipper's consideration Quote If the Y coordinate is set to $D0, then the sprite in question and all remaining sprites of the 64 available will not be drawn. Minor issue. But annoying. ;) that if you perform clipping (and you should, to avoid what I said before) then this isn't surely a problem, you just shouldn't have any sprite at Y=208...

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Thu Mar 12, 2015 10:37 am
	hang-on wrote The Nes-guys have touched upon a similar topic: http://wiki.nesdev.com/w/index.php/Limitations Very interesting reading, and almost everything applies to SMS too :)

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Thu Mar 12, 2015 1:07 pm
	sverx wrote I was objecting to Zipper's consideration Quote If the Y coordinate is set to $D0, then the sprite in question and all remaining sprites of the 64 available will not be drawn. Minor issue. But annoying. ;) that if you perform clipping (and you should, to avoid what I said before) then this isn't surely a problem, you just shouldn't have any sprite at Y=208... Haha - this thread has made me realize my wrongdoings in my current project. I have 32 hardware sprites that travel vertically, and I treat them like they would wrap around with no problem. They sure seem to do this, but from time to time I experienced what I thought were graphic glitches due to sprite overdraw (overflow?) on some of the other sprites. I fixed it by rearranging the sprites in the sprite attribute table (thus changing sprite priority), but I'm sure the real problem is that some of these vertically travelling sprites sometimes hit the $d0 vertical position, and thus turns off all the remaining sprites... You live and learn.

Forums

View topic - The SMS is meant for vertical scrolling shoot 'em ups!