SNES Doom Source Released! Now What?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: SNES Doom Source Released! Now What?

Post by Señor Ventura »

93143 wrote: Sun Jan 29, 2023 10:41 pmThe PPU is not programmable. It does what it does. You can poke registers to change settings, but ultimately it's fixed-function hardware.

What you are describing is hardware sprites, and there are only 128 of them. I need more.
I was thinking something more... procedural... but i didn't think about two or more bullets within a tile, in that cases the variability grows exponentially.

A bullet of 4x4 pixels can have ¿¿64?? possible positions inside an 8x8 tile, you can keep these 64 tiles in the vram, and use the proper one in every position of the layer depending of the coordenate. The difficult here is to devise the algorythm.

But sometimes two or more bullets fits in one tile, so you must keep more tiles with all the possible graphics to prevent all the possibilities, and so the algorythm turns more complex... and even is possible that there is not enough vram to store all the variables (possible tiles).

Too much work for the programmer... but you keep some bandwidth.


Anyway, crazy ideas...
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES Doom Source Released! Now What?

Post by 93143 »

Individualised wrote: Mon Jan 30, 2023 3:20 amThe music in SNES Doom was likely automatically converted from .MUS files, hence the strange sounding timing of the music, as the sound driver likely can't handle the precise timing of the MUS format.
That doesn't explain why the sound effects have such horrific timing. Watch this fight, and then go ahead and try to tell me that's normal for a SNES game.

Señor Ventura wrote: Mon Jan 30, 2023 11:39 amI was thinking something more... procedural... but i didn't think about two or more bullets within a tile, in that cases the variability grows exponentially.

A bullet of 4x4 pixels can have ¿¿64?? possible positions inside an 8x8 tile, you can keep these 64 tiles in the vram, and use the proper one in every position of the layer depending of the coordenate. The difficult here is to devise the algorythm.
This doesn't sound like what you were saying before. You were talking about one bullet tile in VRAM, which is exactly how hardware sprites work. Unless you meant building a BG layer in which the bullets are constrained to move in 8-pixel increments in both axes, which would be pretty goofy...

The thing about the "64 possible positions inside an 8x8 tile" is that unless the bullet is literally just a single pixel, it's going to hang off the side of the tile and into a different tile. This complicates things quite a bit, especially if you want another bullet nearby.
But sometimes two or more bullets fits in one tile, so you must keep more tiles with all the possible graphics to prevent all the possibilities, and so the algorythm turns more complex... and even is possible that there is not enough vram to store all the variables (possible tiles).
This won't work with a BG layer, because you can't freely position BG tiles. Even for single-pixel bullets that are never in the same tile with more than one other bullet (an implausible constraint), you'd need 4096 8x8 tiles, which at 2bpp would consume the entirety of VRAM (leaving no space for a tilemap, never mind anything else you might want to see onscreen, not to mention that a BG layer on SNES is constrained to a movable address window spanning 1024 tiles, meaning you couldn't freely pick from 4096 tiles anyway).

