any body remember ff7 being converted....

[TakaIsSilly]

- Snow (simply too many quads needed)

The problem is not the quads, it's the time needed to sort them. I confess I only played the PC version of MGS, but snow looked like plain, 1-bit color quads, using a basic "snow physics" model like the ones in demos of the 90's, but in 3D. That doesn't look very hard to implement... biggest problem would be stuff like priority over the scenario.

- Underwater transparency

That would be well, hard. Not impossible. We'd draw the scene below the water on the framebuffer, then a window effect, store that framebuffer result, then draw the remaining polys(considering clipping problems, of course)over the previous "picture". The framerate would be cut at 30fps, due to the two rendering stages.

- Motion blur in cutscenes

We could mock something out with the direct framebuffer access. We'd store the previous frame, and apply a motion filter tru the new frame using err... the DSP? Slave SH2? depends. I forsee less than 30fps in this events, altough, since the algorith is heavy.

...Now, the ninja suit, _that_ I have no idea how to do it, especially in real time and in gameplay ^^;

--

Isn't the impossibility of the 5 layers at the same time due to memory limitations? In that, you could activate them, but there would not be bandwidth enough to send all the data needed, and the screens would be corrupted. So the marketing would be correct, the screen can be activated, they just can not be used ^^;

 

[Daniel Eriksson]

One thing I thought about when talking about groundplanes. How many can the Saturn show at the same time? I know streetracer uses loads of them. It has 8 player splitscreen, and each screen has its own "mode7" plane. Either that, or there is only one plane but its shown in 8 windows. However, that would be strange since there are polygonal objects on the track. And loads of sprites. In one or two-player mode they have used one plane for clouds, and another one for clouds shadowed on the ground. How does all this work? Can the Saturn use 8 "mode7" planes?

 

[antime]

Two rotational planes simultaneously, but you can change the parameters when going down the screen. If there is a vertical split the game probably uses something else.

 

[Tagrineth]

Are you certain? I'm thinking especially of the bull-like creatures at the start. When you kill them, they get overlaid with this flame animation and the game slows down for a few frames. I admit I'm using composite through a capture card, so the details are kind of hard to see.

Absolutely certain. They may have used dithering to make the flames appear transparent, but there are no attempts at real transparency.

EDIT: According to one of the Saturn introduction manuals, the following combinations can be used (normal-rotation): 4-0, 2-1, 0-2. Maybe they're counting the line and back screens in their marketing?

Could've sworn it was five. Ah well, anyway, 4-0/2-1/0-2 actually makes sense - let's say it has four theoretical "Background execution units." For a standard scrolling background plane we need one execution unit, so 4 backgrounds; or, for a "Mode 7" plane, we need two units, so if you used one, two units would be left for either another "mode 7" plane or two standard backgrounds. =)

That's what I mean. Aku DX uses full projection, despite being a fully 2D game, because of some use of 3D backgrounds (the clock tower in the background, in the large room before fighting Richter comes to mind) and other 3D effects (Save rooms).

Have you disassembled the game?

You seem to know a lot about Saturn's real capabilities. Can Saturn render non-projected planar objects over a projected 3D background? Or how about for save rooms, can it have the spinning... things... pass correctly behind Alucard without some 3D sorting?

Didn't Christmas Nights used snow?

The problem is not the quads, it's the time needed to sort them. I confess I only played the PC version of MGS, but snow looked like plain, 1-bit color quads, using a basic "snow physics" model like the ones in demos of the 90's, but in 3D. That doesn't look very hard to implement... biggest problem would be stuff like priority over the scenario.

Hmm... yes, sorting them would be painful, now that I think about it. I know they were plain 1-bit quads... how many quads per second could Saturn theoretically project?

And wrt Christmas Nights: I don't think it does; I haven't played it yet, but I've seen some screens of it running in GiriGiri and Satourne and I don't remember seeing any snow flakes.

That would be well, hard. Not impossible. We'd draw the scene below the water on the framebuffer, then a window effect, store that framebuffer result, then draw the remaining polys(considering clipping problems, of course)over the previous "picture". The framerate would be cut at 30fps, due to the two rendering stages.

Hmm... I suspect the frame rate would be less than 30, I'm afraid. It isn't as straightforward as 'two rendering stages.' It never is. =)

We could mock something out with the direct framebuffer access. We'd store the previous frame, and apply a motion filter tru the new frame using err... the DSP? Slave SH2? depends. I forsee less than 30fps in this events, altough, since the algorith is heavy.

PSX does it, AFAIR, by rendering the new frame, shifting the previous frame, and blending it over the new frame. Repeat for as many stages of blur you want.

Considering that AI, collision detection, etc. could be (and are) turned off in favour of pre-defined paths, one SH-2 probably could be dedicated to the task... wouldn't it be nice if Saturn supported pre-compiled display lists like PS2 though? =)

 

[Daniel Eriksson]

