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.