HomeForumsWhat's newResources 
 
 
Retail Game Research
TrekkiesUnite118 - Feb 16, 2021
  TrekkiesUnite118 Feb 16, 2021
This is a topic I figured I'd make after discussing it in the discord channel so it wasn't lost. Basically this topic is for researching neat things retail Saturn games do so homebrew developers can try to use them in their own games and demos.

So first up I'm posting one I found in Grandia. Grandia uses the RGB0 layer to draw Planes for the lowest floor layer in it's maps. What's interesting is it uses 1 RGB0 layer to draw the plane at different heights for the map, and is even able to move the camera freely around without issues:


https://youtube.com/bSHJ8x7L2rM



https://youtube.com/AOsUdG8P9pg



In these videos you can see the RGB0 layer is being split to draw at different heights and even have different effects applied such as the water effect. It was discussed last night that they could be using interrupts to update the K-Tables or that they're probably using the Window Screen to pull it off. But overall it's a pretty neat trick that's probably worth looking into to figure out exactly how it's done.

 XL2 Feb 16, 2021

TrekkiesUnite118 said:


With line windows you can switch between rotation parameter A and B and have 2 RGB0 planes overlapping each other.
Sgl has a demo showing this, "Fighting", with sadly very few comments.
As for how to do the wave effect, I don't know exactly other than it uses coefficient tables, but it looks really nice indeed.
The annoying thing with RGB planes is just how much memory they use.
Like here, that would be 3/4 of the vdp2 ram, leaving you only 128 KB for other things.
Maybe with bitmaps it would be possible to spend less vram, but I haven't had success with it when I tried...probably because I shared my coefficient/rotation parameter memory bank with other stuff

 Ponut Feb 16, 2021
As pointed out by Fafling, this is using the "line window" feature of VDP2.
Ostensibly, it can be used to give different parameters for certain sections of the screen given a start and end coordinates on each line of the screen for each window.


In short, this is a documented feature and we should not be surprised to see it used, but it is a very cool feature that is noteworthy for one who wants to integrate VDP2 into their 3D environments.

However, the line window is "binary". 0 or 1 is its option, and it is not a bitmap. As its title suggests, it is a line-based window, thus has start and end coordinates for window process selection on each line.

  XL2 Feb 17, 2021

Ponut said:

The line window can be seen as a polygon : you would just software rasterize your top plane.
Of course, you could add more planes with vertical interrupts, so you could probably do a quite complex scene with the rbg0 only...but of course it's rarely useful considering you could just do it with the VDP1 in a few minutes.

 fafling Feb 17, 2021

XL2 said:

The distortion effect over the water part doesn't seem to rotate with the texture, nor change on a screen line, so I don't think the coefficient table requires a bank because It only needs to be read once per screen line. In that case, it can be set anywhere in VDP2 VRAM. So RBG0 minimum requirement here is 2 bank partitions since it's a tilemap, which would leave half of VRAM free.

The temporal change in distortion can be obtained by variating the coefficients each frame. They seem to be looping.

To ensure that the switch between rotation parameters can always be made with the line window, one of the 2 areas of RBG0 has to be convex. That way it never needs more than one start and one stop coordinate on each screen line.