HomeForumsWhat's newResources 
 
 
Some technical questions
RockinB - Aug 20, 2005
  RockinB Aug 20, 2005
How long is the vblank period, between vblank-in and vblank-out interrupt? This is the time when we can savely access VRAM, so it's good to know how much computation can be done during that.

From the discussion about PAL-progressive video output of modern DVD players (or from photos taken from TV screens) you know, that one frame is only shown by half, followed by the other half. Is that true, even for NTSC? If so, why don't we just let the VDP1 render only the top half and then render the bottom half? This would assume that the drawing is in synch with TV update and would most likely only be a senseful option when running at full speed, e.g. 50 FPS for PAL and 60 FPS for NTSC.

The goal is to reduce the load on the VDP1 for increasing the number of frames per second. One can set the framebuffer write & erase area manually.

It is said that with the VDP1 color calculations (gouraud...) are only possible with RGB format character pattern. Could it be possible with color lookup table format, too? Because the lookup table can contain both, RGB and palette pixel format.

Using double interlace in VDP1 uses both framebuffer at the same time, each for writing to from VDP1 and reading from with VDP2. So what about VRAM access conflicts between both video processors? When would the erase take place?

The high resolution mode of VDP1 is IIRC only possible using 8 bits per pixel palette format. So how can these high resolution fighting games use gouraud shading? Or did they use double interlace instead? Or am I slightly wrong about that....

Why can't the SCU perform burst read (DMA?) from the VRAM (possibly including framebuffers)? Can instead the CPU perform DMA read access in these areas?

Thanks guys!

 antime Aug 20, 2005

  
	
	

		
		

			Originally posted by Rockin'-B@Sun, 2005-08-21 @ 05:42 PM



From the discussion about PAL-progressive video output of modern DVD players (or from photos taken from TV screens) you know, that one frame is only shown by half, followed by the other half. Is that true, even for NTSC? If so, why don't we just let the VDP1 render only the top half and then render the bottom half? This would assume that the drawing is in synch with TV update and would most likely only be a senseful option when running at full speed, e.g. 50 FPS for PAL and 60 FPS for NTSC.

Even though the fields are sometimes called "upper" and "lower" they contain every other scanline and span the whole screen height. If you want to display different images for each field, use the noninterlace mode (double-interlace mode would work as well, but be a bit pointless).


  
	
	

		
		

			It is said that with the VDP1 color calculations (gouraud...) are only possible with RGB format character pattern. Could it be possible with color lookup table format, too? Because the lookup table can contain both, RGB and palette pixel format.

You can use Gouraud shading with palettized textures, but it will interpolate the texture index values, not the actual colours. The same applies for transparency, shadow and half-brightness.


  
	
	

		
		

			Using double interlace in VDP1 uses both framebuffer at the same time, each for writing to from VDP1 and reading from with VDP2. So what about VRAM access conflicts between both video processors? When would the erase take place?

When using double-interlace you're still only accessing the "back buffer". The only difference is that one framebuffer will hold the even-numbered lines and the other the odd-numbered ones. Apart from setting the odd/even bit and essentially drawing the same screen twice, handling is the same as for other modes.


  
	
	

		
		

			The high resolution mode of VDP1 is IIRC only possible using 8 bits per pixel palette format. So how can these high resolution fighting games use gouraud shading? Or did they use double interlace instead? Or am I slightly wrong about that....

I don't remember at least VF2 using Gouraud shading. You can do it with carefully designed palettes, but more probable would be that only the vertical resolution was increased.


  
	
	

		
		

			Why can't the SCU perform burst read (DMA?) from the VRAM (possibly including framebuffers)? Can instead the CPU perform DMA read access in these areas?

IIRC it will interfere with RAM refresh. You can use CPU (non-burst) DMA access anywhere you can access manually; it operates the same.

 RockinB Aug 21, 2005
Thanks for your response!

So the upper and lower field just contain either even or odd lines. The double interlace mode should thus be high quality. But if the game does not run at 50/60 Hz this would mean the same image for even and odd lines for a couple of fields/frames. So using double interlace would be best at full speed.

About using color calculations with character patterns made using a color lookup table....it could be possible, maybe. The 16 color lookup table is an excellent method for saving texture memory. AND for assigning different priorities and different color calculation registers for each single pixel in palette mode.

I've once again read the CHROME demo of SGL. Indeed it does enable to put highlights into the interior of polygons, Which otherwise would only be possible by increasing polygon count.

The author furthermore says, that it renders faster than in RGB mode. But I'm not sure if that's right and for what reason.

Using this method is really crazy and difficult. I wonder if one could really efficiently exploit this, not only because of the lack of tools.

 antime Aug 22, 2005

  
	
	

		
		

			Originally posted by Rockin'-B@Mon, 2005-08-22 @ 01:23 PM



So the upper and lower field just contain either even or odd lines. The double interlace mode should thus be high quality. But if the game does not run at 50/60 Hz this would mean the same image for even and odd lines for a couple of fields/frames. So using double interlace would be best at full speed.

Yes, you have to pretty much design your game around never missing the frame buffer swap if you use that mode.


  
	
	

		
		

			About using color calculations with character patterns made using a color lookup table....it could be possible, maybe.

Take a look at late 80s and early 90s DOS demos for examples of what you can do with palette manipulation.


  
	
	

		
		

			The author furthermore says, that it renders faster than in RGB mode. But I'm not sure if that's right and for what reason.

Could very well be, but depends on the internal design of VDP1. Using RGB textures you need to read two bytes per source pixel, but only one when using VDP2-palettized textures. VDP1-palettized textures would need three reads (index and colour definition).

By the way, I checked with Charles MacDonald's VDP1 doc, and the shadow and half-transparency modes will not change palette values in the framebuffer. Instead, shadow will skip the pixel and half-transparency will write over it.

 RockinB Aug 22, 2005
I could verify in the VDP1 manual that all color calculations can be done in color lookup table mode, too. This includes the palette gouraud shading tricks, although the manual says that the result cannot be guaranteed. Hopefully this doesn't mean that there are different VDP1 revisions with some of them acting different for this case.

I'm interested in performance benchmarks of the different drawing modes to find an optimal solution.

The only things I found are:

- "shadow and half-transparency take 6 times longer, than without color calculation"

- "pre clipping takes up to 5 CPU cycles per line"


  
	
	

		
		

			Originally posted by antime+Mon, 2005-08-22 @ 08:24 PM-->
QUOTE(antime @ Mon, 2005-08-22 @ 08:24 PM)
Could very well be, but depends on the internal design of VDP1. Using RGB textures you need to read two bytes per source pixel, but only one when using VDP2-palettized textures. VDP1-palettized textures would need three reads (index and colour definition).




[post=138578]Quoted post[/post]


[/b]



So the only reason for speedup is due to reduced access to the VDP1 VRAM.

BTW: This trick allows textured polygons by drawing non-textured polygons (further speedup), by using a palette code for polygon color + gouraud shading. But the restriction of the result is even bigger.