Sega Saturn to the limit (I)

First draft translation. Apologies for the mistakes. I will improve the text in future revisions.

Advice: long post

Introduction

Long ago I started this post, possibly by 2010 or 2011. At that time I was finished or just happened (I can not remember perfectly) the Panzer Dragoon Saga in my second SS, a model B. Both second hand. The first one A PAL model, launch. What gave me, I believe remember, my cousin Nono on behalf of his sister-in-law Maripaz. That was the Sega Saturn they had in the “legendary” Legend store in my town. The problem is that It had no A/V cable at that time, the one It had, It had one of the pins of the output video connector of the SS broken. I managed it as best I could and started it, in unorthodox way. Welding the cables, one by one, on the inside of the console, on the legs where each color corresponded with the pin.

But as I said, I just had the Panzer Dragoon Saga, but without before, I did not have the Panzer Dragoon 1 and Zwei… and a few more games of SS. At that time, I was “on fire” playing old platforms, remembering those years 1995/96 when I could not have my 32bits of turn… ains, ains…

But the magic of nostalgia, although almost 16 years later I played these games, the emotion was the same … the magic was there. And the memory of the struggles/talks with friends of PSX (In Loja with cousin Nono and Fernando Filter mainly) or the talks with friends pro SS as Pablo Vidal in Málaga returned to my mind again, to my heart.

And today, after 24 years since the SS left, I see myself reading their official SDKs, and even more incredible: understanding them. Understanding the beautiful complexity of this SEGA machine. And I find myself solving the pending debts of the past with myself and with her. Looking for the possibility that what was not. Why was it? or in the best of cases, find the justification that if it had been done. And yes, IF it is possible, and it is more, I have discovered that it was done … and very well that it was done in some cases.

And here is another task in which I embarked, to investigate and understand how it was done in those games, possible the “impossible”, which was also perhaps the best thing that could be done at that particular moment, now historical. Well it was a moment full of variables that, sadly, went against the Sega Saturn itself. From the fierce competition that at that time with the arrival of Sony existed and with the variables against coming from the same mother of the console, the same SEGA.

But I will try more than to focus on the general technical aspects known. Put the focus on what at the time most doubts caused me regarding the PSX.

As a clarification of the complete technical specifications of the Sega Saturn, we have this great wiki page:

• Segaretro.org – Sega Saturn / Technical specifications

The rest of the general technical issues of the Sega Saturn I think are superbly exposed in these companion entries Urian:

• Gráficos Retro: Sega Saturn (in Spanish)

• Fe de Erratas sobre Saturn (in Spanish)

Nor will I focus, at least in this entry, on the “political” part of the time: the errors and/or such complex and special circumstances of the moment, where SEGA and his/our Sega Saturn lost out. This part also explains Urian very well, where I share with him many of his thoughts:

• El boicot contra Sega Saturn (in Spanish)

But let’s go to the cut, to what interests me. For this I have used a study that I have been doing as I was progressing in the investigation of the games that seemed to me the best of the machine. In this spreadsheet you have the data that I have collected from 323 games. Of the approx. 1200 titles in total. That they are 20% approx. of the total. We go in parts:

Index:

1. The impossible to solve: Triangle vs Quadrangle.
   1.1 Triangle vs Quadrangle – EXTRA Ball: UV Mapping
2. The least complicated: Gouraud shading and dynamic colour lighting.
3. The complicated I: Softness in 3D games = 500/1.000/1.500/~2.000 quads frame = 25/30/60 stable FPS.
   3.1 The complicated I – EXTRA Ball I: Use of the SCU-DSP
   3.2 The complicated I – EXTRA Ball II: Resolution screen SD/HD
   3.3 The complicated I – EXTRA Ball III: Tessellation/LOD scenario/Mip Mapping
4. The complicated II: FMV full screen and colour quality.
   4.1 The Complicated II – EXTRA I Ball: Advanced Color Calculation Function “Gradation / Boken / Blur”
   
5. The most complicated: Transparencies and / or half-transparencies
   5.1 Transparencies and / or half-transparencies – EXTRA I Ball: Transparencies + Gouraud = “Table FOG “o Depth Cueing
   5.2 Transparencies and / or half-transparencies – EXTRA Ball II: Reflections in floors
6. The most complicated II: Render-to-texture
7. The difficult to” see “: Reverb and / or Echo sound effects
   7.1 The difficult to” see “- EXTRA I Ball: ADPCM and CD-ROM XA
8. The difficult thing to” load “: Loads the game without stopping
   Conclusions
   Epilogue
   References
   Glossary

---

1. The impossible to solve: Triangle vs Quadrangle.

