I was just watching some gameplay footage of the MSX version of Dragon Quest 2, and was surprised about how they did a great job of getting colorful character graphics on the screen despite the hardware limitations of the MSX.
Let's review the capabilties of the TMS9918 graphics chip (also found in the ColecoVision):
* 1bpp background tiles
* 1bpp sprites, up to 16x16 pixels large
* Each 8x1 pixel chunk of a background tile can pick two different colors.
So the game is drawing big 16x16 black/transparent sprites to black out the characters' shapes, then for the colors of the characters, it is using background tiles with 2 colors per 8x1 chunk. This allows the system to create graphics that look somewhat like a NES, only with two different colors per scanline instead of 3.
You can clearly see this when you look closely at the game's graphics, and count how many colors appear in a 8x1 area.
And amazingly enough, the NES graphics match the MSX graphics very closely. So you can see how hardware restrictions from the MSX affected how the NES version's graphics turned out. Especially look for things like flat horizontal lines.
Attachment:
dq2_msx.png [ 836 Bytes | Viewed 7460 times ]
In theory, if graphics use the common subset of MSX and NES capabilities (2 colors per 8x1 pixel sliver, 4 colors per sprite or 16x16 pixel tile), one could compress them to 11 bits per sliver, saving about one-third compared to raw 2bpp.
So basically the game uses background to draw sprites ? This sounds like it should have been a major hassle to code,
I know what I'm talking about. Also wouldn't a huge black box appears behind the moveable characters if it was done that way ?
There was many variants of the MSX and they had different graphical limitations. I suspect most MSX games, especially ports from NES games, didn't run on the lowest-end earlier released MSX with the TMS9918, but were designed for later versions of the computer with a better chip. Considering how much NES games were ported to MSX I'd be surprised if all of them were running on the very limited TMS9918.
As for Dragon Quest II, it is far from even approaching to using NES graphics to it's limits...
It's only a problem if you try to do fine scrolling. But if everything just moves 8 pixels at a time (and it does), then you just move the sprite overlay at the same time as you update the tiles in the background.
How is it possible that MSX limits to 2 colors + transparent per line ? This makes few sense, as the total amount of possibilities is 3, not a power of two number, which makes it impossible to store efficiently (without ressorting to major hacks). On the other hand, 3 colours + transparent or single colour + transparent makes perfect sense.
PS :
Quote:
It's only a problem if you try to do fine scrolling. But if everything just moves 8 pixels at a time (and it does), then you just move the sprite overlay at the same time as you update the tiles in the background.
I know it might be
less a hassle to code, but it's still going to be a hassle to code compared to just moving sprites around.
For background tiles, it's two colors per 8x1-pixel area. For sprites, it's two 1-color sprites overlaid, where the 1-color sprite may specify a different color for each 8x1-pixel area.
Bregalad wrote:
How is it possible that MSX limits to 2 colors + transparent per line ?
Not 2 colors + transparent. Just two colors.
The datasheet for the TMS9918A explains Graphics 2 mode, which is honestly pretty weird to me, but whatever.
Basically
1- Unlike the NES, the "color tables" apply to the pattern tables, not the name tables. (Regardless of video mode.)
2- In Graphics 2, the color table specifies a unique pair of colors per 8x1 sliver of pattern.
Bregalad wrote:
I know it might be less a hassle to code, but it's still going to be a hassle to code compared to just moving sprites around.
There's no hardware support for scrolling. If you're going to implement any scrolling at all, you have to move all the data in the name table. At that point updating a single X,Y coordinate for a masking sprite is incrementally negligible.
Also, the Sprite Attribute Table is in the same address space as the name table; there's no need to prepare OAM for DMA.
Bregalad wrote:
How is it possible that MSX limits to 2 colors + transparent per line ? This makes few sense, as the total amount of possibilities is 3, not a power of two number, which makes it impossible to store efficiently (without ressorting to major hacks). On the other hand, 3 colours + transparent or single colour + transparent makes perfect sense.
The description confused me for a moment too.
The two colours per line is all in the underlying background tiles. Then there is a rectangular black masking sprite on top to "cut out" the shape. (So underneath the black parts, the background is still just 2 colours per line.)
1 bpp solid + 1 bpp transparent = 3 colours?
Might have been good for the illustration to show what the backgrounds look like under the sprites, maybe blinking on and off with an animated GIF.
By the way, it turns out it's not a black mask anyway.
So it's black + another color per line on the background, and 2 single-color sprites on top, is that it?
lidnariq wrote:
By the way, it turns out it's not a black mask anyway.
You're right, and while either solution can achieve the same 3 colors, this means that when 4 16x16 sprites meet in a single scanline, the large solid color is what will flicker, not the mask.
A single single-color sprite. Sprites on the TMS9928A are globally 8x8 or 16x16, unlike the 2C02.
And it
could be two arbitrary colors per 8x1 sliver in the background, but all the ones I saw used black for one of the two colors.
Dwedit wrote:
this means that when 4 16x16 sprites meet in a single scanline, the large solid color is what will flicker, not the mask.
I assume you mean five sprites?
Must have misread the documentation, thought it was 4 sprites per scanline.
It is, but that means that the 5th sprite is what drops out...?
So this is even more complicated than I feared.
So backgrounds are not shown under sprites, and are used instead to draw sprites with 2 colours per line (black + another customizable colour). Then a single-colour sprite is used on top of that to add another colour, which makes a total of 2 colours per line + black. Is that correct ?
What looks particularly awful is not the fact there's one less colour per line than on the NES, but the fact the background is solid black behind sprites. This is ugly.
There is many NES games ported to MSX, I wonder how others managed to do this. I think of Gradius, Double Dragon, Vampire Hunter (clone of Castlevania), etc.... Did those have the same limitations as Dragon Warrior II, or were they ported to a superior version of the MSX ?
Final Fantasy in particular has very colorful graphics on MSX; which definitely added colours as opposed to the NES version. Even though the scrolling is still shitty.
Bregalad wrote:
So this is even more complicated than I feared.
So backgrounds are not shown under sprites, and are used instead to draw sprites with 2 colours per line (black + another customizable colour). Then a single-colour sprite is used on top of that to add another colour, which makes a total of 2 colours per line + black. Is that correct ?
It's slightly more restricted than this, apparently. Dwedit's first post made it sound like the two colours were coming from the background, which would have meant any 2 colours for every scanline, plus black (from a masking sprite).
...but instead we have a whole sprite of one solid colour, then the background is always black + one other colour. So it's black + 1 custom colour per scanline, + 1 more sprite colour for the whole sprite.
Dwedit's suggested idea would have been slightly better, for probably the same cost.
Bregalad wrote:
Final Fantasy in particular has very colorful graphics on MSX; which definitely added colours as opposed to the NES version. Even though the scrolling is still shitty.
According to the
Final Fantasy Wiki the Final Fantasy port was for MSX2, which is why it's more colourful (also has some interestingly enhanced music). (
longplay)
MSX1 was much more limited. I think a lot of what you are thinking of was for MSX2.
Bregalad wrote:
So backgrounds are not shown under sprites,
What? No, sprites are 1 color and transparent. Lower priority (i.e. earlier in the Sprite Attribute Table) always takes priority. No way to draw sprites under the background.
Quote:
Then a single-colour sprite is used on top of that to add another colour, which makes a total of 2 colours per line + black. Is that correct ?
The software sprites used by Dragon Quest 2 here are: two colors for each 8x1 pixel region (totaling 32 total bytes of attribute data: this part is implemented via name tables) and one shared color for the entire 16x16 pixel overlay (the overlay is a hardware sprite)
Quote:
but the fact the background is solid black behind sprites. This is ugly.
What's awkward is that they could have actually made it look better.
But maybe they put minimum effort into making the MSX1 build work? When I made the screenshot above I initially found the (much nicer looking) MSX2 build.
Gradius/Nemesis was MSX1.
(youtube). They used a mixture of hardware sprites and faking more (and more colorful ones) with the tilemap.
Vampire Killer was MSX2.
Double Dragon 2 was MSX1.
(youtube). Player is implemented with two sprites; opponents are all faked using the tilemap.
Sortable list on wikipedia.
rainwarrior wrote:
...but instead we have a whole sprite of one solid colour, then the background is always black + one other colour. So it's black + 1 custom colour per scanline, + 1 more sprite colour for the whole sprite.
No, it does NOT have to be black.
In graphics 2,
each 8x1 sliver of background has its choice of an arbitrary pair of two colors from the
anemic 15-color TMS9928A palette.
lidnariq wrote:
rainwarrior wrote:
...but instead we have a whole sprite of one solid colour, then the background is always black + one other colour. So it's black + 1 custom colour per scanline, + 1 more sprite colour for the whole sprite.
No, it does NOT have to be black.
I didn't mean that was a hardware constraint. It was a constraint in their convention here for the sprites, which have to be surrounded by blackness.
If they used a non-black colour in the background it has to go to the edges of the tile (i.e. you lose the sprite silhouette shape). If they'd used Dwedit's idea for a black masking sprite instead they'd get 2 arbitrary colours (+ black) for each line, which would have been slightly better, while keeping the same visual convention of surrounding the sprite with black.
... tangenting, the aesthetic reminds me of
Excelsior, which used VGA text mode and 16x16 tiles.
Background was almost always black there too, for probably similar reasons.
rainwarrior wrote:
It's slightly more restricted than this, apparently. Dwedit's first post made it sound like the two colours were coming from the background, which would have meant any 2 colours for every scanline, plus black (from a masking sprite).
...but instead we have a whole sprite of one solid colour, then the background is always black + one other colour. So it's black + 1 custom colour per scanline, + 1 more sprite colour for the whole sprite.
That's actually exactly what I previously understood. Sorry if that wasn't clear.
Quote:
What? No, sprites are 1 color and transparent. Lower priority (i.e. earlier in the Sprite Attribute Table) always takes priority. No way to draw sprites under the background.
I was talking about "metasprites" or characters as used by DQ2, not hardware sprites. Sorry if that wasn't clear.
Quote:
If they'd used Dwedit's idea for a black masking sprite instead they'd get 2 arbitrary colours (+ black) for each line, which would have been slightly better, while keeping the same visual convention of surrounding the sprite with black.
Oh, I didn't understand that originally, but that idea is actually genius. They should have put only the colours in the actual background, then having a solid black overlay on top of it. So it'd be 2 free colours per line, instead of one solid colour + one free colour. Overall that didn't make all the difference, since it doesn't solve the problem a huge black box is there around characters and is what look the most awful, not the sprite colours themselves.
I agree that the black box around the characters looks terrible, but back in the day of text mode or spriteless games, that was quite common. In an RPG, smooth movement isn't really necessary, you just need to know where the characters are, and this is a decent enough representation for the time, I think.
lidnariq wrote:
... tangenting, the aesthetic reminds me of
Excelsior, which used VGA text mode and 16x16 tiles.
Background was almost always black there too, for probably similar reasons.
Wow, that website is still up and hasn't changed since the late 90s!??? I remember trying this game back then.
rainwarrior wrote:
According to the
Final Fantasy Wiki the Final Fantasy port was for MSX2, which is why it's more colourful (also has some interestingly enhanced music). (
longplay)
MSX1 was much more limited. I think a lot of what you are thinking of was for MSX2.
I still don't understand. MSX2 is supposed to allow scrolling vertically while still having shitty non-scrolling (shift the map one tile a time) horizontally. Yet Final Fantasy still has shitty scrolling in both directions. Also, the new graphical chip adds more sprites and higher resolution, but it does not seem to add more colours, except when overlaying sprites, where you can make it so by overlaying 2 sprites you get 2BP sprite or overlaying 3 or 4 sprites you get 3 or 4BP, at the cost of using most sprites available per scanline. Only in a bitmapped mode do you get more colours for background. Yet the graphics are more colourful than the NES version. Did they use a bitmapped mode ?!
Let's see; doing my best to summarize the V9938 datasheet...
Register differences:
R0 - Digital passthrough, Lightpen interrupt enable, Hsync interrupt enable, Mode5, Mode4, Mode3, ExtVid
R1 - Memory Clamp, Display Enable, Vsync interrupt enable, Mode1, Mode2, reserved, Sprite Size, Sprite Magnify
R2 - Name table address, in multiple of 1 KiB. 4 bits on 9928, 7 on 9938.
R3 - Color table address, in multiple of 64 bytes. 8 bits on 9928, 11 bits on 9938. (Extra bits in new register R10)
R4 - Pattern table address, in multiple of 2 KiB. 3 bits on 9928, 6 on 9938.
R5 - Sprite attribute table address, in multiple of 128 bytes. 7 bits on 9928, 10 bits on 9938. (Extra bits in new register R11)
R6 - Sprite pattern table address, in multiple of 2 KiB. 3 bits on 9928, 6 on 9938.
R7 - foreground color in text mode. backdrop and overscan color always.
Everything after is new to the V9938:
R8 - mouse, light pen, "TP"??, "CB", video DRAM geometry, sprite disable, greyscale
R9 - 212scanline mode, "simultaneous mode", another, interlace, autointerlace, PAL/NTSC, pixel clock source
212 scanlines is 27.5 character cells. Only works in new video modes.
R10, 11 as above
new "Text2" mode supports blinking attribute on character cell basis
R12: Replacement foreground and background color for blinking cells
R13: duration of on and off periods (in # redraws) for blinking cells ... should make it possible to use without technically blinking?
R14: outer bank selector for VRAM interface
R15: select one of ten different status registesr to read
R16: palette address
R17: configure indirect addressing??
R18: fine tune upper left start of visible field. Should be able to abuse this to generate fine X scrolling, albeit with jumping edges.
R19: generate interrupt at specific scanline
R20, 21, 22: magic numbers pertaining to colorburst generation. Normal is 0,59,5; 0,0,0 is fully disabled.
R23: Y fine scrolling
R24-31: don't exist?
R32-46: Video bitblit accelerator parameters
Mode differences:
All video modes support replacing the default 9928 palette with entries out of a RGB333 space.
TEXT1, GRAPHIC1, GRAPHIC2: no other changes
New sprite mode supports 8 active sprites per scanline. Each scanline of sprite supports independent 1 of 16 colors, shift left/offscreen of 32 pixels, collision detection vs background cancel, sprite vs sprite collision cancel and color combination for generating multicolor sprites.
New modes support 212-scanline mode, if enabled:
TEXT2: 80 columns. Nametable is 80x27. Color table provides one bit of attribute per character cell ("blinking"). Blinking periods are a configurable multiple of 10 vsyncs.
GRAPHIC3: identical to GRAPHIC2 but with new sprite mode. All new graphic modes use new sprite mode.
GRAPHIC4: 16-color packed pixel bitmap mode
GRAPHIC5: 4-color high resolution packed pixel bitmap mode. Sprite color per scanline selects one of 4 colors for left and right half of each sprite pixel.
GRAPHIC6: 16-color high resolution packed pixel bitmap mode.
GRAPHIC7: 256-color R3G3B2 directcolor packed pixel bitmap mode.
so ... I guess that explains things? The new features were basically unrelated to the tilemap modes. There was support for higher-color sprites, supporting both unique colors per scanline and coincidence to increase bitdepth per scanline; a lot of new bitmap-based video modes and a blitter to improve its usability for games; fine Y scrolling; and the ability to change all 16 colors in the palette.
Looking at the longplay ... yeah, I think they used bitmapped mode.
You can increase the bitdepth but it eats 2 sprites. So basically assuming you have sprites identical to the NES version of a game, you still have 4 sprites per line, in the case of 16x16 metasprites it's the same as on the NES and does not allow for much improvement. OK if single-palette per line is also applicable to sprites this leaves room for improvement.
On the other hand sprites overlaping accidentally could look awful if they blend into a 3rd colour when you don't want them to.
Also the graphical capabilities for the BG seems to be basically the same as on the original MSX, except with vertical scrolling... which means it's worse than the NES.
Bregalad wrote:
Also the graphical capabilities for the BG seems to be basically the same as on the original MSX, except with vertical scrolling... which means it's worse than the NES.
?? But it really looks like they used one of the bitmapped modes. I think the problem is a software decision again: they appear to have just mindlessly emulated a 2bpp tilemap display instead of having redrawn the tiles to take advantage of the extra bitdepth.
