HomeForumsWhat's newResources 
 
 
VDP2 questions
AntiPasta - Apr 3, 2003

 < Prev  1  2  3  Next> 

  fafling Oct 21, 2019
There are examples of games (in the intro video of Megaman 8, and in game for Machinehead) where color RAM mode different of 0 cancels the effect of gradation, which is a particular case of extended color calculation that always require CRAM mode 0. So it's very likely that setting CRAM mode to 1 in your game would cancel the ECC effect on the console (if not, that would be an undocumented behavior of VDP2).

So what you describe is another emulator bug, this time in SSF. However, in SSF 0.12 Preview R9, ECC is working in Sonic R which uses CRAM mode 0. What version of SSF are you using ? And by the way, what is that game you're working on ?

Generally speaking, even if Saturn emulators have made a lot of progress, none of them is 100% accurate currently.

About why ECC was not widely used, I think there are several factors :
  • You have to read VDP2 manual almost entirely to be aware of ECC, and it's not the easiest read (I needed several pass to fully understand ECC process and restrictions).
  • It's hardly mentioned in the graphic libraries manuals. SBL manual doesn't mention it at all (in the code of the library, ECC can be set by a macro documented in japanese). There is a documented way to set it in SGL, but again they don't explain it and refer to VDP2 manual. In other words, it possible that some developers were simply unaware that ECC existed at all, especially for 2D games that most likely used SBL.
  • Most 3D games using SGL were geared toward localized blending effects between polygons, rather than layered effect like ECC. Moreover that kind of multilayer full screen blending effect would have been problematic for performance on PSX, so multiplatform games would tend to avoid it. That's why Sonic R is really an exception, it's built with Saturn in mind by developers who understood the machine very well. Maybe there would have been more game like this if Saturn had had a longer support.
  • The fact that ECC halves the number of colors in CRAM to make it work with a palette background could have been a deal breaker for some games that preferred to have more colors available for palette graphics.

  paul_met Oct 22, 2019
Perhaps I did not quite correctly put it. Multilayer translucency also works with Color Ram Mode = 0, but the NBG3 palette is getting wrong (multilayer translucency works with Color Ram Mode = 1 on all versions of SSF). I also tested ECC at Mednafen. There the situation is different: with Color Ram Mode = 1, multilayer translucency does not work. In the case of Color Ram Mode = 0 (if activated from the very beginning), the palette of the NBG3 layer again is getting wrong, but if you set Color Ram Mode = 0 on the screen with a global map exclusively, multilayer translucency works correctly (exept VPD1 layer - it palette is getting wrong). Yabause does not respond to changes in the Color Ram Mode parameter.
The game is called Soldnerschild. It was also released on the Playstation (but in a degraded form, despite the label "special"). But in the PS1 version there are no problems with multilayer transparency on the screen with a global map.

 fafling Oct 22, 2019
So the game originally uses color RAM mode 1, and you modify it to 0. VDP2 manual says colors must be loaded in CRAM after mode change (p. 46 "Saving color data to the color RAM must be done after thes bits have been set."). So if you change CRAM mode during game, you're supposed to reload the CRAM, otherwise graphics corruption will happen.

It's possible that the game is using colors located in both halves of CRAM, nothing prevents that in mode 1. If that is the case :
  • If the CRAM mode change to 0 is done after the loading of those colors, CRAM is in an incoherent state because its 2 halves are different instead of mirrored. That will cause graphics corruption on the console, in the best case scenario only when ECC is used.
  • If the CRAM mode change to 0 is done before the loading of the colors, CRAM state is coherent, but there will be a corruption of graphics pixels whose color index refers to colors whose that have been changed in CRAM due to the mirroring.

  paul_met Oct 23, 2019

fafling said:

So what is the solution in this situation? Can you suggest any options?

 fafling Oct 23, 2019
I don't think there is an easy solution to that because the game was not programmed with the constraint of a color RAM limited to 1024 colors for the map screen.

In order to use ECC on that screen, you would need to :
  • Analyze what colors are used in that screen that are located in the 2nd half of the color RAM, and find how they are referenced by the graphics (pixels indexes + VDP2 tilemap palette number or VDP1 color bank palette number + CRAM offset).
  • Before the game enters the screen, relocate colors from the 2nd half of the color RAM to the 1st half, probably over unused colors on that screen. keeping them grouped as palettes and completely reloading the CRAM after mod change, and change the way relocated colors are referenced by the graphics.
  • Restore CRAM content and mode as the game expects them to be as it exits the screen.

  David Gámiz Jiménez Oct 23, 2019

fafling said:


Really, I don't sure at 100%, but I checked a lot sonic R and about the ECC I know it very well. I have read and have re-read a lot of times the vdp2 manual. But in the Sonic R case. The #s waves are a line color screen animated and applied over RBG0 in the transparent areas only. And the reflection is the half of background animated. Only one layer with VDP2 transparency here.
I am sorry the ripple is a sprite VDP1 with transparency against VDP2. And also this not blend with the waves. There are here two layer in VDP2 whit ECC activated and in real hardware not blend the two, only one. The most higher layer or priority agains the background, the reflection effect.

 fafling Oct 23, 2019
RBG0 is not transparent in the water area, otherwise the line color screen would not be displayed : it displays only through color calculation on the non transparent pixels of the layers that activate it.

The water texture is very faint with the blending because it has a very low ratio (3:29 !), but it's there on RBG0 and it is visible in movement. Here's a screen of it from a WIP version of Kronos where color calculation didn't work on that layer.


For some reason, water texture is more visible in the Regal ruin circuit with color calculation working (and yes, I checked that it displays like that on the console) :

