Forums

Hi guys,

I know that the sms VDP1 have an issue displaying zoomed sprites, somebody know if in theory is possible fix this issue using software tricks and get all the 8 sprites zoomed horizontally and vertically such as the sms VDP2 does?

In fact I wish zoomed sprites only horizontally as charles McDonald did sometime with a demo cake for one Bock´s birthday (working in the sms2) . Could be cool to use this feature in my demos for avoid sprite flicker and do my demo compatible with the sms 1 and sms 2 machines...possible?
Can somebody help me with this question?

Thank you very much beforehand.

maxxfarras

Due to the way the sprite fetching works, you cannot really do anything to increase the sprite limit over 8. Sprite tile patterns are fetched before the line they are on is actually drawn, so you can't change the sprite tile pattern OR the Xpos once it has been fetched.

The zoom feature is likely a broken hardware bug in the VDP1 and as such will never be fixed. You can however make sprites only zoomed horizontally, by playing around with the sprite table and changing the Y position in increments of 1 as you draw it to avoid getting the vertical doubled. There is a gamegear game which does this.

ie. Say on line 10 you want a sprite drawn, so its YPOS is set to 9 in the SAT. After it has fetched the sprite on line 9 to be drawn on line 10, you decrease its Ypos by 1, this way on line 10 when it is fetching the sprite it will use the actual second line of sprite data rather than the first line doubled up. You repeat this 7 times and you will have a horizontally only zoomed sprite.

If you time this correctly, you will be able to update all 8 sprites in a similar manner if they are all after one another in the SAT (using the VDP autoincrement to avoid address changes), it will take ~208 z80 cycles in this case.

It is somewhat limiting if you can't order sprites, or if you can't assume certain things about the sprites. It would be easy to do such things for a demo, but having 64 onscreen sprites all zoomed only horizontally in some kind of "game type" way would be very hard!

Of course, since the VDP1 only allows the first 4 sprites to be zoomed horizontally you will have to target the VDP2.

thanks for you reply PoorAussie,
I was afraid of some answer like that...so do you have any other idea for show /simulate more sprites in a scanline without flicker...??
(using the hardware sprites)

or any suggestions?

Thanks again

The best way in my opinion to simulate more sprites on the SMS is to use background manipulation.

Simply have unique tiles where these "background sprites" can move, and write/rewrite the tiles to show sprites moving. In this manner you can have as many objects as the CPU/VDP will allow you to update.

If an object you want to move is say 16x32 pixels you need to write 256 bytes to show it. So you need to factor in the time needed to work out which tiles/pixels to update in the BG tiles, the time needed to erase where the object was before, etc.

I think you could maybe update 16-32 extra 8x8 "sprites" per frame (all of which could appear on same line as there is no "Line limitation" as such with this method). This would limit the amount of VDP updating you could do for other things though,so you would need to manage the CPU/VDP budget accordingly. The other issue would be sprite priority, you could possibly work in a system which automatically handled the priority system and put sprites into the hardware sprite system or software BG sprite system depending upon their priorities, but then you would need the palettes to match also. Devising a system which uses say "special effects" or "bullets" for the BG sprites and keep the hardware sprites for main objects might be a compromise.

Another "cheap" method older SG1000 type games used for scrolling was to store all the combinations an object could move on a tile in VRAM and simply switch tiles according to the position. Usually this limits you in color choices and sprite sizes though.

If I choose to use background manipulation for moving "software sprites", I think that it means that I must create a mask system via software and I must use the same 16 color palette that the background uses for the "software sprites" That could be mean too much cpu consumming time,
Im correct?
Or there exists other better optimal way?
(for avoid that ugly squares around the "sprites").
Which do you think that could be the fastest way for create this software mask?, I mean, if I must do it for avoid deformation.

Thx for your help

maxxfarras wrote

If I choose to use background manipulation for moving "software sprites", I think that it means that I must create a mask system via software and I must use the same 16 color palette that the background uses for the "software sprites" That could be mean too much cpu consumming time,
Im correct?
Or there exists other better optimal way?
(for avoid that ugly squares around the "sprites").
Which do you think that could be the fastest way for create this software mask?, I mean, if I must do it for avoid deformation.

Thx for your help

