Macross Scrambled Valkyrie (one of the finest shmups ever, tons of sprites on screen with no slowdown, trounces over the average PCE & Saturn Macross games)
I'd hardly call it one of the finest shmups ever. The level design for the most part, is rather plain or repetitive. The first and sixth level stand out as pretty nice, but the rest are mostly only average. It doesn't have tons of sprites on screen, well maybe for a SFC game and certainly nothing to point relative to the PCE's and Genesis' shmups. The last levels do get some more enemy action, but still nothing special. I don't see how someone could think this game trounces the PCE's Macross 2036. PCE one has more interesting levels designs and variety. The bosses are pretty generic in the SFC port, while the PCE port as fantastic looking bosses. Almost all the of the SFC bosses are generic and/or don't fit the theme of Macross. The PCE one is more cinematic too, not just in cinemas - but levels too (like the large ship you're accompanying that crashes/pierces the large enemy fleet ship - in the game level). The music is pretty good on the SFC port, but still can't touch the PCE's sound track. The actual shmup design of the SNES one is pretty thin. The PCE one a better power up system through out the game as well as earned points(money) to buy secondary weapons. Much more choice of weapons to add strategy to the levels. The PCE one is pretty like Area 88 SFC games meets Macross. The PCE one doesn't have the nice transparency effects of level 1 and 6 of the SFC port, but the level graphics are much more interesting or breathtaking overall. The PCE one just has sooo much more going for it than the SFC port. The PCE version easily owns the SFC version. And the PCE on runs on a system card 2.0 too. That's an extra diss to the super fammy port.
The Neo Geo hardware is probably the best BECAUSE it has no background tiles. A sprite-only system with a 1536 sprite-pixels-per-line limitation means you can have just about as many layers of parallax as you want. So... why don't the Genesis fanboys ever compare their console to the Neo Geo? Oh yeah, that's right... because they would get their asses kicked by a console which is similar in architecture (68k CPU, Z80 coprocessor for sound, same VRAM and sound buffer) but vastly superior (higher speed CPU, 7 ADPCM channels, 16 bit color palette with 12 bits of color output, 384 sprites of sizes up to 512 pixels tall, etc etc etc).
Someone already tried to do that. I read a thread where someone was comparing Neo Geo to the Genesis. Saying how the Genesis had better parallax hardware and that the Neo Geo couldn't do it. All because they didn't see it on the NG, of the level they saw on the Genesis (Sonic, Ristar). The NG has a scanline interrupt and can change position of any chain of sprites needed for line scrolls or parallax. Though for parallax for games like Ristar, on the NG you wouldn't even need interrupt stuffs. You just build it all out with sprites.
Genesis:
16bit CPU, 16bit data bus. VDP 8bit I/O on cpu side (grouped 8bit ports), and 8bit data bus to vram (vram is two 4bit chips). The VDP also works in 8bit segments internally. As a side effect, certain things screw up when in Genesis 'mode' because it tries to emulate a 16bit I/O port by using a latch or some other type logic (like the increment register, if it's an odd value and you write a WORD to the I/O port - the two bytes of the word end up in two different places). But that makes sense, since the it's BC with SMS and that was an 8bit VDP.
SNES:
16bit CPU, 8bit data bus. It has two sPPU's, cpu read/write port is 8bit (and the DMA on the sPPU pulls data in byte segments on the CPU address bus). The external vram (which is dram and needs refresh cycles), is two 8bit chips. Each sPPU has direct access to each 8bit data bus. They work in conjunction with each other to build the display. For the most part, this is transparent to the programmer because of how they are interleaved and show/treated as a continuous memory range. But mode 7 shows the real layout of this. Pixel data is byte (for 256 color). The tile map data is also byte (instead of word). The pixel data and the map data are interleaved. So you have to take this into account when writing or DMAing to vram. And it's interleaved because the bandwidth to display 256 color byte pixels is very high, so they take advantage of the dual 8bit bus layout. On sPPU reads the 8bit vram chip holding the tilemap, the other sPPU reads the other 8bit chip that holds nothing but the tile data.
PCE:
8bit cpu, 8bit data bus. The VDC is 16bit device through and through. All memory is accessed as WORD addressing (16bit). All reads and writes are 16bit to the I/O. All registers are 16bit. Sprite cells are 16 pixels wide because the VDC's data bus is 16bit. It can't read less than that at a time. The only reason tiles are 8pixels wide instead of 16 pixels wide, is because the second 8bits of the WORD fetch are treated as the second plane of the tile, rather than the continuation of the tile's horizontal pixels.
No one uses "blast processing" unless they're referring to the Genesis, so I don't understand your question. Of course it's incorrect to call a non-SNES thing "mode 7".
Yes you do. You're faining innocence and ignorance, but I know you understand the point I was making. Magazines, forums, and people have been using the term mode 7 to describe anything that looks remotely similar, on other systems, for years and year. Even to this day. Everyone here know exactly what is meant of someone uses that term. BP never obtained this kind of word context and association outside of the Genesis. But that doesn't mean one negate the other's usage. But you already know this. I don't think you care to have real discussion, as you are to stir the pot. I've seen your posts before and that all you ever do here. And it was
your post that brought this whole thread off topic. I bet that tickles you pink inside. Are you on the Sega-16 forums? Cause if you are, your attitude/behavior most be completely 180 over there as I don't recall recognizing you over there.
And since people are talking about arcade systems with no background layers, even the original 16bit System16 only had 1 BG layer. And it only uses 3bit pixel tiles or 8 colors (though it has a ton of subpalettes). Sprites uses 14 colors (color #0 was transparent, color #15 was EOL).
I've thought the sfc is capable of 32768 colors output? so is it all all big LIE?
In normal modes, it's a total of 241 colors. And it has the same restrictions like the Genesis and PCE. 15 color tile/sprite pixels and subpalettes to choice from. Mode 7 has 256 pixel color tiles. They index a 256 color pixel palette. But mode 7 can only show up to 256 unique tiles (like an NES), so it's no good for detailed backgrounds. Mode 6 is Direct color mode. It has direct RRRGGGBB pixel mode for 256 colors per tile. But the tilemap holds some more bits to be added to RGB tile bits. This is the 2048 color mode. 2048 mode is rather limiting and missleading. Effectively, you use the tilemap to set the color temp of the 256 color pixel. If you try to do that for every tile, you'll get hard transitioning. So really, only 256 color mode. On BG grounds can display this much color. No sprites. And it limits the BG to 1 layer when doing this (because the bandwidth is just too great for the sPPU's to do anything else). You can add color math into the mix to get more color, but some of the more advance transparency options are not possible in the higher color modes and you don't have per pixel control.
