TiagoSC wrote: Sat Aug 06, 2022 7:43 am
I'm not porting the complete Sonic to the SNES because the snes sprite limits really complicate porting 1:1, as I use 8x8/16x16 sprites to maximize the 512 sprite tiles, it would be difficult to make the large objects of the next stages.
What large objects made from sprites are you referring to that would have caused an issue in that level, and what issue specifically (would it be avoiding hitting the max sprites per scanline before flicker limit maybe)?
Just to see how the MD engine has the advantage, even in H32 mode (maximum 64 sprites):
[moderator: attached images from links to post]
On SNES mmx (70 sprites used out-of 128)
SNES-MMX.png
On MD mmx (28 sprites used out-of 64, in this H32 mode)
MD-MMX.png
On snes, for a game with many particles you will have an advantage for the 128 total sprites, or in a game like Sparkster that uses 16x16/32x32 sprites, you can get more and bigger sprites than the MD, but the limit is to fit all the art in the 512 tiles
snes Sparkster
Sparkster-J-000.png
sprite tiles on vram:
Sparkster-VRAM-sprites.png
I guess the trick in these cases to work best within SNES' limits would maybe be to use the 16x16 and 32x32 sprites, like in Sparkster, and try not to make every tile of the sprites use completely unique art, so as to maximize the optimal way of working within that VRAM limit, as well as use a limited amount of variation of the sprites on-screen at any time and create characters that use as much if each tile's space as possible.
I'm curious as to what difference it would have made using the 16x16 and 32x32 sprites in the Mega Man example there and trying to optimize things that way, as that presumably would have cut down on the total required to show the characters in the image you provided above.
You managed to do it in only 28 sprites of varying sizes on Genesis, but I'd be interested to see the lowest number of SNES sprites you could get away with if you were to use the 16x16 and 32x32 sizes instead of the 8x8 and 16x16 sizes Capcom originally went with (assuming it still fits into the VRAM and sprites per scanline limits).
SNES definitely makes it more of a hassle for sure though.
I am neurodivergent, so if any of my posts unintentionally upset you, I apologize.
SNES AYE wrote: Sun Feb 12, 2023 3:59 pm
What large objects made from sprites are you referring to that would have caused an issue in that level, and what issue specifically (would it be avoiding hitting the max sprites per scanline before flicker limit maybe)?
Just to see how the MD engine has the advantage, even in H32 mode (maximum 64 sprites):
[moderator: attached images from links to post]
On SNES mmx (70 sprites used out-of 128)
SNES-MMX.png
On MD mmx (28 sprites used out-of 64, in this H32 mode)
MD-MMX.png
On snes, for a game with many particles you will have an advantage for the 128 total sprites, or in a game like Sparkster that uses 16x16/32x32 sprites, you can get more and bigger sprites than the MD, but the limit is to fit all the art in the 512 tiles
snes Sparkster
Sparkster-J-000.png
sprite tiles on vram:
Sparkster-VRAM-sprites.png
I guess the trick in these cases to work best within SNES' limits would maybe be to use the 16x16 and 32x32 sprites, like in Sparkster, and try not to make every tile of the sprites use completely unique art, so as to maximize the optimal way of working within that VRAM limit, as well as use a limited amount of variation of the sprites on-screen at any time and create characters that use as much if each tile's space as possible.
I'm curious as to what difference it would have made using the 16x16 and 32x32 sprites in the Mega Man example there and trying to optimize things that way, as that presumably would have cut down on the total required to show the characters in the image you provided above.
You managed to do it in only 28 sprites of varying sizes on Genesis, but I'd be interested to see the lowest number of SNES sprites you could get away with if you were to use the 16x16 and 32x32 sizes instead of the 8x8 and 16x16 sizes Capcom originally went with (assuming it still fits into the VRAM and sprites per scanline limits).
SNES definitely makes it more of a hassle for sure though.
snes has several features that would help solve certain problems, as 93143 explained using scroll table offset.
I prefer to go with sprites only, the best way is to use 16x16/32x32 and dynamically update the tiles in the vram as the objects appear on the screen, this ends up using more CPU and DMA, but as it will spend less sprites in total per screen, will get similar or better performance than the current one.
That same format would be good in a Megaman too, but it depends on each game.
TiagoSC wrote: Fri Aug 07, 2020 7:47 pm
it's an engine I'm making to create a platform game that will mix Donkey Kong Country's with the gameplay of Sonic.
Just noticed what you said above. So, is it a game for SNES you were/are making then, and is there any update on how that's coming along?
I am neurodivergent, so if any of my posts unintentionally upset you, I apologize.
