Why the Genesis video resolution was higher than most other systems at the time?

[tisurame]

When the Genesis was released in 1988, very few arcade boards at the time was able to produce the same video resolution (320x224). There are a lot of systems with a much better hardware but using a lower resolution, like Namco System 2 (288x224), Konami TMNT2 Based hardware (288x244) or Neogeo (304x224). The same could be said about the home consoles (SNES = 256x224).

Is there any technical reason for that?

[Chilly Willy]

When the Genesis was released in 1988, very few arcade boards at the time was able to produce the same video resolution (320x224). There are a lot of systems with a much better hardware but using a lower resolution, like Namco System 2 (288x224), Konami TMNT2 Based hardware (288x244) or Neogeo (304x224). The same could be said about the home consoles (SNES = 256x224).

Is there any technical reason for that?

TV overscan. 320 pixels is NOT what you could see - overscan meant that of the 320 pixels, you might see 304 down to as little as 288 pixels, but it varied from TV to TV, so they allowed more with guidelines on where to keep the action and stats so that nearly all TVs showed all the "important" pixels. That same TV frame on 256 wide modes means you might see as little as 228 pixels - the same rules about overscan apply to all consoles. It's only with the advent of digital TV circuits and especially digital displays that overscan has dropped to almost nothing. You STILL lose several pixels on either side of the display on most TVs, even modern LCDs. If you know how to get into the service mode of the TV, you can adjust the overscan to a certain amount - perhaps even eliminate it altogether depending on the TV.

[tisurame]

Hum. I don't think the overscan area eat that many pixels, and the overscan is much less prominent on the horizontal resolution. On the vertical resolution there are a lot of pixels hidden by the overscan area, but since Genesis games use x224 (and not x240), it's also a negligible problem.

For example, most PSOne games use 320x240. Then, a SDTV will only display 224 (vertical) pixels.

Overscan doesn't seem to be a valid reason. The SEGA arcade boards since the mid 80's started to use 320 pixels - so, I'm not sure why others companies did not do the same.

No doubt, with the resolution increase there is a huge impact in the viewable area of the game, and since most games are horizontal oriented, it makes much more sense to increase the horizontal resolution to 320 pixels and with that achieve a near perfect 4:3 aspect ratio. You can see a lot of arcade boards with multiple CPUs, sound chips and other crazy stuff - but using a resolution less than 320. So, I was wondering why.

[Joe Redifer]

Overscan wasn't the reason. There was a giant border around all games (without exception) to account for that. But it would eat up a few pixels. I know that if you draw a perfect circle in a game that runs at 256x224 it will be horizontally stretched when viewed on a TV screen. This is why many SNES games look "fat". Compare Earthworm Jim, for example. Many, many SNES games are guilty of this. However if you draw a perfect circle in a game that has a 320x224 resolution, then you will get a very nearly perfect circle on the TV screen. 320x224 is closer to a square pixel version of a TV's aspect ratio. 256x224 does not use square pixels and that is taken into account during design as often as it should have been. Also, many games that were designed for 256-wide screens on other systems were squished inside a 320-wide screen ont he Genesis and given a status bar to make up for the extra screen real-estate it afforded like Devil's Crush/Dragon's Fury and Zombies ate my Neighbors. Also Blackthorne.

[Chilly Willy]

Overscan wasn't the reason. There was a giant border around all games (without exception) to account for that. But it would eat up a few pixels. I know that if you draw a perfect circle in a game that runs at 256x224 it will be horizontally stretched when viewed on a TV screen. This is why many SNES games look "fat". Compare Earthworm Jim, for example. Many, many SNES games are guilty of this. However if you draw a perfect circle in a game that has a 320x224 resolution, then you will get a very nearly perfect circle on the TV screen. 320x224 is closer to a square pixel version of a TV's aspect ratio. 256x224 does not use square pixels and that is taken into account during design as often as it should have been. Also, many games that were designed for 256-wide screens on other systems were squished inside a 320-wide screen ont he Genesis and given a status bar to make up for the extra screen real-estate it afforded like Devil's Crush/Dragon's Fury and Zombies ate my Neighbors. Also Blackthorne.

Uh - no. 320x224 is NOT square, it's almost perfectly NTSC PAR (10:11). It's CLOSER to square than 256x224, but not so much that you can ignore the aspect ratio. It was as I said - overscan reduced the usable space on the screen, meaning you needed a slighter higher horizontal resolution to do more detailed images.

[Joe Redifer]

It's CLOSER to square than 256x224
Yeah, that's pretty much exactly what I said:


320x224 is closer to a square pixel version of a TV's aspect ratio.

320 x 240 would be square, but the 320x224 area is not being stretched to the edges of the screen, so in development it can basically be treated as square pixels without much worry of distortion when the image is displayed on a TV screen. But your overscan explanation is common sense. The higher resolution, the more detailed the images. But it doesn't answer tisurame's original question. Lots of other game systems of the time which also worked inside the same overscan area predominantly used a lower resolution. Even the Neo Geo you can see a bit of black pillarboxing on many NTSC sets (though very, very slight). Overscan was not the reason for the 320 mode otherwise all systems would have 320. Genesis had a 256 mode as well.

I will accept that overscan IS the reason for the 224 instead of 240.

[sheath]

The Genesis' 40 cell wide mode just adds another column of 8x8 cells. I assumed this didn't affect the sprite pixel aspect ratios at all unless the developer wanted it to.

[j_factor]

Lots of old computers had a predominant resolution of 320 x 200, including the C128, Amiga, Atari ST, Apple IIgs, Tandy CoCo 3, and PC VGA in 256-color mode. I guess that was probably different in Europe.

[Joe Redifer]

The Genesis' 40 cell wide mode just adds another column of 8x8 cells. I assumed this didn't affect the sprite pixel aspect ratios at all unless the developer wanted it to.

Basically, running a game in 320 mode does not mean you take a hit in the sprites nor do you gain anything from the sprites by running in 256 mode. The Genesis accommodates for the increase in resolution in 320 mode. As for their aspect ratios of course it changed. One is 256 pixels across and the other 320 pixels across all displayed in the same TV space.

[Sik]

Basically, running a game in 320 mode does not mean you take a hit in the sprites nor do you gain anything from the sprites by running in 256 mode.
Um, actually yes... though the other way. The sprite limits are increased in H40 (320) mode. On the other hand, H32 (256) mode lets you get away with less pixels, which can be useful when you're really tight on memory usage.

[sheath]

What I was asking without asking is if the sprites' aspect ratio changes between 32 Columns and 40 Columns. I think I know the answer to that question though because I've seen people talking about sprites getting stretched and needing to be redrawn for 320 wide mode.

[Sik]

ALL pixels get stretched. The screen size remains the same, the pixel size change. Pretty much the same way as for different resolutions in computers.

[sheath]

Is the background color that goes outside of the normal game screen considered part of the horizontal resolution?

[Chilly Willy]

256 wide mode and 320 wide mode occupy the same space on the screen. All that changes is the width of the individual pixel. That means the in 320 wide mode, more pixels are visible and they are closer to square in aspect ratio. The "closer to square AR" is helpful with art, but not crucial as you can see from all the consoles that have 256 wide displays. The "more pixels are visible" is the REAL improvement since that means you can show more detail.


Is the background color that goes outside of the normal game screen considered part of the horizontal resolution?

No, but it technically should. Anything that is not part of the horizontal blank range should be considered the active line and therefore contribute to the horizontal resolution. TECHNICALLY, most "320" wide display modes are closer to 340 to 360 wide with the extra pixels not addressable and automatically filled with the background color. Now you're getting into the nuts and bolts of the VDP, so it will vary on the exact console, and sometimes revisions of the console.

[Sik]

No, but it technically should. Anything that is not part of the horizontal blank range should be considered the active line and therefore contribute to the horizontal resolution. TECHNICALLY, most "320" wide display modes are closer to 340 to 360 wide with the extra pixels not addressable and automatically filled with the background color.
At this point you should probably just ditch the concept of resolution and use frequencies, considering how TVs have absolutely no concept of pixels at all. The idea of pixels is imposed by whatever generates the signal, not the display.