It only kinda works with sprites, when you can freely position the tiles, and you could probably use the Super FX to check for bullets close enough to each other to share a sprite (though even that is difficult to optimize, and anything other than a greedy algorithm would probably be too much for the Super FX). Somebody actually suggested this to me years ago. But with a maximum of two bullets per sprite you max out at 256 bullets onscreen (assuming nothing else is using sprites, which isn't the case), and attempting anything more than that rapidly runs into combinatorial explosion. How do you handle three bullets in the same sprite? Four? Five? How about two or three different types of bullet? How about bullets that show visible directionality?

Since this is a port, I can't choose freely what the game contains. And what the game contains is a very poor fit for this method.
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: SNES Doom Source Released! Now What?

Post by Señor Ventura »

93143 wrote: Mon Jan 30, 2023 11:22 pm
Individualised wrote: Mon Jan 30, 2023 3:20 amThe music in SNES Doom was likely automatically converted from .MUS files, hence the strange sounding timing of the music, as the sound driver likely can't handle the precise timing of the MUS format.
That doesn't explain why the sound effects have such horrific timing. Watch this fight, and then go ahead and try to tell me that's normal for a SNES game.

Señor Ventura wrote: Mon Jan 30, 2023 11:39 amI was thinking something more... procedural... but i didn't think about two or more bullets within a tile, in that cases the variability grows exponentially.

A bullet of 4x4 pixels can have ¿¿64?? possible positions inside an 8x8 tile, you can keep these 64 tiles in the vram, and use the proper one in every position of the layer depending of the coordenate. The difficult here is to devise the algorythm.
This doesn't sound like what you were saying before. You were talking about one bullet tile in VRAM, which is exactly how hardware sprites work. Unless you meant building a BG layer in which the bullets are constrained to move in 8-pixel increments in both axes, which would be pretty goofy...

The thing about the "64 possible positions inside an 8x8 tile" is that unless the bullet is literally just a single pixel, it's going to hang off the side of the tile and into a different tile. This complicates things quite a bit, especially if you want another bullet nearby.
But sometimes two or more bullets fits in one tile, so you must keep more tiles with all the possible graphics to prevent all the possibilities, and so the algorythm turns more complex... and even is possible that there is not enough vram to store all the variables (possible tiles).
This won't work with a BG layer, because you can't freely position BG tiles. Even for single-pixel bullets that are never in the same tile with more than one other bullet (an implausible constraint), you'd need 4096 8x8 tiles, which at 2bpp would consume the entirety of VRAM (leaving no space for a tilemap, never mind anything else you might want to see onscreen, not to mention that a BG layer on SNES is constrained to a movable address window spanning 1024 tiles, meaning you couldn't freely pick from 4096 tiles anyway).

It only kinda works with sprites, when you can freely position the tiles, and you could probably use the Super FX to check for bullets close enough to each other to share a sprite (though even that is difficult to optimize, and anything other than a greedy algorithm would probably be too much for the Super FX). Somebody actually suggested this to me years ago. But with a maximum of two bullets per sprite you max out at 256 bullets onscreen (assuming nothing else is using sprites, which isn't the case), and attempting anything more than that rapidly runs into combinatorial explosion. How do you handle three bullets in the same sprite? Four? Five? How about two or three different types of bullet? How about bullets that show visible directionality?

Since this is a port, I can't choose freely what the game contains. And what the game contains is a very poor fit for this method.
It was a crazy idea, cause the number of bullets inside a tile, and the kind of behaviour (speed, trajectory, type of ammunition, etc) is limited by the actual animation.

And it is what it is. Basically 64 tiles with the bullet in a different position in every tile until covering all the positions for all the possibilities. Then you choose the correct tile with the proper bullet position into the correct tile position in the layer (not moving the tile layer inside the layer).

But, as i said, is hugely limited. You would need hundreds, if not thousands of different stored tiles in VRAM to cover the different possibilities of bullets behaviour of a normal game (and then, do the algorythm to connect all that puzzle).


Imagine a layer divided into 4 tiles (upper left, upper right, lower left, and lower right). If you want to simulate a ball traveling from a side to another, you only have to animate the tiles with the correct frame (not moving the tiles). With 64 positions stored you can animate the upper left tile simulating the ball moving to the upper right tile, and then start to update that upper right tile using the same pattern of stored tiles... due to the animation, you can animate the ball traveling to any direction.

As i said, it doesn't work with a shooter unless you have stored hundreds and hundreds of different bullet drawings, and it not worth all that work (when two bullets coincides within a tile, the number of possible drawings increases exponentially... and with three bullets it turns a nightmare... with four would be better to die... and so on, and so on, ando so on... and now, every bullet has different speed and different properties... so, it doesn't worth at all. Impossible).


It was a crazy idea, as i said ^^u
Post Reply