The Sega Saturn had as a 3D primitive the quadrangle, that is, a polygon with four edges, not the minimum polygon with 3 edges. The problems derived from it: There are more vertices to transform, although there were ways (at the level of code and SEGA SDK algorithms) to save the repetition of the calculation, if a quad is used as a triangle. But the deformation in both texture and shading Gouraud persists. And to model more textured objects requires a different technical dynamics than the triangle. Another issue is the issue of passing models based on the triangle of PSX to SS pull, this caused more ugly textures in our Saturn compared to the original PSX.

At this point note, as we have said. The SS has as its basic primitive the quadrangle. But being more precise, it’s the sprite. That is to say, this translates that as a difference with PSX, the textures are not projected in a UV space, so well known by 3D artists. The textures do not fit into a space. The SS already has this space “blocked”. This even makes converting 3D models from PSX to SS more complex. With this “imposition”, or maladjustment of UV texture space, the flexibility at the time of texturing was lost, since playing with tiles and scale in a large polygon, something very used, in SS I could not do. One would have to use a quad per tile, compose textures in realtime and/or do pre-computed “mip mapping” that would entail occupying more VRAM, typically 1/3 more per texture.

The reality was that the SS was a machine that handled Sprites. It was a machine eminently designed for 2D games. But with the arrival of 3D, Sega during its final development adapted it to the maximum for it. This particularity is that at the end internally the SS when drawing textured faces/polygons, what it really does is distort a square sprite. Giving perspective and placing it in space.

In the end was this situation of disadvantage fixed?

Complicated and possibly partially solved. Depending on the title and the company that is behind each one. When we talk about ports or versions from other systems almost with total security they used automatic converters of triangle to quadrilateral meshes and textures to SS format, to accelerate conversions. All in all, almost certainly, since the modeling philosophy changes a lot, we would have to tweak the conversions. For where in the original 3D model there was a triangle yes or yes, in Saturn one of two. Or it was passed to a deformed quad or a triangle-shaped texture was made. Needless to say, if the meshes went badly stopped sometimes, the textures were not going to be less. With very incorrect color conversions, which distorted the original art in many cases. With the theme of meshes we find two situations:

1. Or a triangle was made by forcing two vertices to the same XYZ coordinate, wasting the 3D transformation process, quite expensive. Unless a special function was used to “save” this calculation. But even causing the distortion of texture by forcing the native quadrilateral of SS to be a triangle. It can be seen in some games as the Resident Evil in its main characters. As an improvement, a pre-deformed texture could be created to save this defect, with all the pixels in it being distorted, like in Impact Racing, The Lost World Jurassic Park or Wipeout 1. Examples of Impact Racing textures:
   
2. Or an entire quadrilateral with a texture was used, with half texture painted using a mask so as not to paint the other half. And simulate a triangle. It was used in many games, for example Tomb Raider or Shining Force III. Examples of Tomb Raider textures:
   

Regarding the problem of 3D modeling, the only way to minimize this “over process” was to reduce the polygonal load by remodeling 3D models to compensate for those vertices that can not be removed. The easy thing, was possibly to reduce the distance of drawing or objects on the screen or with more aggressive LOD *. There were also tricks in the libraries SBL (Sega Basic Library)/SGL (Sega Graphics Library) to reduce the repetition of the calculation, at the expense of a certain precision.

On the other hand, the solution to the problem of the textures as well as the modeled ones, would be to retexturize … as it is obvious this would be to remake a game, practically. And it was not the usual solution, unfortunately.

In summary and in chronological order let’s start with the good examples of remodeling, retexturing or good conversions, for me. Because this list does not stop being very subjective.

• Loaded (1996) → Very good graphics conversion in global.
• Battle Arena Toshinden URA (1996) → Well converted models and better this time with color palettes.
• Tunnel B-1 (1996) → A very good modeling conversion, with the color palettes in general very well converted, but perhaps improving the final contrast.
• Fighting Force (unreleased) (1996) → Conversion of modeling and perfect color palettes.
• Hardcore 4×4 (1996) → Good conversion of models and good selection of color palettes, maybe the final contrast can be improved.
• Pandemonium! (1997) → Very good graphics conversion in global with the color palettes in general very well converted, but perhaps improving the final contrast in some cases.
• Fifa 97 (1997) → Very good graphics conversion in global with the color palettes in general very well converted, but perhaps improving the final contrast.
• Croc: Legend of the Gobbos (1997) → Very good graphics conversion in global with the color palettes in general very well converted, but perhaps improving the final contrast in some cases.
• The Lost World Jurassic Park (1997) → Very good graphics conversion in global with the color palettes in general very well converted, but perhaps improving the final contrast in some cases.
• Fifa 98 (1997) → Very good graphics conversion in global with the color palettes in general very well converted, but perhaps improving the final contrast.

Good examples but with improvable details:

• Battle Arena Toshinden Remix (1995) → Well converted models, with improvable color palette
• Lemmings 3D (1996) → Textures deformed by direct conversion.
• Impact Racing (1996) → Pre-deformed textures, which waste resolution.
• Tomb Raider (1996) → Textures with bad palettes, or with double face activated and not necessary. Cases of flat color, could have used better “flat polygon” than “quad with texture with triangle and replace”
• Resident Evil (1997) → 3D models worse and textured than the originals and with worse Gouraud shading.
• Nascar 98 (1997) → Textures deformed by direct conversion.

Examples where conversions are notoriously improvable:

• Wipeout 1 (1996) → Deformed textures and color palette that can be improved by direct conversion.
• Criticom (1996) → Improvable models, deformed textures and very improvable color palettes.
• Destruction Derby (1996) → Models, textures and color palette very improvable.
• The Incredible Hulk – The Pantheon Saga (1996) → Right models, lots of textures in low resolution and some at very high. Color palettes and use of the improvable effects.
• Krazy Ivan (1997) → Very improvable models, deformed textures and very improvable color palettes.

Finally and without belittling others, I prefer three of the best, in my opinion. In this section. Would:

• Soviet Strike
  Launched in 1997-02-17, early of the 3rd wave of games for SS. It is noted that the American developers were already strongly familiar with the machine and the maturity of their SDKs are clearly evident in this. Take advantage of the SS really well, showing dynamic color lighting with Gouraud. A high quality FMV in full screen and stereo sound, through a proprietary EA codec. Using the two SH2 in magnificent way, and showing signs of using the SCU-DSP. We also find signs of using CD-XA for game narrations and MIDI music. Striking 77% of total system memory usage. Really a great port, in general nothing to envy to the PSX version, even improving it. It is true that they took their time, in this case 4 months, but it is nothing compared to other ports for SS. And we find some well-converted graphics. Textures, colors, videos … Everything. Proving that when things went well, SS was up to PSX or above. And coming from EA a joy, company that certainly behaved half regular with the machine, not in this case. Putting 5 in-house programmers to it. Something very unprecedented at the time for the ports of SS.
• Wipeout 2097
  Launched in the 1997-09-17, mid of the 3rd wave of games for SS. European developers already had the machine very close at hand. Take advantage of the machine very well. The two SH2, there are signs of use of the SCU-DSP as well and also of the sound DSP. Touching 70% of the total in memory resources. Implementing the PSX LOD and Mip-mapping, and even improving the drawing distance. Same lighting, same particle effects. It is unfortunate that it remained stable at 20FPS as well as Wipeout 1. Equalizing the main characteristics of the PSX content. Textures, colors and meshes at the same level as PSX. Another great conversion of Tantalus and Perfect Ent. where they reached their culmination with this game. Lacked to reach that coveted 30FPS, implement a better video codec, take advantage of the possible transparencies of SS better and finally use the reverb effects of the DSP in the tunnels. Without a doubt, if this had been improved, the icing on the cake of this port would have been almost perfect.
• Zero Divide: The Final Conflict
  Launched in the 1997-11-20, already of the end of the 3rd wave of games for SS. The Japanese Third parties were not as skilled as the European or American, but in this title as in others already showed a clear domain on the machine. We are facing the only game in the catalog that in its title highlights: “SH2 Featured”. All a declaration of intentions, that perfectly fulfills. Using 73% of the total system memory, but only 65% of the VDP1, more textures may have been introduced. As it says, it uses the SH2 with mastery and also the SCU-DSP, in this last case reaching almost 60%, few games reach this level. You can also see the use of sound DSP. To compensate for the use of less geometry in the backgrounds with respect to PSX, the VDP2 is used quite well, both for the ground and for 3 background layers. Using 5 of the 6 available layers of the VDP2. At the resolution level, it doubles the vertical of PSX, but it is a little lower on the horizontal. It is difficult to find a 3D fighting game well converted to SS from PSX. Of course at 60FPS constant. This for me is one of the best. The colors and textures and graphics are well converted. Meshes, textures, colors and correct uv mapping. Not as in other cases where we find conversions with badly converted meshes, distorted textures with saturated colors or very bad palettes. Like Criticom or the Toshinden. I know I’m missing some use of the SS transparencies, since by not using HiRes it would have been possible for them to use for the shadows at least the transparency of VDP1> VDP2 and if they had also implemented these shadows with the shape of the fighter as in PSX, It would have been perfect. But in summary a magnificent conversion and a great fighting game that closes the saga.

1.1 Triangle vs Quadrangle – EXTRA Ball: UV Mapping

As we have said before. The SS has as a basic primitive the quad or sprite. Which deforms in space to give it perspective.

The advantages of this, is a certain simplification for the artist to texturize and for the programmer to manage the space of mapping of texture and storage in memory, the latter certainly simpler than in PSX. Since the space of UV mapping in SS is blocked to a quadrangular space adjusted to the quad.