And wrt Christmas Nights: I don't think it does; I haven't played it yet, but I've seen some screens of it running in GiriGiri and Satourne and I don't remember seeing any snow flakes.

I can confirme that it has snowflakes. They even light up the ground 1 cm around them when they land.

 

[M3d10n]

On the multiple mode7... aren't those limitations per frame, and when running at full sync (60fps)?

If so, one can double the amount of mode 7 planes if their games are locked to 30fps. They just render 2 planes in one frame, then keep the buffer and draw more 2 planes. You get 4 planes in a 30fps game.

In a 20fps game (many Saturn games used that rate), one could use 6 planes. And 8 planes for 15fps.

I also have a game that any of you guys who own an actual Saturn should take a look, that seems to make a FAR more abusive usage of mode7 planes: Hexen. The game doesn't use polygons. It seems the WHOLE scenery is built using mode7 planes! You can tell it the moment you lay the eyes upon the game, since the textures have sub-pixel accuracy, something only the VDP2 planes can do, instead of becoming blocky and shaking as Quake's and Duke Nukem's textures. They move in a much more smoother way. But the framerate is kinda low, so...

As for snow:

Hmm... yes, sorting them would be painful, now that I think about it. I know they were plain 1-bit quads... how many quads per second could Saturn theoretically project?

And wrt Christmas Nights: I don't think it does; I haven't played it yet, but I've seen some screens of it running in GiriGiri and Satourne and I don't remember seeing any snow flakes.

Xmas Nights has snowflakes when you play the winter version of the level. The XMAS version has falling stars. And when those stars hit the ground they lit the area they hit, with gouraud shading.

It's a sight to be seen.

Anyway, you don't need quads for rendering bilboard particle stuff. That's a bummer! One can get away using zoommed sprites, by doing some less accurate distance/zoom ratio calculation, and calculating only the single 3D point where the particle is.

 

[antime]

Originally posted by M3d10n@May 30, 2003 @ 11:34 PM

On the multiple mode7... aren't those limitations per frame, and when running at full sync (60fps)?

No.

 

[antime]

Originally posted by Tagrineth@May 30, 2003 @ 09:22 PM

Can Saturn render non-projected planar objects over a projected 3D background? Or how about for save rooms, can it have the spinning... things... pass correctly behind Alucard without some 3D sorting?

Sprites are sprites are sprites. They will be drawn on top of each other in the order defined by the display list. The objects will have to be sorted in some way anyway for the priorities to be correct, it doesn't matter that one object happens to be a 3D model of a coffin as long as it is drawn before the character sprite.

 

[M3d10n]

Hmm... wouldn't it be possible to use the same two planes, but render them in different positions with different "texture" in consecutive frames and displaying only the result? Thus faking four planes at half rate?

 

[Daniel Eriksson]

But have you SEEN Street Racer? I am sure they use 8 "mode7" planes in 30 fps. No doubt, or what kind of strange programming would it else be?

 

[Tagrineth]

Originally posted by antime+May 30, 2003 @ 04:54 PM--><div class='quotetop'>QUOTE(antime @ May 30, 2003 @ 04:54 PM)</div><div class='quotemain'> <!--QuoteBegin-Tagrineth@May 30, 2003 @ 09:22 PM

Can Saturn render non-projected planar objects over a projected 3D background? Or how about for save rooms, can it have the spinning... things... pass correctly behind Alucard without some 3D sorting?

Sprites are sprites are sprites. They will be drawn on top of each other in the order defined by the display list. The objects will have to be sorted in some way anyway for the priorities to be correct, it doesn't matter that one object happens to be a 3D model of a coffin as long as it is drawn before the character sprite. [/b][/quote]

But the sorting for an object that wraps around or at least moves around another object (or even several other objects) is more computational than regular ordering.

Also it isn't as simple as "Drawn before the character sprite" because the pieces spin around Alucard and at one point he is inside the coffin.

 

[antime]

Originally posted by Tagrineth@May 31, 2003 @ 01:42 AM

But the sorting for an object that wraps around or at least moves around another object (or even several other objects) is more computational than regular ordering.

Also it isn't as simple as "Drawn before the character sprite" because the pieces spin around Alucard and at one point he is inside the coffin.

Sure, but it's a special case in a special room. IIRC there are some other cases were sprites will pass both over and under the "playfield". There's so few sprites and simple animation that it's not computationally expensive. For the coffin animation you could even include the priorities in the animation: the parts of the coffin that face the screen gets a higher priority than the player sprite, the rest get a lower priority.

 

[antime]

Originally posted by M3d10n@May 31, 2003 @ 12:44 AM

Hmm... wouldn't it be possible to use the same two planes, but render them in different positions with different "texture" in consecutive frames and displaying only the result? Thus faking four planes at half rate?

VDP2 doesn't work that way, there's no back buffer to render into. The screen is completely redrawn each frame.