Well you need to loop through every pixel to be written, test if opaque , if opaque send it to the VDP. Then next frame you need to clean up your writes, you could do this with a blanket update of the tiles touched, mark them as dirty and simply reupload them. Then you repeat the process.

In the worst case, a single 8x8 software sprite can make 4 tiles dirty, so this means a budget of writing out 4 tiles for each 8x8 software sprite, to clean it up, then writing another tile worth of data to display it. 5 tiles is 160 bytes. When writing out the opaque pixels it would also then mean you need to set the VDP address whenever appropriate. You could avoid this by ensuring any software sprites had no transparent pixels, or simply had no "broken runs" of pixels (eg a rounded bullet). There are likely better ways to do it, more optimizations you can make in certain cases, I haven't really thought about it until now.

You're going to be making compromises either way, but you do have about ~1800 bytes in PAL to write out in the non active parts of the screen if you use OUTI blocks. If you used the active portion to be readying your sprites you would have plenty of time to be writing out blocks of VDP data for these sprites. You could also reduce the vertical resolution by blanking the display for more update time. ie Make it a widescreen display 256x144

The absolute fastest way would be to have precomputed tiles for every possible sprite position over every background tile, but that would be extremely restrictive in terms of how much you could display.

There are various ways you could try to speed up the tile rendering but the bottleneck will be the writing to VRAM.

How important is it to have more than 8 sprites on the scanline? How important is real-system compatibility to you?

Quote

Maxim said:

How important is it to have more than 8 sprites on the scanline? How important is real-system compatibility to you?

Real system compatibility is very important for me because I could wish that in a future my demos/games pushes the system´s limitationes :) Or at least try it.

Respect to your first question, I always asked me if there is some way of "broke" the 8 sprite limitation of some way, for in game sprites, and create some enhancement .
One option is given for Poor Aussie: background manipulation.

When I readed the Charles next statement, I thought that other option is possible, but Im not sure if I understand it correctly:
What do you think about the follow quote that Charles McDonal wrote?:

Quote

When the sprite table is changed during a scanline, the VDP starts buffering Y positions from the new table so you get a mix of the two. Visually this looks like the sprites are misplaced.

I don't think the register write can be accurately timed to prevent this. If you want to show 128 sprites (alternating per scanline) the latter 64 need to have the same Y position as the first 64. The X position and tile number can be changed freely as those are read and used during the rendering phase on the next line.

Please tell me if I missundertood the Charles McDonald statement, as I interpret Charles information I been thinking that instead of 16 sprites with flicker in a scanline you could get "16 interlaced sprites" without flicker, for switch the sprite atribute table in each scanline ...possible? the problem could be that sprites appearing interlaced and the background could be vissible trough them, but do you think that is possible? or I missanderstood the Charles quote?

Thanks guys

maxxfarras wrote

Please tell me if I missundertood the Charles McDonald statement, as I interpret Charles information I been thinking that instead of 16 sprites with flicker in a scanline you could get "16 interlaced sprites" without flicker, for switch the sprite atribute table in each scanline ...possible? the problem could be that sprites appearing interlaced and the background could be vissible trough them, but do you think that is possible? or I missanderstood the Charles quote?

Thanks guys

You have misunderstood charles. The VDP has 8 internal registers which are ~40bits or so. Every line after active display the VDP tries to fill these 8 internal registers with sprite information so they can be displayed on the next line. You can determine what gets put into these 8 slots by playing with the SAT or the registers affecting sprites (like charles was doing) but you will never be able to increase the sprites to over 8 simply because there are only 8 slots to be filled, nothing more nothing less.

Sorry, I suppose I dont explain me very well, my english is crap.
I know that is only possible to show a maxim of 8 sprites in a scanline, however you could be alternate by scanline two sprite tables, with inverse order each respect to the another just as for get the flicker effect except that switching in each scanline the sprite table.

I told this because I just check the following program that charles wrote with my tototek (in a real sms1) and creates the illusion of 16 sprites horizontally! with no flicker! (even with the drawback that the sprites look as "interlaced")

(after that you turn on the console, you must press sometimes pause in the console for get the correct effect! )
My question is now that if is possible get that effect for "in game sprites" or there exists some obstruction for that, I think for the Charles comments that it is possible, if not is possible thanks again for help me to clear my confusion, sorry, I just still asking because Im trying to understand :)
Thanks for be so patient.