Now you're getting into the nuts and bolts of the VDP, so it will vary on the exact console, and sometimes revisions of the console.
Or in this case, even the pixel width can change within a given scanline... (and technically those shouldn't be even considered pixels, but rather VDP clock cycles)

[Kamahl]

The genesis uses 320px because it's awesome.
(Honestly I have no idea, it's great that it does though).

[sheath]

256 wide mode and 320 wide mode occupy the same space on the screen. All that changes is the width of the individual pixel. That means the in 320 wide mode, more pixels are visible and they are closer to square in aspect ratio. The "closer to square AR" is helpful with art, but not crucial as you can see from all the consoles that have 256 wide displays. The "more pixels are visible" is the REAL improvement since that means you can show more detail.



No, but it technically should. Anything that is not part of the horizontal blank range should be considered the active line and therefore contribute to the horizontal resolution. TECHNICALLY, most "320" wide display modes are closer to 340 to 360 wide with the extra pixels not addressable and automatically filled with the background color. Now you're getting into the nuts and bolts of the VDP, so it will vary on the exact console, and sometimes revisions of the console.

Okay, so the fact that I typically don't see the boarder color on my TVs and properly cut that section out when I make videos isn't lowering the resolution? That jives with the fact that when I record a 320 wide game and crop out the border the videos and pics are all 640x448.

[Chilly Willy]

Okay, so the fact that I typically don't see the boarder color on my TVs and properly cut that section out when I make videos isn't lowering the resolution? That jives with the fact that when I record a 320 wide game and crop out the border the videos and pics are all 640x448.

D1 NTSC is 704x480 and goes from the end of the hblank for one line to the start of the hblank of the next line as well as from the end of the vblank to the start of the next vblank, summed over two fields. Consoles tend to output what is referred to as D1/2, which is 352x240. That has the exact same characteristics, going from blank end to blank start, but is 240p instead of 480i. 352x240 is exactly 4:3 for the display aspect ratio, taking into account that D1/2 pixels have a PAR of 10:11. If you calculate those values back, 320 wide with 4:3 DAR and NTSC PAR SHOULD give ~219 lines high, so the Genesis 320 has pixels just slightly wider or they merely accept that 224 will be a little taller than 4:3 just to keep the display height an even number of cells in height.

[Black_Tiger]

Sega was an arcade game developer with current arcade hardware that ran at a resolution of 320 x 224 and previous arcade hardware that ran at 256 x 2224. Supporting those resolutions with their new console just made sense for porting their exclusive hit arcade games.

The Mega Drive was also brought in as competition for the PC Engine, which had games using a resolution of 336 x 240/224.

If anything, not supporting the 320 x 224 resolution would have been questionable. I'm guessing that all of the nice looking PCE games which only used the 256 x 224 resolution factored into Nintendo not bothering to go beyond that (for practical use) with the Super Famicom.

[Curryman123]

The genesis uses 320px because it's awesome.
(Honestly I have no idea, it's great that it does though).

If that's the cause of blurriness than it's not awesome.

[Chilly Willy]

Sega was an arcade game developer with current arcade hardware that ran at a resolution of 320 x 224 and previous arcade hardware that ran at 256 x 224. Supporting those resolutions with their new console just made sense for porting their exclusive hit arcade games.

The Mega Drive was also brought in as competition for the PC Engine, which had games using a resolution of 336 x 240/224.

If anything, not supporting the 320 x 224 resolution would have been questionable. I'm guessing that all of the nice looking PCE games which only used the 256 x 224 resolution factored into Nintendo not bothering to go beyond that (for practical use) with the Super Famicom.

This is almost certainly the real reason. :)

[tisurame]

Well... But what are the disadvantages of using a higher resolution? I suppose it's just not a matter of choice, otherwise Nintendo would choose to also use 320x224 with the SNES.

[sheath]

If I recall it depends a lot on the system bus speed, which is also usually dependent on the main CPU speed in some way. The SNES' DMA to its PPUs is also significantly slower than the Genesis' DMA to its VDP.

That is all in the nitty gritty engineering of the systems though. Nintendo obviously thought that more colors, the completely sample based sound chip, and Mode 7 more than made up for anything their competition could show. That is in fact how they marketed the SNES.

[Sik]

Well... But what are the disadvantages of using a higher resolution? I suppose it's just not a matter of choice, otherwise Nintendo would choose to also use 320x224 with the SNES.
Um, takes up more memory? =P

And I guess Nintendo stuck to 256×224 because that's what the NES used (even if they never implemented NES compatibility in the end). Note the SNES does have a 512-pixels wide resolution (though if I recall correctly it's faked by using blending, which is why the blending hardware isn't available in that mode).

[Black_Tiger]

Well... But what are the disadvantages of using a higher resolution? I suppose it's just not a matter of choice, otherwise Nintendo would choose to also use 320x224 with the SNES.

Well, there are related pros and cons with various consoles, but they are simply related to resolutions, not a result of it. The Genesis can't shade as well or pack as much detail with the same variety of color as the other consoles, so the higher resolution helps with dithering and defining detail using fewer colors. The PC Engine can only line up 256 pixels wide worth of sprites per screen, so using its higher resolutions means less sprites on-screen than the Genesis. The SNES technically has higher vertical and horizontal resolutions, but I assume that they are also tied to various limitations (like interlacing) since they aren't commonly used.

If the SNES retained all of it's color abilities, but used a 320 pixel-wide resolution, it would take more memory to display the same proportionate amount of artwork per screen, so the lower resolution used in almost every SNES game keeps cart sizes smaller than if they ran in a higher resolution.

[Kamahl]

If that's the cause of blurriness than it's not awesome.
It has nothing to do with the blurriness.

[tisurame]

Well, there are related pros and cons with various consoles, but they are simply related to resolutions, not a result of it. The Genesis can't shade as well or pack as much detail with the same variety of color as the other consoles, so the higher resolution helps with dithering and defining detail using fewer colors. The PC Engine can only line up 256 pixels wide worth of sprites per screen, so using its higher resolutions means less sprites on-screen than the Genesis. The SNES technically has higher vertical and horizontal resolutions, but I assume that they are also tied to various limitations (like interlacing) since they aren't commonly used.

If the SNES retained all of it's color abilities, but used a 320 pixel-wide resolution, it would take more memory to display the same proportionate amount of artwork per screen, so the lower resolution used in almost every SNES game keeps cart sizes smaller than if they ran in a higher resolution.

OK. My main question is if the lack of colors from the Genesis hardware is somehow related with the higher resolution.

Cons = fewer colors
Pros = higher resolution

Is it safe to assume that?

[Kamahl]

OK. My main question is if the lack of colors from the Genesis hardware is somehow related with the higher resolution.

Cons = fewer colors
Pros = higher resolution

Is it safe to assume that?
Nope, no relation in this case.
Now we could debate for ages about cutting corners in some places to add in others, but that wouldn't be directly related to the resolution.

[Sik]

The lower amount of colors is directly tied to the low amount of memory, period. I guess this is because they tried to put CRAM on-die instead of having it separate (though having separate CRAM and color DAC could have potentially bumped up the price of the console quite a bit).

[TrekkiesUnite118]

The lower amount of colors is directly tied to the low amount of memory, period. I guess this is because they tried to put CRAM on-die instead of having it separate (though having separate CRAM and color DAC could have potentially bumped up the price of the console quite a bit).

Did making CRAM a part of the VDP also make it impossible to put traces on the expansion port and cartridge port allowing for CRAM expansion? If it didn't I wonder how much more that would have cost to do.

[Sik]

Did making CRAM a part of the VDP also make it impossible to put traces on the expansion port and cartridge port allowing for CRAM expansion? If it didn't I wonder how much more that would have cost to do.
No, given that all lines are available in the VDP (and some more... e.g. you can genlock two VDPs together). In fact, arcades based off the VDP use external CRAM and color DAC. They were probably just being cheap in this case =P

[Curryman123]

It has nothing to do with the blurriness.
yeah....I figured later that I spat out some nonsense.

[Tom M.]

TV overscan. 320 pixels is NOT what you could see - overscan meant that of the 320 pixels, you might see 304 down to as little as 288 pixels, but it varied from TV to TV, ...

Nonsence. Overscan has nothing to do with horizontal resolution, like 320 pixels on Genesis. Overscan is related to scanlines, so in case of Genesis, to 224 pixels in vertical resolution. If Genesis used 320x240 there would be a lot of TVs that wouldn't display the whole picture because 240 scanlines at 60 Hz is simply too much for normal 15 kHz TV set.

And why 320 pixels On Genesis and only 256 on SNES? Because Genesis :rock: does...

[Sik]

Technically Sega reported that there was one row of tiles at the top and the bottom that weren't guaranteed to be visible on TVs... and that's for 224 lines, so basically 240 lines would have been a waste (the SNES doesn't have a 224 lines mode, so either you're stuck with reduced vblank time or you're forced to use raster effects to get that extra blanking time).

[Chilly Willy]

Nonsence. Overscan has nothing to do with horizontal resolution, like 320 pixels on Genesis. Overscan is related to scanlines, so in case of Genesis, to 224 pixels in vertical resolution. If Genesis used 320x240 there would be a lot of TVs that wouldn't display the whole picture because 240 scanlines at 60 Hz is simply too much for normal 15 kHz TV set.

What are you, an idiot? Of COURSE there's such a thing as horizontal overscan!! Don't open your mouth if you haven't the vaguest idea what you're talking about. :hand: :shame:

[Sik]

In the end both of you are wrong though because I really doubt Sega went with 320×224 because of any overscan issues =P (in fact I think the only thing that may be even remotely related to that is the V28/V30 switch, given how it only works properly in PAL, which shows more lines)

[Chilly Willy]

In the end both of you are wrong though because I really doubt Sega went with 320×224 because of any overscan issues =P (in fact I think the only thing that may be even remotely related to that is the V28/V30 switch, given how it only works properly in PAL, which shows more lines)

If you believe the V28/30 switch is remotely related, then you MUST also believe the H32/40 switch is related, even if remotely, for the same reasons. :)

In any case, the SEGA Software Guidelines clearly state that games may not put important info into either the first or last columns of the display due to horizontal overscan. If you NEED 256 pixels for your display and they MUST be visible pixels, you have no choice but to run in H40 mode.

[JDB]

it's because it has MEGA power

[Sik]

If you believe the V28/30 switch is remotely related, then you MUST also believe the H32/40 switch is related, even if remotely, for the same reasons. :)
Not really. The V28/V30 switch affects the amount of space the rendering area takes up on screen (vertical size changes, pixel size remains the same), while the H32/H40 switch doesn't (horizontal size remains the same since the size of pixels change). In fact, you get overscan in both H32 and H40 modes.

[Chilly Willy]

Not really. The V28/V30 switch affects the amount of space the rendering area takes up on screen (vertical size changes, pixel size remains the same), while the H32/H40 switch doesn't (horizontal size remains the same since the size of pixels change). In fact, you get overscan in both H32 and H40 modes.

Yes, but H40 gives you more VISIBLE pixels to mess with. That's the point. How they do it is immaterial.

[Tom M.]

OK I admit there is also a horizontal ovescan, but what I was trying to say: that is not the problem. the problem is always scanlines vs refresh rate - that's where some TVs start not to display the whole picture even when you adjust them (unlike horizontal adjustments which are always doable!!!)...

[Sik]

Yes, but H40 gives you more VISIBLE pixels to mess with. That's the point. How they do it is immaterial.
I said that V28/V30 was relevant to overscan because V28 in PAL does not have vertical overscan, while V30 does (as opposed to NTSC which always has vertical overscan). On the other hand, H40/H32 really doesn't affect horizontal overscan.

In the end they just probably added H40 mode because they just wanted a higher resolution, period.

[synapse]

You guys got it all wrong. The Mega Drive had blast processing. Which means guts. Guts to feature a higher resolution. That's all ;)

[Da_Shocker]

3 words

HIGH DEFINITION GRAPHICS!

[Chilly Willy]

OK I admit there is also a horizontal ovescan, but what I was trying to say: that is not the problem. the problem is always scanlines vs refresh rate - that's where some TVs start not to display the whole picture even when you adjust them (unlike horizontal adjustments which are always doable!!!)...

Sorry I was rude about it. Not been having a good week. If you can get into the service mode, you can often adjust the overscan to make more/all of the video visible. I did that on my TIMM, which had SEVERE overscan by default.

[kool kitty89]

The Genesis' 40 cell wide mode just adds another column of 8x8 cells. I assumed this didn't affect the sprite pixel aspect ratios at all unless the developer wanted it to.
It changes the resolution for the entire screen, all pixels will be narrower than in H32, though you also increase sprite bandwidth to compensate (you get 80 sprites on screen, 20 per line, and up to 320 pixels per line vs 64, 16, 256), though you still need more VRAM space (and ROM) to hold those higher res sprites. (otherwise you just get narrower sprites of the same resolution, like setting an emulator to square pixels for H32 games -which often looks better regardless of that since most games assume square pixels)

The PCE's higher res modes don't add to sprite bandwidth, so you're stuck with 256 pxels/16 sprites per line (and 64 on screen) in all modes, which is the main reason the high res modes were less popular. (sprites will be smaller and take up less of the screen -or have more flicker/drop-out -especially in 512 res)





Um, takes up more memory? =P

And I guess Nintendo stuck to 256×224 because that's what the NES used (even if they never implemented NES compatibility in the end). Note the SNES does have a 512-pixels wide resolution (though if I recall correctly it's faked by using blending, which is why the blending hardware isn't available in that mode).
Both the PCE and MD supported the NES/SMS(etc) resolution too (5.37 MHz) but had higher res modes on top of that . . . so making the VDP resolution more programmable would have been the issue, not NES compatibility.

For most games and most TVs at the time, the higher res wasn't that big of an advantage, though having closer to square pixels is nice too (MD went too far for that really to be worthwhile in NTSC -though incidental the PAL/NTEC compromise is nice).

Given the SNES's master clock (21.48 MHz), that could conveniently be divided to 7.16 MHz, so a clock source wasn't an issue in this case either. (and the exact same resolution as the Amiga and PCE highres) Albeit that's no good for square pixels . . . where you'd really want ~6.25 MHz, and the lowest 5.37 MHz-compatible clock that comes close to that would be 32.22 MHz (dividing nicely to both 3.58 MHz and 5.37 MHz while offering 6.44 MHz too -slightly narrower than square, but pretty close and a slight benefit to PAL users too).






TV overscan. 320 pixels is NOT what you could see - overscan meant that of the 320 pixels, you might see 304 down to as little as 288 pixels, but it varied from TV to TV, so they allowed more with guidelines on where to keep the action and stats so that nearly all TVs showed all the "important" pixels. That same TV frame on 256 wide modes means you might see as little as 228 pixels - the same rules about overscan apply to all consoles. It's only with the advent of digital TV circuits and especially digital displays that overscan has dropped to almost nothing. You STILL lose several pixels on either side of the display on most TVs, even modern LCDs. If you know how to get into the service mode of the TV, you can adjust the overscan to a certain amount - perhaps even eliminate it altogether depending on the TV.
Overscan is only a factor for vertical resolution, but only percentage of horizontal resolution . . . actual horizontal resolution is virtually unlimited and mainly dependent on dot clock (though practically limited by composite video and RF -or other transmission- limits as well as beam precision and phosphor dot pitch).

The main issue here is dot clock, and that's what the Genesis had over many contemporaries with H40 (320 wide mode) which did indeed allow roughly 320 visible pixels on average TVs of the early 90s (some a bit less and some might actually show a bit of boarder -ie TVs with very tight calibration with no overscan or even overkill showing more overscan than normal NTSC screen spec -albeit the latter case usually only from custom calibration).
In the MD's case, this is 6.7 MHz vs the common 5.37 MHz of NES/SMS/SNES/PCE(lores) and MD H32 (among others -like the Colecovision and MSX).
The Neo Geo runs at 6 MHz and gives nearly square pixels in NTSC (only slightly wide), but only shows ~280 visible pixels on average TVs. (ie TVs that show just under 256 pixels at 5.37 MHz or just under 320 pixels at 6.7 MHz)

However, there were several computers/consoles prior to the MD that have higher dot clocks: the PC Engine has 2 higher res modes (7.16 and 10.74 MHz -the former being much more commonly used), the Amiga's lowest resolution was 7.16 MHz, the Apple II used 7.16 MHz (though only 280 pixels), CoCo used 7.16 MHz (but only 256 pixels), the A8 computers have a 7.16 MHz mode, the C64 has an 8 MHz mode (320 wide with a large boarder), Atari ST's lowest res is 8 MHz (320 pixels with a large boarder), etc. But, prior to the MD, only ST and Amiga games used higher resolutions than 5.37 MHz as routine (and, again, both are higher dot clocks than the MD -and the Amiga wasn't limited to 320 pixels like the ST so the added screen space could be nominally useful -otherwise you'd at least be guaranteed to have 320 pixels on-screen even on TVs with hefty overscan)


It's also interesting to note that the MD's H40 resolution at 6.7 MHz is a nice compromise for PAL and NTSC pixels in games that have square pixel art (ie both look a bit off, but are still reasonably close to square -hence Sonic being a wide oval in PAL and a tall oval in NTSC -unless you specially calibrate the monitor to show square pixels)
The Amiga (and PCE highres, etc) has almost square pixels in PAL, but very tall/narrow pixels in NTSC (though having the resolution at exactly 2x the NTSC color clock makes for fewer artifacts in composite/RF than more in-between resolutions in the same range on systems using similar video encoders . . . especially at higher dot clocks like the ST -though lower clocks also have issues as seen in the MD and Neo Geo -5.37 MHz seems to fare better though, perhaps as it's exactly 1.5x the NTSC colorburst)
The ST (and C64 highres) has even narrower pixels such that even in PAL they're a bit off (but much more so in NTSC . . . somewhat like pixels in VGA mode 13h with the monitor calibrated to stretch 320x200 to 4:3)




As to why the designs used those resolutions, that's really up to the engineers, both in terms of hardware limitations (memory capacity and bandwidth/speed and DAC speed, and convenient system clock rates -many systems used colorburst-centric timing) and concerns for video quality (possible artifacting at higher resolutions and pixel aspect ratio issues).

[kool kitty89]

OK I admit there is also a horizontal ovescan, but what I was trying to say: that is not the problem. the problem is always scanlines vs refresh rate - that's where some TVs start not to display the whole picture even when you adjust them (unlike horizontal adjustments which are always doable!!!)...
Sorry I was rude about it. Not been having a good week. If you can get into the service mode, you can often adjust the overscan to make more/all of the video visible. I did that on my TIMM, which had SEVERE overscan by default.
Horizontal overscan is a consideration, but it isn't a limitation like vertical scan resolution/overscan . . . horizontal overscan (and screen calibration) ONLY affects the number of pixels visible at a specific dot clock/resolution output by the VDP. (and virtually unlimited -only practically limited by monitor quality/video transmission quality)

This is compared to vertical resolution which is fixed (on SDTVS usually ~224 lines or a bit less -or double that for interlace).

So it's really all about the dot clock the system uses (with overscan only limiting the section of the scanline that's actually visible -which is approximately 75% of H-time on most SDTVs, or a bit more than that on some older/cheaper sets -and less than that on sets with little/no overscan or custom calibration).
Hence why the MD's H40 is "320 pixels" in the same context that H32 (and SMS/NES/etc) is "256 pixels" (for 6.71 and 5.37 MHz dot clocks, respectively). That's also why the PCE's 7.16 MHz dot mode is listed as 344 pixels. (though many older systems also used that resolution with only 320 pixels or less and a sizable boarder -save for TVs with really excessive overscan- hence resolutions being labeled as less than 344 pixels . . . or possibly more than that too -though you'd need a monitor with tighter calibration to actually display that, like 360 pixels on the Amiga or A8 -albeit the C64 or ST's 8 MHz res could easily show 380 pixels on average TVs)





The lower amount of colors is directly tied to the low amount of memory, period. I guess this is because they tried to put CRAM on-die instead of having it separate (though having separate CRAM and color DAC could have potentially bumped up the price of the console quite a bit).
Didn't the PCE take that route exactly (a separate IC holding the CRAM and DACs -similar to RAMDACs used on VGA cards)
And a 12-bit RAMDAC with 128 CRAM entries (or 121 if you forced zero to always be transparent -with 1 color reserved for the window layer) you'd still probably have a substantially smaller chip than the PCE used (9-bit DACs with 512 CRAM entries -so 4608 bits of SRAM vs 1536 or 1452 bits for 128/121 12-bit entries)

Plus, that's also a design choice that could scale very well in the long run (when larger ASICs became cheap to make), and the pin count would also be significantly reduced too. (no need for external digital pixel output lines -just analog RGB)

[Chilly Willy]

Overscan is only a factor for vertical resolution, but only percentage of horizontal resolution . . . actual horizontal resolution is virtually unlimited and mainly dependent on dot clock (though practically limited by composite video and RF -or other transmission- limits as well as beam precision and phosphor dot pitch).

Why do so many people here know NOTHING about TVs? TVs don't show the ENTIRE ACTIVE LINE, they show PART of the active line. The rest is overscan. TVs have ALWAYS had a variable amount that didn't show. This has NOTHING to do with pixel rates and dot clock or anything of the sort. It has EVERYTHING to do with the limitations of the CRT. Old tubes have problems with convergence near the edges of the TV... that is, ALL EDGES - not just the top and bottom, but the RIGHT AND LEFT EDGES AS WELL!!! Because of this, they not only don't show all the lines from top to bottom, they also cover the left and right edges of the lines they DO show to cover the mis-convergence. That is precisely why SEGA made a rule that any game that places important info (like lives or score) in the left or rightmost cell columns would be rejected out of hand. Many TVs won't show those columns due to HORIZONTAL overscan.

Is this really that hard to understand? You cannot see the whole screen - not just the top and bottom, but the sides as well. Anyone who has worked on TVs or computer monitors (like myself) will tell you this. The older the CRT, the more overscan the TV generally has. Modern CRTs have special deflection yolks and circuits to minimize convergence errors over a larger area of the display, but still have some. When they use overscan on LCD TVs, it's usually so that you see something similar to what you are used to on the older CRTs, but they've been doing less of that now that digital broadcast is the rule. My HDTV in the living room does overscan on "TV" inputs, but no overscan on the VGA input.

[Sik]

MD went too far for that really to be worthwhile in NTSC
Eh?

Also something I'm surprised nobody had mentioned yet: PCs. Two common resolutions on PCs were 320×200 and 320×240. It's possible Sega was trying to aim for the latter (320×224 is close enough, and in fact PAL effectively can do 320×240).

[kool kitty89]

Why do so many people here know NOTHING about TVs? TVs don't show the ENTIRE ACTIVE LINE, they show PART of the active line. The rest is overscan. TVs have ALWAYS had a variable amount that didn't show. This has NOTHING to do with pixel rates and dot clock or anything of the sort. It has EVERYTHING to do with the limitations of the CRT. Old tubes have problems with convergence near the edges of the TV... that is, ALL EDGES - not just the top and bottom, but the RIGHT AND LEFT EDGES AS WELL!!! Because of this, they not only don't show all the lines from top to bottom, they also cover the left and right edges of the lines they DO show to cover the mis-convergence. That is precisely why SEGA made a rule that any game places important info (like lives or score) in the left or rightmost cell columns would be rejected out of hand. Many TVs won't show those columns due to HORIZONTAL overscan.

Is this really that hard to understand? You cannot see the whole screen - not just the top and bottom, but the sides as well. Anyone who has worked on TVs or computer monitors (like myself) will tell you this. The older the CRT, the more overscan the TV generally has. Modern CRTs have special deflection yolks and circuits to minimize convergence errors over a larger area of the display, but still have some. When they use overscan on LCD TVs, it's usually so that you see something similar to what you are used to on the older CRTs, but they've been doing less of that now that digital broadcast is the rule. My HDTV in the living room does overscan on "TV" inputs, but no overscan on the VGA input.
I already know all of that and pointed it out several times in my last 2 posts. (among other things)

Horizontal overscan only affects how much of a scanline is visible, it doesn't limit the horizontal resolution (that's limited by the dot clock of the VDC -and practically limited by the quality of the analog signal and monitor being used).