There is also another advantage that is deformation by perspective, it is less in SS than in PSX and in some cases, non-existent.

Disadvantages has several. The main one, which breaks the basic and common technique of 3D texturing known to artists and to programmers: By types of projection, scale and misalignment of the UV space. Limit the use of this UV space by programmers to get new things. As for example reflex map, use of repeated tiles in a large polygon, retexturized of a geometry subject to tessellation, etc …

Another serious issue, how to automatically convert textured models from PSX to SS. As we have said before, the results in ports are very variable, mostly negative. As we say, the differences are great. And look for an algorithm that, interpret and cut each polygon + texture in PSX and do something equivalent in SS, would not be easy.

In the end was this situation of disadvantage fixed?

Yes and No. We have now discovered that for Sonic R in the reflex map effect, software UV mapping was programmed to recreate the graphic algorithm of the reflex map or classical environment.

But we do not know other games anymore. Perhaps, and it is a speculation, Firestorm: Thunderhawk 2 of Core Design that seems to use a complete software engine to render 3D. If so, we could consider that the textures are being adjusted in a UV space, because it is logical and common. Less for the SEGA engineers who designed the VDP1 of the SS or the VDP of Virtua Fighter 1 of the Model 1 XD.

Also, a well-known developer of the first stage of the homebrew scene of the SS, RockinB. He made an implementation and demo for years, with spectacular results. On your website and a Video of a YouTube user:

The doubts remain if:

1. With the implementation of J. Burton’s team in Sonic R, could we see reflections in a car game like GT on PSX?
   YES. I believe that without problems. Analysing the reflection of the home screen. We see that it is a Normal Sprite. Applying a Replace/Half-Transparent. Imagine a car where the “R” is, even with similar number of polygons is very easy. It would be the main car and the rest with a similar effect but without calculating again, repeating the main and ready. It would be an even better reflection than the PSX GT. You may see a clipping problem, but nothing that does not already happen or can be corrected in some way.
2. With the implementation of RockinB would it be possible to achieve the same, if it is fast enough to be used in a complete game?
   Here I do not see it so clear. Testing the technical demonstration, it shows that it costs and is a single object. It would be necessary to debug the code much more and the necessary thing would be to write the maximum in assembler of both the SH2 and use the SCU-DSP. It is fair to say, that with the flat mapping, which is already an improvement over the non-UV mapping of SS, it works very fast….

2. The least complicated: Gouraud shading and dynamic colour lighting.

But complicated for the Sega Saturn with respect to the PSX. The shading Gouraud with several sources of light in motion and with color clearly cost, but Loaded, NiGHTS into Dreams (less), Burning Rangers, Exhumed, Darklight Conflict, Duke Nukem 3D and Quake made it to leftovers. And all this thanks to the simplification and easy access in the revisions of the SDK and the creation of the “SGL” (aka Sega Graphics Library) so that the developers could reach the same in similar way to the PSX. Also, and you have to be fair, to the skill of some developers.

At this point I would like to distinguish, between shaded Flat and Gouraud. And how with or without Light Sourcing Color affects overall performance. As in PSX from the beginning these features are available in many games and in SS no. Lighting with a source, in general, already in SS was complicated, since it was not integrated in their SDK from the beginning. And it had to be programmed, and it was a complex technique at the level of geometry and demanding in calculation. The SS as we said had a lot of computing power, more than PSX. But distributed in several parts, while the PSX had it concentrated and easy to use. Many times we can find games where there is flat lighting, faceted but with source and color, where the result is still spectacular. The performance is thus less. When adding the Gouraud to the scene the calculation requirement, main memory and in the VRAM goes up, in both machines. Finally, finding lights with colors or not, is also for the same reason. Reduce the use of memory and simplify the calculation.

Another detail, similar between the machines. It is the way to illuminate flat polygons, or the flat shading. Both can use Gouraud shading flat, without gradient, with a predefined base color or calculated for dynamic lighting. It was also often used to color particles or illuminate menu letters. Using it for 3D graphics, maybe it would not be the best option. Because the Gouraud process has a cost in both, with or without demotion, in fact the same. In some games another technique was used. That was to make color levels by luminance in the palettes of the flat colors or textures to be used. It was faster, face to the graphic process, occupying something more of VRAM. As I say the same in both machines.

It’s funny how in the PSX SDK you can clearly see how the entire theme of lighting is integrated. Making reference even to the maximum lights and types of lights that can be used directly with the GTE, in an optimal and accessible way. In this case up to three parallel lights and one environment. Typical shaded 3D polygonal appearance. Where we can perceive that base of environmental color plus directional shading.

