Home / News
The Forums!
Dreamcast
Dev Forum
Saturn
Dev Forum
Misc
Wiki
SegaCD Utils


Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
vdp 1 3d?
01-08-2012, 10:52 AM
Post: #1
vdp 1 3d?
a question that i had for years after i first read the vdp 1 manual, is how do the saturn

do 3d (x,y,z and face normals)?

i only see 2d hardware function in the manual (the vdp 1 user manual) yet the SGL and SBL show

3d vertices and face normals like in other 3d hardware.

what do this mean does the vdp 1 have built in hardware for these functions or is it only

in software?

I know the saturn has some 3d hardware support as i look in the vdp 2 manual i see 3d placement

or the scoll and rotation screens.

can anybody help me?
Find all posts by this user
Quote this message in a reply
01-08-2012, 12:18 PM
Post: #2
vdp 1 3d?
VDP1 is a strictly 2D chip. You have to translate into display coordinates in software. If it wasn't immediately obvious, this also implies there's no Z-buffer, perspective correct texture mapping or other depth-related functionality.

ETA: Also, while you can provide a transformation matrix to rotate and scale VDP2 layers, they're not "3D". They're drawn strictly in the specified priority order, and don't intersect each other etc.

Saturn development resources
SATNKernel - a real-time kernel for the Saturn
Visit this user's website Find all posts by this user
Quote this message in a reply
01-08-2012, 07:12 PM
Post: #3
vdp 1 3d?
To go into a little more depth, you need to do all the 3D rotation/translation yourself with the SH2 or DSP, then calculate the screen projection coords (x and y on screen) from x/y/z, and feed those coords to VDP1. You handle EVERYTHING right up to the point where you would start rasterizing the polygon in a software renderer.

If you aren't familiar with this, a simple example 3D software renderer can be found in Yeti3D. There's a Saturn port here you can search for where it substitutes the VDP1 warped poly draw for the final step. That would demonstrate all steps leading up to using VDP1 for 3D.

Note that this is not perspective correct - VDP1 cannot render perspective correct polys. This means that as a poly gets closer to the viewer, you may wish to tesselate the poly to limit the size to make the affine rendering less noticeable. That's what later games on the PSX and Saturn did to minimize the "fish-eye" affect seen in many early games.
Visit this user's website Find all posts by this user
Quote this message in a reply
01-08-2012, 10:30 PM
Post: #4
vdp 1 3d?
the psx can't do 3d either?

saturn has gourad shading made hardware, that seems to be a clue of 3d hardware.

if it dont process any z positioning how it render shawdows calculations like it do?

also how do it process the normals (polygons face) data?

as for it not having a z-buffer that dont mean much but that it's old, a zbuffer is just

for not displaying overlapping pixels, but i heard the saturn uses zsort to handles overlapping

polygons.

and again for the vdp2 im pretty sure it do handles 3 axis xyz, i'll look back into that. i was

thinking if the vdp2 can handle 3 axis space and not the vdp1 then maybe the z code get pass to the

vdp2 where it get place and handles, sort of like they do transparacies. people say saturn cant do tranparacies

but clearly it can by vdp2 with color calculation's color ratio.
Find all posts by this user
Quote this message in a reply
01-08-2012, 11:23 PM
Post: #5
vdp 1 3d?
Coolgame Wrote:the psx can't do 3d either?

It doesn't do PERSPECTIVE CORRECT 3D. Almost no early 3D hardware did - it's all affine mapping. The GPU in the PSX is like the Saturn in that you need to pass it already calculated x/y screen coords rather than the 3D coords, but the PSX also has the GTE (Geometry Transform Engine) that specifically deals with 3D calculations and perspective projection - it takes the 3D coords and gives the GPU just what it needs. That all has to be done in software on either the SH2 or the DSP on the Saturn.

Quote:saturn has gourad shading made hardware, that seems to be a clue of 3d hardware.