However, it seems that you can set up VDP2 to read a coefficient table for each pixel. If the circuit is completely flat you might get by using the viewpoint mode, but I'm not quite clear on how this mode works. But setting up parameters for each pixel of the screen for each frame starts getting so expensive you could software-render the track as a bitmap instead.

 

[ExCyber]

There's so few sprites and simple animation that it's not computationally expensive.

:agree

Keep in mind that Z buffer rendering systems - which have been implemented in software renderers - essentially do the equivalent of a per-pixel depth sort, while the save room animation would probably be fine with a per-sprite depth sort.

 

[TakaIsSilly]

Err.. isn't Hexen based on a software raytracing like the doom port? That explain the pixel texture accurancy _and_ the low framerate.

With 8 players on the same screen, can't the tracks be just lower-resolution sprites? Street racer is not very heavy in the 3D department.

As for the snow and amount of sprites, it's a matter of trying. My bet goes that the saturn can go up to a couple million of unsorted 1bpp snow sprites at 60fps. I'll play with the concept next week and let you know.

 

[Alexvrb]

Last I heard, the last console port of Doom to use a raytracing engine like the PC game was 32X doom. Which actually was a very good conversion, pretty accurate to the PC one. Last console port handled by John Carmack himself, I believe. The Saturn Doom and Hexen ports suck.

I was thinking, with the help of the 4MB RAM, one game that would have made a great port to Saturn would be Daggerfall: Elder Scrolls 2. It ran well on my 486, loading aside (which is where streaming and the 4MB RAM would come in). The ground in most areas could just be a mode7 plane, it already has a cut-off "fog" to limit the amount of polys displayed, and basically everything constructed out of two triangles could become one quad. Also the characters/monsters are 2d. If you've played the game, you could see what I mean. It was a great game and a massive adventure, and could have been a killer game for Saturn.

 

[ExCyber]

Err.. isn't Hexen based on a software raytracing like the doom port?

I think you're confusing raytracing and raycasting. Raytracing is a painfully slow rendering method that is generally unsuitable for realtime game engines. In raytracing, light paths are traced from light emitters and followed until they are either absorbed by objects, fly off into space, or hit the camera. This is an extremely intensive operation because every light path has to be followed. Raycasting is basically a hidden surface removal method (like depth sorting and Z buffering) that allows various kinds of hefty optimizations if set up correctly; games like Wolfenstein 3D, Doom, and Hexen are actually quite two-dimensional internally, with the height aspect being "faked" in varyingly sophisticated ways.

edit: maybe I'm thinking of the original Heretic and not Hexen.

 

[Daniel Eriksson]

I was thinking, with the help of the 4MB RAM, one game that would have made a great port to Saturn would be Daggerfall: Elder Scrolls 2.

I have also thought about that. The game would work perfectly. Maybe a little hard with all controls though, but I think it would work.

With 8 players on the same screen, can't the tracks be just lower-resolution sprites? Street racer is not very heavy in the 3D department.

They are not lower resolution, but might be sprites. One huge, scaled, rotated sprite

Since you can turn around and see everything from every angle, so its not just like those old racinggames (Outrun) that only used sprites.

Anyone here who have played Street Racer? It rules! Check this :

It looks fantastic.

 

[M3d10n]

The split-screen plane does looks like mode7.

Lemme see if I got this... in Street Races split screen, it's actually a single plane, but each split area uses a different rotation/scaling matrix?

So, while you can't display more than two planes on top of each other, you can have the same planes viewed from different angles if you split the screen? It seems the case.

Anyway, I don't know exactly how Hexen works, but one thing is for sure: the scenery is drawn to/by the VDP2. I say that because Hexen has some transparency effects in some areas, and those transparencies only affect other 2D sprites, not the 3D background itself.

It's the VDP1 sprite-to-sprite transparency, that never shows the backgrounds (when a sprite with such transparency is put against the background, it renders opaque).

But the framerate manages to be a bit higher than Doom's, while sitll being low. Doom was made using polygons, as the 3DO version.

 

[TakaIsSilly]

Originally posted by ExCyber@Jun 1, 2003 @ 06:04 AM

Err.. isn't Hexen based on a software raytracing like the doom port?

I think you're confusing raytracing and raycasting.

yes i am >_< stupid me. i really meant raycasting.

Oke, let's see... Street Racer does look quite nice. and the infinite gound seem to show a mode7 screenie. This boggles my mind,since using a sprite arena won't work like this.

I'm still convinced that a great deal Hexen's (and Doom's) low framerate is due to massive software calculation in one point or another. And, i'm not sure if i'm right or not, but sprite "wobbling" is a weakness of the 3D engine, and not of the way the sprites are setup. The sprite has the same deformation parameters/matrix than a mode7 screen. So, a very accurate 3D engine, let's say that used floating point or somthing, would make high quality scenario at cost of framerate.