As we have been saying, the key to seeing games from the beginning with dynamic color lighting and Gouraud on PSX was thanks to the “GTE” processor or customizable engine of geometric transformations and lighting. Completely accessible also through easy-to-use C and C ++ libraries and source code. Also, code in assembler or macros. Provided by Sony, from minute 0 of PSX’s life.

Where against in the SS it had to be programmed using the two SH2 as DSP plus the SCU-DSP in conjunction with the hardware Gouraud function of the VDP1. Until the SGL 2.1 (in 1996-05-05 for Fighting Vipers) or more advanced, this was not simplified in similar way to the PSX at the bookstore level. With C code and assembler and source code (not in its entirety). With the “brute” power of the SS it was possible to equal or surpass PSX. But few programmers got into this garden. SEGA facilitated it, but with all I do not get to take advantage 100% of the maximum possibilities of the SS. At least in its SDK, which we would be talking about would be used between 80/90% because I could not see the presence of the integrated SCU-DSP easily within SGL, if however in SBL, but I do not know the degree of optimization that have. Or even the M68000 to help in the geometric transformation and lighting calculations. Which in theory is perfectly possible. The use of the SH-1 is complicated, being in buffer of the system different from the main one.

In particular about the shading Gouraud in the SS. Highlight, that the way, technically speaking, to perform this effect in SS, is slightly different from the PSX. Although the two processed this effect by hardware that currently translated into a penalty for using the effect in both.

On the one hand, the PSX made the effect at the triangle level, with 24bit (8: 8: 8) of color depth, which it then trimmed to 15bit (5: 5: 5) on v1 of its GPU and then on its v2, leaving it on 24bit (8: 8: 8), finally when using dithering in the final framebuffer, the color was degraded and the swaths of change were dissimulated more than in SS although it used a depth of 15bit (5: 5: 5) equal to the v1 of the PSX GPU. On the other hand SS would need less memory to use it, PSX to have it fixed at 24bit (8: 8: 8), would need more memory per vertex and quad (2xTris) as a whole. Finally the SS was able to draw the Gouraud shader in less time than the PSX.

Also, when mixing the effect with the texture or base flat polygon the SS did it in additive way that affected luminance and in the case of the PSX in multiplicative way. Which implied that visually in the case of SS, the color of the gradient will cover the base texture, and in the case of the PSX it will mix more smoothly. This caused the most saturated (dark) aspect of the 3D SS games, so characteristic of this one. And a more standard aspect in PSX for this part.

At the “end”, in essence, the result is the same. Soften the changes in the edges and give the possibility of creating a soft lighting on the textured polygons or not.

In the end was this situation of disadvantage fixed?

For the most part, with the SGL library, not by all the Third parties, as most developed first in PSX and this already limited to take advantage of the SS for them.

For the first parties of SEGA clearly. So much, AM1, AM2, AM3, Sega CS2, Sonic Team, Team Aquila and Team Andromeda. They took the machine to the limit with different results. For me the most notable and that set the bar at the level of PSX or in some cases more: The Sonic Team with Burning Rangers and Team Andromedia with Panzer Dragoon Saga

AM2 and AM3 followed more philosophies of fidelity to their arcades, trying to transfer the highest amount of FPS and resolution to SS. Forgetting Gouraud shading and dynamic lighting.

But let’s not forget how AM2, later, with Fighters Megamix (formerly with Fighting Vipers), designed for SS and to compete with PSX, they also achieved it. But the visual feeling of PSX was achieved by Sonic Team with its 3D engine (Nights, Sonic Jam [World map] and Burning Rangers) and Team Andromedia with the Panzer Dragoon. Using Gouraud shading with color and moving sources. Burning Rangers being a game at a frame rate smooth and stable (20 FPS), great color, Gouraud shading and lighting with color.

Also, Camelot Software Planning whith Sonic Co. companies behind Shining Force III, the series of exclusive RPG designed and coming from Japan by SEGA. They show the use of Gouraud Shading with dynamic lighting, in masterful way, during the 3D matches. In addition to using the Hardware of the SS in sublime way during the same. Using all the layers of VDP2 next to VDP1, superbly. And even the SCU-DSP to get spectacular 3D effects. In short making use of all the capabilities of SS, as the transparencies that we will see later.

Some Second parties like Treasure (Guardians Heroes, Radiant Silvergun and Silhouette Mirage), Travels Travels (Sonic R: Gouraud and dynamic color lighting, 16bit textures, various forms of semi-transparency with VDP1 and VDP2) and Nextech (D-Xhird carrying the limit their 3D engine), they also took the SS to extremely high limits.

Many Third parties were also finally able to integrate the Gouraud shader plus lighting at the expected level (PSX style).

In its last years back in 1998, some small Japanese third parties exploited the SS in a masterly manner, and the knowledge of the machine and the ease of access to it through SGL has already been assumed by the industry: Example of fighting games and cars like Savaki and Touge King the Spirits 2 are clear demonstrations of this, where the use of Gouraud Shading is complete and perfectly integrated.