Shading has nothing to do with 3D. It's just an effect that some hardware uses at the same time as 3D rasterization of polygons, but it could just as easily be used on plain 2D drawing.

Quote:if it dont process any z positioning how it render shawdows calculations like it do?

also how do it process the normals (polygons face) data?

In software. The GTE in the PSX helps with those calculations - the Saturn is all software.

Quote:as for it not having a z-buffer that dont mean much but that it's old, a zbuffer is just

for not displaying overlapping pixels, but i heard the saturn uses zsort to handles overlapping

polygons.

In software... and the PSX is the same for that. The most common thing both do is the Painter's Algorithm - sort the polys from front to back and draw them from back to front.

Quote:and again for the vdp2 im pretty sure it do handles 3 axis xyz, i'll look back into that. i was

thinking if the vdp2 can handle 3 axis space and not the vdp1 then maybe the z code get pass to the

vdp2 where it get place and handles, sort of like they do transparacies. people say saturn cant do tranparacies

but clearly it can by vdp2 with color calculation's color ratio.

The VDP2 manages a handful of 2D layers made of cells or plain bitmaps. That plane may be rotated about the x/y/z axes, but it's still ONE SINGLE FULL PLANE. You can only have two rotation planes on VDP2, so if you are satified with TWO 3D ROTATED IMAGES, yes, it does indeed do 3D. [Image: wink.gif] [Image: biggrin.gif]
Visit this user's website Find all posts by this user
Quote this message in a reply
01-12-2012, 03:34 AM
Post: #6
vdp 1 3d?
I like to get WinterSports Eins again, it's not on this site any more or the link is

broken.

but wintersports use 2d sprites it's 3d is prerendered.
Find all posts by this user
Quote this message in a reply
01-15-2012, 09:14 PM
Post: #7
vdp 1 3d?
Tank you Chilly Willy, this is the first time I see somebody speaking about my yeti3d Saturn port [Image: smile.gif]

And as explained above, everything related to 3D is actually done on software. The VDP1 is only used in order to display quads (2D shapes) on screen.
Visit this user's website Find all posts by this user
Quote this message in a reply
01-15-2012, 10:57 PM
Post: #8
vdp 1 3d?
cafe-alpha Wrote:Tank you Chilly Willy, this is the first time I see somebody speaking about my yeti3d Saturn port [Image: smile.gif]

And as explained above, everything related to 3D is actually done on software. The VDP1 is only used in order to display quads (2D shapes) on screen.

I've a bit of an interest in Yeti3D... I did ports to the 32X and N64, and now I'm working on ports of Yeti3D-Pro, which is the next step up from the original Yeti3D. The two main differences between the original and the Pro versions is Pro allows for slope, and uses models for objects and enemies, where the original is all flat, and uses sprites. The other difference is Pro uses a lot more memory. That's making it tough to port to the 32X as just the level map uses ALL the ram in the 32X. It would do well on the Saturn, though.
Visit this user's website Find all posts by this user
Quote this message in a reply
01-21-2012, 10:07 PM
Post: #9
vdp 1 3d?
Chilly Willy Wrote:I've a bit of an interest in Yeti3D... I did ports to the 32X and N64, and now I'm working on ports of Yeti3D-Pro, which is the next step up from the original Yeti3D. The two main differences between the original and the Pro versions is Pro allows for slope, and uses models for objects and enemies, where the original is all flat, and uses sprites. The other difference is Pro uses a lot more memory. That's making it tough to port to the 32X as just the level map uses ALL the ram in the 32X. It would do well on the Saturn, though.

About 3D models: there is support for displaying 3D models on non-Pro engine too !

(See draw_entity_as_model function in draw.c)

Memory should not be a problem on Saturn, but the increase of number of quads to process because of 3D models would make it unplayable on Saturn ...

Yeti3D Pro ... I discovered it when I made the first public release of my Yeti Saturn adaptation ^^;

At that time, I googled of the spelling of Yeti3D original author (in order to write readme.txt or so), and saw he actually released the Pro engine sources some months before.

