VDP2 questions

I was trying to set up the VDP2 in a way to get a 512x256x32bit bitmap mode in a 320x240x24bit resolution using NBG0... so after reading that darned long PDF file I found some registers that apparently need to be set:

-TVMD to %1000000000010000, to set the proper resolution

-EXTEN to 0 (dunno why but Antime does this in copper2.asm)

-BGON to $101, to enable NBG0 and turn it's transparency off

-CHCTLA to %1000010 to set a 512x256x24bit bitmap

But I feel that isn't all - I mean, where exactly IS NBG0 located in VRAM? Do I need to set that somewhere? Moreover, what is this thing with windows? I don't have a clue how they fit in with the multiple screens thing...

/me is really really confused now :-(
 
I set EXTEN to zero, because I don't use its features. There's little harm in leaving the functions enabled but if someone happens to leave a lightgun plugged in and starts playing with it you might get crashes. The register should be cleared on startup, but it is a good practice to set registers to known values and only enable the features you use.

Anyhoo, I believe the map offset register is what decides where the bitmap starts in memory. Bart Trzynadlowski has a bitmap sample program on his page, maybe you can find out the details from that.
 
EDIT: antime already awnsered to the question that was here.

Moreover, what is this thing with windows? I don't have a clue how they fit in with the multiple screens thing...


Ever seen a SNES game with a curtain effect, like the Super Mario World opening (the cartoon-style "ball" fade-in)? It's a setting that "clips" a BG to a given size. Saturn has the mother of all clippers... SNES had horizontal clippers only to a given color. Saturn can do clipping on the horizontal and vertical locations, and show the inside, the outside, overimpose two windows with AND (a way to create transparency without cost) and er... lots of other fancy stuff.

To add to that, you had to make a special DMA mode in SNES to let the window do fancy drawings, that had some processor cost. VDP2 eats stuff like that for breakfast
smile.gif
It's very exciting stuff ^^;;;
 
yeah I'm pretty darn certain VDP2 holds a lot of untapped power... but I should add the PSX' GPU is a LOT easier to program <_<
 
okay I've looked up the map offset register (MPOFN). The bit layout, however, makes no sense to me! There are these 3-bit groups like N0MP8, NOMP7 and N0MP6. Now the documentation isn't very clear on this, how is an address formed from these values? Are they somehow combined with the MPxxN0 registers? And what are these planes?
 
The bits are explained on page 86 of the doc (page 104 of the PDF). For NBG0, use bits N0MP6-N0MP8. The bits are numbered 6-8 because for tiled modes they are combined with the Normal Map Screen Scroll Registers, which hold bits 0-5. For bitmaps the start address seems to be 0x20000*offset bit value.
 
okay I wrote some more code to deal with the VDP2... however I keep getting stuff like this:

capture00.jpg


Now here's what I write to the registers:

-%1000000000010000 to TVMD

-0 to EXTEN

-0x101 to BGON

-0 to LCTAU and LCTAL

-%110010 to CHCTLA

-0 to CHCTLB

-0 to MPOFN

And then I blast some test pixels to $25E00000 (I believe this is the greeny bar you see) - but instead of a 'clean' screen with some the lines of pixels that I wrote I get all this garbage - what did I do wrong?
 
Now here's what I write to the registers:

-%1000000000010000 to TVMD

-0 to EXTEN

-0x101 to BGON

-0 to LCTAU and LCTAL

-%110010 to CHCTLA

-0 to CHCTLB

-0 to MPOFN

I may be mistaken, but it looks like your write to BGON enables NBG2, and you never configure it anywhere else, so your writes to VDP2 RAM are probably translating into garbage on NBG2.
 
-0x101 to BGON

That's a hex value (stupid of me to mix number systems), so it sets bit 0 and bit 8... by the way printf told me to try some other values for MPOFN, and setting it to 3 got me a clear screen (so apparently the garbage comes from VRAM and sits somewhere in the lower region)...
 
If you're still interested in finding out what caused this, page 265 (PDF page 283) of the VDP2 doc has a table of all data structures that use VRAM, and their corresponding configuration registers. You might want to try setting it up so that nothing shares the same address and then run through a loop throwing your test pixels at each area and waiting a few seconds or some similar diagnostic.
 
In order not to create a new topic, I’ll ask here. Is it possible to make layers 1 and 2 translucent for layer 3 at the same time (when I see layer 3 through layers 1 and 2)? If it possible, what should be the settings for all layers.
 
It is possible only in standard resolution.

I suppose that layers are numbered in decreasing priority order, layer 1 has the highest priority and 3 the lowest.
I also suppose that layer 3 has no transparent pixels. Otherwise, replace layer 3 in the following explanation by whatever mix of layers is below layers 1 and 2.

Page numbers are those of VDP2 manual.

So you have to :
  • Set VDP2 horizontal resolution to normal graphic A or B (p. 18).
  • Enable extended color calculation and disable gradation (p.240-241). Extended color calculation can't be used with gradation.
  • Set color calculation ratio mode and color calculation mode (p. 241). Any value can be used, but for the sake of simplicity (this is complicated enough), I suppose they're set to classic values : CC ratio are used and taken on the top layer.
  • Enable color calculation on layers 1 and 2 (p. 242). If sprites is one of those layers, set their color calculation condition (p. 207).
  • Set CC ratio on layer 1, and, if layer 1 has transparent pixels, on layer 2 (p. 210-212 for sprites and 243-244 for other layers). This CC ratio is only used when a layer is the top layer, so layer 2 CC ratio is used where layer 1 has transparent pixels.
  • One of the following conditions must be met :
    • Layer 3 must contain only RGB pixels (sprites color mode set to 1 p. 207, with only RGB pixels in the framebuffer, or character color mode set to RGB format for the other layers p. 60-61).
    • If layer 3 contains palette pixels, the color RAM must be set to mode 0 (p. 46).
When layer 2 is under a semi-transparent pixels of layer1, it is first blended with layer 3 with a fixed 0.5 CC ratio (see table p. 238), then blended with layer 1 using this layer's CC ratio.

Not the simplest subject for my first post here !
 
Last edited:
When layer 2 is under a semi-transparent pixels of layer1, it is first blended with layer 3 with a fixed 0.5 CC ratio (see table p. 238), then blended with layer 1 using this layer's CC ratio.
This is exactly the effect I want to achieve. But so far it does not work out. Here are screenshots with layers and layer settings.
As you can see, when you turn on the translucency for the topmost layer, the second layer becomes opaque and the third layer is not visible through it.
soldner.png

VDP2-sets.png
 
You're using a palette layer as layer 3. Is color RAM mode set to 0 ?
It can be checked in Kronos v1.7.0, where it is added in General info of VDP2 debug window, under Sprite stuff.
 
Last edited:
From I know and see of vdp2. It not can blend more than once layer between other. In simply words. Only one layer can be have translucy, not multilayer.
That's why I was embarrassed, why the developers did not make the dialog box translucent on the screen with the global map (in other cases, the dialog box is translucent).

You're using a palette layer as layer 3. Is color RAM mode set to 0 ?
Yes . There are no different visually from CRM=0 and CRM=2. But when CRM= 2 is activated, it turns out like this.
 

Attachments

  • m2.png
    m2.png
    162 KB · Views: 136
@David Gámiz Jiménez Sure you can have multilayer blending, that's what extended color calculation is for. Check Sonic R, it uses that for the water ripples and reflections in the first stage.

@paul_met You mean color RAM mode 0 and 1 are not different visually. Mode 2 is different because it uses 24 bit colors instead of 15 bit colors like the other 2.
The difference of mode 0 is that colors are mirrored so it contains twice as less colors than mode 1. It's probably to enable a faster access to the color RAM than in mode 1.
I see that the mosaic effect is enabled on NBG0, it could be what prevents the blending effect in the emulator. Since there's no such restriction in the manual, could be an emulator bug. Have you tested on the console ?
 
Last edited:
I see that the mosaic effect is enabled on NBG0, it could be what prevents the blending effect in the emulator. Since there's no such restriction in the manual, could be an emulator bug. Have you tested on the console ?
No, I don’t have the original hardware. But I tried on another emulator (SSF) and double translucency works! But it works only if Color Ram Mode = 1. So, you are right, Yabause have a bug with ECC. Anyway it is strange why developers did not want to use ECC...
 

Attachments

  • ssf.png
    ssf.png
    174.8 KB · Views: 119
Back
Top