The Charles McDonald´s program is

Sprite Multiplex Demo (03012005) by Charles MacDonald (PD).zip (2.26 KB)

I think Charles' comment was saying that because the next 8 sprites' data is fetched during the scanline, writing directly to the sprite table means the data it reads may be half updated.

The multiplexing demo works by having two sprite tables in VRAM and changing the sprite table pointer register (register 5), giving an interlaced view of two sprite sets, which themselves are only updated during the VBlank. Maybe if you switched which table got the even/odd lines every frame it would look more like 16 x 50% (flickering) transparent sprites. You'd still get odd effects where sprites within each table would occlude each other (with index-based priority) but sprites in separate tables would sort of "blend".

Maxim wrote

I think Charles' comment was saying that because the next 8 sprites' data is fetched during the scanline, writing directly to the sprite table means the data it reads may be half updated.

This is correct. There is nothing you can do to increase the sprite limit, and the demo I wrote just changes the sprite table address in VRAM. If you change tables at 60Hz the flicker isn't so bad, but you still never really have more than 8 sprites per scanline. You can never get around that. If you run the demo in an emulator and pause it or advance frame-by-frame you will see that there are always 8 sprites shown at the very most.

The Bock's Birthday demo used the same technique. Because zoomed sprites are twice as big, I switched the sprite tile set on every scanline so the first row of zoomed pixels used graphics from one set of tiles, and the second row of zoomed pixels used graphics from another set. This gives the illusion that a 8x16 zoomed sprite has a resolution of 8x32. Again if you pause that demo and look at the individual frames the sprites are really 8x16 zoomed.

As PoorAussie said, the only method to have more moving objects is to draw them into the background. Games like Mortal Kombat and Golden Axe use three bitplanes for their pseudo-sprites so they have a reasonable color depth (eight colors) and less VRAM updates to make. MK in particular uses all the sprites for one player and the entire background for the other player which is pretty creative.

If you are writing a game and really need more sprites, you can always move to the Genesis, and run software in SMS mode (Z80 is in control) but use the Genesis-specific video mode with 80 sprites and 20 per scanline. ;D

The only SMS sprite trick I know of is that you can make the VDP latch sprite data for eight sprites in SMS mode, then switch into a TMS9918 mode and show more than 4 sprites. But it is ugly and not practical - and who cares about more sprites in TMS9918 mode when SMS mode already has eight. :)

Guys, thanks for take the time and share your knowledge with me and clear me some doubts, now I think that I understand a little more about the sega master system ^.^

maxxfarras

Charles MacDonald wrote

If you are writing a game and really need more sprites, you can always move to the Genesis, and run software in SMS mode (Z80 is in control) but use the Genesis-specific video mode with 80 sprites and 20 per scanline. ;D

This would be a very cool thing to see on hardware, but as far as I know there are no Genesis emulators that would support that, not even Fusion and Gens+.

Tom wrote

Charles MacDonald wrote

If you are writing a game and really need more sprites, you can always move to the Genesis, and run software in SMS mode (Z80 is in control) but use the Genesis-specific video mode with 80 sprites and 20 per scanline. ;D
This would be a very cool thing to see on hardware, but as far as I know there are no Genesis emulators that would support that, not even Fusion and Gens+.

It's our responsibility to write programs that break emulators and force the authors to implement obscure and seldom or never-used features. :D

