[GeneralAdmiralChipotle]

Sonic 1 SMS looked like a significant drop in quality from the original Genesis game. Most would agree it looks like crap by comparison with its baby blue single shade sky line, low color-depth sprites, and lack of detail. After giving Sonic Edusoft a spin (no pun intended), I couldn't help but notice how close it looks in terms of visual quality to Sonic 1 16-bit, and even to an extent, Sonic 3D Blast in its isometric overworld. It even looks as good as the the prototype isometric game in the early stages of Sonic Xtreme's development (might I add, a game late in the life cycle of the Genesis/MD). Sonic looks completely faithful in the game as well. The sprite is just like the 16-bit sprite (albeit with a subtle loss of "depth" owing to the 32 color palette of the SMS), it also has smooth animations compared to Sonic 1, but most importantly, IT HAS GOOD COLOR DEPTH. Even the pig animal and Motobug look just as good on the 8-bit hardware. The game also had just as many on-screen objects at once as Sonic 8-bit (maybe about 2-4 fewer when you start talking about stages filled with rings). Keep in mind- this game is a relatively low-budget spinoff. To have the visual quality it had presumably with fewer dollars thrown at it speaks volumes for the capability of the SMS.

*It really begs the question, "Could Sonic have been done faithfully on 8-bit hardware?" and if so, "Why couldn't Sega get the sprite work right after 5 tries?"

EDIT: Dear Mods/Admins- This isn't a speculation topic. The idea isn't to speculate on the questions, but rather focus on the game itself in relation to aesthetically unappealing SMS games that actually were released. I just brought up those questions as an aside, so please consider that before trashing this topic amid possible speculation that I may be speculating.

EDIT 2: Here are some pictures for the sake of comparison. The primary difference is in the palette...

Sonic 1 8-bit


Sonic Edusoft

This post has been edited by GeneralAdmiralChipotle: 03 March 2013 - 04:07 PM

[Aerosol]

The amateur in me compels me to say that Sonic Edusoft used less VRAM at a time than Sonic 1 SMS.

[GeneralAdmiralChipotle]

AerosolSP, on 03 March 2013 - 03:20 AM, said:

The amateur in me compels me to say that Sonic Edusoft used less VRAM at a time than Sonic 1 SMS.

I suppose so. Nonetheless, I imagine that is because the design was more efficient. On top of that, the SMS had 16KB of VRAM, the same as the boot RAM and main RAM combined. Perhaps it has more to do with the handling of collision mappings. Sonic Edusoft never had to process collisions from what I saw. There really wasn't anything but scripted movements...

[Black Squirrel]

It's all about screen estate - in the Mega Drive and Master System platformers Sonic takes up about 1% of the screen (and it's a similar story for Mario on the NES). It's a pretty good size to be - just enough detail to see the character, but "zoomed out" enough to see what's coming as you traverse through the stage.

Sonic Blast is an example of when you shove big sprites into a small window - you can't see what's coming, and the level design (and game as a whole) suffers as a result. Sonic takes up about 5% of the Game Gear window in that game.


Otherwise you have to remember an entirely different team worked on the Master System (and Game Gear) Sonic 1 and probably didn't have access to all the final assets (which probably explains why there's no Marble Zone or Spring Yard or whatever). They were never going to look identical - Edusoft came much later and has a completely different style of play

also I'd say it looks pretty awful at times but whatever

[dsrb]

AerosolSP, on 03 March 2013 - 03:20 AM, said:

The amateur in me compels me to say that Sonic Edusoft used less VRAM at a time than Sonic 1 SMS.

Yeah, and sprite size and number probably factors into this to a significant degree: Edusoft looks as though it doesn't have to potentially move lots of sprites (Sonic, badniks, rings) on the screen at any one time, which makes smaller sprites quite necessary for StH.

Also, as Black Squirrel said, the size of Sonic relative to the frame could well have been another reason.

[GeneralAdmiralChipotle]

Black Squirrel, on 03 March 2013 - 12:28 PM, said:

It's all about screen estate - in the Mega Drive and Master System platformers Sonic takes up about 1% of the screen (and it's a similar story for Mario on the NES). It's a pretty good size to be - just enough detail to see the character, but "zoomed out" enough to see what's coming as you traverse through the stage.

Sonic Blast is an example of when you shove big sprites into a small window - you can't see what's coming, and the level design (and game as a whole) suffers as a result. Sonic takes up about 5% of the Game Gear window in that game.


Otherwise you have to remember an entirely different team worked on the Master System (and Game Gear) Sonic 1 and probably didn't have access to all the final assets (which probably explains why there's no Marble Zone or Spring Yard or whatever). They were never going to look identical - Edusoft came much later and has a completely different style of play

also I'd say it looks pretty awful at times but whatever