You could easily have 1024 visible pixels on an SDTV at factory spec if the VDC supported a high enough dot clock (ie ~22 MHz) . . . though the pixels might not be clearly visible unless you used s-video or component (or monochrome composite) and had a decent quality/size TV.



For SDTVs, horizontal and vertical overscan are fixed factors for the most part (there's some variety from TV to TV, but a general defacto-standard for calibration that usually has overscan a bit beyond NTSC spec -hence ~224/448 lines rather than 240/480, and a proportionally "missing" part of the horizontal display too -the true spec intending approximately 80% of H-time to be active display)




Obviously, with manual/custom calibration, you could have a larger portion of a horizontal line visible (or less -like if you wanted an Atari ST or C64's display to fill the screen), but for standard TVs (and cheaper monitors without user-adjustable scan controls), you're stuck with the default calibration. (and hardware designers have to work around that -thus visible horizontal resolutions are limited by dot clock and maximum vertical resolution is totally fixed -aside from interlacing)

[kool kitty89]

Eh?
I meant in terms of pixel aspect ratio for NTSC. (the MD's resolution is only very slightly closer to square than the common 5.37 MHz -on properly calibrated TVs)
The higher resolution is still advantageous in other areas, though with additional trade-offs. (namely memory usage and considerably greater composite video artifacting -though the latter can come in handy if you want to have blended/blurred pixels . . . though moire artifacts can still be a problem there too)

Given the SMS/MD 53.7 MHz master clock, it would have been interesting to see a VDP mode clocked at 1/9 that rate (5.97 MHz) which would be much closer to NTSC square pixels (and nearly identical to the Neo Geo) while obviously not pushing the VDP/VRAM speed any higher (opposed to 7.16 MHz, which would obviously need more bandwidth/speed).


Also something I'm surprised nobody had mentioned yet: PCs. Two common resolutions on PCs were 320×200 and 320×240. It's possible Sega was trying to aim for the latter (320×224 is close enough, and in fact PAL effectively can do 320×240).
320x240 wasn't common for PC games until the mid 90s (and by that point, much higher resolutions were common too), so 320x200 would be the only factor there

Plus, (IBM compatible) PC gaming was very niche/limited at the time the MD was being developed (and mainly limited to CGA/EGA/Tandy graphics and PC Speaker/Tandy sound) . . . unless you meant "home computers" in a more general sense than PC-compatibles, in which case there's much more to compare there. (including the high-end gaming computer in Japan at that point -the X68000- which had games usually running at 256x240 iirc, the much weaker but market-dominant NEC PC98 series with 640x400 with 16 indexed colors)


Plus, if you DID want pixel-accurate PC (or Amiga) type resolutions and aspect ratios, then you'd want a 7.16 MHz dot clock (or close to it) since CGA/EGA/Tandy games ran at that and VGA 13h normally has similar pixel aspect too. (unless you ran it at 60 Hz or manually adjusted the monitor)

[Jorge Nuno]

Im not sure about this but I beleive MD's full line width (3420 master clocks, on H32 and H40) is chosen so that it remains an integer multiple of both NTSC and PAL color bursts (228 NTSC / 285 PAL bursts), meaning that color/Y artifacts resulting from compositing would remain stationary onscreen instead of moving to either side.

This would explain the odd EDClk division ratio, and rule out other crazy dividers like MClk/9 :U

On the other hand the 32X has a dedicated oscillator for color ruining this effort of line sync with the burst, and thus causing some "moving artifacts" on composite.

[kool kitty89]

Im not sure about this but I beleive MD's full line width (3420 master clocks, on H32 and H40) is chosen so that it remains an integer multiple of both NTSC and PAL color bursts (228 NTSC / 285 PAL bursts), meaning that color/Y artifacts resulting from compositing would remain stationary onscreen instead of moving to either side.

This would explain the odd EDClk division ratio, and rule out other crazy dividers like MClk/9 :U
Do you mean that the dot crawl will remain consistent/solid from 1 line to the next rather than being staggered?

That doesn't seem to be the case for other platforms using 5.37 MHz dot clocks . . . (artifacts vary widely across the different systems, but the resolutions are all identical -TMS9918 derivatives, SMS, NES, MD, PCE, etc)


On the other hand the 32X has a dedicated oscillator for color ruining this effort of line sync with the burst, and thus causing some "moving artifacts" on composite.
Yet the 32x's video encoder shows fewer artifacts in general than any of the MD encoders, overall. (moire is MUCH less of an issue than on any encoder save the Samsung KA2195D and the picture is about as sharp as the best composite encoders on the MD -and much better than the KA2195D; the dot crawl seems a bit better too, but that's more TV dependent it seems -the blur is TV dependent to some extent too, though moire is not, though moire is usually not visible for H32 stuff and often not at all for PAL -presumably due to the higher color clock)

The dot crawl itself seems to be very similar on the 32x too. (and, unlike most contemporaries, present solely as vertical bars rather than checkerboard patterns -which IMO is preferable since you don't get swarming like with checkerboarding)

[tisurame]

In the end, I really think the higher resolution is a great advantage compared to the SNES, for example. And it's something highly ignored when people talk about each system.

http://img163.imageshack.us/img163/7106/reileaosnesmega.gif

As you can see, the higher resolution really affects the gameplay, since it gives you a wide view - unlike the color amount.

[Christuserloeser]

Seems to me that Lion King was designed for MS-DOS PCs with 320x240 VGA in mind and then downgraded for Mega Drive (reduced colors) and SNES (reduced resolution). The MS-DOS version clearly was the best looking version of the game.

A comparable original Mega Drive game usually looks more colorful while graphic artists for an original SNES game take the low resolution into account when designing the graphics. If Lion King for SNES looks like on that comparison it would mean that the sprites appear stretched on TV.

[Black_Tiger]

In the end, I really think the higher resolution is a great advantage compared to the SNES, for example. And it's something highly ignored when people talk about each system.

http://img163.imageshack.us/img163/7106/reileaosnesmega.gif

As you can see, the higher resolution really affects the gameplay, since it gives you a wide view - unlike the color amount.

The resolution of a game only affects the view area when a game is ported without being re-proportioned. A Genesis game can also suffer when ported straight across from a different resolution.

[kool kitty89]

Seems to me that Lion King was designed for MS-DOS PCs with 320x240 VGA in mind and then downgraded for Mega Drive (reduced colors) and SNES (reduced resolution). The MS-DOS version clearly was the best looking version of the game.

A comparable original Mega Drive game usually looks more colorful while graphic artists for an original SNES game take the low resolution into account when designing the graphics. If Lion King for SNES looks like on that comparison it would mean that the sprites appear stretched on TV.
Don't forget the Amiga version too. (not sure how the AGA version compares to the DOS game though . . . the music should be nearly identical though, like Aladdin -since the PC game uses MOD music . . . though the Amiga version seems to cut out music channels for SFX while the PC version doesn't -also note that some of Virgin's earlier games used Aldlib/OPL FM sound -rather poorly- like with Jungle Book -which sounds notable worse than the mediocre GEMS based MD version ;) -the case for pretty much all other GEMS games too that had Adlib PC counterparts)

The DOS game runs at 320x200 (standard VGA mode 13h), not 320x240 . . . which probably means most PC gamers had the graphics all stretched (since 13h normally gets displayed in 4:3 without a boarder in 70 Hz VGA -you could manually calibrate the monitor or drop to 60 Hz for square pixels and letterboxing though).



The resolution of a game only affects the view area when a game is ported without being re-proportioned. A Genesis game can also suffer when ported straight across from a different resolution.
True: a better example would be with a game optimized with modified graphics in 2 different versions with both scaled to the appropriate TV aspect ratios. (if we did that with Lion King, things would look "too wide" on the SNES, but also "too tall" on the Genesis -unless you aimed at PAL, then both would be too wide, but the SNES horribly so)
The Amiga version would probably look just about right in 50 Hz PAL though. (almost square pixels)

[j_factor]

Also something I'm surprised nobody had mentioned yet: PCs. Two common resolutions on PCs were 320×200 and 320×240. It's possible Sega was trying to aim for the latter (320×224 is close enough, and in fact PAL effectively can do 320×240).

I did mention that, on page 1. Kthnx. 320x240 wasn't that common, though.

[Tom M.]

320x240 would make more sence than 320x224 but as it was said, overscan troubles at 60 Hz... 50 Hz would be fine but stupid America and Japan... thanks god for ZX Spectrum and its 256x192 - fully "square pixels" 4:3 display as it should be...

[Tom M.]

horizontal overscan (and screen calibration) ONLY affects the number of pixels visible at a specific dot clock/resolution output by the VDP. (and virtually unlimited -only practically limited by monitor quality/video transmission quality)

This is compared to vertical resolution which is fixed (on SDTVS usually ~224 lines or a bit less -or double that for interlace).

Yup, 224 scanlines / 60 Hz is a safe maximum for home TVs. But if you get yourself a genuine 15 kHz (or multisync) CRT arcade monitor like Wells Gardner D9500 :sonic:, you can easily get full 240 scanlines at 60 Hz. That's why I always say: do not bother with consumer scart TVs for MAME, get yourselves specifically designed arcade monitors because they can handle pretty much every 15 kHz resolution of any video game...

[kool kitty89]

320x240 would make more sence than 320x224 but as it was said, overscan troubles at 60 Hz... 50 Hz would be fine but stupid America and Japan... thanks god for ZX Spectrum and its 256x192 - fully "square pixels" 4:3 display as it should be...
As far as pixel shape is concerned, overscan is a non-issue. What matter's is the NTSC standard resolution/calibration for the overall horizontal and vertical scan/picture shape. (ie, a TV may show more or less overscan, but the actual shape of the image should be nearly identical -just with more or less lost in the boarder)

As such, you could get square pixels extremely consistently on any TV, you just need the right pixel clock. For NTSC this is approximately 6.25 MHz, which gives roughly 298x224 pixels on TVs with average overscan (320x240 on TVs with perfect NTSC calibration and zero "extra" overscan -or custom calibration to show even more of the boarder).
You'd need double that rate for interlaced displays. (so 12.5 MHz and ~594x448i)

However, you wouldn't get square pixels with PAL TVs at that same dot clock.


Again, the Neo Geo uses 6 MHz, which is pretty close to that but not quite there (closer than either of the Genesis's resolutions). It will also be limited to roughly 286x224 on average TVs. (worse on some, better on others)

[Jay See Double You]

Okay, so leave it to me to be looking for one piece of info, find nothing of value at all on google but a long dead thread on Sega-16 where people much more knowledgeable than myself are talking about something close to but not quite what I'm asking, and then have me come along with my semi-related (and comparatively basic) question, hoping to have someone like kool kitty masterfully answer my question (this just happened a few days ago with a question about FM approximated square wave tones, and kool kitty was awesome about it).....well, here we go again:

Let me start out by just stating the facts as best I understand them, then I'll leave myself open to correction about them:

SNES/SFC had the theoretical capability of running in 256x224 or 512x448, yet all but never used the higher mode for static images, and absolutely never did for actual game play. The sluggish CPU in the SNES was often suspected as the cause for the lack of high res support, but it actually had more to do with an issue in the PPUs (unclear on what that issue was) - in other words, 256x224 was the -NOMINAL- resolution of the system.

Genesis/MD had the theoretical capacity of running in 256x224 or 320x224, and actually ran on both depending upon the game, but usually ran in the higher of the two - in other words, 320x224 was the -NOMINAL- resolution of the system.

Neo Geo had the theoretical capacity of running in 304x224 or 320x224, and actually ran both depending upon the game, though it usually ran in the lower of the two - in other words, 304x224 was the -NOMINAL- resolution of the system.

TG16/TG/PCE had the theoretical capacity of running in 256x224 or 336x224, or 512x224, though 336x224 was very seldom used in actual game play contexts, and the 512x224 was never used other than in games like Sherlock Holmes Consulting Detective - in other words, 256x224 was the -NOMINAL- resolution of the system.

Of these assertions, the one I'm the most confident in is the Genesis/MD, followed very closely by the SNES/SFC, followed at a good distance by Neo Geo, followed at an even greater distance by the TG16/TG/PCE assertion. Can anyone (kool kitty, or otherwise) confirm where I'm right, correct where I'm wrong, and flesh out both where I'm right and where I'm wrong?

Thanks!

p.s. The way this started, the only piece of info I was originally looking for was whether the nominal Neo Geo resolution was 304 or 320. An off-hand mention was made about PCE that indicated I might be wrong about my understanding of its resolution modes and frequency of occurrences, and so now I had to find out about that as well. While I was here, I figured I'd also just get myself fact checked about the SNES and Genesis as well (though I feel I have a more comfortable grasp on them). Don't you just love the snowball effect? :-)

[XGoldenboyX]

Exciting topic.... : ) I like Joe`s explenation... Genesis still manages to impress yet again.

[sheath]

The PCE / TurboGrafx-16 nominally runs at (http://www.gamepilgrimage.com/content/turbografx-16)256x256 or 320x256 with usually only 219 lines visible. Plenty of games use either resolution, some like Art of Fighting ACD use both. Everything else looks about right to me. The SNES' 448 and 478 line modes are interlaced (http://www.gamepilgrimage.com/content/sega-genesis-vs-super-nintendo) and the one game that tried to use them was low color and suffered from a juttery image.

[Jay See Double You]

Okay, but if we're looking at the mode the TG16 most commonly ran in, would it be best to say 256x224 (256x256?), would it be best to say 336x224 (336x256?), or were they both common enough that neither statement would be fair? Also, you make mention of one SNES game that tried to run in 512x448, with disastrous results. Can you tell me what game that is? I would be very eager to check it out.

Also, if the list is not long, can you give me a rundown of PCE games that ran in higher than 256? I'll assume 336 unless otherwise indicated. If the list is very long, then don't worry about it. Or, if such a thing exists, can you point me to a resource that would have this info?

Thanks!

[Espio]

I dont like the Genesis Overscan. Even when I play with aspect ratio on my tv I still see it and my TV reads the overscan as part of the video signal. It wouldnt bother me if it was solid black.

[sheath]

Supposedly it is RPM Racing that does the SNES interlaced "high res" (http://www.sega-16.com/forum/showthread.php?7370-S-video-mod-giving-washed-out-colors&p=150575&viewfull=1#post150575) but I haven't been able to confirm this. I think it is 256 wide.


http://www.youtube.com/watch?v=OyvecUB5xp4

On the TG16 resolution, I think it is fairly split between 320x256 and 256x256 resolutions in software. Ninja Spirit is a higher resolution I know for sure.

[XGoldenboyX]

It wouldnt bother me if it was solid black.
This I agree!

[sheath]

Yeah, the Genesis is the only system I have noticed that puts the background/transparent color in the overscan. Fortunately I have always been able to test TVs before buying them and have always gotten ones that correctly crop the overscan out.

[evilevoix]

When the Genesis was released in 1988, very few arcade boards at the time was able to produce the same video resolution (320x224). There are a lot of systems with a much better hardware but using a lower resolution, like Namco System 2 (288x224), Konami TMNT2 Based hardware (288x244) or Neogeo (304x224). The same could be said about the home consoles (SNES = 256x224).

Is there any technical reason for that?

It's mostly overscan, back in the day when I had to play my Sega Genesis on my 50" Plasma Via Composite I got the 4:3 box in the widescreen and the over-scan is just the overlaping of the background, most notably skitchin you can see how the game layers stuff to make the illusion of moving work. You aren't missing anything basically.

It also shows the one background color that everything is matched too, most notably shown in Eternal Champions.

[Black_Tiger]

PC Engine games run in 224 or 240 pixel vertical resolutions. 240 was often used, but I can't say for sure if it was more common than 224 (I'm guessing that it was).

Other games like Shadow of the Beast use the 512 pixel wide resolution for still images. It is very practical (sprite bandwidth-wise) for many sections of various genres, but eats up way more memory to display the same artwork than lower resolutions and the PCE's color bandwidth already allows it to pack high quality (for the time) detail at its lowest resolution.

I'd say that most PCE games use the 336 wide resolution. I once sat down for a brief period and tested games that were close at hand and counted over one hundred which used the 336 resolution for real gameplay sections. I did not include 512 wide games and many games that I tested (but did not include) used the 336 res for sections that could arguably be included.

The Mega Drive came out just as the PCE had taken the lead in Japan. It makes sense that it would support similar resolutions to what the direct competition was using in its games. By the time that the SFC came out, the PCE had already proven that strong color bandwidth at a 256 x 224 pixel resolution was all that was necessary for graphics that rivals arcade games.

[kool kitty89]

SNES/SFC had the theoretical capability of running in 256x224 or 512x448, yet all but never used the higher mode for static images, and absolutely never did for actual game play. The sluggish CPU in the SNES was often suspected as the cause for the lack of high res support, but it actually had more to do with an issue in the PPUs (unclear on what that issue was) - in other words, 256x224 was the -NOMINAL- resolution of the system.
It's just that the higher resolutions weren't very useful for most things. Unlike the Genesis, the sprite bandwidth didn't increase with resolution on SNES or PC engine, so that becomes a problem quickly, and the SNES also has very limited background capabilities in 512 width mode. Sprite limitations also become an issue for running in interlaced modes (if you want decent height sprites), and VRAM usage comes into play for anything that's higher res (unless you re-use tiles like crazy -which kind of defeats the purpose of higher detail). AFIK, only Sonic 2's vs mode used interlace on the MD.

Likewise, the 256 color palette modes on the SNES are virtually useless for typical games due to the sheer VRAM space 8-bit color tiles take up (plus you need 2x the bandwidth to update tiles compared to 4-bit). Super FX games and splash screens are the only uses of these, and even then almost exclusively mode 3 since mode 4 has some other bugs. Typical SNES games use mode 1 or mode 2 using 2 16 (actually 15+transparent) color per tile modes with 8 palettes (plus 8 more for sprites). Both use 2 15 color tile BG layers, but mode 1 also gives a 3rd layer limited to 4 color (3+transparent) tiles. Donkey Kong Country and Earthworm Jim 2 used those for some far background effects, and a handful of others too. Some others used them for the status bars (rather than sprites), and Star Fox uses the 3 color layer to display the "Star Fox" logo on the tile screen. (3 color tiles also use 1/2 the memory of 15 color, they're 2 bits per pixel vs 4-bits -or 8-bits for 256 colors) You also get more subpalettes for the 3 color layer, 32 instead of 8. (the BG palette entries are divided on different intervals, but shared with the colors used for the 8 15 color palettes)

Mode 7 is technically a 256 color mode too though, and that's a lot more common since it's used for specific effects rather than a direct altenative to mode 1 or 2. (in fact, that actually has a separate 256 color palette, so you could technically have more than 256 colors on-screen without "tricks" if you had particularly colorful mode 7 textures used along with sprites)

There's also mode 0 with 4 3 color BG layers, but that was only used for a few stages in one or 2 games IIRC. This is actually really interesting since you get the full 32 subpalettes as well, and the advantage of 4 layers and less VRAM used per tile (and less bandwidth for updates). That potentially allowed for some really interesting color optimization potential with all those palettes in spite of the 3 color per tile limit, though no game really did that.
Too bad the PC engine didn't include a 2 layer 3 color tile mode . . . I'm sure that would have been popular for tons of games. (especially if they increased the subpalette count to utilize the full CRAM space -ie 64 palettes instead of 16)


Genesis/MD had the theoretical capacity of running in 256x224 or 320x224, and actually ran on both depending upon the game, but usually ran in the higher of the two - in other words, 320x224 was the -NOMINAL- resolution of the system.
320x448 is the highest res in NTSC for the MD, and Sonic 2 used it.

320 wide is very common on the MD, and unlike higher res on any of its contemporaries, the sprite bandwidth increases proportionally to the increased resolution. (goes from 256 to 320 pixels) Not only that, but the number of sprites per-screen is increased from 64 to 80.


Neo Geo had the theoretical capacity of running in 304x224 or 320x224, and actually ran both depending upon the game, though it usually ran in the lower of the two - in other words, 304x224 was the -NOMINAL- resolution of the system.
304 is all you'd see on a TV or monitor with normal screen calibration . . . actually, typical TVs would probably show more like 286 pixels on the Neo Geo. (6 MHz pixel clock, compare that to the 5.37 MHz of common "256" resolutions or 6.67 MHz of the MD's 320 width)

Note that several old consoles and computers used resolutions lower than would fill the screen with the pixel clocks used, so you have boarders. The 160 or 320 pixels on Atari 8-bit, 5200, and C64 leave quite a bit of boarder, as does the 320 of the ST and Amiga. (C64 and ST more so since they use 4/8 MHz dot clocks -or 16 MHz for the 640 wide ST mode . . . to fill the screen you'd need roughly 384 or 192 pixels for the ST, or on the Atari 8-bit and Amiga you have 3.58/7.16 MHz dot clocks and need about 172/344) In the Amiga and 8-bit, you could actually enable overscan to fill more of that space. The Apple II and Tandy CoCo have even wider boarders since they both use 7.16 MHz dot clocks like the Amiga's 320 wide yet only show 280 and 256 pixels.


TG16/TG/PCE had the theoretical capacity of running in 256x224 or 336x224, or 512x224, though 336x224 was very seldom used in actual game play contexts, and the 512x224 was never used other than in games like Sherlock Holmes Consulting Detective - in other words, 256x224 was the -NOMINAL- resolution of the system.
Quite a few "normal" games used the "336" mode on the PCE, it wasn't super common, but it was at least reasonably useful (unlike the SNES's higher res modes). 336 is also somewhat conservative and typical TVs could probably show closer to 344 pixels (it's the same 7.16 MHz dot clock as the Amiga used), but I forget what the actual limits of the VDP scan is in that mode. (I'm pretty sure it's at least 344)

Sprite limitations are more severe in that mode though, which is why 256 is typical.





The PCE / TurboGrafx-16 nominally runs at (http://www.gamepilgrimage.com/content/turbografx-16)256x256 or 320x256 with usually only 219 lines visible. Plenty of games use either resolution, some like Art of Fighting ACD use both. Everything else looks about right to me. The SNES' 448 and 478 line modes are interlaced (http://www.gamepilgrimage.com/content/sega-genesis-vs-super-nintendo) and the one game that tried to use them was low color and suffered from a juttery image.
I'm pretty sure it's 512x448, the pixels look noticeably finer. The title screen really makes that obvious too. (in fact, I wonder why that mode wasn't used more for title screens and menus, given how nice it looks for that -and wouldn't have problems with the limitations for actual in-game use)




PC Engine games run in 224 or 240 pixel vertical resolutions. 240 was often used, but I can't say for sure if it was more common than 224 (I'm guessing that it was).
For 60 Hz displays, this really doesn't matter since you won't be seeing more than 224 pixels anyway, unless you custom calibrate your TV or monitor to show overscan. (or have a multimedia monitor or HDTV with auto underscan options)

[Robotwo]

Yeah, the Genesis is the only system I have noticed that puts the background/transparent color in the overscan. Fortunately I have always been able to test TVs before buying them and have always gotten ones that correctly crop the overscan out.

Doesn't the Mastersystem handle it similarly?

[sheath]

Probably, but I haven't had the same amount of trouble with games using the background color for overscan with Master System games. I think I did notice one game doing it recently but wasn't really paying attention to which one. :/

On the vertical resolution thing. I just went back and checked the Schluesinger's VDCDOX.txt (http://www.gamepilgrimage.com/sites/default/files/SystemSpecs/TG16/vdcdox.txt) to see what the resolution was and remembered why it says 256 and not 224 or 240. The system internally has to display lines that are divisible by 8 because of the tile format. So the display is technically 32 tiles tall even if most games only display 219 lines of it. I usually capture at 720x480 and crop the image and haven't noticed a significant difference between SNES, TG16/PCE and Genesis output. In fact I can use the same crop template across all platforms and it usually works.

Interesting comparison of PCE Resolutions (http://forums.magicengine.com/en/viewtopic.php?t=1798).

[Black_Tiger]

Cant quote kool kitty properly, but the jump from 64 to 80 sprites with the jump in resolution on Genesis is virtually meaningless. Using the smallest sprites possible, in 320 mode the screen gets completely filled (scanline limit reached on all lines) with 68 sprites. Both resolutions on Genesis and the PCE in 256 pixel mode can only ever fill as much as one screen with sprites. Which is why Genesis and PCE games look so similar. The SNES' bottleneck is the two sprite size limitation.

[sheath]

Cant quote kool kitty properly, but the jump from 64 to 80 sprites with the jump in resolution on Genesis is virtually meaningless. Using the smallest sprites possible, in 320 mode the screen gets completely filled (scanline limit reached on all lines) with 68 sprites. Both resolutions on Genesis and the PCE in 256 pixel mode can only ever fill as much as one screen with sprites. Which is why Genesis and PCE games look so similar. The SNES' bottleneck is the two sprite size limitation.

How do you figure that? The smallest sprite object is 8x8, which would make 40 fit into 320 wide, which is twice the 20 sprite per scanline limit in that mode. The sprite per scanline limit in 256 mode is 16, so that is another way the 320 mode helps. Also, 320x224=71680 pixels, divide that by 64 pixels in an 8x8 sprite and you get 1120, the genesis would never fill the screen with 8x8 sprites before hitting its 80 sprite limit.

[kool kitty89]

How do you figure that? The smallest sprite object is 8x8, which would make 40 fit into 320 wide, which is twice the 20 sprite per scanline limit in that mode. The sprite per scanline limit in 256 mode is 16, so that is another way the 320 mode helps. Also, 320x224=71680 pixels, divide that by 64 pixels in an 8x8 sprite and you get 1120, the genesis would never fill the screen with 8x8 sprites before hitting its 80 sprite limit.
There's also the issue of flicker/tearing . . . having more sprite allows for situations where you'd be willing to suffer some tearing/flicker to allow more simultaneous objects to be manipulated on-screen. (plus there's the issue of off-screen sprites) This would apply to cases of small sprites hittng the 20 per line limit or large sprites hitting the 320 pixel limit.

However, to address the 8x8 sprite issue, also you's hit the per line limit at 20 with only 160 pixels used, though even then you'd run out of sprites before allowing 224 pixels tall. With 8x32 you could fill the vertical screen and hit the horizontal sprite limit too.

I forget whether sprite bandwidth get eaten up with transparent tiles or not too, but that could be an interesting factor. (sprites are all mapped out of 8x8 cells, but if the VDP allows specific cell to be completely empty, it could avoid wasting bandwidth on partially filled sprites -otherwise, there's more cases you'd want to composite odd-shaped objects from smaller sprites to optimize for pixel bandwidth)




On the vertical resolution thing. I just went back and checked the Schluesinger's VDCDOX.txt (http://www.gamepilgrimage.com/sites/default/files/SystemSpecs/TG16/vdcdox.txt) to see what the resolution was and remembered why it says 256 and not 224 or 240. The system internally has to display lines that are divisible by 8 because of the tile format. So the display is technically 32 tiles tall even if most games only display 219 lines of it. I usually capture at 720x480 and crop the image and haven't noticed a significant difference between SNES, TG16/PCE and Genesis output. In fact I can use the same crop template across all platforms and it usually works.
The MD tilemap is fixed at 64x64 iirc, though active obvously display shows far less than that. (it makes scrolling and tile updates more flexible though, with all that extra tile space)



Yeah, the Genesis is the only system I have noticed that puts the background/transparent color in the overscan. Fortunately I have always been able to test TVs before buying them and have always gotten ones that correctly crop the overscan out.
Not sure about consoles, but several home computers have control over overscan boarder/blanking color. I'm pretty sure the TMS9918 (and derivative) do that too.

[TmEE]

MD tilemap is configurable from 32 x 32, 64 x 32, 32 x 64, 64 x 64, 128 x 32 and 32x 128.

[kool kitty89]

MD tilemap is configurable from 32 x 32, 64 x 32, 32 x 64, 64 x 64, 128 x 32 and 32x 128.
Why did Stef mention he had to use 64x64 in his demo?

I can't keep the VRAM double buffer... SGDK use some tiles for plain color tiles and more over the font. Then take that i have to use 64x64 tilemap size for both plan, have to keep space for probable future sprites and of course for the background and then you can see i just run out of free tile to store a double buffer in VRAM.
SNES Starfox store sprites table in dedicated memory, tilemap are probably smaller, well i guess they are very short on free vram. I could probably optimize my vram usage but i know i will meet problems later with that so that will happen in last.

Does it have anything to do with using column scroll?

With the polygon layer needing no scrolling at all, I don't see why 32x32 wouldn't be used to save VRAM space. Or is it just that the tool set Stef is using has 64x64 set up as the default?

[Chilly Willy]

Just because the map is 64x64 doesn't mean you HAVE to use ALL of it... if you never scroll the screen, you can use just the 40x28 part needed for a 320x224 display and use the rest for tiles or other things. The only parts of a tile map that needs valid values are the entries that will be displayed, which also depends on the scrolling used. If you only scrolled horizontally by one column before reseting, you'd only need to worry about the 41x28 entries. Add one row vertically and you'd only worry about 41x29 entries. I use 128x32 in a number of my demos, where the first 80 columns are used for double-buffering layer A, and the next 40 columns are used for an unscrolling layer B, with the last 8 columns being unused. It's all up to the programmer to make effective use of both the tile maps and the unused vram.

[kool kitty89]

Just because the map is 64x64 doesn't mean you HAVE to use ALL of it... if you never scroll the screen, you can use just the 40x28 part needed for a 320x224 display and use the rest for tiles or other things. The only parts of a tile map that needs valid values are the entries that will be displayed, which also depends on the scrolling used. If you only scrolled horizontally by one column before reseting, you'd only need to worry about the 41x28 entries. Add one row vertically and you'd only worry about 41x29 entries. I use 128x32 in a number of my demos, where the first 80 columns are used for double-buffering layer A, and the next 40 columns are used for an unscrolling layer B, with the last 8 columns being unused. It's all up to the programmer to make effective use of both the tile maps and the unused vram.
It may also be an issue with the way Stef's MD tool set is currently set up. That, and I know he's keeping some things simple for now and optimize later.

Edit: Stef elaborated more here:
http://www.sega-16.com/forum/showthread.php?23549&p=564364&viewfull=1#post564364

So it seems that it' not anything specific to the tools he uses.