Author	Message
maxxfarras Joined: 29 Dec 2007 Posts: 48 Location: Hermosillo, Mexico	16 sprites in a scanline without flicker? Posted: Tue Apr 14, 2009 10:08 pm
	Hi guys, I know that the sms VDP1 have an issue displaying zoomed sprites, somebody know if in theory is possible fix this issue using software tricks and get all the 8 sprites zoomed horizontally and vertically such as the sms VDP2 does? In fact I wish zoomed sprites only horizontally as charles McDonald did sometime with a demo cake for one Bock´s birthday (working in the sms2) . Could be cool to use this feature in my demos for avoid sprite flicker and do my demo compatible with the sms 1 and sms 2 machines...possible? Can somebody help me with this question? Thank you very much beforehand. maxxfarras

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Wed Apr 15, 2009 2:05 am
	Due to the way the sprite fetching works, you cannot really do anything to increase the sprite limit over 8. Sprite tile patterns are fetched before the line they are on is actually drawn, so you can't change the sprite tile pattern OR the Xpos once it has been fetched. The zoom feature is likely a broken hardware bug in the VDP1 and as such will never be fixed. You can however make sprites only zoomed horizontally, by playing around with the sprite table and changing the Y position in increments of 1 as you draw it to avoid getting the vertical doubled. There is a gamegear game which does this. ie. Say on line 10 you want a sprite drawn, so its YPOS is set to 9 in the SAT. After it has fetched the sprite on line 9 to be drawn on line 10, you decrease its Ypos by 1, this way on line 10 when it is fetching the sprite it will use the actual second line of sprite data rather than the first line doubled up. You repeat this 7 times and you will have a horizontally only zoomed sprite. If you time this correctly, you will be able to update all 8 sprites in a similar manner if they are all after one another in the SAT (using the VDP autoincrement to avoid address changes), it will take ~208 z80 cycles in this case. It is somewhat limiting if you can't order sprites, or if you can't assume certain things about the sprites. It would be easy to do such things for a demo, but having 64 onscreen sprites all zoomed only horizontally in some kind of "game type" way would be very hard! Of course, since the VDP1 only allows the first 4 sprites to be zoomed horizontally you will have to target the VDP2.

maxxfarras Joined: 29 Dec 2007 Posts: 48 Location: Hermosillo, Mexico	Posted: Wed Apr 15, 2009 2:31 am
	thanks for you reply PoorAussie, I was afraid of some answer like that...so do you have any other idea for show /simulate more sprites in a scanline without flicker...?? (using the hardware sprites) or any suggestions? Thanks again

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Wed Apr 15, 2009 3:28 am
	The best way in my opinion to simulate more sprites on the SMS is to use background manipulation. Simply have unique tiles where these "background sprites" can move, and write/rewrite the tiles to show sprites moving. In this manner you can have as many objects as the CPU/VDP will allow you to update. If an object you want to move is say 16x32 pixels you need to write 256 bytes to show it. So you need to factor in the time needed to work out which tiles/pixels to update in the BG tiles, the time needed to erase where the object was before, etc. I think you could maybe update 16-32 extra 8x8 "sprites" per frame (all of which could appear on same line as there is no "Line limitation" as such with this method). This would limit the amount of VDP updating you could do for other things though,so you would need to manage the CPU/VDP budget accordingly. The other issue would be sprite priority, you could possibly work in a system which automatically handled the priority system and put sprites into the hardware sprite system or software BG sprite system depending upon their priorities, but then you would need the palettes to match also. Devising a system which uses say "special effects" or "bullets" for the BG sprites and keep the hardware sprites for main objects might be a compromise. Another "cheap" method older SG1000 type games used for scrolling was to store all the combinations an object could move on a tile in VRAM and simply switch tiles according to the position. Usually this limits you in color choices and sprite sizes though.

