More than 32 sprites on 9918/9938

Master (199)

18-12-2020, 05:55

Lately I'm playing with Gameboy development and found this cool trick: they put an interruption on a given screen line (mid screen for example) and then rewrite the sprite attributes table, so new sprites are writen on the bottom half of screen, doubling the number of sprites at same time on screen.

Could it be possible on 9918 / 9938?

I'm not sure if I made myself clear.

Entrar ou registrar-se para comentar

Por Manuel

Ascended (17501)

18-12-2020, 08:36

I think this is done in several V9938 games, but I forgot which. Space manbow comes to mind.

Por thegeps

Paladin (670)

18-12-2020, 11:11

Yep, on 9938 you have hblank. On 9918 you haven't hblank but you can use a trick to have something like: causing a 5th sprite condition at a given y coord and polling status register until it happen. Then rewrite your sprites from that "split" position. You have to use 2 SAT buffers and check them for all of your sprite operations and check both every frame

Por Bengalack

Champion (301)

18-12-2020, 12:20

It works as explained by others here. On 9938 I have 48 sprites in the game mentioned in this thread (using only one SAT though):
https://www.msx.org/forum/msx-talk/general-discussion/i-migh...

The game is still under development, but the sprite handling is done. It may sound like its pretty crowded on screen, but 24 of the sprites are used as masks on the borders to hide horisontal adjust :-)

Por PingPong

Prophet (3623)

18-12-2020, 12:39

C64 coders knows a lot of this trick because of the limited n. Of spritea on screen

Por thegeps

Paladin (670)

18-12-2020, 12:52

Well, Bengalack, you use only one SAT because you don't need to do checks on your multiplexed sprites. You use them only to mask borders

Por thegeps

Paladin (670)

18-12-2020, 12:56

It seem like you said Ping Pong, but I thought one thing: they can have 8 sprites/line, we only 4. Probably our poor VDP has only 4 sprites multiplexed realtime by the VDP itself...

Por PingPong

Prophet (3623)

18-12-2020, 13:49

It is no secret that Vic-ii sprites were copied from the tms ones, trying to improve them.
However 32 sprites on screen without limitations was not easy with the ram bandwidth restrictions on those era.
C64 engineers took another way. In the effort of optimizer things they trued to stuff the sat data into internal registers. However 128 bytes of register data could have been a little too much. So they sacrified the total n. Of sprites by giving in exchange :

Larger sprites and (for free) the ability of multicolor and indipendent zoom. The on chip sat saved a lot of mem fetch cycles etting them available for a third sprite byte to get 24px wide sprites. The limitation of max 8 sprites per scanline is the same of 8 sprites per screen so you do not have to check Which sprites you can display on every scanline. Another n. Of mem cycles saved.

However there is a draw back: the ability to reuse sprites is handled by the cpu and some times you need to sort sprites to know if you can reuse a sprite. This is costly and make life harder to coders

Por mohai

Paladin (911)

18-12-2020, 19:19

thegeps wrote:

It seem like you said Ping Pong, but I thought one thing: they can have 8 sprites/line, we only 4. Probably our poor VDP has only 4 sprites multiplexed realtime by the VDP itself...

Well ... not really.
The limitation is that TMS VDP cannot manage more than 4 sprites per line, due to clock speed and VRAM access.
Keep in mind that every line in screen is "prepared" in the time a border is drawn.

Por thegeps

Paladin (670)

18-12-2020, 19:36

mohai wrote:

thegeps wrote:

It seem like you said Ping Pong, but I thought one thing: they can have 8 sprites/line, we only 4. Probably our poor VDP has only 4 sprites multiplexed realtime by the VDP itself...

Thanks for the explanation. Mine was a speculation I did without any check. Glad to know, now

Por wouter_

Champion (450)

18-12-2020, 20:12

mohai wrote:

Keep in mind that every line in screen is "prepared" in the time a border is drawn.

Small correction (detail). There's not enough time in the border to fetch all data required to draw the sprites. Instead this data is fetched during most of the previous line. You can find more details in this article, more specifically in this diagram.