By putting specific numbers in the situation. We would be talking about 35.65% of the study that I have done have some kind of lighting. 27.13% of the games have lighting with a source similar to that of PSX. And equal or superior to PSX, 3 sources of light or more with source and with color, a 5.42%. If we extrapolate to the catalog total, as we can see, in relation to PSX only a few games. Without going into how well optimized they are.

There is a list by publication date and study type, of all territories. Detailing the type of lighting implemented:

1st Party

• Virtua Fighter 1 (1994-11-22) → 1 Light source parallel Flat Palleted color.
• Wing Arms (1995-09) → First game with dynamic lighting with 1 light source no color with Gouraud shading. Through SGL 1.0
• NiGHTS into Dreams (1996-07) → 3 or + Dynamic point and directional lights with source and color with shading Flat/Gouraud
• Fighting Vipers (1996-08) → 1 Dynamic Light with source and without color with Gouraud shading. Opaque human shadows with the dynamic light source.
• Fighters Megamix (1996-12) → 1 Dynamic Light with source and without color with Gouraud shading. Opaque human shadows with the dynamic light source.
• All Japan Pro Wrestling Featuring Virtua (1997-10) → 1 Static Light source no color + Ambient Light with Gouraud shading.
• Burning Rangers (1998-02) → 3 or + Dynamic lights with source and color with flat shading/Gouraud.
• Panzer Dragoon Saga (1998-03) → 2 Dynamic lights source color Gouraud/3D plane human game. 3 or + dynamic lights with source with color Gouraud/Plane in 3D Flight/Battle. Light map on VDP2 plane.
• Pro Yakyuu Greatest Nine ’98 Summer Action (1998-08) → 1 Static Light source no color + Ambient Light with Gouraud shading. Human shadows with fountain and animated. Distant LOD with a star shape.

2rd Party

• Ghen War (1995-12) → 1 Bake static light (pre-calculated) with no shaded color plane/Gouraud on stage. 1 Static light source no color with flat shading/Gouraud in elements and enemies.
• Congo: The Movie – The Lost City of Zinj (1996-03) → 1 Bake static light (pre-calculated) with no shaded color plane/Gouraud on stage. 1 static light source no color with flat shading/Gouraud in hand/Weapon and in 3D objects.
• Pandemonium! (1997-02) → 3 or + Dynamic lights with source and color with shading Flat/Gouraud
• Sky Target (1997-04) → 1 Static light source no color with Gouraud shading/Flat
• D-Xhird (1997-05) → 2 dynamic lights with source and color with shading Flat/Gouraud. Human shadows with dynamic light source and mesh shading.
• Assault Rigs (1997-09-11) → 1 Dynamic light source color + Ambient Light with flat shading using Gouraud.
• WipEout 2097 (1997-09-17) → 2 Lights Static no Source with color whit shaded Flat/Gouraud
• The Lost World Jurassic Park (1997-10-07) → 3 or + Dynamic spot lights with source and color with shading Flat/Gouraud. 1 Parallel Light (Directional) and 2 or + Spot Lights.
• Duke Nukem 3D (1997-10-29) → 3 or + Dynamic spot lights with source and color with shading Flat/Gouraud. Pre-calculated lighting in scenarios with Gouraud.
• Sonic R (1997-11-21)→1 Light Static Source Color Gouraud/Flat. Gouraud Color in scenery. Source and Color in character models.
• Zero Divide: The Final Conflict (1997-11) → 1 Parallel Static Light (Directional) with source and color with Gouraud shading in parts of the fighters and Flat Shading through Gouraud in all remaining parts of the fighter and planets/scenarios of the scenario/enemy selection screen.
• Quake (1997-12-03) → 3 o + Dynamic point lights with source and color with shading Flat/Gouraud. Pre-calculated lighting in scenarios with Gouraud.
• Shining Force III (1997-12-11) → 3 or + Dynamic lights with source and color with shading Flat/Gouraud
• Zap Snow Boarding Trix 98 (1997-12-18) → 1 Bake Static Light (Pre-calculated) with Color with Gouraud shading on stage. 1 Dynamic Light not source if color with flat shading in character.
• Stellar Assault SS (1998-02) → 3 or + Dynamic lights with source and color with shading Flat/Gouraud
• Radiant Silvergun (1998-07) → 1 Light source not Color Flat/Gouraud in 3D Assets and enemies

3st Party

