When I read this post above me this maybe like looking in a mirror. I need to keep this in mind more. Sorry, y'all I see it more now. Hyper aggressive first impressions.
When I read this post above me this maybe like looking in a mirror. I need to keep this in mind more. Sorry, y'all I see it more now. Hyper aggressive first impressions.
I wish people would abandon the term fanboy. Not a shot at Turbo as he was called one in a previous post. Just in general. It seems like just the laziest way to try to discredit someone.
Also can a mod not change your email on your old account to an updated one? I know in the Admin Panel some forums allow this. I used to do it often.
That's exactly what SMW uses, objects are drawn in 3bit color to save on ROM space. Same thing with LttP and other early SNES titles. So of course sprites in Sonic 2 can look more colorful. I never thought it affected the games, SMW is still a classic even if it does play like an NES game with more sprites.
I believe the CPS1 can also use 3bit graphics with the 4th bit used for priority to have part of an object behind or in front of a sprite, but I haven't looked into the documentation to confirm that's how it works.
Heh. I always put SMB3 on the NES as basically a 16bit game with 8bit graphics. It has all the physics/controls and level/design complexity of a 16bit generation game. Quite a few later gen NES games were like that.
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 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).Quote:
I believe the CPS1 can also use 3bit graphics with the 4th bit used for priority to have part of an object behind or in front of a sprite, but I haven't looked into the documentation to confirm that's how it works.
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).
Prior to watching the SNES video I would have said "of course artists drew the graphics with 4:3 in mind, they were working on CRTs not modern LCD monitors."
But Super Metroid really does look better in 8:7 and Nintendo provides support for that AR in their official emulators... so maybe that was intended after all?
I hate to do this (:p) but ran across this post today:
"The SNES actually had the better CPU. The Genesis had the mainstream CPU that was well used in the industry at the time. So, much easier to program for. The SNES basically went exotic like The Cell on PS3 did. It was actually a very powerful CPU with far more potential.
The problem was it was annoying to program for in an industry with small budgets and short development cycles. And some wanted to keep their games multiplatform. So, you hamfisted it on SNES and used its far superior graphics hardware set to compensate while your game ran “slower”.
The genesis had to do many things via software implementation and due to various design constraints, as a platform, the SNES had too much overhead to have its CPU do similar things. So, most of what the Genesis did was through cheating and faking it. Whereas, technically, the SNES did most things “right” but due to seriously questionable architecture decisions, it had unnecessary overhead and its CPU was mostly limited because of cheap memory compatibility issues where the Genesis’ architecture was designed more intelligently and could do both expensive and cheap roms without impacting CPU cycling.
I would nitpick at everything you said but you’re not too far off, just enough to annoy me and mention it here but I doubt many are actually interested in a full-blown technical discussion for two dead systems in which we split hairs.
I just want to make it clear the Genesis never had better horsepower and sheer horsepower. It simply had a better understood manual and was far easier to sloppily program for and, really, it was its platform/architecture that was better since the SNES is just a pig in cost-cutting maneuvers and poor design decisions on Nintendo’s part. It’s a classic case for hardware design hell since the platform was stuck there for a relative long time before Nintendo decided to ham fisted it. It was, at first, basically a Neo-Geo in costs. Nintendo was pretty stupid with hardware back then when they didn’t use off-the-shelf stuff like they did with the NES and Gameboy."
So there you go folks. Thread over.
Lol, they literally quoted that Nintendo propaganda from bitd that was designed to look like a real magazine article.
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).
To be fair the post it's replying to is just as dumb (bonus points because the particular effect it points out (tilting) is also doable on SNES and with more granurality, Time Trax uses it in the helicopter chase level).
And the original article does say that the Genesis "simply couldn't reproduce" the Mode 7-like graphics effect...
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.