I agree with you for the most part, and I knew beforehand that Sonic 1 SMS didn't have a game to base itself off of, but you can still see some things that weren't very hard to do for Sonic 1 SMS. Notice the gradient background in the two minigames in Edusoft. The SMS game even uses some of the same colors in drawing the spikes on the ground that could just as easily be used to give the skyline color depth. I also noticed that Sonic's sprite in Edusoft is hardly bigger than his SMS sprite. Color and animation really make the difference with this game. The Edusoft game has rippling water effects as well as rippling lava in the trampoline minigame. Even Sonic's jump in the trampoline looks like a much smoother parabolic trajectory. I can nitpick, but I'm running out of trial posts and I don't know if one of the admins will let me have 20 more posts, and I don't want to make it obvious I had enough free time to spend doing 2nd grade math and word scrambles in Sonic Edusoft for 5 hours (WHO SAID CRAZY!? I AM NOT CRAZY, YOU'RE CRAZY!). I did notice the viewing area is a little bit smaller, but it's nowhere near as bad as the small viewing area of Super Mario Bros. Deluxe for GBC (viewing area reduced from 16x16 tiles in SMB to 10x10 tiles), and that game was still great despite losing over half the viewing area. Hardware just isn't a massive constraint. Cutting the color palette from 64 to 32 colors reduces VRAM usage by 1/2, and reducing the field of view by a couple tiles and lowering the onscreen sprite count should take care of the rest. Sonic 1 for Genesis/MD didn't even push the hardware to its limits. I can't really think of a part of that game that used more than 90% of the VRAM while hacking it until I started throwing in badniks and switch puzzles all willy-nilly.

EDIT: Capitalization error fixed

This post has been edited by GeneralAdmiralChipotle: 03 March 2013 - 01:30 PM

[minichapman]

On an unrelated note, the top right picture with the wagging finger Sonic just feels awkward.
it just looks like he's getting busy with his right hand.

[Black Squirrel]

The overly blue backgrounds are a result of hardware limitations - on the Mega Drive there are layers dedicated to the background, while on the Master System, the background belongs to the same set of tiles as the foreground and they can never overlap each another.

Essentially you'd have to have multiple sets of slopes and loops and you're limited to how many of those you can store. Alternatively it would look like garbage, or you'd have to be extremely clever with what you do. Again, Edusoft doesn't really have this problem because we're dealing with mostly static screens.

By the time you reach Triple Trouble ways are found to work around these limitations. You have a constantly adjusting skyline and loops/half pipes are raised off the ground, but it sort-of works. But you can't do detail - drawing attention to a lack of parallax scrolling, particularly in a fairly fast-paced game like Sonic wouldn't do them any favours.

[dsrb]

minichapman, on 03 March 2013 - 01:31 PM, said:

On an unrelated note, the top right picture with the wagging finger Sonic just feels awkward.
it just looks like he's getting busy with his right hand.

control
standard MANUAL

[doc eggfan]

Black Squirrel, on 03 March 2013 - 01:43 PM, said:

The overly blue backgrounds are a result of hardware limitations - on the Mega Drive there are layers dedicated to the background, while on the Master System, the background belongs to the same set of tiles as the foreground and they can never overlap each another.

Essentially you'd have to have multiple sets of slopes and loops and you're limited to how many of those you can store. Alternatively it would look like garbage, or you'd have to be extremely clever with what you do. Again, Edusoft doesn't really have this problem because we're dealing with mostly static screens.

By the time you reach Triple Trouble ways are found to work around these limitations. You have a constantly adjusting skyline and loops/half pipes are raised off the ground, but it sort-of works. But you can't do detail - drawing attention to a lack of parallax scrolling, particularly in a fairly fast-paced game like Sonic wouldn't do them any favours.

I had this very issue with Sonic 2 LD. I used to get people complaining about the "mistakes" in the background horizon, but it's not possible to keep it perfect unless you had multiple versions of every 32x32 tile, and then you run out of space.

[nesboy43]

Sonic 1 SMS is processing a full game environment and its assets (including multiple objects with their own rule set). Sonic 1 SMS also has a relatively complex physics system. Edusoft does not have anything too complex in terms of game design so they could put in detailed sprites since they had the RAM to do so. Look at the screen in Sonic and Knuckles that pops up when you lock on a cart that isn't S2 or S3 (the "No Way Screen"). These are some incredibly detailed (almost 3D) models that the game is showing, but the characters do not look like that in game. Since it is a mostly static screen they had the memory to do something advance looking (same goes for the title screen).

[GerbilSoft]

GeneralAdmiralChipotle, on 03 March 2013 - 01:15 PM, said:

Cutting the color palette from 64 to 32 colors reduces VRAM usage by 1/2

This isn't actually the case on SMS/MD. All sprites are limited to a palette of 16 colors on both systems. Tiles are 4bpp, and one 8x8 tile takes up 32 bytes of VRAM.

The difference is that on MD, there's four palettes, and sprites can use any one of the four palettes. On SMS, sprites are limited to using the second 16-color palette (out of two; tiles on the background scroll plane can use either palette.)

[Cooljerk]

It doesn't. Sonic 8-bit has a cohesive art style that fits the limitation of the system. Sonic Edusoft is just a bunch of genesis sprites with their color depth crudely reduced against some appallingly amateurish backgrounds. To me, this is like being amazed by Sonic Blast's graphics.

[tokumaru]

GerbilSoft, on 04 March 2013 - 10:59 PM, said:

GeneralAdmiralChipotle, on 03 March 2013 - 01:15 PM, said:

Cutting the color palette from 64 to 32 colors reduces VRAM usage by 1/2

This isn't actually the case on SMS/MD.

Even if you completely disregard the use of palettes and consider direct color indexing, the difference between 64 colors (6 bits) and 32 colors (5 bits) is just 1 bit, so graphics would be ~83% of the size, not 50%.