31–40 of 275 posts
> One of the exceptional characteristics of the Super Nintendo was the ability for game cartridges (cart) to pack more than instructions and assets into ROM chips Wasn't this true even on other Nintendo consoles? Gameboy and Gameboy Color cartridges did similar if not even more outlandish things, like the GameBoy Camera
Earlier quoted context omitted.
The file sizes given by the site are wrong. Super Mario World is 512KB, or 508KB if you discard the padding at the end. Only compressing it to ZIP format gives you a file size around 360KB.
Yea, after writing this I regretted using zip to estimate usage. Probably would get better number by extracting each zip and look how much zero padding is at the end of the file. WDYT?
Earlier quoted context omitted.
Yea, after writing this I regretted using zip to estimate usage. Probably would get better number by extracting each zip and look how much zero padding is at the end of the file. WDYT?
Just query each archive for the total uncompressed data. While the 'real' code+data is less than the size of the banks, the banks are always ^2.
The SuperFX is mentioned to have it's own framebuffer and copy the whole thing over to VRAM.
Does that mean, it would technically be possible to put some ridiculously overpowered SoC into an cartridge, and use that to render modern graphics (at SNES resolutions), copying the resulting frames back into the SNES VRAM?
What are the limitations there?
I wonder what you could do with modern tech, exploiting that ability of having "enhancement chips" in the cartridge. The SuperFX is mentioned to have it's own framebuffer and copy the whole thing over to VRAM. Does that mean, it would technically be possible to put some ridiculously overpowered SoC into an cartridge, and use that to render modern graphics (at SNES resolutions), copying the resulting frames back into…
I wonder what you could do with modern tech, exploiting that ability of having "enhancement chips" in the cartridge. The SuperFX is mentioned to have it's own framebuffer and copy the whole thing over to VRAM. Does that mean, it would technically be possible to put some ridiculously overpowered SoC into an cartridge, and use that to render modern graphics (at SNES resolutions), copying the resulting frames back into…
https://youtu.be/ar9WRwCiSr0?si=LArQqOoH2bLtTXCQ
Earlier quoted context omitted.
Some Details on the Doom Wiki ( https://doomwiki.org/wiki/Super_NES ): Randy Linden, the port's sole programmer, initiated the port of Doom for the Super NES on his own initially, as he was fascinated by the game. Since Doom's source code was not yet released at the time, Linden referred to the Unofficial Doom Specs as a means of understanding the game's lump layout in detail. The resources were extracted from the IW…
Also it was recently figured out that using the SNES's mosaic feature in an unconventional way could have nearly doubled the game's framerate.
Earlier quoted context omitted.
Well, we have to account for the fact that modern system simply don't require that much optimization and compression. Working with stricter limits meant that dev teams had to get creative and minimize file size, while nowadays a single game update can be around 20 GB.
> nowadays a single game update can be around 20 GB Irrespective of the abundance of storage we now enjoy, and even though I could rationally understand the reasons, this will always make me raise an eyebrow or sigh.
OK, I will use that excuse if someone asks me why I am so bad at it.