AtariAge "CPU comparison"

[Stef]

I mean't power of 2 for smaller sized sprites/metasprites. Larger metasprites would be multiples of 16.

Yeah, I understood it but even for larger sprite you need no square sprites for "edge" part (if you really want to optimize your hardware sprite usage). And in my case, i allocate VRAM for the whole (meta)sprite given it's maximum number of tiles, i'm not doing per hardware sprite VRAM allocation. So if you do many sprite allocation / release operations you end by having fragmented VRAM. Hopefully in reality you can statically allocate a certain number of sprite and "dynamic" sprites are allocated / released by block almost time so that is not much a issue.

It's kind of funny how the backwards sprite capabilities of the SNES actually kind of comes in handy here. There are less (by a lot) sprite sizes, but there's also about one and a half times the sprites on the SNES.

Yeah having square sprite is convenient for some reason, specially in a hardware perspective. But because of that you tend to use more sprite on SNES (using 2 16x16 sprites instead of one 8x24 one for instance), then you need more CPU processing (something you really don't want to waste) and at same time the sprite pixel scanline limitation can be reached faster.

[psycopathicteen]

I didn't say make metasprites out of square sprites. I just said make the slot sizes multiples of 16. If you had a metasprite made of 3 24x24, it would be rounded up to 32 tiles.

[Stef]

Oh you mean having allocation slot of 16 tiles when you use 16 tiles or more for a sprite ? I'm not sure how much it help about fragmentation, it does probably but if I understand your idea then if you want to allocate 6 sprites using 18 tiles each, you end up allocating 6 x 32 tiles (2 x 16 tiles slot per sprite) ?

[Sik]

It does help reduce how badly fragmented it gets when the gaps are the same size a sprite is likely to need.

[tepples]

In such an allocation scheme, would it be worth it to add some sort of incremental defragmentation of sprite VRAM slots in the background?


Remember me?

[93143]

There've been some recent edits to the SNES page on tvtropes, and I'm not sure I like them.

Is there actual evidence that Nintendo intentionally nerfed the S-CPU in favour of adding chips to cartridges, such that it should be asserted as fact?

[tepples]

Are you referring to jnv11's recent edits claiming that the clock speed was cut on purpose to save money?

Otherwise, I've read rumors that something like the DSP-1 was originally going to be included on the mainboard but was cut.

[Sik]

I really doubt they nerfed the CPU >_> They did remove a part that computed math which is why Pilotwings has a DSP (its whole purpose was to simulate the missing part since there wasn't enough time to rewrite the game to not use it).

That said:

Are you referring to jnv11's recent edits claiming that the clock speed was cut on purpose to save money?

Well, I could see the LoROM clock having been added for that (not to cut costs on the SNES, but on the cartridges, seeing as one would be spending lots more of money buying games).

[HihiDanni]

The CPU limited RAM throughput?? Ummm, if that's the case then FastROM wouldn't have been a thing. I'm pretty sure the slow RAM throughput is because... the RAM is slow.

Also I'm pretty sure that 16-bit operations are at worst case one cycle slower than the same thing in 8-bit.

Has this person ever programmed a Super Nintendo or are they just going along with "correlation implies causation"?

[Revenant]

I read the edit(s) as saying that the memory speed limited the CPU speed, not the other way around (which is basically correct).

whoops, I was reading the text that was already there, not what the user added. The "Nintendo crippled the CPU in order to make cartridges more expensive" is definitely "[citation needed]" material.

[Near]

Otherwise, I've read rumors that something like the DSP-1 was originally going to be included on the mainboard but was cut.

The SNES could have been a beast had they included a NEC uPD7725 with program and data RAM (for per-game upload of firmware) instead of ROM.

But I still think a lot of games wouldn't bother with it, because programming in that thing's VLIW ISA was brutal.

[tepples]

whoops, I was reading the text that was already there, not what the user added.

The link I gave was to the most recent history. At the bottom there should be a link to expand the history so you can see when and by whom that particular phrase was added.

[psycopathicteen]

This is basically the "circle of logic" everybody uses to "prove" the SNES is "slow."

[93143]

Are you referring to jnv11's recent edits claiming that the clock speed was cut on purpose to save money?

Yes.

I've made some contributions and corrections to that page myself in the past, but I've been wary of saying too much since I know I'm biased and probably don't understand things as well as I think I do. Still, I think I understand things better than jnv11 does. Based on given edit reasons, this person seems to believe that the 8-bit bus "castrated" the console, and that the bit depth of the DSP was why it "blew out" competing sound chips.

I don't want to start an edit war, and I certainly don't want to stomp on valid observations with misinformation. Maybe I should start a discussion there...

I'm pretty sure the slow RAM throughput is because... the RAM is slow.

Yeah, but with a 16-bit bus (and 16-bit memory) the throughput is doubled for the same memory speed. This is the reason the Mega Drive's bus speed in MB/s roughly matches that of the SNES (FastROM) despite the fact that the bus accesses happen roughly half as often.

The thing is, the bus width comes with the CPU. You can't criticize it in isolation; the proper place for complaints about the bus width is a technical discussion of the relative merits of different CPUs. The discussion as it currently stands on that page seems unbalanced and incomplete (and a fuller discussion should probably be inside a note because it's already getting bloated).

[tepples]

A. BECAUSE THE SNES IS SLOW
B. BECAUSE I INTENTIONALLY PROGRAMMED IT TO BE SLOW
C. GOTO A

C. Because finding and hiring somebody who knew how to make a 65816 not be slow was too expensive within the time and money that the publisher allotted.

The 68000 had a pool of Amiga, Atari ST, and arcade programmers to draw from. The 65816 had only the Apple IIGS, and that platform wasn't quite as conducive to training programmers in action game logic optimization because of its dumb, unscrollable, single frame buffer. The fastest you could scroll on a GS was about 10 to 15 fps using the obscure "PEA field" technique that overlays the stack on the hardware frame buffer, and the back buffer is stored backwards as a block of self-modifying code.

Based on given edit reasons, this person seems to believe [...] that the bit depth of the DSP was why it "blew out" competing sound chips.

Compare the clarity of "Nintendo!" in Tetris Attack to "Say-Gah" in the Sonic games to see what a difference bit depth makes. Or compare the clarity of any Super NES game to its GBA port, which is usually a pile of hiss and aliasing because of its 8-bit DAC usually filled by software mixing at 18 kHz.

The thing is, the bus width comes with the CPU. You can't criticize it in isolation; the proper place for complaints about the bus width is a technical discussion of the relative merits of different CPUs.

So you then have to disprove "65816 sux; 68000 roolz".

If you do decide to make major changes to the Super NES page at TV Tropes, could you consider doing the same for the corresponding page on All The Tropes? You can't copy text back and forth because of copyright issues, as the two wikis use incompatible copyright licenses, but you can put your own original words on both pages. All The Tropes is a fork that still uses the same free content license as Wikipedia, from a backup of TV Tropes from before July 2012 when TV Tropes changed to a less fork-friendly license (which change allegedly infringes its pre-July 2012 contributors' copyrights).