"SNES has a more powerful CPU and higher resolution in games than the Genesis"

Quote:

---

Originally Posted by SegataS

I truly have no idea so I am not arguing. Genuinely curious. Like many, I have always been under the assumption that Mode-7 was unique of the 2 systems to SNES. Was Genesis able to replicate it in some way or completely? Which games did and do you have visual examples? I'd be very curious and thankful.

---

It wasn't ever used in a game that I know of, but I was thinking of the demo from gasega:



http://www.sega-16.com/forum/showthr...or-Genesis-MD/

It definitely can't replicate it with the performance the SNES does though, you're not going to beat dedicated hardware, and even if you could somehow infinitely overclock it the color limitation would still be a problem.

If the SNES was forced to do it in software though it'd definitely struggle just as much if not more. This was also a problem with 3D graphics (though I don't think many games tried it without a SuperFX — there's a good reason)… really, seems to have been a problem with anything that involved blasting around a lot of data, the 65816 is not that great for software rendering (and that's considering the 68000 already struggles a lot for starters). It's just that the average game wasn't supposed to do software rendering anyway.

That's pretty cool thanks. Now I wish SEGA tried a something similar. Tho I always admire the wireframe effect in Ranger X

This whole debate is dumb. "System that came out later is more advanced!" :shock:

Quote:

---

Originally Posted by Melf

This whole debate is dumb. "System that came out later is more advanced!" :shock:

---

lol I was wondering when you'd chime in!

Quote:

---

Originally Posted by turboxray

You're probably thinking of the early Sega System-16 boards? I've ripped graphics from CPS1 roms, and they definitely weren't 3bit. And if you check MAME source code, it's not one of the 3bit color cell systems. But even then, the System-16 3bit background tiles has hundreds of palettes to use haha. Sprites were 4bit but only 14 colors (other values were control codes for run length encoding).

