How MSX limitations affected Dragon Warrior 2's graphics

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

User avatar
rainwarrior
Posts: 8735
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: How MSX limitations affected Dragon Warrior 2's graphics

Post by rainwarrior »

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. :P
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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: How MSX limitations affected Dragon Warrior 2's graphics

Post by lidnariq »

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.
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)
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.
User avatar
rainwarrior
Posts: 8735
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: How MSX limitations affected Dragon Warrior 2's graphics

Post by rainwarrior »

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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: How MSX limitations affected Dragon Warrior 2's graphics

Post by lidnariq »

... 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.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: How MSX limitations affected Dragon Warrior 2's graphics

Post by Bregalad »

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.
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.
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.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: How MSX limitations affected Dragon Warrior 2's graphics

Post by tokumaru »

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.
User avatar
rainwarrior
Posts: 8735
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: How MSX limitations affected Dragon Warrior 2's graphics

Post by rainwarrior »

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.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: How MSX limitations affected Dragon Warrior 2's graphics

Post by Bregalad »

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 ?!
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: How MSX limitations affected Dragon Warrior 2's graphics

Post by lidnariq »

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.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: How MSX limitations affected Dragon Warrior 2's graphics

Post by Bregalad »

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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: How MSX limitations affected Dragon Warrior 2's graphics

Post by lidnariq »

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.
Post Reply