So here we have 3 layer blending (RBG0, line color screen and NBG0). Actually, they could have pushed it further since VDP2 can do up to 4 layer blending when line color screen is in 2nd position. Like they could have made a blending of 2 reflections layers instead of 1.

On that topic, I think there's a typo on the ratios on the line with the arrow of this extended color calculation table from p. 238 of VDP2 manual. It should be 2:1:1 instead of 2:1:0, otherwise it makes no sense :

  paul_met Oct 24, 2019

fafling said:

It turns out that ECC cannot be forced to work in Color Rm Mode = 1?

 fafling Oct 24, 2019
Extended color calculation can be used without changing the CRAM mode, but it requires you to change NBG0 to be in RGB format instead of 8 bpp palette. So 16 bpp RGB makes its tiles twice as big. Is there enough room in VDP2 VRAM ? And that requires you to tweak the cycle pattern register for that screen (hint : grab a console to test that).

 David Gámiz Jiménez Oct 24, 2019

fafling said:

Well. I rechecked all again. At the beginning of my analysis. Sonic R was once of the games that more I checked. I my first notes, checked in emulators first and after in real hardware. I saw some blend between layers. Only checked always the first level. It is true in the third is more clear the effect. Well, more forward in my 3 or 4 four time read the vpd2 documentation. I understand that it is possible have multi-layer (4 max) blend with VDP2. And in other way between sprite whit MSB Shadow function, this last it is a lot restrictive and quite usefulness by my point of view, at least for 3D. Well. I try to share my current results:

In first level or third level is the same configuration. Only changes the ratios. The priorities it is the same in both scenarios. All have "Extended Color Calculation Enabled".

In this chain work all OK. All see between them and blend all.
Prio:5/6 Map: NBG3 [T] + Prio:3 Ripple character water and depth cueign: VDP1 [T] + Prio:2 Pixel water areas: RBG0 [T] + Prio:2 NBG0 [Opaque]

The Line Color Screen only work with the RBG0 + NGB0, in this part of chain, NBG3, VDP1 not blend with the LCS:
Line Color Screen [per Line color Animated]+Prio:2 Pixel water areas: RBG0 [T] + Prio:2 NBG0 [Opaque]

Finally. My perception that VDP2 only can blend one layer. It is because, sadly, the all most games that use VDP2 transparency, when have two or more layer, not use or not use well "Extended Color Calculation Enabled" and not blend. But I take note, for the next point in my analysis research I will take more time in this games.

Thanks for sharing your knowledge.

 paul_met Oct 24, 2019

fafling said:

Yes, if I switch the NBG0 layer to RGB (16bpp) mode, then double translucency works. But in this case, all other backgrounds are also switched to RGB mode (global parameter).

 fafling Oct 24, 2019
@David Gámiz Jiménez... Yes, the line color screen is inserted only on the top layer. So if RBG0 is behind a semi-transparent layer, the line color screen disappears. Sonic R allows to check that in emulators.
Did you find some other games that use extended color calculation ? Even games where ECC doesn't work because some condition isn't met, it can be interesting to check how emulators handle that situation.

@paul_met... To set only NBG0 to RGB format, you should change the character color number registry bits N0CHCN2~N0CHCN0 (p.60 of VDP2 manual), leaving unchanged the other bits of that registry.

 paul_met Oct 25, 2019

fafling said:

That's exactly what I did. But I meant that the color change parameter for the NBG0 layer is global and all other backgrounds that are displayed through the NBG0 layer also go into RGB mode. I apologize for my English, it’s not good, as I would like.

 fafling Oct 25, 2019
Changing that register is not enough. Have you changed NBG0's tiles, map and cycle pattern accordingly? If you don't, it's normal that graphics get corrupted. Like I said, enabling extended color calculation after the facts is not an easy task.

 paul_met Oct 25, 2019

fafling said:

If I go this way, I will have to change not only the picture of the global map, but also all the other backgrounds in the game. That's what I wanted to say.

 fafling Oct 25, 2019
OK I didn't understand that.

There's yet another possibilty that doesn't require to enable ECC, but that's not simple either. You could make the black part of the dialog box displayed by normal shadow pixels on the framebuffer instead of NBG3. Would need to :
  • Replace the black pixels of the dialog box tiles by the transparent code in VDP2 vram.
  • Setup the shadow to be rendered over NBG0 and NBG2 (p. 259-260 of VDP2 manual).
  • Probably the trickiest part, insert some untextured drawing commands in VDP1 command list for the map screen to draw normal shadow pixels on the same area as the black pixels of the dialog box.

  paul_met Oct 25, 2019

fafling said:

I'm afraid that I don’t have enough skills to create VPD1 objects.
On the other hand, if the degree of translucency of the dialog window is reduced to a certain level, the non-translucency of the NBG2 layer is almost not evident.

 fafling Oct 25, 2019
I think it's still pretty obvious.

 paul_met Oct 26, 2019
Okay. I noticed that when I switch Color Ram Mode = 0, the palette for only two layers deteriorates (NBG1 - text, NBG3 - dialog box). While the background palette (NBG0) and color areas (NBG2) remain the same. In addition, if you change bits 8 and 9 at the address 18000E, it turns out that the layers NBG0 and NBG2 use VRAM-A, but NBG1 and NBG3 use VRAM-B. How to make all layers use VRAM-A?

 fafling Oct 26, 2019
The color RAM adresses used by a layer have nothing to do with where that layer is stored in VDP2 VRAM. CRAM addresses are determined by (p. 69-74, 76-78 and 216-217 of VDP2 manual) :
  • Character pattern dot color code
  • Pattern name palette number
  • Supplementary palette number if pattern name data size is 1 word
  • Color ram address offset

 < Prev  1  2  3  Next>