Yeah, some of the early SNES titles did the whole 3bit compression thing too (it's a fast planar trick). But 3bits paired with a decent palette list, paired with a really fat master palette gets more mileage (Amiga is a close example). 25% compression doesn't get you much though. SNES has the ram for handling more complex compression schemes (like LZ based ones). PCE with its 8k of system ram just for hucards, does not (you only see LZ used in later SuperCD games, and even then). I've adapted some LZ based decompressors to use a ring buffer, make it possible to get much better compression ratios on the PCE with just 512 or 1024 ring buffer, but it needs a pre-pare of linear pixels before conversion to get good results - so it's pretty slow to decompress. Almost useless nowadays when you can just throw mappers and megs of rom at a game on these retro systems. Look at the two ports of Parodius for SNES and PCE. Both are the same size rom (8meg). Both systems have planar graphics for cells. SNES one has all the levels, while the PCE is missing two (and uses 3bit compression).

---

Yeah you are right I must be thinking of some other board that does something like that. I just looked at cps1.cpp in MAME and there's nothing like that. The reason I was thinking the CPS1 has that ability is because of cases where you see sprites move in front of and behind a background layer, like stage 1 in G&G: https://www.youtube.com/watch?v=cOAi3-jYw_M. I guess it must just use extra sprites to get that effect.

And yes going from 4 to 3 bits is not a great trade-off so far as compression goes but if your game is just over 8 mb and you need to squeeze it onto ROM quickly I can see why it would get used on launch titles.

Quote:

---

Originally Posted by axel

Yeah you are right I must be thinking of some other board that does something like that. I just looked at cps1.cpp in MAME and there's nothing like that. The reason I was thinking the CPS1 has that ability is because of cases where you see sprites move in front of and behind a background layer, like stage 1 in G&G: https://www.youtube.com/watch?v=cOAi3-jYw_M. I guess it must just use extra sprites to get that effect.

And yes going from 4 to 3 bits is not a great trade-off so far as compression goes but if your game is just over 8 mb and you need to squeeze it onto ROM quickly I can see why it would get used on launch titles.

---

I mean, for PCE at least with limited system ram for hucards, it does have the advantages of decompressing directly to VRAM in realtime (not as fast as its block move instructions, but still fast enough since PCE has unlimited vram read/write access during active display). It's just that snes can buffer, or decompress a head of time because of that nice chunk of 128k ram haha so better decompression scheme makes sense.

Also this, from CPS1.cpp in MAME

Code:

---

0x68-0x69  Priority mask \  Tiles in the layer just below sprites can have
0x6a-0x6b  Priority mask |  four priority levels, each one associated with one
0x6c-0x6d  Priority mask |  of these masks. The masks indicate pens in the tile
0x6e-0x6f  Priority mask /  that have priority over sprites.

---

Pens in the tile are the pixels. Gives you per pixel priority settings.

Quote:

---

Originally Posted by SegataS

I truly have no idea so I am not arguing. Genuinely curious. Like many, I have always been under the assumption that Mode-7 was unique of the 2 systems to SNES. Was Genesis able to replicate it in some way or completely? Which games did and do you have visual examples? I'd be very curious and thankful.

---

It took gasega68k a bit to work it out, and top of that we're in an age where a lot of the tricks are already known (there are plenty of write ups of how to do fast scaling/rotation, even on the 68k). That, and almost all Japanese game companies, honestly, weren't optimal coders. Great with game development/design, not so great with optimizations IMO. Euro developers had crazy optimization techniques, but crappy games IMO haha. Even with demoscene nowadays for retro systems; there really isn't anything new out there - just improvements/variations on old stuff that's known now. A single homebrewer/coder today doesn't have deadlines like developers BITD. And there's also the size. The G-Zero demo is almost 4megabits. No enemies, one map? You're gonna need a pretty big rom for a production game.

I absolutely LOVE the tech gasega68k has pulled off. But honestly, 1/4 the resolution of SNES mode 7? At less than half the frame rate? With 16 colors vs 256 colors + color math (transparency, fading, etc) on the SNES? Impressive as it is, and it definitely is, it would have give SNES fans and magazines all the more to harp on the Genesis/MD.

Quote:

---

Originally Posted by Sik

It definitely can't replicate it with the performance the SNES does though, you're not going to beat dedicated hardware, and even if you could somehow infinitely overclock it the color limitation would still be a problem.

If the SNES was forced to do it in software though it'd definitely struggle just as much if not more. This was also a problem with 3D graphics (though I don't think many games tried it without a SuperFX — there's a good reason)… really, seems to have been a problem with anything that involved blasting around a lot of data, the 65816 is not that great for software rendering (and that's considering the 68000 already struggles a lot for starters). It's just that the average game wasn't supposed to do software rendering anyway.

---

Honestly, if it weren't for the linear pixel mode none of this stuff from gasega68k would be running on the MD. It was just a happy fluke that the 16bitter uses that pixel mode, even if the tile segments hinder it somewhat.

The snes pulled off Wolf 3D on a stock snes. That's really impressive! I mean yeah, it's using Mode 7 byte pixel mode and scaling it up, but it's still impressive. Not only because the 3.57mhz on the snes is like 3mhz with wait-state ram and dram refresh cycles, but memory layout they added on top of the '816 is horrendous. At least for stuff like this. LoRom and most HiRom banks are pretty much just a standard NES mapper layout (upper 32 swappable, lower 32 fixed with ram and some ports).

But given the 128x48 rendered resolution he's outputting for the lower half of the screen (G-Zero demo), snes could handle that in a single frame DMA as well as double buffer. Mode 7 gives you 256 colors and there's no need for an HDMA to fix the lines (like what gasega68k) is doing. The issue is going to be memory access; you'd want fast near mapped data for use with faster opcodes on the '816. But the added memory layout is funky (byte pixels are fast, but also eats up memory). That's going to be the tricky part.

Quote:

---