I have added some Pro features to ietx2, but it is still WIP (well, I haven't modified source code for half a year, but let's say it is WIP anyway ...)

According to my changelog, I have added the following features:

- Level editor + conversion of all levels found in Yeti3D Pro sources to Saturn.

- Better visual looking by bilinear-resizing textures on PC when converting level data.

- Slopes.

- Transparency. (example here)

It is good to hear somebody interested in Yeti3D [Image: smile.gif] It gives me some motivation to continue my Saturn port !

I plan to release my Saturn port after S.A.T.U.R.N. contest judging and prizes shipping.
Visit this user's website Find all posts by this user
Quote this message in a reply
01-23-2012, 06:29 PM
Post: #10
vdp 1 3d?
cafe-alpha Wrote:About 3D models: there is support for displaying 3D models on non-Pro engine too !

(See draw_entity_as_model function in draw.c)

Support, yes, but it's not used. Yeti redirects all entity drawing to the sprite code. Given that there aren't any test models in the code, I'm not sure how complete the model code is. It may still have bugs, which led him to not use it until later versions which became the pro version.

Quote:Memory should not be a problem on Saturn, but the increase of number of quads to process because of 3D models would make it unplayable on Saturn ...

Well, that would depend on how many, wouldn't it? [Image: smile.gif] And using VDP1 for the drawing certainly increases the number since the processor doesn't have to draw the quad, just process them. Did you try changing the number of models, or which ones were used? There are comments in the Pro code about not using a couple models as it increased the number of polys so much that it became too slow, mainly from the sheer number of the objects (it think it was the cactus that had that comment).

Quote:Yeti3D Pro ... I discovered it when I made the first public release of my Yeti Saturn adaptation ^^;

At that time, I googled of the spelling of Yeti3D original author (in order to write readme.txt or so), and saw he actually released the Pro engine sources some months before.

I have added some Pro features to ietx2, but it is still WIP (well, I haven't modified source code for half a year, but let's say it is WIP anyway ...)

According to my changelog, I have added the following features:

- Level editor + conversion of all levels found in Yeti3D Pro sources to Saturn.

- Better visual looking by bilinear-resizing textures on PC when converting level data.

- Slopes.

- Transparency. (example here)

It is good to hear somebody interested in Yeti3D [Image: smile.gif] It gives me some motivation to continue my Saturn port !

I plan to release my Saturn port after S.A.T.U.R.N. contest judging and prizes shipping.

Well, it's good to discuss things with someone actually working on the code. I did various tests with the drawing parameters on the 32X when trying to get the speed up without resorting to large amounts of assembly. One thing I noticed in the 32X code that would affect the Saturn as well is to watch the signed vs unsigned integers in places where lots of shifting occurs. Unsigned ints use inline multi-bit shift opcodes, while signed ints call a subroutine that shifts the int one bit at a time (there are no multi-bit shifts for signed ints). There were places in the code I forced a cast to unsigned because I knew at those places the values were never negative and it was critical to use inline multi-bit shifting, not a subroutine. Depending on how many bits are shifted, it would actually be better to do something like this than to use signed shifting:

Code:
#define rshift(val, n) ((v<0) ? -(int)((unsigned int)(-val) >> n) : (int)((unsigned int)val >> n))

You avoid the jsr/rts, and several shifts. At least if you use a constant for the shift count, they have different subroutines for each constant shift count. If the shift count is unknown, it has to call a more generic routine to handle the unknown number of shifts, which makes it even slower.

I got in the habit of compiling snippets of code to assembly with the SH2 to see if it needed a little help. [Image: smile.gif]

I ran into the same thing when making a version of Tremor for the 32X... which would probably be pretty good on the Saturn. It runs completely on the slave SH2. The 32X can handle 22kHz mono or 11kHz stereo with my current code, so the Saturn should be even better with it's faster clock rate and 32 bit buses.
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: