| Home | Forums | What's new | Resources | |
| any body remember ff7 being converted.... |
| Shitface - May 21, 2003 |
| Prev | 1 | 2 | 3 | 4 | 5 | 6 | Next |
| antime | May 30, 2003 | ||
| 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. | |||
| Daniel Eriksson | May 30, 2003 | |||
I can confirme that it has snowflakes. They even light up the ground 1 cm around them when they land. | ||||
| M3d10n | May 30, 2003 | |||
| 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:
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 | May 30, 2003 | |||
No. | ||||
| antime | May 30, 2003 | |||
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 | May 30, 2003 | ||
| 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 | May 30, 2003 | ||
| 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 | May 30, 2003 | |||
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 | May 31, 2003 | |||
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 | May 31, 2003 | |||
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 | May 31, 2003 | |||
: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 | May 31, 2003 | ||
| 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 | May 31, 2003 | ||
| 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 | Jun 1, 2003 | |||
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 | Jun 1, 2003 | ||||||
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. They are not lower resolution, but might be sprites. One huge, scaled, rotated sprite Anyone here who have played Street Racer? It rules! Check this : It looks fantastic. | |||||||
| M3d10n | Jun 1, 2003 | ||
| 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 | Jun 1, 2003 | ||||||
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. | |||||||
| Prev | 1 | 2 | 3 | 4 | 5 | 6 | Next |