Originally Posted by gamevet

@EPSYLON EAGLE

The TG-16 and SNES are using more colors, which will require more video memory. The trade-off is using a slightly lower resolution, to save some VRAM space.

---

So, it was a conscious decision to reduce the colors capabilities of the system to allow more resolution?

In that case, I'm glad they did it. Unlike the colors, the resolution really impact the gameplay and it also looks much better. I hate that stretched look of NES/SNES games, reason why I only play using 8:7 aspect ratio, even on a real CRT.

Quote:

---

Originally Posted by tisurame

So, it was a conscious decision to reduce the colors capabilities of the system to allow more resolution?

In that case, I'm glad they did it. Unlike the colors, the resolution really impact the gameplay and it also looks much better. I hate that stretched look of NES/SNES games, reason why I only play using 8:7 aspect ratio, even on a real CRT.

---

As turboxray pointed out that's not how the PC Engine works and even if it did the "trade-off" claim is obviously not true as the PC Engine is a resolution monster and loses none of its color capabilities when running at 512 x 240 non-interlaced.

Yeah, but I do believe their are trade offs for using more colors. CGA could do a lot more than 4 colors using lower resolutions. It’s crazy to see what a world of difference screen resolution has on that graphics interface, reducing the available video RAM needed to produce more colors.,

Quote:

---

Originally Posted by Black_Tiger

As turboxray pointed out that's not how the PC Engine works and even if it did the "trade-off" claim is obviously not true as the PC Engine is a resolution monster and loses none of its color capabilities when running at 512 x 240 non-interlaced.

---

The majority (90%) of games on the PC Engine run at 256x240. If there wasn't any "trade-off", most games would be using a horizontal resolution of 320 or higher.

256x240 is objectively worse. Can't imagine someone choosing this resolution for any other reason other than a technical limitation.

I’ll take more colors. The screen resolution never bothered me.

Quote:

---

Originally Posted by gamevet

I’ll take more colors. The screen resolution never bothered me.

---

Anyhow, the lower resolution is detrimental to the game play, mainly for side-scrolling games since you view 20% less screen horizontally.

A lower resolution will also be stretched to fill the screen, reducing the graphical quality, mainly for games not adjusted for the stretching (which was the large majority).

Quote:

---

Originally Posted by tisurame

The majority (90%) of games on the PC Engine run at 256x240. If there wasn't any "trade-off", most games would be using a horizontal resolution of 320 or higher.

256x240 is objectively worse. Can't imagine someone choosing this resolution for any other reason other than a technical limitation.

---

Their is no trade off for color use as gamevet theorized.

Hundreds of PC Engine games use resolutions higher than the Mega Drive can do (more like 30%) and some also run at "only" 320 x 224+. Someone on here checked the resolutions of the Genesis/Sega-CD library and found that around 30% ran at 256 x 224.

The number one reason games use lower resolutions is the same as why Mega Drive SFII ports are lowest resolution: games have budgets. Why make the same game require twice as big a rom when all you have to lose is your profit margin.

The other reason exclusive for PC Engine is that most of its library is on CD, which only allows you a tiny space to run content out of. When the Arcade Card finally arrived games that supported it were of two extremes: not making much use of the extra space at all or games so huge that the space was still not enough.

So, memory was a factor, it’s just not VRAM memory.

Quote:

---

Originally Posted by tisurame

Anyhow, the lower resolution is detrimental to the game play, mainly for side-scrolling games since you view 20% less screen horizontally.

A lower resolution will also be stretched to fill the screen, reducing the graphical quality, mainly for games not adjusted for the stretching (which was the large majority).

---

It’s not something that ruined a game experience for me. It not like Gradius III was going to be easier, because I got an extra inch of view on each side of the screen. It certainly didn’t make Dragon’s Revenge (that music sound track is sick though) a better gaming experience than Devil’s Crush, because the play field still looked pretty much the same, including a round ball.