maxxfarras Joined: 29 Dec 2007 Posts: 48 Location: Hermosillo, Mexico	Posted: Wed Apr 15, 2009 10:09 pm
	If I choose to use background manipulation for moving "software sprites", I think that it means that I must create a mask system via software and I must use the same 16 color palette that the background uses for the "software sprites" That could be mean too much cpu consumming time, Im correct? Or there exists other better optimal way? (for avoid that ugly squares around the "sprites"). Which do you think that could be the fastest way for create this software mask?, I mean, if I must do it for avoid deformation. Thx for your help

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Thu Apr 16, 2009 12:34 am
	maxxfarras wrote If I choose to use background manipulation for moving "software sprites", I think that it means that I must create a mask system via software and I must use the same 16 color palette that the background uses for the "software sprites" That could be mean too much cpu consumming time, Im correct? Or there exists other better optimal way? (for avoid that ugly squares around the "sprites"). Which do you think that could be the fastest way for create this software mask?, I mean, if I must do it for avoid deformation. Thx for your help Well you need to loop through every pixel to be written, test if opaque , if opaque send it to the VDP. Then next frame you need to clean up your writes, you could do this with a blanket update of the tiles touched, mark them as dirty and simply reupload them. Then you repeat the process. In the worst case, a single 8x8 software sprite can make 4 tiles dirty, so this means a budget of writing out 4 tiles for each 8x8 software sprite, to clean it up, then writing another tile worth of data to display it. 5 tiles is 160 bytes. When writing out the opaque pixels it would also then mean you need to set the VDP address whenever appropriate. You could avoid this by ensuring any software sprites had no transparent pixels, or simply had no "broken runs" of pixels (eg a rounded bullet). There are likely better ways to do it, more optimizations you can make in certain cases, I haven't really thought about it until now. You're going to be making compromises either way, but you do have about ~1800 bytes in PAL to write out in the non active parts of the screen if you use OUTI blocks. If you used the active portion to be readying your sprites you would have plenty of time to be writing out blocks of VDP data for these sprites. You could also reduce the vertical resolution by blanking the display for more update time. ie Make it a widescreen display 256x144

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14749 Location: London	Posted: Thu Apr 16, 2009 8:09 am
	The absolute fastest way would be to have precomputed tiles for every possible sprite position over every background tile, but that would be extremely restrictive in terms of how much you could display. There are various ways you could try to speed up the tile rendering but the bottleneck will be the writing to VRAM. How important is it to have more than 8 sprites on the scanline? How important is real-system compatibility to you?

maxxfarras Joined: 29 Dec 2007 Posts: 48 Location: Hermosillo, Mexico	Posted: Fri Apr 17, 2009 12:01 am
	Quote Maxim said: How important is it to have more than 8 sprites on the scanline? How important is real-system compatibility to you? Real system compatibility is very important for me because I could wish that in a future my demos/games pushes the system´s limitationes :) Or at least try it. Respect to your first question, I always asked me if there is some way of "broke" the 8 sprite limitation of some way, for in game sprites, and create some enhancement . One option is given for Poor Aussie: background manipulation. When I readed the Charles next statement, I thought that other option is possible, but Im not sure if I understand it correctly: What do you think about the follow quote that Charles McDonal wrote?: Quote When the sprite table is changed during a scanline, the VDP starts buffering Y positions from the new table so you get a mix of the two. Visually this looks like the sprites are misplaced. I don't think the register write can be accurately timed to prevent this. If you want to show 128 sprites (alternating per scanline) the latter 64 need to have the same Y position as the first 64. The X position and tile number can be changed freely as those are read and used during the rendering phase on the next line. Please tell me if I missundertood the Charles McDonald statement, as I interpret Charles information I been thinking that instead of 16 sprites with flicker in a scanline you could get "16 interlaced sprites" without flicker, for switch the sprite atribute table in each scanline ...possible? the problem could be that sprites appearing interlaced and the background could be vissible trough them, but do you think that is possible? or I missanderstood the Charles quote? Thanks guys

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Fri Apr 17, 2009 1:57 am
	maxxfarras wrote Please tell me if I missundertood the Charles McDonald statement, as I interpret Charles information I been thinking that instead of 16 sprites with flicker in a scanline you could get "16 interlaced sprites" without flicker, for switch the sprite atribute table in each scanline ...possible? the problem could be that sprites appearing interlaced and the background could be vissible trough them, but do you think that is possible? or I missanderstood the Charles quote? Thanks guys You have misunderstood charles. The VDP has 8 internal registers which are ~40bits or so. Every line after active display the VDP tries to fill these 8 internal registers with sprite information so they can be displayed on the next line. You can determine what gets put into these 8 slots by playing with the SAT or the registers affecting sprites (like charles was doing) but you will never be able to increase the sprites to over 8 simply because there are only 8 slots to be filled, nothing more nothing less.