• Tama – Adventurous Ball in Giddy Labyrinth (1994-11-22)→ 1 Light source parallel Flat Palleted color.
• Victory Boxing (1995-10-20) → 2 Parallel (directional) dynamic lights source no color with flat shading using Gouraud.
• Tadaima Wakusei Kaitakuchuu! (1995-11) → 1 Static Light source no color with flat shading/Gouraud
• Robo-Pit (1996-02) → 1 Static Light source no color with flat shading/Gouraud
• Loaded (1996-06) → 3 or + Dynamic lights with source and color with shading Flat/Gouraud
• Blam! Machinehead (1996-08) → 1 Parallel Lights (Directional) source no color with shading Flat/Gouraud in 3D assets. 1 Static Light bake (pre-calculated) without color with shading Gouraud/Plane in scenarios.
• Exhumed (E)/Powerslave (U) (1996-09) → 3 or + Dynamic spot lights with source and color with shading Flat/Gouraud. Pre-calculated lighting in scenarios with Gouraud.
• Tunnel-B1 (1996-10) → 3 or + Dynamic point lights with source and color with shading Flat/Gouraud. Pre-calculated lighting in scenarios with flat shading.
• Mighty Hits (1996-10) → 1 Static Light source no color with flat shading/Gouraud in 3D models and some mini-games. 1 Light bake (Pre-calculated) with shading Flat/Gouraud in all the rest.
• Tomb Raider (1996-10) → 1 Static Light source no color with flat shading/Gouraud in 3D characters and models. 1 Light bake (Pre-calculated) with shading Flat/Gouraud on stage.
• Street Racer (Extra) (1996-11-16) → 1 Parallel/Static Directional Bake (Pre-calculated) without Color with Gouraud shading in all 3D Assets.
• Fighting Force [Judgment Force] (1996-11-26 Unreleased) → 1 Bake Static Light (Pre-calculated) without Color with Gouraud shading only in character selection in the models.
• Harcore 4×4 (1996-12) → 1 Light Parallel Static Source in cars and 3D models. 1 Light Bake Gouraud / Flat in scenarios/terrain.
• NHL 97 (1996-12) → 1 Light bake (pre-calculated) without color with shading plane/Gouraud in characters and 3D models.
• Fighting Illusion K1 Grand Prix (1997-01) → 2 Parallel Lights (Directional) with source and Color with shading Flat/Gouraud. Transparent human shadows with the source of static light.
• Soviet Strike (1997-02) → 3 or + Dynamic spot lights with source and color with Flat/Gouraud shading.
• Die Hard Trilogy (1997-02) → 3 or + Dynamic spot lights with source and color with shading Flat/Gouraud.
• Drift King Syutokoh Battle 97/Shutokou Battle ’97: Tsuchiya Keiichi & Bandou Masaaki (1997-02) → 1 Static Light source no color with Gouraud shading in vehicles and menu circuit map. 1 Light Bake (Pre-calculated) without Color with Flat shading in scenarios.
• MechWarrior 2: 31st Century Combat (1997-04) → 1 Static Light source no color with Gouraud shading. Without Dynamic Lights.
• Touge King the Spirits 2 (1997-04) → 2 or + Static Lights with source and color with Flat/Gouraud shading only in cars. Car light in night mode on road and degrades to dark on the horizon. Degradation of the dark scenario on the horizon using color luminance with shading plane.
• Swagman (1997-06) → 1 Static Light source no color with shading Plane/Gourand in 3D assets. Use of Gouraud for light intensity in 2D elements. 2D projected shadows with shaded light source with Mesh.
• Darklight Conflict (1997-07) → 3 or + Dynamic point and directional lights with source and color with shading Flat/Gouraud.
• Resident Evil (1997-07) → 1 Dynamic Light source no color with shading Flat/Gouraud in 3D models and assets.
• Croc: Legend of the Gobbos (1997-09) → 1 Light bake (pre-calculated) no color in character, stage and rest in 3D game. 1 Static Light source no color in 3D elements in menus. 1 Dynamic Light source no color in 3D Logo of the main menu.
• Ninpen Manmaru (1997-12) → 1 Dynamic Light with source without Color Flat/Gouraud on stage, enemies and 3D assets. 1 Light Bake (pre-calculated) with shading Gouraud in main character.
• Savaki (1998-04) → 2 Dynamic Lights source and color with Gouraud shading.
• Virtual Kyōtei 2 (1997-12-04) → 1 Dynamic Light source no color with shading Flat/Gouraud in 3D models and assets.
• Code R (1998-07-09) → 2 Dynamic Local Lights with font and color with Gouraud shading.

Finally, again I stay with three of the best games in this section. What would they be:

• Fighting Illusion K1 Grand Prix
  Published at the beginning of 1997 only in Japan, principles of the 3rd wave of software for the SS. For me the technically most complete 3D fighting game of the SS catalog. Not from the analysis of gameplay. If not technically, we are talking about that we have dynamic lighting in color and with a source with direct and diffuse light. Completely 3D and large scenarios. Use of VDP2 for the scenario. Deph Cueing for the distance. Transparent shadows on the VDP2 plane with human form and from a point of light. Large amount of geometry on screen. VDP2 HD mode for UI. Great use of color and gradients of the Gouraud of the VDP1. A speed between 25 and 30FPS stable. Using the two SH2. Using 68% of the total system memory. But without using the SCU-DSP and the sound DSP.
  As port in general with respect to PSX, it was outstanding. Matching most features: number of polygons, lighting, color and FMV quality. Adding more content as compensation: Effects in scenarios, shadows fighters, more fighters, less loading time … Only slightly less resolution in 3D and the FMV somewhat smaller, but almost full screen. And all this with a difference of 5 months, it is enough, but it was the normal thing unfortunately between the games of the 1st wave and the beginning of the 3rd wave. Already by the middle of the 2nd wave the SS SDKs improved a lot and became almost on par with PSX, translating the good results at this time, early 1997.

• Quake
  Published at the end of 1997, end of the 3rd wave. As we see the level in the machine is already very high. Of course magnificently using the Gouraud shading on the entire stage, animated water texture and dynamic color lighting, the latter even better than PC. Maybe I need to see this lighting in the weapon, as in PC. Possible on the other hand, using (for example) the Color Offset or Line Color Screen on the layer of the weapon, which was a 2D graphic.
  Take advantage of the two SH2 plus the SCU-DSP, the latter almost certainly for 3D (animations or vertex transformations, can not be easily specified). But if we can specify, that you are using 50% of the available memory of the SCU-DSP and 43% of your total records. Unequivocal proof that you are using. Note that it is the only game of the, on the other hand, magnifies Lobotomy Software. With 3 main programmers plus 2 supporters. And developing at the same time the port of Duke Nukem 3D. And with only two months of difference between the two.
  Leveraging 66% of total memory, versus 88% of Duke 3D. The truth remains curious. Possibly, the complexity and variety of Duke3D was greater. Although Quake had enemies and objects in 3D.
  Anyway a version that did not have to invest much to the PC, understanding the power and cost of this at the time. And the final result in FPS and resolution was medium-high. Equating the standard resolution of PC (320×240) and with some FPS between 15 and 30 FPS. Also Quake in SS, it was rendered at 16bit, prohibitive for the PC at that time. And saving that it required 8MB of minimum RAM, and in SS it had 2MB main RAM, plus 1.5MB VRAM and 0.5MB of RAM for sound. In total 4MB RAM, which is half the PC minimum. They had to reduce the scenarios and frames of enemies for it. But the port maintained the total essence of the original, with complete levels without intermediate loads, textures, sounds, features and everything! Note that although you can see a minimum use of the M68000 and the SCSP-DSP.
  As a curiosity, note that Lobotomy never “expressly” used the M68000 for the main sound process, let alone the SCSP-DSP. The minimum usage may respond to the playback of CD tracks for music. Being really amazing the juice that they took to the two SH2, and in this game to the SCU-DSP.
  Also comment as a curiosity, possibly next to the rest of their games. They are among the few that use the User Clipping function to accelerate the graphics of the VDP1, in this game up to 30 times per Frame. Some geniuses. Who knows if they could have gone a little further even with the machine. At least, we have another great game for 1997.
• Shining Force III
  Also published at the end of 1997, we are facing the best SS RPG without hesitation. With the permission of the magnificent Panzer Dragoon Saga. And it is one of the games that best uses the machine, particularly in the Gouraud shading is spectacular. Using it in all 3D: maps and battles, with up to three dynamic lights in color, resulting in a magnificent illumination.
  Making use of 83% of the total available memory, with 95% peak usage of the main RAM.
  With a spectacular FMV intro, full screen, smooth and in stereo. Using the VDP2 to put up to 32bit of color on the screen.
  Using all the process units for 3D. Specifically the SCU-DSP to make “render to texture” for procedural texture effects. Reaching 100% of the memory of the SCU-DSP and almost 40% of the records available. Using all the layers of the VDP2 masterfully. And all possible modes of transparency of the machine, both the semi-transparency of the VDP1, and the different transparency modes of the VDP2: Combined with the VDP1 or the chip itself. For shadows and all kinds of effects of light, magic or particles especially in 3D combat. But also in cinematics and in the game map. In this review of the use of the special chips of the machine, we could not stop talking about the SCSP-DSP. That in this game, we can be talking about the best use I’ve heard. The melodies, amount and effects of DSP that are used in them are spectacular. Being able to perfectly perceive the use of Reverb and Chorus in many of its notes, and being able to see in the channel viewer of Yabause the use of the 32 channels. There are more games with great use (PDS, Radiant Silvergun …), almost like in this one. But Shining Force III sets the bar almost in infinity with music.

End first part.