maxxfarras Joined: 29 Dec 2007 Posts: 48 Location: Hermosillo, Mexico	Posted: Fri Apr 17, 2009 6:05 am
	Sorry, I suppose I dont explain me very well, my english is crap. I know that is only possible to show a maxim of 8 sprites in a scanline, however you could be alternate by scanline two sprite tables, with inverse order each respect to the another just as for get the flicker effect except that switching in each scanline the sprite table. I told this because I just check the following program that charles wrote with my tototek (in a real sms1) and creates the illusion of 16 sprites horizontally! with no flicker! (even with the drawback that the sprites look as "interlaced") (after that you turn on the console, you must press sometimes pause in the console for get the correct effect! ) My question is now that if is possible get that effect for "in game sprites" or there exists some obstruction for that, I think for the Charles comments that it is possible, if not is possible thanks again for help me to clear my confusion, sorry, I just still asking because Im trying to understand :) Thanks for be so patient. The Charles McDonald´s program is Sprite Multiplex Demo (03012005) by Charles MacDonald (PD).zip (2.26 KB)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14749 Location: London	Posted: Fri Apr 17, 2009 7:14 am
	I think Charles' comment was saying that because the next 8 sprites' data is fetched during the scanline, writing directly to the sprite table means the data it reads may be half updated. The multiplexing demo works by having two sprite tables in VRAM and changing the sprite table pointer register (register 5), giving an interlaced view of two sprite sets, which themselves are only updated during the VBlank. Maybe if you switched which table got the even/odd lines every frame it would look more like 16 x 50% (flickering) transparent sprites. You'd still get odd effects where sprites within each table would occlude each other (with index-based priority) but sprites in separate tables would sort of "blend".

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Fri Apr 17, 2009 5:27 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Maxim wrote I think Charles' comment was saying that because the next 8 sprites' data is fetched during the scanline, writing directly to the sprite table means the data it reads may be half updated. This is correct. There is nothing you can do to increase the sprite limit, and the demo I wrote just changes the sprite table address in VRAM. If you change tables at 60Hz the flicker isn't so bad, but you still never really have more than 8 sprites per scanline. You can never get around that. If you run the demo in an emulator and pause it or advance frame-by-frame you will see that there are always 8 sprites shown at the very most. The Bock's Birthday demo used the same technique. Because zoomed sprites are twice as big, I switched the sprite tile set on every scanline so the first row of zoomed pixels used graphics from one set of tiles, and the second row of zoomed pixels used graphics from another set. This gives the illusion that a 8x16 zoomed sprite has a resolution of 8x32. Again if you pause that demo and look at the individual frames the sprites are really 8x16 zoomed. As PoorAussie said, the only method to have more moving objects is to draw them into the background. Games like Mortal Kombat and Golden Axe use three bitplanes for their pseudo-sprites so they have a reasonable color depth (eight colors) and less VRAM updates to make. MK in particular uses all the sprites for one player and the entire background for the other player which is pretty creative. If you are writing a game and really need more sprites, you can always move to the Genesis, and run software in SMS mode (Z80 is in control) but use the Genesis-specific video mode with 80 sprites and 20 per scanline. ;D The only SMS sprite trick I know of is that you can make the VDP latch sprite data for eight sprites in SMS mode, then switch into a TMS9918 mode and show more than 4 sprites. But it is ugly and not practical - and who cares about more sprites in TMS9918 mode when SMS mode already has eight. :)

maxxfarras Joined: 29 Dec 2007 Posts: 48 Location: Hermosillo, Mexico	Posted: Fri Apr 17, 2009 10:54 pm
	Guys, thanks for take the time and share your knowledge with me and clear me some doubts, now I think that I understand a little more about the sega master system ^.^ maxxfarras

Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Posted: Sat Apr 18, 2009 5:16 am
Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Charles MacDonald wrote If you are writing a game and really need more sprites, you can always move to the Genesis, and run software in SMS mode (Z80 is in control) but use the Genesis-specific video mode with 80 sprites and 20 per scanline. ;D This would be a very cool thing to see on hardware, but as far as I know there are no Genesis emulators that would support that, not even Fusion and Gens+.

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Sat Apr 18, 2009 4:34 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Tom wrote Charles MacDonald wrote If you are writing a game and really need more sprites, you can always move to the Genesis, and run software in SMS mode (Z80 is in control) but use the Genesis-specific video mode with 80 sprites and 20 per scanline. ;D This would be a very cool thing to see on hardware, but as far as I know there are no Genesis emulators that would support that, not even Fusion and Gens+. It's our responsibility to write programs that break emulators and force the authors to implement obscure and seldom or never-used features. :D

Forums

View topic - 16 sprites in a scanline without flicker?