Sega Saturn to the limit (V)

david.gamiz.jimenez david.gamiz.jimenez

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

Very, very, long entry warning. In this post I have used a lot of information, complex and in some ways imprecise. It is possible that I have made errors of interpretation or understanding. I will try to correct everything that arises.

In this spreadsheet you have the data that I have collected from 323 games. Of the approx. 1200 titles in total. Which are 20% approx. of the total.

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 color lighting
  3. The complicated thing I: Smoothness 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 II ball: SD / HD screen resolution
    3.3 The complicated I – EXTRA III ball: Tessellation / LOD scenario / Mip Mapping
  4. The complicated II: FMV screen complete and quality color
    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

5.1 The most complicated thing – EXTRA I Ball: Transparencies + Gouraud =” Table FOG “/ Depth Cueing

As already we have spoken before combining transparency with Gouraud gave rise to very interesting and spectacular effects. But undoubtedly one of the most striking was this: Table FOG “/ Depth Cueing

On PSX we can read as possible effect or even see games with effects of” Table FOG “. It was not actually a feature as such on the machine. to be able to calculate half-Transparencies very efficiently (in various modes and layers) and to be able to do Gouraud shading, like SS It combined both effects on the unique Frame buffer of the PSX, to achieve a practically the same “Table FOG”. Accessible by the developers through a function called “Depth Cueing” used by the GTE.

In the SS, which is what interests us, was it possible? The answer is YES. Finally, already in version 3.0 of the SEGA SGL, it was included a function in the same way as PSX. Calling even the same.

It was done in a similar way. As in everything in SS, using the VDP1 or VDP2 or adding both. There is some game that does it very well. In the case of the Saturn, it lacks single frame buffer, and its mode constraints s transparency. The effect is not as spectacular as that of PSX, but in essence, again, it’s the same. It worked as follows:

The farthest polygons were taking on a color similar to a horizon or background color. And when they approached the clipping of the horizon (popping area or generation of the stage), they faded with a fog color (usually black or white) with a transparency of the VDP1 or using the mesh mode. Or in the best of cases using the half-Transparency VDP1> VDP2, seen in Sonic R. The sum of gradient color similar to the background plus the use of transparency or mesh, gave the sensation of being lost in the horizon as if was fog.

A small improvement from the previous one, was in addition to giving a gradient color depending on the distance to the horizon. Add gradient on the polygon with Gouraud shading, thus softening the color in transition even more to the background. If we add to this the transparency of the Gouraud values, the fading is total. Here again we find that the SS did, with its limitations. And that PSX achieved it with better final quality.

Of course, the fades with the SS transparency, which is not at the triangle level, and which in the case of the VDP1 generated calculation errors, did not show a perfect final finish. If they used the mesh, better in one way (performance) worse in another (aesthetic). But essentially on PSX the same was done. In the best case in SS, adding to the use of VDP1, the transparency of VDP2 is finally used, which is the case of Sonic R, the effect is clean and also with gradual transparency when using the possibility of up to 8 simultaneous the 32 alpha levels of this chip. The effect is very smooth, the best. The question remains whether it was possible to use the “as is” mode to get the levels to the maximum, 32 possible. Using the Gouraud in the VDP1 so that later with the VDP2 mixture it interprets these brightness levels as transparency levels thanks to the additive mixture.

Other games only used the color gradient up to the final color of the horizon. And there they stopped drawing the polygon. It is a simpler and less spectacular effect. But less expensive for the machine. On PSX it was also used in the same way. If the background is very dark or with a flat color, without texture. The use of half-Transparency could be eliminated, since it did not contribute anything and it is an expensive process.

We also have the case of using a VDP2 Screen, normally an RGB, a horizon gradient, using the option Line Color Screen Insertion to simulate this effect. Which could define what Screen or Screens would affect. The effect is limited and very flat. But at the pixel level, per line. And it can be used in conjunction with the Color Calculation Function to make transparency on multiple layers. Being able to add this to another normal VDP2 layer transparency (CC VDP1 included and its variants).

Finally there are also cases that use an even flatter and simpler effect using the VDP2. What is to use a Screen with transparency superior to the background. It appears in games where the camera does not rotate on its normal axis or where the fog is far away or in the “3D” background. I’ve only seen it in a few games.

In the end it is about concealing the “popping” in the best possible way. Today, it is still used, much less … but the generation of geometry is not infinite in any system.

Was this disadvantage finally resolved?

We could say YES. Although, in the absence of easy implementation from the start, there was no unified approach. Resulting in disparate results.

I have come to see it in 37% of the total number of games analyzed. Most of them with VDP1 only 50%. Some with the VDP1 + VDP2 reaching 45%. And also only using the VDP2 in some of its forms by 5%.

Now let’s move on to a list by type and chronological date:

3D effect games using VDP1:

  • 1994
    • Gale Racer
  • 1995
    • Panzer Dragoon → Palette change and LOD.
    • Robotics: Cybernation Revolt
    • Bug!
    • Off World Interceptor Extreme
    • Touge King – The Spirits / High Velocity: Mountain Racing Challenge
    • Dragon Ball Z: Shin Butōden
    • Hi-Octane
    • Black Fire
    • Devil Summoner: Shin Megami Tensei
  • 1996
    • GunGriffon
    • Panzer Dragoon II Zwei
    • Magic Carpet
    • Shellshock
    • Lifescape – Seimei 40 Okunen Haruka na Tabi Disc 1
    • Lifescape – Seimei 40 Okunen Haruka na Tabi Disc 2
    • Dragon Ball Z: Idainaru Dragon Ball Densetsu
    • Starfighter 3000 (Star Fighter)
    • Alien Trilogy
    • NiGHTS into Dreams
    • Shockwave Assault
    • Blam Machinehead
    • Dark Savior
    • Exhumed (E) / Powerslave (U)
    • Space Hulk: Vengeance of the Blood Angels
    • Tunnel-B1
    • Tomb Raider
    • Street Racer (Extra)
    • Hardcore 4×4
    • Bug too!
    • Black Dawn
    • Shining the Holy Ark
  • 1997
    • Die Hard Trilogy
    • Scorcher
    • Crypt Killer
    • Gundam Side Story 3 Kidou Senshi Gundam Gaiden III: Sabakareshi Mono
    • Independence Day
    • Doom
    • Touge King the Spirits 2
    • Krazy Ivan
    • Sonic Jam → World 3D Area
    • Zero4 Champ Doozy J Type-R
    • Bulk Slash
    • Lifescape 2 – Body Bionics – Kyoui not Shouuchuu Jintai
    • Söldnerschild / Soldnerschild
    • NBA Action 98
    • Steep Slope Sliders
    • Duke Nukem 3D
    • Devil Summoner: Soul Hackers
    • Sonic R
    • Quake
    • Courier Crisis
  • 1998
    • Only Crisis
    • Panzer Dragoon Saga
    • Stellar Assault SS
    • GunGriffon II → Gouraud 3D objects
    • Baroque
    • Akumajo Dracula X: Gekka no Yasokyoku (aka: Castlevania: Symphony of the Night)
    • Code R

Games with 3D effect using VDP1 + VDP2:

  • 1996
    • GunGriffon (1996-03) → Flat polygons with transparency in VDP2?
    • NiGHTS into Dreams (1996-07-05) → VDP1> VDP2 cc + ratio 8x Polygon flat degrade horizon over RGB0
    • Street Racer Extra (1996-11) → Depth cueing with transparency VDP1 + VDP2 in near clipping.
  • 1997
    • Doom (1997-03-26) → Depth cueing VDP1 + VDP2.
    • Bulk Slash (1997-07-11) → Only in some levels on the VDP2 layers like Sonic-R. In the rest possibly against the Back Buffer.
    • Sonic R (1997-11) → in the last circuit, which is transparent integer. Does it have fewer levels of gradient in the fade or does it not?
  • 1998
    • GunGriffon II (1998-04) → Flat polygons with transparency in VDP2

Games with effect in 2D / 3D using VDP2: Line Color Screen Insertion (Hard to detect, approximate list):

  • 1994
    • SEGA GAME SAMPLE 1 → Windows + screens and flying carpet .
  • 1995
    • Panzer Dragoon 1995-03-10
    • Wing Arms 1995-09-29
  • 1996
    • Guardian Heroes 1996-01-26
    • GunGriffon 1996-03-15
    • Panzer Dragoon II Zwei 1996-03-22
    • Dragon Ball Z: Idainaru Dragon Ball Densetsu 1996-05- 31
    • NiGHTS into Dreams 1996-07-05
    • Decathlete / Athlete King 1996-07-12
    • Battle Arena Toshinden URA 1996-09-27
    • Street Racer (Extra) 1996-11-16
    • Sega WorldWide Soccer 97 / Victory Goal ’96 1996-11- 29
    • Shining the Holy Ark 1996-12-20
  • 1997
    • Shinrei Jusatsushi Taroumaru 1997-01-17
    • Gundam Side Story 3 Kidou Senshi Gundam Gaiden III: Sabakareshi Mono 1997-03-07
    • Independence Day 1997-03-15
    • Doom 1997-03-26
    • J League – Go Go Goal! 1997-05-30
    • D-Xhird 1997-05-30 → Some Scenarios
    • Sonic Jam 1997-06-20
    • Bulk Slash 1997-07-11
    • Thunder Force V 1997-07-11
    • G-Vector 1997-10-16
    • Sega Worldwide Soccer 98 / J. League Victory Goal ’97 1997-10-16
    • J.League Pro Soccer Club or Tsukurou! 2 1997-11-20
    • Sonic R 1997-11-21
  • 1998
    • Panzer Dragoon Saga 1998-01-29
    • Dragon Force II 1998-04-02
    • Savaki 1998-04-16
    • Gungriffon II 1998-04-23
    • World League Soccer 98 1998-06 -05
    • Radiant Silvergun 1998-07-23
    • Pro Yakyuu Greatest Nine ’98 Summer Action 1998-08-06

Games with 2D / 3D effect using VDP2: Screen with superior transparency:

  • From TV Animation Slam Dunk: I Love Basketball → Effect in park
  • D-Xhird→ Level with fog in the background.

Again I am left with a selection of three games, which are good representatives of this section and as games for the system:

  • Blam MachineHead

    Released on 1996-08-30 is a game from the 3rd wave of developments third party European. In this case, Core Design and its components already demonstrate an outstanding knowledge of the machine. A game with a really powerful 3D engine, but with base decisions thinking of PS1 and PC that clearly harm the final finish. Although it was first released on SS, 2 months earlier. We do not know if as part of the first agreements that SEGA had with Core Design, such as for the Tomb Raider. We also can’t know how it hurt this too, being released earlier. But this Blam Machinehead does seem to be well polished, although it can be improved.

Blam Machinehead has a motor that smoothly moves at least 800 textured quads and Gouraud seen on screen. Maybe more. Approximately 1,100 calculated. Of which approximately 100 quads seen are from the vehicle and its weapons. It is true that at 20FPS totally stable, possibly blocked by Vsync. All this at 352×224 points.

We see no trace of subdivision in terrain or LOD in features although clipping appears to be similar to that of the Tomb Raider for terrains and features. So not with the dome, which is always drawing. On the other hand, the clipping of the rotated map is very well accomplished by playing with the VDP1 clipping windows.

For the lighting part, the engine shows lighting in the vehicle and in the weapons dynamically, plus one lighting per source. Possibly in enemies and entities there is also basic lighting by source. The stage shows pre-calculated lighting with Gouraud.

It has a really remarkable drawing distance. Plus Depth cueing’s black smoothing makes poping almost imperceptible most of the time. It is true that PS1, being exactly the same, is better. The main cause is, as I said before, basic decisions that were made thinking more about PS1 and PC, and that, as usual, were detrimental to the SS version. It is true that SS was out of the norm. But it was not so difficult to do the same well in SS. I mean the “dome”. The “dome” in 3D games is the total background. In many it is usually 2D, more in SS, but at the time with PS1 they mainly began to see more background in 3D. With cylindrical, spherical, or textured cube shapes that simulate being spherical. In this case, this entity is a basic entity that is repeated in all the scenarios only changing the color and the Gouraud gradients. So far the SS can do it without problem. This Gouraud geometry is now on top of a flat overall background with a color gradient. The first geometries simulate mountains, buildings or clouds in the twilight of the distance. The second is the gradient of the sky. The first on the second both on PC and PS1 have a transparency, to show the total background and mix everything very efficiently and thus save a great texture or textures for it. It is also faster than moving and drawing all this with textures. But the problem is that they use exactly the same geometry as for the other versions, that is, with many triangles. And also in the absence of a transparency for 3D that work they use the mesh mode. Well. As there are no transparency gradients in these two final layers, Depth Cueing in the lower area does not melt against black or background gradient. If not against the stippling of the dithering mesh, leaving this final effect less efficient. Besides that this dome is always being drawn, with this large amount of wasted redrawing. For the SS it is a total waste. Because he is doing Gouraud in triangles, which makes him throw fillrate in quantity. This dome could have been converted to quads well, first. Second, having used a gradient in the final background with the VDP2 Back screen, and finally using Sprite’s transparency with VDP2 of these quads with Gouraud against the Back Screen. All this would have been infinitely lower cost for SS and would have looked the same as on PC and PS1. It would even have allowed to raise the FPS to 25FPS or 30FPS, the drawing distance or the resolution of the textures of the stage from 24×24 to 32×32. This dome could also have been made with the RGB0 layer of the VDP2, as in Exhumed, with the final transparency on the Back Screen the same, but it is true that if it had been a solution 100% adapted to SS, and not something more valid for all versions. Finally there is also the problem that using the transparency of the VDP2 for the UI could have mixing problems. But using the VPD2’s extended color calculation mode correctly (as in Sonic R), in theory both layers of the VDP2 could have been seamlessly mixed.

The rest of the transparent elements, including billboards such as flames or flares, make use of the mesh mode. It is true that in this game they are on other elements of the VDP1 all the time, but strangely the developers do not use it at all. Maybe thinking you had a fillrate problem on VDP1. When really the problems come more from the misuse of the east, and also most likely from the CPU, in its transformation and lighting code.

We see a use of the gradation calculation and color calculation function for the ratio and priority. In the case of the first one, we should perceive a smoothing in the horizontal lines both in the graphics of the VDP1 and in the layer of the VDP2. But it doesn’t work because the developers didn’t properly configure the VDP2 logs for it. Of the second I really do not know what they use it for, or what their intention was. Since the only thing they could do is some element of the VDP1 make it transparent against the only layer they are using for the UI, or for the Back screen, but I can’t see what.

All of these cues, plus others we’ve talked about, may be the result of an early search for better solutions for the game. But all of them unfinished.

For the sound part, they made use of the SEGA 2.x driver. The Core Design team is not complicated. And it does not use the extra DSP possibilities, which would have looked so good in this game. Like the reverb or echo, which were almost certainly used in the PS1 version. Although we do see a typical use of DSP for CD-DA playback for music. Neither at the sound level FX we see great advances. It seems that they put all the sounds per level into the Sound RAM, in raw mode. Surely half the quality, or less, than on PS1 to fit everyone.

There may be a possible use of CPU render to VDP1 Frame Buffer on loading screens. I’m not sure though.

The kinematics are all full screen, with good compression. At 320×200 at 24FPS. The sound however remains in mono PCM at 22254 Hz. With a bitrate of 1800kbps peak. 1400 for the video stream and 356 kbps for the audio. There was still some room for a little more sound quality. All this shown in the VDP1 by means of a distorted sprite at 15BPP.

The use of the hardware is remarkable. Using 2xSH2 for FMV and 3D. We can see a typical use of the SCU-DSP in FMVs and 3D of up to 20% of memory and 17.4% of records. The game uses 70% LRAM and 80% HRAM. Up to 95% of the VRAM of VDP1 and finally of the VRAM of VDP2 60% and CRAM 60%.

  • SEGA WorldWide Soccer

    97/98 Launched on 1996-11-29. Being a game of the 3rd wave of developments Japanese first parties. SWWS 97 is a great soccer game for the SS. Aquila Team was charge of this particular saga and already showed a great mastery of the use of the machine. Even more in making use of its transparency capabilities, like few others in the system.

In my point of view we are before the title of the Victory Goal saga that marked an important point. It marked the maturity of one of the SEGA CS teams that best used the machine and specifically in this genre. It is true that there were other important and good titles in SS. But for SEGA, this was their star soccer title. With the next SWWS 98 they only added, league mode, and improved other minimal aspects.

SWWS 97 moves at 352×256 at 15BPP exceptionally, at fully stable 30FPS. At 60FPS in menus even with 3D. It is true that the polygonal load in this game is not high and there is no lighting during matches either. During which we are talking about 500 quads seen, making use of up to 2 levels of LOD for players and shadows.

If we can see 3D lighting in the menus. When we select the stadiums, with a light source. Also on the flags before the game.

But if this game stands out technically and this team is in the intelligent and precise use of SS capabilities for transparencies. In games we can see a large number of them and used intelligently to make them work as well as possible. So we can see native and transparent transparencies on the VDP2 working at the same time and almost without problems in the Screens and through the shared mode between VDP1 and VDP2. In the latter we can see its use mainly in the shadows of the players, but also in the splash of water when it rains and the shadow of the ball. VDP2 transparencies can be seen used for rain, field radar, UI signs, or menus.

Special mention to the use of the insert mode on the Line Color Screen or LCS. In this case to simulate the haze towards the distance on the playing field. It is seen only in day mode. This effect is missing in FIFA 98, which was on PS1, but Climax in the SS version did not integrate it. As we can see in this SWWS it is totally possible. In addition to having seen it in many other games as we have seen.

In the menus we can see how it is also used for button shadows or selection square backgrounds or the UI. I have also been able to see the use of the extended color calculation mode or ECC, but not in matches. Add as a curiosity that I have not been able to see where it is actually being used, since I have not seen any place where 2 or more Screens of the VDP2 are overlapping. And the other detail is that the Aquila Theme runs away from using the mesh mode of the VDP1. But in the menus in the player editing part when, two windows overlap. In scaling animation they use mesh mode, possibly to prevent transparency from this cover to the bottom. It is still curious that these with the knowledge they demonstrate would not have avoided it in other ways. If you already had the ECC mode activated they could have used it for one element to do it with the native VDP2 and another one with the VDP1> VDP2 with the ECC and thus mix it with the VDP2 ECC. Or use the transparency of the VDP1 for the two elements and both send them through the VDP1> VDP2 mode.

As a final note, such is the use of the machine they make. Which is one of those few games in the catalog in which all the Screens of the VDP2 are being used, with the majority of active and used functions. Both in menus and during the 3D game, it is spectacular without a doubt.

The sound as in most first party titles is superb. In this title we also have the use of CD-XA and ADPCM in an extra way. In addition to MIDI music with active DSP reverb and echo effects. Making use of the SCSP-DSP in the menus of 60% memory and in 3D game up to 30%. Of course they also make use of CD-DA tracks. Comments can be seen that they are in individual files. In SWWS 98 they packaged everything in a single file, I suppose to speed up access to the flight in the matches and minimize the stops for searches on the CD on the fly, typical in these cases.

At the time the intro of this game shocked me. At 320×176 and 15FPS. With ADPCM stereo sound. The truth is that it is very good. Although the compression in Cinepak is upgradeable, too many typical codec artifacts are seen and they tarnish the end result. Not so in version 98 that sets the bar really high. That reaches 320×224 also has 15FPS, but now in PCM, even stereo at 22050hz, a great quality for the system.

The use of the machine is remarkable as we have been saying. Use 1xSH2 for FMVs, while 2xSH2 for the rest of the game. SCU-DSP signals typical of 20% memory and 17.4% Registers are seen. Possibly for transfer of audio or data stream. RAM usage is 95% for LRAM and 90% for HRAM. The VRAM usage of the VDP1 reaches 80%. While the VRAM of the VDP2 reaches 90 and that of the CRAM 95%.

  • Sonic R

    Released 1997-11-21. Being a game of the 4th wave of European developments from a Second partys.

We are before a true miracle. Well, the SEGA mascot has been lurching from before the release of SS. Up to 3 different Sonic 3D titles are known to be on the way: One in 32x and two in SS. But we can thank SEGA Europe that it was able to carry out this Sonic 3D, and also with a company and leader in high-level programming: Traveller’s Tales. We are possibly one of the best titles in the system. And it is also a Sonic, and we could say that even “original” being a racing game. Built in just one year, and converted from a Formula 1 game originally to compete against Bizarre Creations’ PS1 F1 96. John Burton and his team made a true masterpiece.

If it is true that the TT itself is in charge of the also unique Sonic 2D isometric that came out on SEGA machines. And that for the SS version a fully 3D bonus was included. And there is also the 3D map mode of the Sonic Jam of the Sonic Team itself. But as a game thought entirely in 3D, this is the only Sonic we can consider.

Running at 30FPS like a rock at 352×224 dots of resolution in 16BPP color mode on VDP1 and equal output resolution and maximum color depth for VDP2. With an incredible amount of on-screen geometry. It is the game with more quads painted and calculated on the screen and stable system FPS. Peaks of about 1500 quads on display. All said for both one and two players on split screen.

The use of both VDPs is masterful. The VDP1 is fully used: Flat polygons, normal sprites, scaled sprites, distorted sprites. In different types of color depth. Gouraud shading in static and lively color. Different modes of color calculation. half-Transparency used with great intelligence: Speed ​​trail (with a minimum of redrawing error), shields … Mesh mode used only in extreme cases: Shadows, smoke … In the case of VDP2 the use is at the same height. Something really weird to see in SS. Most games focus their use on the VDP1, and not excellently as it is the case, and almost completely forget the magnificent VDP2. This is not the case as we speak. John Burton puts up to two infinite shots on screen at a maximum possible resolution. Use backgrounds with animated parts. And of course all the possibilities of transparencies that it gives. Both its own per screen for UI elements, as well as special ones such as the Color Line Insertion, even animated for the waves. Color calculations and ratio with VDP1 to achieve an effect of depth cueing with magnificent fading, with up12 levels. And for the ripple effect in the water when the character is underwater. Adding the use of the Extended color mode for the color calculation function, but in this case fully functional and well used, mixing up to 3 layers of the VDP2.

In addition to everything exposed. John still has more surprises for us. Illumination with 1 dynamic parallel light with source and Gouraud color in all characters. Of course the stages are illuminated with color and Gouraud, but in this case they are bake lights.

But there is still more. John Burton’s team went further. In the absence of UV coordinates in VDP1. John Burton commissioned a teammate to implement via SH2 assembler a triangle rasterizer with affine projection and UV coordinates similar to the PS1’s GPU for use in Sonic R for Ambience Map effects. And he did. Finally I don’t use it extensively, just in: the R 3D of the logo on the initial screen, the 3D head of Sonic rotating during the loads and in the 3D position number of the limit switch. But the idea was to use it also for Sonic Metal. There it is.

It should also be noted that Sonic R makes use of the 3D sound capabilities of the SS SCSP-DSP chip. In this case the Qsound implementation. Possibly for echo or reverberation in tunnel or closed areas. I have not been able to verify it 100%.

We end with the use of Hardware. As it could not be otherwise, it is excellent. The SH2 pair plus SCU-DSP is being used for the entire 3D pipeline. In this game reaching one of the highest figures: 80% of Memory and 57% of Registers used. Presumably Sonic R is close to using 100% of the process on the SH2 Slave when it is using its software 3D renderer. As we have said, use the SCSP-DSP processor in this case we see up to 90% of the memory used. On the part of the main memories. It is at 85% combined use of the main RAM. In 85% of the VDP1 and 85% of the VRAM of the VDP2 and 60% of the CRAM.

5.4 The most complicated – EXTRA II ball: Reflections in floors / Flat surfaces.

It is a subject that has been attracting attention progressively. When I have discovered how the SS draws, and how they used it in the games of the moment, I was asking questions. One that was in crescendo was Why are there no reflections in basketball or ice hockey games?

Because if I had seen them in games like Panzer Dragoon before looking at Basketball or Hockey games. But it is that only two Basketball games have this effect. That is, the reflection plus the shadows.

In those of Hockey none. They have transparent shadows, but no reflections. The one with reflexes is NHL 97 but they are Mesh. Some Basketball games had at least also transparent shadows like NBA Live 97.

Like everything related to “transparency” in SS, the problem was that it was not simplified, “clear” and accessible to developers. If it had been really simplified and accessible through the libraries and SDK, they would have used it more.

Was this disadvantage finally resolved?

Sadly NO. As I say only one basketball game did. When in fact, from my point of view, everyone could have. Same with Hockey.

I have come to see it in only 3.4% of the total number of games analyzed. When as we see for the VDP2 and in many games it is a totally possible effect and free at the performance level.

Well let’s go with a chronological list of what I have been able to find:

Games with 3D reflex effect using VDP1 + VDP2:

  • Panzer Dragoon Zwei (1996) → Reflection Water and underwater
  • Linkle Liver Story (1996-03-15) → Reflection Water
  • Shining Force III (1997) → Church Scenario 3 or Premium. Seen in videos and images, I could not verify it.
  • Ten Pin Alley (1997) → Reflection park
  • Mass destruction (1997) → Reflection Water
  • Panzer Dragoon Saga (1998) → Reflection Water and underwater

Games with 2D / 3D reflex effect using VDP1 + VDP2:

  • From TV Animation Slam Dunk: I Love Basketball (1995)
  • Slam ‘n Jam ’96 Featuring Magic & Kareem (1996)

Games without the reflection effect, worst possible, but with 2D / 3D shadows using VDP1 + VDP2:

  • NHL Powerplay 96 (1996)
  • NHL All-Star Hockey’ 98 (1997)
  • NHL 98 (1998)

We turn again to analyze three games that are representative of this point:

  • Panzer Dragoon Zwei and Saga

    Released on 1996-03-22 and 1998-01-29 respectively. Panzer Dragoon Zwei and Saga are the second and third part of the saga in SS. 3rd and 5th wave games respectively from a Japanese First party developer. We can see an important use of the machine in 96 and extraordinary in 98.

Note that both games share technology. It is curious because the difference between the two is approximately two years. But analyzing both in detail the data is there. Dynamic color lighting is present in both games. Creative transparency effects with VDP2 or 3D sound using SCSP DSP. Even the sound driver version is the same with a slightly different build date but from 1996. They use the available processors and memories in% the same or very similar. The use of the Cinepak codec is also the same. When at this time there were SEGA games using ADX and Cinepak with ADK for more quality. Even the use of VDP2 for FMV is the same.

Let’s go into detail. As we said, both games have dynamic lighting with a source plus Gouraud in color. Also flat dynamic lighting in some entities. And for supposed lighting baked in stages with Gouraud and flat. Both have Depth cueing with the VDP1 and with color palette changes with the CRAM of the VDP2.

Both games run at fairly stable 30FPS. In 3D cinematics on Zwei it even reaches 60FPS. In both games the charge of quads is similar around 500 quads, maybe more in battles with many enemies, bullets or very large enemies. In the Zwei cinematics over 300 quads. In the series on some very large 3D maps you can see drops at 15 / 20FPS. Otherwise it is quite stable. In terms of resolution, both games run at 352×256 in the 3D parts and in the HD menus at 704×256, with a clarity that still surprises today. Although the game is in 15BPP mode, the content of textures and patterns is usually between 4BPP and 8BPP for both VDP1 and VDP2. Of course both games follow in the wake of the first in the use of the infinite planes of VDP2 to recreate huge spaces as could only be seen in SS: Deserts, clouds, seas …

Zwei already in 1996 made it clear that when you wanted to the SS could put transparency without blush on the screen. Especially underwater effect and reflection of the enemy of the caves in the second episode, if I remember correctly. Of course they both use the Color and Ratio calculation transparencies with the elements of VDP1 and finally mixed by VDP2. In various effects from: Zwei’s forest level shadows, underwater elements in both games and many others. As a curious fact for lighting the bonfire in the tent. Of course the full screen transparency effect of the VDP2 is used for different weather effects, cloud cover on map or magic. Also in many elements of the game UI.

On the other hand the half-Transparency of VDP1 is also used. But in this case I have not seen it in the Zwei, if in the Saga. It is used for many particles and billboards in a very intelligent way from: Smoke, shots, explosions, magic particles … Both on the 3D map and in battles.

When the spoken transparencies cannot be applied, the Andromeda team has to resort to mesh mode as we usually see in many other games, so we can see it in: Character shadows, various particle effects or on the radar …

As I said before both games use Cinepak + PCM for FMVs. The sound quality is the same: 32000 Hz, 16bit, Mono. For my taste a waste for the quality of the Soundtrack and the sound in general not being able to have it in Stereo. They differ in the resolution and FPS of the image stream. Zwei has less resolution but more FPS and Saga backwards. But from my point of view a waste of CGI quality. This saga should have used Duck or at least Cinepak + ADX to have a quality close to Wachenröder or Lunar 2. Finally highlight as a detail that these are the few titles that use the scaling of the VDP2 in the FMV to be able to take better advantage of the total area from the screen.

Noting that one of the extra docs the developers left on Panzer Dragon 1. The sound programmer said he was left wanting to use 3D sound. But that for the next occasion I would use it.

◆エンド前にカゼ.

今回はできなかっ3Dサウンドとか使っ.

サターンのサウン,と反省し つ つ 次 回 に 乞 う ご 期待。

サ ウ ン ド 担当 ： 澤 田 朋 伯

◆ It cost me a lot, I caught a cold before the end, but I could safely finish it.

I couldn’t do it this time, but I would like to use 3D sound next time.

I’m sure we can do even more amazing things with the Saturn sound, so please look forward to next time.

Head of Sound: Tomoharu Sawada

So it was. In both Zwei and Saga we see a great use of SCSP-DSP. Both in reverb effects and in MIDI sound and music in general. Thus we can see a use of up to 90% of the DSP memory of the sound. Plus .exb file signs per track. Files of the compiled code of the sound DSP. The quality of the sounds that you could see is from PCM at 11025 Hz mono.

The use of the hardware is excellent. Using 2xSH2 for both FMV and 3D. With typical SCU-DSP usage signs of 30% and 26% in memory and registers respectively. On the other hand we can see a use of the main memory at 70-80%. From the VRAM of the VDP1 of 80-90%. In the VDP2 I have seen slight differences. In the PD: Zwei 55% of the VRAM of the VDP2 and 90% of CRAM. In the PD: Saga of 80% of the VRAM of the VDP2 and 70% of the CRAM.

  • From TV Animation Slam Dunk: I Love Basketball

    Launched on 1995-08-11. Slam Dunk is a game from the 2nd wave of Japanese Third party developments. And I have to say that a development of a superb quality to be so early in the system.

BEC Co. Ltd which is the company that is accredited as developers of this title. They are still a division of Bandai. They were in charge of the most known IP of Mangas. Another great title of them is Dragon Ball: The Legend.

It is not a game with a large quad load, about 400 quads, but strangely it goes at 15FPS like FMV. At a resolution of 320×224 15BPP. I get the feeling that they wanted this to be the ultimate FPS goal. Because the feeling, for various details, that technically they are going well.

What really catches the attention of this title is the implementation of the reflection effect that it has on the court. That is not seen in the rest of basketball titles or the like. And this game shows it as entirely possible. Also making very clever use of color ratio calculations for the VDP1 elements on the VDP2 alongside the specular gloss blend in another layer of the VDP2. All this against the court using RGB0. And without ever using the extended color calculation mode, it feels like everything is getting mixed up. It really works very well. To end the transparency issue, also point out that they use the half-Transparency of the VDP1 in a very correct way for the glass board, which is always on elements of the VDP1.

We can highlight that it may be one of the first titles that use the SEGA InVision library, for MIDIS. The music of the game the truth is that it sounds very good. Regarding the use of the SCSP-DSP there are clear signals up to 60% memory, and I have the feeling that the sounds in the stadiums are heard with echo or reverberation.

I have to say that the FMVs of this title seem superb to me. Seriously, the quality and the quantity is very good. It has 288×216 scaled on the VDP1a full screen, 30FPS and PCM 22256 Hz 8-bit Stereo. It surprises me mainly because of how early they are in quality. And at the time similar titles in SS made quite worse videos, even from the same Bandai the first Dragon Ball Z or Rayman of Ubisoft.

The use of hardware, IMHO, is magnificent more meritorious as a Third party and at such an early stage of system development. The use of the processors is total. The 2xSH2 for both 3D and FMV. And also in 3D the SCU-DSP is being used in some important figures, 95% memory and 44% records. Regarding the use of memories, we are 95% of the LRAM and 65% of the HRAM. The VRAM of the VDP1 reaches about 90% usage. The VRAM of the VDP2 at 80% and the CRAM at 70%.

  • Mass Destruction

    Launched on 1997-11-20 as a game from the 3rd wave of European developments. For me this title is especially remarkable because it is remarkably well resolved for the SS and also the other versions. It has not been prioritized in some more than others. And a job has been done to make them look the most similar and correctly on each support. What should be. Just note that it came out two months apart from the PS1 version, and that only one programmer is credited for the SS version. All in all, as I say for me the best version.

It seems that the NMS team did not have much life, but at least with quality. It can be seen that they were professionals with a long journey, even from 8bits. Skilled at playing low-level code and creating graphics in different circumstances. SS was positively benefited by this. And also in this Mass Destruction you can see all your knowledge. A direct action game with little details, but that make the apparently small games big and durable in time.

Running at a resolution of 320×224 at 15BPP although the graphics are mostly at 8BPP, just like the PS1 version. But at constant 60FPS and if slowdowns, against the PS1 version is not so smooth, perhaps this at 30FPS. Which is not bad either. The ground quality also in SS is clearly superior, since the RGB0 of the VDP2 is capable of drawing perspective perspective-corrected 3D plans with very high detail per tile. PS1 couldn’t match this without extreme sacrifice. It is also not a game that draws many quads on the VDP1, in this case around 300 quads.

This game does not have dynamic lighting, you can only see a pre-calculated lighting in some elements such as palm trees or objects with flat polygons.

This game makes excellent use of the transparency possibilities of SS. Only one downside can be put, not having implemented transparency in buildings as in PS1 totally possible, just by sending the entire building and to the tank under RGB0 with CC + ratio as the reflections they make in the water, it would have been enough. But hey, on the contrary, we have those reflections in the water that are not on PS1 or PC and that are very spectacular. NMS also makes use of the MSB On mode for some shadow transparencies. And of course from the normal layer VDP2 transparencies for the UI, even animated, masterfully.

Mass destruction introduces a use of low-sounding but existing DSP. 20% memory usage. The music is mainly CD-DA although there is also some in MIDI.

NMS appears to have implemented its own code for FMVs, which appears to be the same for all versions. Giving 8BPP remarkable quality at an unknown FPS amount, but I estimate it to be 15 / 25FPS.

The use of hardware as we have seen in remarkable. At the processor level, 2xSH2 is being used for 3D and FMV. On the part of memories, the main one reaches a use of 70% in LRAM and 80% of HRAM. 80% of the VRAM of the VDP1. And finally 90% of the VRAM and CRAM of the VDP2.

6. The most complicated II: Render-to-texture

This point has been another one of the last additions that I have made. In the course of this maximum delving into the machine. I have seen in a few numbered titles, something that a priori could not believe. Well, in my eyes, it was a Render-to-texture effect. Something that was born practically with PSX and its unified buffer. Which was later seen and used in GPUs on later PCs and consoles.

But how could this be? Theoretically it is “impossible”. Because the SS has completely separate “two buffer areas”. And read them during the pipeline, if it can be very expensive in cycles.

But there are games where we can clearly see how the screen image of that moment is captured and then 3D graphics are made, which is effectively drawing the VDP1. In other words, they are quads and textures.

Finally we can differentiate in this case several possible ways to do it:

A) Render Buffer (Case type PSX): Take something from the FrameBuffer of VDP1 or Screen of VDP2, inside or outside the drawing area, to reuse it in a pattern / texture for the VDP1 or VDP2. And create a concrete effect to all screen or in part via hardware or software. Doing part of the effect with hardware is less expensive for the system. Doing an extra process by software greatly increases the cost (more time) for the system.

B) Render CPU and / or SCU-DSP: Where the CPU / SCU-DSP draws something internally (Process and RAM) and transfers it directly to one / s texture / s, to the Frame Buffer of VDP1 or to a Screen of VDP2. Example: Sonic R

C) Render CPU and / or SCU-DSP with Read + Write in the FrameBuffer of VDP1: This is the most aggressive and complicated method of all. It involves reading the FrameBuffer, inside or outside the drawing area, at runtime, internally processing (CPU and RAM process) what you want and drawing on it. You need the operation or function you want to perform to be extremely fast, since the time to do it is very short. We talk about a few more. If it goes too high it will stop the game too much causing severe slowdowns. Example: Scorcher.

D) Reading the VDP1 FrameBuffer + CPU / SCU-DSP + RAM Process + Reading the VDP1 Frame-buffer + Final writing in the VDP1 Frame-buffer: This is the most complex and expensive method that I have been able to document. I’ve only seen it in Die Hard Trilogy in the third game, the car game. The team uses it to make half-transparency additives in sparkles and explosions / fire. They look beautiful. The item to “process” is drawn at the end of the command list outside the drawing area. My intuition tells me, that inspired by the original PS1 code. They do a kind of Render-to-texture like they did for the radar of the first game, which is to read the frame-buffer to use it as a texture and do a hardware process. But in the case of SS they actually go through the VDP1 Frame-buffer three times, which is a snap. Which for the PS1 is already an expensive process, despite having a unified frame-buffer, with access to 32-bit words and a little more bandwidth to go to more Mhz. In SS the memory is faster, quite a lot. But accessing 2 more times and adding an extra process in the CPUs for the effect via software, is already a hyper risky action at the performance level. So much so, that when you have 20 or 30 particles on screen occupying a large area, the performance drops to a digit. I would like to end by praising the team’s work, because despite the lack of ports. It does not stop seeing good intentions to go further with the machine, in many aspects. Perhaps the lack of budget + timing necessary for the complexity of the system, again played against the SS version.

Was this disadvantage finally resolved?

Yes and no. Yes, because as we speak, there are games that do it. But NOT because it is not documented by SEGA and there is not even a library for it. At least that I have found. As such, we can find said “feature” applied in a different way, with different objectives and results.

What I have not found is literally a case of the type: Giant TV screen.

The remaining question is whether it would be possible at low resolution, without penalizing much in FPS to achieve this effect. Since on PSX there was no penalty, up to a point. According to @XL2 that I asked on the Segaxtreme forums, it would be entirely possible at low resolution. In fact in Burning Rangers or the same in its 3D engine it does it for the transparency layer similar to how they did it in Burning Rangers too.

The Render Buffer cases found in games published at the time are clearly “Static” for the most part. With obvious pauses before the effect (even on PS1 depending on how). We would be talking that to perform them the CPU would have to completely stop the graphic pipeline.

Except as we say the Burning Rangers case. Also in Grandia in battles, but I’m not entirely clear. Where there are no stops.

I have also seen something very similar in many games, to render the FMVs or in some loading screens, although I have left it out of the following list.

I have come to see the use of this technique or very similar in 11.4% of the total number of games analyzed. It really surprised me. Since he thought it was impossible for the SS because of the design of its graphic pipeline. But I was happy to see that it is possible, at the same time, I was sad that SEGA did not facilitate it again. Perhaps we could have seen it more since it allows very spectacular effects.

We are going to see a chronological list and by type of technique used with what we could find:

A) Render Frame-Buffer to:

All the complete frame of VDP1 + VDP2 → To elements of VDP1

  • Rayman (1995) → Final loading level screen with one more fade animation with 3D elements. 320×224 resolution the same as the original in all layers and VDPs.

All the frame or partial of the VDP1 → To elements of the VDP1

  • Loaded (1996) → Game background in Pause / Inventory menu. Same 352×224 resolution as the original in several elements.
  • Welcome House → Game Background in Pause / Inventory menu, with mask pixels to correctly display the VDP2 background. 320X120, Half resolution “Y” Render.
  • Akumajo Dracula X: Gekka no Yasokyoku (aka. Castlevania: Symphony of the Night) (1998) → Photo effect in-game intro at 320×216 resolution, does it pretty fast.
  • Genso Suikoden (1998) → Effect in Full Screen Battles. Like PS1 but poorly implemented, with silly problems. At 320×240 possibly, I have not been able to verify it, it seems that it is relatively slow.

All the frame or part of the VDP1 → To one layer of the VDP2

  • Tomb Raider (1996) → 3D game background in Pause / Inventory menu 352×256. It does it very fast.
  • NBA Live 97 (1997) → 3D game background in Pause / Menu options 320×240.
  • Burning Rangers (1998) → Layer of transparent elements and mask (black) at 160×122.
  • Arcana Strikes (1997) → VDP1> VDP2 Appears to send sprite data with the same resolution as original VDP1 → NBG1
  • Grandia (1997) → In battles, the sprite characters that are drawn in VDP1 are transferred to VDP2 NBG1 and, therefore, the transparency effect is used in VDP1> VDP2. It appears that it only transfers VDP1 data that is out of date or paused. The only animated data is drawn on VDP1 at this time.

B) CPU / SCU-DSP Render to:

A Layer (Bitmap or pattern / pattern / s) of the VDP2:

  • BIOS menu (1994-11-22) → Background stars space.
  • Cyberia (1996-01-01) → All 2D and FMV are rendered by the CPUs and sent to NBG0 of the VDP2.
  • Shellshock (1996-04) → 3D Mode 7 Ground as Firestorm: Thunderhawk 2.
    • PassThrough of VDP1 primitives for assets, enemies, and particles.
    • CPU + VDP1> VDP2 from Elements.
  • Hexen (1997) → Map-Scenery BSP Engine Software raster render
  • Tempest 2000 (1997) → Blur effect, very slow FPS
  • Amok (1997) → 3D Voxel Engine
  • Shining Force III (1997) → SCU-DSP Render to Texture VDP1 and VDP2 Texture Procedural gradient to VDP1 and / or pattern / pattern / sa VDP2 screen

A Texture / Pattern of VDP1:

  • Firestorm Thunderhawk II (1995-11) → 3D Mode 7 Most degraded soil horizon
  • Sonic R (1997) → Environmental Map effect
  • Shining Force III (1997) → SCU-DSP Render to Texture VDP1 and VDP2 Procedural Gradient Texture to VDP1 and / or pattern / pattern / sa VDP2 screen

C) Read / Write to / to the FrameBuffer of VDP1.

  • Rayman (1995) → Particle Blast when you pick up items.
  • Scorcher (1997) → Fixed red and blinking white haloes.

D) Reading the VDP1 FrameBuffer + Process CPU / SCU-DSP + RAM + Reading the VDP1 Frame-buffer + Final writing in the VDP1 Frame-buffer.

  • Die Hard Trilogy (1997) → Billboard: Flashes, colored flashes with Gouraud and explosions

Finally again I am left with three other of the best games in this section. What they would be:

  • Firestorm: Thunderhawk 2

    Being released on 1995-11-08. It is a title of the 2nd wave of developments for the system. Virtually 1 year after launch. Core Design had already shown since the 8bits to have a more than guaranteed tradition in everything it did. And its members with all that extensive experience already in 95 testify to this with each launch. It was a game developed in parallel for PS1 and PC in just 3 months, as its developer tells it in a short twitter conversation that I had with her, thanks Sarah:

“The versions of Saturn and PS1 took 3 months to create, and the PC version took another month. The game was C-coded, with machine code subroutines where needed for speed.

I should add that I had to code a new 3D engine from scratch, using 3D polygon hardware for objects and most of the floor, with the distant floor represented by a software routine I had developed based on the MegaCD ASIC. ”

Sarah Jane Avory

The game runs at typical SS resolution of 320×224 at 15BPP although the graphics content is between 4 and 8BPP. At fully stable 20FPS. It is a game that caught my attention because it does not show the typical drawing commands in the Yabause VDP1 debugger. Displays tons of Normal Sprites at 8BPP small. And on the other hand it can be seen how the Mode 7 rotated flat floor is not being drawn by the VDP2 with an RGB0 layer. All this added up made me think that everything was drawn by software. But when you put the emulator in OpenGL you can see how the graphics go up in resolution and you can even appreciate the use of Gouraud and Mesh typical of VDP1. I don’t know exactly how Sarah programmed VDP1, but she’s using it. What is rendered by software as she confirms is the Mode 7 floor with a Depth Cueing effect in addition. Which in your next project, Fighting Force, if I use VDP2 for it. If you use RGB0 for the background rotated according to the tilt of the camera. It could also be doing a render-to-texture on the radar that we see inside the cabin or the 3rd person camera.

F: T 2 does not have dynamic lighting of any kind. If you have bake lighting on terrains and features, using Gouraud or Plane smoothing.

The music in the game is on CD-DA track. Although we can see 35% DSP usage of sound, I don’t know exactly why.

F: T 2 has a frankly very good FMV. It can already be seen that Core was quite used at the moment due to her previous stint on Mega-CD. The intro has a very good quality at 320×200 at 15FPS, the sound quality is good but in mono.

Finally the use of the hardware is very good. Already using 2xSH2 for both FMV and 3D. Typical signs of use of the SCU-DSP are seen. From the use of memories we can see up to 85% in the LRAM and 45% in the HRAM. 95% of the VRAM of the VDP1. And 22% of the VRAM of the VDP2 and 90% of the CRAM.

  • Amok / Scorcher

    Being both releases from the 3rd wave of developments Third party on 1997-01-17 and 1997-03-01 very close. Both from a USA company but with teams from other places. We find these two titles being developed internally by two different Scavenger teams: Lemon and Zyrinx both with components from Denmark from the Amiga demo-scene. In the case of Amok everything points to being one of the technical demos that were previously shown for and on the 32X. It can also be deduced by the size of the final games and by a series of technical details in both games.

Let’s start chronologically with Amok. Really under my opinion it is a game for the shocking moment. The voxels, which have always been the poor brother of 3D, have always liked and surprised me. It is also a type of 3D that is not cheap to process either, and that in the RISCs of the SS goes so well it seems to me a great achievement. Well, in fairness, Amok does voxel and classic 3D processing, since 3D entities are processed as a raster of textured triangles. We can also observe Depth cueing towards the bottom by software in all the elements.

On the transparencies in this game the solution via software has not been used, an implementation of the mesh or screening type has also been chosen. If we can promptly see the use of VDP1 transfer for radar in the UI. And in the least the transfers of the VDP2 with CC.

Amok runs at 320×224 at 16BPP on the VDP1 elements and on software render which is on the VDP2 and the background of the VDP2 at 8BPP. This game goes 30FPS, sometimes counted down to 25 or 20FPS. It is not possible to know how much geometry is on the screen.

The sister version of PC is practically identical. At least in the main features and drawing distance. Although it asks for a minimum of an Intel i486DX2, the recommended was the Intel Pentium at 100MHz. Possibly in a 320×200 to 8BPP mode with scanline the DX2 would be fine. But going up to 640×480 from 8BPP to 16BPP would already need a good Pentium and perhaps not with that it would go as smoothly as in SS. On PC the transparencies are real alpha all by software instead of mesh as in SS.

Sound level uses CD-DA for music, hence perhaps the possible use of SCU-DSP for something besides SCSP-DSP in 35% of memory.

Although there is no FMV as such, there is some full screen animation for the Logo. Possibly RAW image loaded on the fly.

The use of Amok hardware is remarkable. Using 2xSH2 for 3D. With signs of use of the SCU-DSP as we speak typical 25/26% for Memory and registers respectively. And using even the sound DSP as we have also commented. At the memory level we can see a use of 85% of the main RAM available. A very low use of the VRAM of the VDP1 over 45% and an irregular use of the VRAM of the VDP2. In this case, 95% of the VRAM and 55% of the CRAM. I don’t know exactly how it can take up so much VRAM, when you are only using two layers and one of them at 8BPP.

In this case Scorcher is a post-apocalyptic racing game. Where you can easily see that it shares code with its sister version of PC.

We can see above all as a key detail about the SS version, the use of real alpha transparencies via software in some elements on the screen. In this case, blinking white or solid red flashes on some tracks. These are drawn onto the VDP1 framebuffer itself by the CPU. We can verify this by seeing that this does not appear as a drawing command in the VDP1 debugger in Yabause. And also with how the effect looks, being a very smooth multiplicative blend against the data drawn from the VDP1. Finally leaving the typical black spot against the areas of the Framebuffer that have not been drawn and reserved for the VDP2 in subsequent stages. Finally we can corroborate the nature by software when observing in the real console that when we are very close to these flashes occupying a large part of the screen, the console takes a long time to process it and the frame rate drops very abruptly with this effect it is on the screen.

Native SS “transparencies” are also used, both those of VDP1 and VDP2. For those of VDP1 we can see them very well used in the effects of smoke particles: green or gray. With quite a few overlapping on-screen particles and textures of considerable size. For the use of transparencies of the VDP2, we can see the typical use in a layer with Color Calculations with Ratio. In this case in the first circuit in an RGB1 layer to represent the moving clouds in the sky.

Graphically we are facing a game that is being rendered at 16BPP in all its elements on the screen of VDP1 and the backgrounds of VDP2 at 8BPP. At 320×224 at 30FPS most of the time with 600 quads on display normally. Only with falls as I commented when the camera passes near the flashes made by software. The PC version is practically identical. Only that it has a 640×480 mode, having the menus and the game twice the resolution. And giving option to render to 8BPP or 16BPP. Clearly this second most prohibitive for the time on PCs at the time which required a minimum of an Intel Pentium. Finally with the same transparencies but more precise and without the SS problems.

The game uses Gouraud on all elements of the stage. It also has a colored light on them. And it makes use of Depth Cueing towards black.

The level of use of the processors is remarkable. Using the 2xSH2 for the 3D and with signs of use in the SCU-DSP of up to 25% of Memory and 26% of registers. It makes use of CD-DA music and MIDI music, using the memory of the SCSP-DSP up to 60%.

The use of memories is from Scorcher is remarkable. The main RAM usage is at 80%. The one of the VRAM of the VDP1 in 95%. And the VDP2 of 55% for both VRAM and CRAM.

Finally, I would like to point out that @Zyrobs via comments commented that Scorcher could be downloading and downloading graphic data from the VRAM of the VDP1. I have not been able to contrast this data, in such a way if it were so. It would be another great technical milestone for this game along with the process of real transparencies via CPU and writing / reading of the Frame-buffer at drawing and execution time.

  • Hexen

    Hexen was first released on 1997-03-31. Strangely 3 months earlier than on PS1. And we could say that better port, narrowly the truth. From this port, also from the Doom engine, I am in charge of another totally different team for GT than Doom. Rage the UK team yields the baton to ATOD a team from Sweden. These choose a totally different path, with its pros and cons.

The game is rendered at 320×224, more than on PS1 at 256×224. Both at 15BPP, but actually with graphic data between 4 and 8BPP. In SS it runs in the average stays between 25 and 30FPS. In the largest at 20FPS, it can drop to 14FPS in very large and deep rooms. On PS1 it goes even worse, strangely. As a curiosity in very small stays it can reach 60FPS. It looks like you have FPS unlocked like the Duke Nukem 3D from PS1.

At the level of elements on the screen it is not high, over the 100 quads maybe more. Keep in mind how Hexen renders SS the Doom engine this time. The developers chose to write the entire part of the wall, floor and ceiling drawing by software and processed by the 2xSH2, and then send it to the NBG1 of the VDP2 as a background at 8BPP. With a cost in the resolution of the textures, which are practically half. On the other hand, the typical sprite elements are drawn by the VDP1 and the VDP1 in turn draws black quads to make a mask and sometimes walls to hide the sprites. VDP1 is also used to illuminate sprites using Gouraud color for background lighting and fading or Depth Cueing. It also uses the half-Transparency + Gouraud CC for particle effects such as smoke, so it only blends with the few elements that VDP1 draws and not against most VDP2. In addition to using a really expensive VDP1 CC like this half-Transparency + Gouraud. Anyway, it is appreciated that at least they used the transparencies in this “Doom”.

Needless to say, the performance problem of this Hexen, as in the Doom, but much less. It is on the CPU side. VDP1 is not experiencing anything on this port.

This game has the typical Doom lighting, although without being perfectly implemented as it should. Hands / weapons don’t seem to receive enlightenment, in Doom at least they do. In the sprites it is somewhat erratic, it seems that if in the lightning of the beginning, but later in dark areas of the dungeons not. However in PS1 as in Doom, if the correlation is seen perfectly.

The sound in this game has the curious. We can see a sound library written by Virtually Unreal Ltd. for Probe, for the use of ADPCM in SFX, which I already saw in Alien Trilogy and Die Hard Trilogy. Could it be that you are using FX ADPCM sound? I do not know. On the other hand we see the typical SEGA driver. If we can see a typical sound DSP usage of 35% memory.

The quality of the FMVs in this version is remarkable. Using Cinepak + PCM. But with high quality. 320×200 at 30FPS, and the audio stream is pretty fair at 22254Hz 8bit Mono. Also rendered in VDP1.

The use of the hardware is quite good. The main memory is at 70% use. The VRAM of the VDP1 by 80%. And the VRAM of the VDP2 in 40% and the CRAM also in 40%.

7. The hard thing to “see”: Sound Effects with Reverb and / or Echo

We are finished. When I get hard to “see,” it’s actually “hearing.” But I mean, it is / was difficult to find SS games where we can perceive, “see”, a change of sound when changing places. However on PSX I remember it perfectly. It hurt even more in ports, where I missed it even more. And as with the graphics, I didn’t understand why it wasn’t there.

Before going any further, I would like to make it clear that the use of Echo or Reverb can be perceived in many SS MIDI melodies in your notes and compositions. Even in some sound effects or jingles. For me a clear example of this are the main melodies of Shining Force III. But let’s say, ambient sound or with examples of rooms or tunnels, I have not been able to find.

In this research where I have been able to understand the machine to its limits, including the PSX. I have seen that this aspect wanted to deal with it. It is still curious, more so when in the sound specifications of SS from the beginning it is clear that it can do this effect.

When you dig into the official documentation and SDK, you understand what happened. When in PSX the effect of marras was accessed with a simple function in its development library, without more. In SS, apart from using a function that in this case uses the digital DSP capabilities of the custom Yamaha sound chip for SS. The development team had to have the “Linker” and the “eLinker (3D Sound)” which was extra development software to load these effects into their projects.

Again we find how Sony simplified the same masterfully. Where SEGA gave a sound chip with a DSP for fully programmable effects, that is, a beast. It also mixed sound up to 32 FM and / or PCM channels. In addition to combining them in the form of MIDIs, which were created with the “SEGA Sound Library” first and later with the “CyberSound SDK”. All this governed by a dedicated 16bit M68000 CPU for all this.

The issue was that to get the most out of the sound chip, you had to go through the SEGA box and buy the extra hardware to the basic development. We are talking that the SS could have 3D sound. Through the DSP of its sound chip. Crazy for the time. Really. But SEGA and / or Yamaha do not know, they preferred to try to monetize this part of the console a little more, loading it to the devs. These that were already passed with the rest of the “extras” of the console, it is not surprising that they will pass to get more out of this beast of the sound chip.

But as we say, next to this, something as simple as echoing or reverberating in a tunnel or in a room. In SS it was very expensive in every way. And on PSX extremely cheap and simple. With the same SDK and with a function where you already had the effect at hand.

And here the crux of the matter. This could translate into that only large companies could afford such an outlay. While all, small and large in PSX used it, giving added value compared to the SS, when it could do it in excess or better.

It is possible that at the end of life, tricks or software could load effects modules without hardware. Or that even I have misinterpreted it. And it could from the beginning. Or that even SEGA came to facilitate it with the latest development kits.

We are talking, possibly, about the chip that was first started to be developed for SS. Of the documentation available is the one with the oldest date, since 1993. It is curious, that it was not 100% ready for launch, with one of its most powerful features 3D sound.

I’ve been looking at the Sound Tools. And I’m still in shock! I thought you could only use the “Linker” and “eLinker” with a Sound Board or Sound Box. But it seems (because I have not tried it) from what I have seen in the basic use of the tools and reviewing official manuals, it could be used without extra hardware.

What has really shocked me is the topic of Qsound and Yamaha3D. The “eLinker” is the one that has them available, apart from other modules present in the “Linker” but with more options. The one that interests us the Reverb module. In both “Linker” has the basics apart from the preset according to type of “room”.

Today I know a little more about the great sound of the SS. I confirm major issues, such as checkout facing developers. It was indented by SEGA and Yamaha. I understand that the Hardware was not essential, but to access these features you had to have the software and the Apple MAC, at least. It was already an investment. And if you also wanted the advanced module, pay something more. And even royalties, 30 yen put by title. Or so I have understood when translating the legal texts.

In the documentation it is said that as of 02/28/1995 it was not yet available. And the oldest date of the documentation in this regard is 03/08/1995 of the eLinker. These dates mean that it could not be used for the launch, and that it was still in development during the pre-launch and first wave of games. And that I am here for the second wave with the SEGA 1.31 driver, delaying its use, knowledge and customer perception in games.

While on PSX the final sound characteristics were out.

Finally add. That all these tools for the sound DSP are programs optimized by Yamaha. It also seems that there was the possibility of programming directly on it, with an assembly language that SEGA documents further on.

Was this disadvantage finally resolved?

YES and NO. Yes, because the SS hardware was fully capable. In fact more capable than the PSX. No, because at least I have not clearly seen (heard) the use of it in many, clearly only in SEGA Rally in the tunnel of the second level. And for this analysis some more that I will list later as possible.

I can list games where at least QSound or Dolby Surround are known to be used, which are two sound technologies where there are Reverb or Echo values. In which levels or parts I do not know, the truth.

I have come to detect, in some cases clearer and in others less, up to 9.6% of the total number of games analyzed.

I’m sure you should see more. But with the current emulators it is the most I could determine.

It is true that I have detected sound DSP activity in the vast majority of titles, in many over 35%. In which I know the effect is used about 90%.

Here is the list of what I found:

Games where it seems that there are:

  • Stellar Assault SS → Start intro
  • Touge King – The Spirits (1995-11-10) → In tunnels97/98
  • Sega WorldWide Soccer→ Only in menus. Music + voices in music all with echo and reverb
  • Robotics: Cybernation Revolt
  • From TV Animation Slam Dunk: I Love Basketball
  • Touge King – The Spirits / High Velocity: Mountain Racing Challenge
  • Linkle Liver Story
  • Panzaer Dragoon Zwei → areas with tunnels or caves
  • Dragon Force
  • Mortal Kombat II
  • The Story of Thor 2 / The Legend of Oasis / Thor: Seireioukiden
  • Fatal Fury 3
  • NiGHTS into Dreams
  • NBA Action 96
  • PriCla (Princess Clara) Daisakusen
  • Sega WorldWide Soccer 97 / Victory Goal ’96
  • NBA Jam Extreme
  • Shining the Holy Ark
  • Drift King Syutokoh Battle 97 / Shutokou Battle ’97: Tsuchiya Keiichi & Bandou Masaaki (1997-02-28) → In tunnels
  • Manx TT → In tunnels
  • Touge King the Spirits 2 (1997-04-18) → In tunnels
  • Sky Target
  • Salamander Deluxe Plus Pack
  • Söldnerschild / Soldnerschild
  • Super Robot Wars F
  • Super Robot Taisen F Kanketsuhen
  • Devil Summoner: Soul Hackers
  • NBA Live 98
  • Devil Summoner Soul Hackers: Akuma Zensho Dainishuu
  • Panzer Dragoon Saga → Sure, .exb files and in the first room the steps and fx resonate alongside music.
  • Burning Rangers → In game 3D.Music and voices all with echo and reverberation
  • Techno Motor
  • Dragon Force II
  • Code R (1998-07-09)
  • Radiant Silvergun

QSound – 2D Games

  • X-Men: Children of the Atom (1995)
  • Street Fighter: The Movie (1995)
  • Arthur to Astaroth no Nazomakaimura: Incredible Toons (1996)
  • Ide Yousuke Meijin no Shin Jissen Mahjong (1996)
  • Street Fighter II Movie (1996)
  • Super Puzzle Fighter II Turbo (1996)
  • Tenchi wo Kurau II: Sekiheki no Tatakai (1996)
  • Mega Man X3 (1996)
  • Night Warriors: Darkstalkers’ Revenge (1996)
  • Street Fighter Alpha (1996)
  • Street Fighter Collection (1997)
  • Marvel Super Heroes (1997)
  • Cyberbots: FullMetal Madness (1997)
  • X-Men vs. Street Fighter (1997)
  • Pocket Fighter (1998)
  • Marvel Super Heroes vs. Street Fighter (1998)
  • Vampire Savior: The Lord of Vampire (1998)
  • Street Fighter Zero 3 (1999)
  • Dungeons & Dragons Collection (1999)

QSound – 3D Games

  • Madden NFL 97 (1996) → Announced but not verified.
  • NiGHTS into Dreams (1996) → Announced but not verified.
  • SEGA Rally Championship (1995-12) → In Tunnel 2nd Level.
  • Sonic R (1997) Tunnels → Announced but not verified.

Dolby Surround

  • FIFA Soccer 96 (1995) → Announced but not verified.
  • Road Rash (1996) Tunnels → Advertised but not verified.
  • Shockwave Assault (1996) → Advertised but not verified.
  • Madden NFL 98 (1997) → Announced but not verified.
  • Croc: Legend of the Gobbos (1997) → Proven release.
  • FIFA Road to World Cup 98 (1997) → Announced but it seems that in the end not included
  • World League Soccer ’98 (1998) → Announced verified.

As usual we are left with a team that represents this point well:

  • SEGA Rally Championship

    Launched on 1995-12-29. I distinctly remember seeing this game launching in Europe around the same time. I arrive at the video game store in my town “Legend”. At that time the PS1 had already conquered many people with Tekken and Ridge Racer. Against the VF1 and Daytona USA 1, they looked worse in comparison. I even remember that Shinobi X and Bug came out! That they raised their spirits a little with Saturn in that early war. Against lost battles of Rayman’s intro and the first Dragon Ball Z, clearly inferior in SS compared to PS1. But Sega Rally when it got on and it looked like the arcade, smooth and with the same graphics (very much alike let’s really be honest at the time). All mouths were closed. And suddenly the Saturn had the momentary lead over PS1.

Sega Rally was an arcade that became classic, at the level of Outrun, just out. SEGA was at that time touched by the hand of God. And this arcade was one of his incredible successes. The Model 2A board was already hitting hard at the time. And well, it doesn’t take long to get to our houses. It developed in less than a year. Considering that the arcade came out on 02-1995. With the luck that at this point the SDKs were already somewhat more mature, not like in the case of Daytona USA.

AM3 led by Tetsuya Mizuguchi achieved a perfect conversion. With licenses of course. The original resolution was 496 x 384 and for SS they maxed out in its 15BPP 352×256 mode. Possibly it could have gone to 640×480 at 8BPP since this game has no lighting with Gouraud. If it has some kind of lighting, which I don’t believe either, it is flat, which can be reproduced in 8BPP with paddles. And that also all your graphic information is 4BPP or 8BPP in color. Anyway. Sega Rally in SS runs at fully stable 30FPS. Giving a sensation equal to the original in everything, movement and physics. Coming to put on screens 900 quads without problem. On the other hand, VDP2 is being used for the UI and for the background of the horizon rotated with RGB0.

This is one of the few games that we know for sure that Qsound is using available via hardware in the SCSP-DSP. Positioned sound and reverberation in tunnels is easy to perceive in-game. And surely it is thanks to this. We see high-sound DSP usage up to 70% of memory. As a curiosity there are three different sound drivers in this game:

– sddrvs.dat: @Driver Ver-1.31 06/95/20 SATURN (S) sampleNao Kas V0.00c

– esddrvs.dat: @Rally 10/18 Nao SATURN (S ) CHECK Nao V0.07 Kas V0.00c

– p2sddrvs.dat: @Driver Ver-1.40 SATURN (S) CHECK Nao V0.07 + 10/18 Kas V0.00c

The use of hardware as it could not be less is outstanding. 2xSH2s are being used, and typical usage signs of SCU-DSP are seen. On the other hand, the use of main memory is 80% LRAM and 70% HRAM. The VRAM of the VDP1 is used in 85% while the VDP2 is in 60% of the VRAM and 60% of the CRAM.

  • NiGHTS into Dreams

    Released on 1996-07-05. I also have the memory of seeing this game recently arrived at the video game store in my town, with the 3D controller, if I remember correctly. Well what I do remember were the owner’s fights to play it (Mari Paz) with her partner of the moment (Fernando). Look, if I remember correctly, at that time the Ristar was hitting hard there too and so Maripaz had a better time.

Anyway, talking about NiGHTS is talking about Yuji Naka’s second attempt to get him to play the lottery as with Sonic. It was close, you have to admit it, but it did not reach Sonic. NiGHTS has personality and charisma. But as a game it does not finish being defined as clearly as Sonic at the time. Technically it is faultless for Saturn and the moment. And at the art level, it is brutal. Capture the childlike essence of dreams. But as a 3D game and for the moment, perhaps the public was expecting a platform in some way. And of course a Sonic. Perhaps all of this added up made NiGHTS a temporary thing. And not memorable. I even have a better memory of Ristar at the time as a pet than NiGHTS. I don’t know, it’s my impression.

NiGHTS is the only game in which I have been able to perceive that it does a load while it is running 3D graphics or processes. A kind of transparent charge, like Crash Bandicoot does before entering the levels or the C: SoN charge between parts of the castle. I don’t know if there are more examples in SS, on PS1 we know some more like the Soul Reaver itself.

NiGHTS is almost at the maximum possible resolution of the VDP1 in 15BPP mode: 352×240. The maximum is the variant pal 352 x 256. Still it is very good. The game runs at fully stable 30FPS at all times. And the maximum amount of on-screen geometry is around 700 quads of which 90% have Gouraud for bake or depth cueing or dynamic lighting. All 3D elements have a Depth cueing function, but 3D elements using Gouraud and billboards using a color palette change.

NiGHTS has Gouraud multi-color and source-source dynamic lighting. Only in the main characters, but it is still extremely spectacular for the moment and the machine. Maybe one of the reasons for the good performance even with lighting is that the NiGHTS engine is using the SGL libraries, possibly the 2.x that already had dynamic lighting,

Transparencies / ECC / LCS-Ins The Sonic Team was not going to stay I cut trying to put the Sega Saturn to the limit. And since they did not go for all with the transparencies. This makes use of all the possibilities that the machine gives. Thus we can find half-Transparency of the VDP1 in some billboard elements.

The transparency capabilities of VDP2 are also used extensively, from transparency by layer in NGB1 over the background. Or even better with the color and ratio calculation feature with elements from VDP1 over VDP2. Here it is used for example for VDP2 RGB0 plane fading effect on enemy phases. Or cool effects like a final enemy that becomes invisible against the total background of the VDP2 giving a portal or disappearing aspect to another dimension. This last effect is achieved using the extended color calculation function, which allows for blends between more layers. They may even have used the Line Color effect inserted in the start menu. But this one is more difficult to detect since no emulator points it out in their debuggers.

Of course the mesh mode of the VDP1 is used extensively in 3D elements and even simulated in the VDP2 in the NBG3 layer for the Nights vortex effect.

The sound in NiGHTS was not neglected. We can see in the driver that the main programmer (A.Miyazawa) takes care of it. Not typical SEGA sound driver authors. It uses CD-DA music, but also MIDI using all the channels of the sound chip in addition to DSP effects. On the other hand, this game is listed as one of the few that Qsound uses, the truth is that it is difficult to perceive during the game. Finally the possibility that you use some sound with ADPCM. Since on the CD we can see .adp files that are ADPCM files from the SS SBL library.

Where I am sure I know that ADPCM is used for the FMV audio stream. NiGHTS is the first, it sounds really good and also this Stereo. On the image side, the compression of the image stream is medium, showing the compression artifacts more than the intro’s great CGI deserves. The resolution is very good 320×200 approximately. Possibly at 15FPS. Since it is not a standard SEGA CPK container. If you can see the version in the header in this case Film 1.08. It is rendered in a VDP2 layer at 24bits of color which does not lose colors. As a final curiosity, add that NiGHTS is one of the few games that is in CD-XA format, with the second track in MODO2 / 2352. And .adp and .cpk tracks cannot be read normally in this CD format. Which also already indicates that it is ADPCM XA secure.

The use of the hardware is superb. Use 2xSH2 for both FMV and 3D. According to a Segaxtreme user using 100% of the SH2 slave at specific times. There are weak signs of SCU-DSP usage, possibly for transfer from Bus-A. We are talking about the LRAM at 95% and the HRAM at 90%. The VRAM of VDP1 at 95% and that of VDP2 at 70%. Finally, the CRAM of the VDP2 is at 75%.

  • Shockwave Assault

    Released on 1996-07-05 as a 3rd wave development by a developer from the USA. Shockwave Assault is still a medium port of an original 3DO title, possibly the best version. After a year it was simultaneously ported for PC / PS1 and finally for SS with half a year of difference with respect to the previous ones and almost two years with respect to the original. At least the advantage was that it came out with the original missions plus the expansion. That in the other versions they were sold separately.

At a resolution of 320×240 at 15BPP like the other versions. Although that color depth is only reached in the VDP2 layers in VDP1 the elements are mostly in 4BPP LUT. The motor uses Gouraud for Depth cueing but not for lighting. Which is present bakeada in the other versions. Also as a curiosity to add that the engine has 3 levels of subdivision or LOD in the field with mip-maps (16×16 / 32×64 / 128×32). It is present in all versions. The game runs at fully stable 30FPS with approximately 400 quads on screen.

The only transparency in this game is the peephole.

On the other hand it is possible that we can have a render-to-texture in the mini FMV and in the radar with map that is seen in the cabin in a layer of the VDP2.

One of the most interesting things about the title is that one of the little ones where the Dolby Surround symbol appears in the game itself. We really don’t know if this is in the audio streams of the dialogues or the cinematics. Or if it really is built into the sound processor DSP. What we do see is the memory usage of the DSP at 35%. Music is mainly CD-DA. Using a fairly old sounding SEGA driver version 1.31 on 06-20-95.

The FMVs of this game are magnificent they are at 320×224 15FPS with a generous bitrate of 1700 kbps, very close to the resolution of PS1 320×240, but of course the PS1 codec is superior in colors and artifacts as usual. The original material already has a very good quality. And the work done with the Cinepak codec is one of the best in the SS catalog, it seems that the PC version shares the same videos. The sound stream also in this Cinepak is excellent, we are talking 22050 Hz at 16 bits and in Stereo. The only downside is that these are rendered on the VDP1 losing the codec’s final color quality. The codec used for the small mission start clips is unknown, although it has very good color and compression quality.

The use of the hardware is correct. Using 2xSH2 for FMV and 3D. With typical signs of SCU-DSP use (25% memory and 26% registers). On the part of the reports, the use of the main ones is at 75% of LRAM and 90% of HRAM. 90% of the VRAM of VDP1. And 20% of the VRAM of the VDP2 and 65% of the CRAM.

7.1 The difficult thing to “see” – EXTRA I Ball: ADPCM and CD-ROM XA

I was finishing, but almost finishing my investigation, I have come across one last interesting “feature” in this particular war: PSX vs SS. Audio compression for FX or Music sounds during gameplay. As we already know the main difference between the PSX and SS sound hardware, is that the first one decompresses and reproduces ADPCM by hardware. While SS PCM.

This topic is even more curious because the rest of the competition, CDi and 3DO, could unzip ADPCM by hardware. In the case of 3DO through the DSP I have seen in its SDK that it was fully supported. On CD-i just like PSX or SNES, completely native. The Jaguar also had a fully programmable DSP, but it doesn’t seem like it gets to the 3DO, nor have I seen any traces of implementation in its SDK.

As a curiosity I have been able to see how years ago in Arcades multiple systems already used ADPCM in some type of quality, not close to CD but acceptable. The earliest of SEGA itself on System16 in 1985. Taito followed SEGA in 1988 with his Taito B badge. The next that I have seen earlier was Microprose in 1990. Highlighting the case of SNK in his famous MVS also in 1990 And later Konami or Data East in 1991. It is curious that SEGA did not have a hardware ADPCM system, although it was partially like its System16 sister.

The advantages of using ADPCM are several. Less space, up to 4 times less, quality practically identical to a PCM. Few resources to decompress. It could be accessed on the fly and stream from the CD. Looping faster and cleaner than CDDA, the latter is still a raw PCM or AIFF. To be able to store more sound on CD-ROM or RAM. To be able to have music or long sounds with low space and high quality. Disadvantages had. It was still a proprietary technology, it seems not very expensive. But few more.

As we can see, again Sony did better in this regard. But it didn’t take SEGA (middle) to fix this situation. Offering from almost the launch (late pre-launch) of the console on its SBLs (from 1994-10-14 before a CSK / CRI development since 1991) first and shortly thereafter also on SGLs, the power unzip an ADPCM or CD-XA stream using CPU unzipping and simple libraries for programmers. All this means, that again, it couldn’t be leveraged for launch during pre-launch development, and first wave of games. This has already left for the second wave, delaying its use, knowledge and customer perception in games. While on PSX he was also from start and pre-launch.

With which CPU or how many ADPCM unzipped with the SBL library? Most certainly with any of the two SH2. In the documentation it is not clear. If you talk about a cost of between 4% to 33% of process for qualities between 11 kHz mono to 44 kHz Stereo.

Comparing the ability to read the flight on the CD-ROM with PS1. PS1 can with up to 8 ADPCM streams (Stereo = 16 mono streams) to 2x hardware CD-ROM. SS on the contrary only 1 ADPCM steam (Stereo = 2 mono streams) to 2x CD-ROM. By hardware it can with up to 2 PCM streams (Stereo = 4 mono streams) to 2x CD-ROM. In the latter it makes sense against PS1 because ADPCM against PCM is 4 times less. Therefore, with the same CD-ROM bandwidth, the SS has a 4 times higher limit when reading PCM.

Someone could say because if reading ADPCM which is 4 times less data, it can only play 1 stream. And the explanation is that SS has to read the ADPCM, save it in memory, and then unzip it via CPU, the PCM results store it in sound memory and reproduce it. Doubling or tripling, if not more, the process with respect to PS1. I suppose that the implementation of the SBL library achieved this result with sufficient robustness and performance guarantee for the moment. Although theoretically, from my point of view, the SS could decompress and reproduce, at least 3 mono streams in ADPCM. More, reading the CD-ROM on the fly I find it complicated. In memory perhaps it could with some more, if they are small files, maximum 4 or 5.

Everything exposed and theorized numerically depends both for PS1 and SS, on the quality of the streams. A stream at 8000hz is not the same as one at 44100hz. The normal was between 11025 Hz and 22050 Hz. Also the standards at 18900 Hz CD-XA Mode C and 37800 Hz CD-XA Mode B. With a standard bit depth of 4bit, which is equivalent to 16 bit real.

On the other hand, Duck’s ADPCM implementation had two qualities. The 4-bit standard and a 3-bit standard that further lowered the kbps for equivalent qualities. We really don’t know how much processing the decompression was taking for the SS. It should be very little, since we found FMV with Duck’s ADPCM using only an SH2 for video and audio.

Already in 1997-98 with the help of CSK / CRI, which already took care of ADPCM in the SBL and SGL library. ADX development, which is an ADPCM, but highly optimized and with better features. ADPCM support for SS software has reached its maximum. We don’t know if it gave the ability to unzip multiple sound files at once from RAM, which would put the balance even more in balance with the PSX. What it seemed to be doing is unzipping up 3 stream on the fly(one of them including data, that is, loading a level while reading another one of stereo music for example) reading from the CD, being able to read several tracks within the same file and make loops without noise, typical of CD- Audio. Minimizing the use of the CPU (about 1%) and the memory for its reproduction. More than enough the truth. Using, I am almost sure, the SCU-DSP for decompression as I have been able to perceive in games that use ADX for streaming or FMV like: Burning Rangers or Lunar 2. Or at least for data transfer between buses.Lastly, it should be noted that the third parties also developed their own file formats and ADPCM “like” decompressors, for sounds or music for SS. Cases like EA, Probe, SNK … maybe some more, but they are the only ones that I have been able to see with clear data. The funny thing about the case is that they were possibly the first SS titles to use ADPCM, both (Alien Trilogy and Road Rash) in mid-1996, a little over a year and a half after the release of SS. The first First party game with ADPCM was NiGHTS on the same date 07-1996. There may be a previous one, but I could not see it.

Was this disadvantage finally resolved?

YES and NO. As we say, YES because SEGA in its basic SDKs (SBL) provided a library to decompress ADPCM and CD-XA, even a stream. Later using the CRI SDK even better, but it is possible that it would be another case of paying more in order to have this feature. The latter I do not know for sure.

Also as we have said, it is seen in many 3rd party games as there is use of ADPCM or XA. I suppose to facilitate the ports or developments between PSX and SS.

AND NO, because we are not aware of CRI ADX, it gave the possibility to reproduce several sounds in the SoundRAM at the same time, and because the decompression is not supported by hardware. Or at least I have no record or I do not know I get to use the SCU-DSP or the same M68x in some effective way in parallel.

Ideally, from my point of view, SH1 in the CD-Rom block on bus A would be the ideal candidate to decompress the ADPCM and send it to the SCSP. Due to its power, dedicated memory and access to CD-Rom reading in the first instance. But the difficulty in using it was enormous because the ROM that controlled it would have to be overwritten first and only doing this was titanium, impossible not but extremely complicated.

What has become clear and practically certain to me is the use of the SCU-DSP by the CRI ADX decompressor, but this is still my assumption when seeing the use of it in many games with ADX such as Burning Rangers.

Another question that remains on this path for me is. If in any audio with ADPCM in SS I get to apply the Filter “Low Pass / High or Pass / Band Pas”, which also had the SCSP-DSP through its modules such as Echo or Reverb. Like the PSX. This filter, “Low or High Pass” was very useful with the ADPCM waves to clean them and get the most of their quality. If they couldn’t hear the sound quite metallic. Although I am almost sure, because I have detected in many videos or games that use ADPCM code in the SCSP-DSP. And to finish with SCSP-DSP, I am left in doubt as to whether it would be possible to use it to decompress ADPCM + Low Filter inside this unit, similar to the DSP of the 3DO. Even if it was a part of the ADPCM.

To finish comment that both Probe (Alien Trilogy) and SNK (Metal Slug) make use of ADPCM in FX sounds.

What we can see in these two cases is that the synchronization is not entirely perfect with delays when starting or ending a sound. It may be a bug with fix, or it is not the best option to use ADPCM for FX. And I know better option to reserve it for long Speech, short voices or ambient music / sound.

I could not go without talking, even if only briefly, about the sound drivers for the SCSP. We can see that the vast majority of all developers used SEGA drivers. Many interestingly early or very outdated versions, even of the first development kits. However, the first parties of course went almost with the most current. And the second parties also with newer drivers. More towards the end and the big companies use the best versions and some companies even have their own driver, or perhaps a customized one. As is the case with Game Arts, Capcom or some internal SEGA studios such as Red and AM2. I expose a small list with theversions official SEGA driver and years that I have seen, they may be missing:

Year D / M   Ver.  New
1994 10/13 1.14 * ADPCM SBL
1.24
1.25
1.27
1.28
1.29
1.30
1995 06/20 1.31 3D Sound
1.33
2.00
1996 01/25 2.04
2.08
2.09
2.08
2.09
07/02 2.10
1997 07/08 2.20 * ADX

I have come to detect the use of ADPCM during the game, not FMV, in 11.2% of the total number of games analyzed. Perhaps few, but many more than the truth expected.

Here is the list of what I found:

Possible ADPCM games:

  • Gex (1995-12-18)
  • Gundam Side Story 3 Kidou Senshi Gundam Gaiden III: Sabakareshi Mono (1997-03)
  • Rockman X4 (Mega Man X4) (1997-08)

Nearly confirmed

ADPCM games: SBL:IMA ADPCM

  • Magic Knight Rayearth (.ADP)(1995-08-25) → ConfirmedDialogues
  • Neon Genesis Evangelion: 1st Impression (1996-03-01) ← Confirmed CD-XA MODE2 / 2336
  • Kuusou Kagaku Sekai Gulliver Boy (adpcm.dat) (1996-03-22) ← Dialogues
  • NiGHTS into Dreams (.ADP) (1996-07-05) → CD-XA MODE2 / 2352
  • Sega WorldWide Soccer 97 / Victory Goal ’96 (1996- 11) ← Confirmed CD-XA MODE2 / 2336
  • Samurai Shodown RPG (1997-06-27) ← Confirmed XA Multistream
  • Sonic Jam (.ADP) (1997-06-20) ← Confirmed
  • Shinsetsu Samurai Spirits Bushidou Retsuden (1997-06-27 ) ← Confirmed ADPCM XA Multi-stream voices
  • Ten Pin Alley (.ADP) (1997-11-15) → Confirmed
  • Kidou Senkan Nadesico – Yappari Saigo wa Ai ga Katsu (.ADP) (1997) ← Confirmed
  • Super Robot Taisen F (. XA) (1997-09-25) ← Confirmed CD-XA MODE2 / 2352
  • Neon Genesis Evangelion 2nd Impression (.ADP) (1997) ← Confirmed CD-XA MODE2 / 2336
  • SEGAta Sanshirou Shinkenyugi (.XA) (1998) ← Confirmed
  • Sega Ages – Phantasy Star Collection (.ADP) (1998) ← Confirmed. Music. Fx possible.
  • Sega Ages – I Love Mickey Mouse – Fushigi no Oshiro Daibouken & I Love Donald Duck – Georgia Ou no Hihou (.ADP) (1998) ← Confirmed. Music. Fx possible.
  • Marvel Super Heroes vs. Street Fighter (1998-10-22) (.ADP) ← Confirmed

EA ADPCM:

  • Road Rash (1996-07-26) ← Confirmed. Music.
  • Andretti Racing (.ADP) (1996-12-20) ← Confirmed. Speechs.
  • Soviet Strike (eng_xa.res) (1997-02-17)97/98
  • Crusader: No Remorse
  • FIFA(1997) ← Confirmed. .STR
    • 22Khz Mono Electronic Arts EA-XA 4-bit ADPCM v1 (mono / interleave) 94 kbps
  • NBA 97/98 (1997)
  • Madden)
  • Nascar 98 (1997)

OKI ADPCM

  • Akumajo Dracula X: Gekka no Yasokyoku (aka: Castlevania: Symphony of the Night) (1998-06)
  • Genso Suikoden (1998-09)

ADPCM Unknown:

  • Metal Slug (ADPCM.BIN) (1997-04-04) ← FXs almost certainly. CD-DA music?
  • Croc: Legend of the Gobbos (.XA) (1997-09-17) ← ADPCM Argonaut?

Confirmed ADPCM games:

ADPCM for FX Sounds from Virtually Unreal for Probe.

  • Alien Trilogy (1996-07-04) ← FX almost certainly.
  • Die Hard Trilogy (1997-02-28) ← FX almost certainly.
  • Hexen (1997-03-31) ← Not confirmed

CRI ADPCM ADX:

  • Deep Fear (1997)
  • Grandia (1997) → use of SCU-DSP
  • Burning Rangers (1998) ← Dialogues and music. → use of SCU-DSP
  • Baroque (1998)
  • Wachenröder (1998)
  • Code R (1998-07-09)
  • Lunar 2 – Eternal Blue (1998) ← Dialogues and music → use of SCU-DSP
  • Device Reign (1999)

IMA ADPCM Standard:

  • Street Fighter Zero 3 (1999) ← Music. FX?

Duck Audio ADPCM:

  • Most games with Duck codec for FMV in their audio stream.

Finally, as we have been doing throughout this journey, let’s keep a last trio of chosen to exemplify this point with a few good games that used it in SS:

  • FIFA 98

    Development of the end of the 4th wave. Posted on 1997-12-17. We can see how the third partys already had a remarkable control of the machine, in this case Climax in charge of this port.

In this FIFA, the problem as in other ports is not how the machine is used, because it is doing very well. If not the level of finish and polish end of the game. Being a port of the PC and PSX versions, which was also subcontracted to another external team, it caused that as in FIFA 97, this FIFA 98 did not do justice to the machine, nor to the large sum of work in each of its sections made by the external team. Less time for full development. No time to redo parts to run correctly on a different system like SS. Perhaps starting later and with the project data overdue. But with a similar or very close release date. All this can be seen in small details or total loss of great features that were in PC / PSX, and that SS could have had without any technical problem, such as: Meteorology (implemented at the selection level, but not visually), final adjustments in animations and menus, proportions of 3D assets, camera positions and visibility, Dolby sound (announced but not the final game), ground with horizon gradient (totally possible with the VDP2 and seen in WWS for example) and taking Some magnificent FMVs (of the best in the system) have scaled them to full screen (totally possible through the VDP2 zoom).

However, as we say Climax shows that he knew the machine and in FIFA we can find how they take advantage of all the available processors according to the situation. For FMVs as usual with EA codecs, in this FIFA with a video at somewhat less than apparent resolution, but equal quality. Apparent because it is still at the top of the codec in SS 304×144, but when reproduced in 352×256 SS mode it seems even smaller. Using the 2xSH2 + SCU-DSP combo, the latter using 70% memory and 39% registration of the SCU-DSP. Possibly I know this using the SCSP DSP for some kind of sound filter. Which in the video is most likely PCM.

Already in the 3D engine part, in this FIFA, we did not find use of clear SCU-DSP, there is a program in memory but SSF does not indicate that I am using it. 2xSH2 is used for 3D. Perhaps the SCU-DSP is being used for the decompression of comments or ambient sound, which are almost certainly in EA’s proprietary ADPCM format. But this is an assumption of mine today. We keep finding signs of SCSP-DSP usage in the 3D engine, possibly for the same sound filters. Because I miss or reverb I could not clearly perceive it. Also curiously this game was advertised on its cover as Dolby Surround, but afterwards there is no trace of it within the game.

Detail that LOD models are used for players and shadows, helping the game run between 20 / 25FPS on open fields. I have not been able to quantify the number of polygons in this FIFA, but we could say that it will be between 1,000 and 1,200 minimum quads (maybe more), if we count the RGB0 equivalents, it would be about 768 more. This game could be over 2000 quads. On PSX I have seen maximum figures of 6,000 triangles, about 3,000 equivalent quads.

On the covered fields during normal play it also stays at 20 / 25FPS, however in replays the FPS drops to around 12FPS when the Crystals are in the foreground with the VDP1 half-Transparencies filling the entire screen or even with others elements that are overlapping behind.

As a curious note, distant Crystals only have Gouraud. The closer they are, these pass to Gouraud Shading / Gouraud Shading + Half-transparent. Climax looked for a way to minimize the burden of this effect.

Yes, FIFA 98 uses VDP1 transparencies a lot, and quite well. We have a use of transparency VDP1 in the pause UI and TV signs without artifacts as they are orthogonal rectangles but without working against the elements that are in VDP2. Like the field on RBG0, the shadows of the players, and some parts of the field lines. These last two features using transparency from VDP1 to VDP2.

As a curious fact in this game the developers use the transparency of VDP1 to VDP2 with the shadows in a very original way. Shadows are Quads with Gouraud, and the gradient values ​​resulting from Gouraud himself are then used with the VDP2 color and ratio calculation values.

The use of memories in this game is remarkable. Reaching 70% of main RAM, 95% of VDP1 and 60% of VDP2.

The menus are in high resolution HD 704×256, although the VDP2 backgrounds are 512×256. You haven’t taken full advantage of the VDP2 for the menus. I even have my doubts, if they could have used VDP2 transparencies instead of the mesh.

As a final curiosity to point out the use of VDP2 bitmap at 1024×256 in the startup licenses. I have rarely seen that mode used. Although it seems that the image is not at that resolution really, or it has not adjusted well at least.

  • Deep Fear

    Released 1998-07-16 This is already a 5th wave game. Last year practically in Europe and the USA. In Japan there was still up to three more years of life, of technical development perhaps less 1 or 2 maximum.

Deep Fear is the Resident Evil 2 that didn’t make it to SS. Or so I saw it at the time. Technically it is very far from the Capcom saga. But SEGA produced an exclusive product of remarkable production quality (dubbing would not fall into this XD category), not perhaps also in technical quality, but well something is something.

Running at a resolution of 320×256 15BPP although the graphic data is at 4BPP on VDP1 and 8BPP on VDP2. at stable 30FPS. With remarkably modeled and textured models. With somewhat robotic animations. I have come to see about 700 quads on the screen, maybe more. VDP2 is used for backgrounds, UI, and inventory.

The game has Gouraud font lighting with color on all 3D characters and entities. Dynamics when there are shots. And there are not many light sets during the game either.

It is strange that this game does not use absolutely not a single possibility of transparency of the machine. Weirder even though for example in the shadow of the characters it would have been totally possible as in Resident Evil, as well as very easy with the color calculation function plus ratios with elements of the VDP1 over the VDP2, the backgrounds mainly. The only “transparency” effect that we can see is the change of color offset for the alarm, underwater or gas effect. For the rest a pity, a type of game that gives to show off these

The sound, saving the dubbing is very good. Using ADX for music and dialogue at excellent quality. I think also some bigger sounds like doors. Showing very high signs of DSP usage over 90%. With almost total security to echo and reverberate the stages. The sound driver used is version 2.01 of April 1997.

The FMVs in this title are very numerous. The quality of them is remarkable. And the perfect Duck codec choice. It is used in its 16BPP mode, but frankly it is perfectly compressed, the dithering is almost negligible and the artifacts practically non-existent. The image and sound quality used is a perfect agreement to be able to put all the immense quantity of video in a single CD. At 320×176 at 15FPS with a framerate of 1200Kbps plus the audio stream with the Duck ADPCM 4bit codec at 22050 Hz Stereo. Rendered on VDP1 all CGI work looks great on the SS.

The use of hardware at these heights of life of the machine is very high. The two 2xSH2s are being used for both FMVs and 3D. There are strong signs of SCU-DSP usage, in this case up to 60% memory and 18% registers, possibly for ADX audio. On the part of memory, 55% of the LRAM and 75% of the HRAM are used. Up to 65% of the VRAM of the VDP1. And 45% of the VRAM and 45% of the CRAM of the VDP2.

  • Street Fighter Zero 3

    Released 1999-08-06. It is already one of the last titles developed for the system. You could count it as a game of the 6th wave of developments of a Japanese team and in this case of a great Third party… of a great saga. And of a game that cannot run on a better system than the SS.

SFZ3 has been ported before on PS1, almost a year earlier. But the SS version used the 4MB expansion cartridge, which already has more RAM, and got a version almost identical to the arcade and superior to the PS1. Both in number of graphics and load times.

The resolution is 352×224 at 15BPP although the original content is at 4BPP over the 24bit CRAM of the VDP2, the original is at 384×224 this resolution is not supported by SS. So they chose the maximum and closest to the original. PS1 however is at 368×224 in between the two. PS1 anyway supports the resolution of the original arcade, possibly to save memory they decided to lower it somewhat. The game runs at 60FPS perfectly. No more than 400 quads are seen on the screen.

This game does not have transparency in its original version. If so in its PS1 version. In SS there is some transparency in the initial menus, but the rest of the game uses mesh mode for transparencies like in the arcade.

The sound look like any Capcom title and even more so in an SF it is awesome. We also found that they are using IMA ADPCM Standard. I really don’t know if it’s the SBL implementation or some kind of license Capcom acquired. What I can say is that the sound quality is brutal. I also do not know if I also use it for FX, possibly for voices almost certainly. The driver does appear to be the SEGA official. One of the latest versions I have seen 2.2.0 July 1997. We can also see incredible MIDI music usage in the menus. Finally we can see a DSP memory usage of up to 35%. We can also perceive a reverb or echo effect during the game, you may be using the DSP for it.

The only FMV in this game is the Capcom logo at the start. A mythical animation. Cinepak + PCM quality is perfect: 320×224 30FPS plus PCM 44100Hz 8bits Stereo on the VDP2.

The use of hardware is brutal. Of course 2xSH2 is used for both FMV and 2D play. The main RAM is 60% LRAM and 75% HIRAM. The VRAM of VDP1 at 95% and the VRAM of VDP2 at 95% and the CRAM at 95%. Of course occupying the expansion cartridge.

9. The difficult thing to “load”: Loads the game without stopping

In the final section of this investigation. And with the shadow of the always Castlevania SotN, I decided to look at this feature. Later on seeing an interview to the main developer of Crash Bandicoot for PS1 and a video of Digital Foundry about Soul Reaver, I thought again about the subject and tried to investigate. Later also by @zyrobs comment in one of the posts.

I also remember that @XL2 was dealing with SEGA’s official load/CD library for SS. And although at first it did not get good results. He managed to load at full system speed in the end. Level loads in your game are very fast. And he fills up a lot of RAM in various wells.

In conclusion we could say that the SEGA library was fast, but perhaps better documentation, examples and of course access to the source code are missing.

Was this disadvantage finally resolved?

In this case as in another in SS. Sadly not. Despite having a fairly competent but closed library for CD loading. The most daring developers did not have it easy, to be able to use it together with the ADPCM decompression or upload or download of graphic data.

Perhaps this is why we find Castlevania’s infamous case of cargo aisles that are not. XD

But like everything in SS again, it was possible. Even more here. SS had a super powerful CD-Rom block. Without having hardware ADPCM capability. It had a powerful processor and memory where no other system had. In fact in many games where the loads are “normal” the SS does it much faster. Even loading even more data than on other systems.

There is another area to explore for the homebrew and the scene.

I really do not know games that have dynamic loading in SS in a totally safe way, here is a possible list:

  • NiGHTS into Dreams.
  • Grandia, possibly.
  • According to @zyrobs Scorcher, he charges on the fly during the race. I am not so clear the truth.

However at least the following are known on PSX with complete certainty:

  • Soul reaver
  • Crash Bandicoot
  • Castlevania: Symphony of the Nights
  • Most likely more.

Conclusions:

The clearest. SS and PSX were (or are, depending on how you look at it) two extremely similar machines at the end of the day. Both in the final and / or real figures. As in the way of doing things. Other consoles from that time also shared ways of doing things as we have seen.

In this way, I have been able to break many myths on both sides. And now more than ever, I appreciate all the work of the people behind the companies that brought about this historic moment.

I would like to point out that it is not a matter of lamenting anything, but of solving doubts, or trying to find out where the SS did not arrive, could or could arrive.

As we see after all this research. SS was a great machine. Domestic SEGA engineers literally did everything they could and knew. SEGA was SEGA again and gave it their all. In ambition there was no one like them, perhaps even today but much less.

What I am clear about is that the product of what they did, even today. It has both a unique look and sound. There is no console that looks and sounds like the SS. With its pros and cons. Coupled with the absurd complexity within it. I think it is the perfect machine for mischievous and curious minds. And for an almost infinite homebrew.

Otherwise, it is a console that I recommend, of course, to anyone. With unique titles, a lot of originality and fun to offer. With 2D games and very good conversions. In addition to exclusive and of course great 3D games.

Also from here to thank the community for their support, there are many more, here is a list:

And recommend participating and supporting emulation projects like:

Thank the current and historical developers. I would like to signalize, Thanks to this commit, I have been able to see the “polygons” on the screen of the games.

Thanks to Yaba Sanshiro I have been able to determine the FPS of many games.

In its latest versions it is easy to see the use of the configured CRAM color mode, the use of the gradation function and LCS Insertion. And also with the wireframe mode the tessellation or subdivision or LOD.

Or open source SDKs, there may be more, here is a list:

Epilogue:

  • I am going to pause this personal project. I will do there any updates and corrections that I already have prepared. Especially in the first part and second part. But I don’t know when exactly.
  • I will now dedicate myself to making 3D and 2D art for the SS homebrew community. And another great project;) that I have quite developed.
  • I have thought about the possibility of making a book of all this. Several people have asked me directly. If there are more interested people leave me a comment in the post or send me a message through the form. Right now I have almost 230 pages in the master document. And hundreds of images in my archive. By laying out and adding some of the tables that are online, there could be a nice book with a minimum of 400 pages, about 500 calculations. Of course the idea would be to edit it in Spanish and English. I would look for a professional translator for it. But for now let’s see the interest you have and I’ll be seeing.
  • There have been games to analyze more deeply or pending games in its entirety or a large part: About 90 of the 324 totals. It’s something that doesn’t really concern me. If someone wants to help, all they have to do is request access to the online table and edit it. If I see something very interesting, I may update it. In principle in the short term I do not think.
  • There are still things to discover. Thanks to the emulation with their debuggers, this possibility of getting where I don’t know once did is a reality. And now with the retro SS scene so alive it’s even more likely.
  • I have questions to notable developers in SS. I have a list of programmers, technicians and artists. With specific doubts. Who knows … From
  • My point of view there is still room to reach and break technical milestones. Also I see them as goals that homebrew can set and break, because SS has this capacity. Given its complexity and power in many of its parts. I will make a list under my humble vision:
    • Best BR trick: resolution and clipping.
      • It is true that XL2 has already passed it. But as more challenges I see:
        • Raise the resolution, not to the maximum but something more.
        • Improve the clipping and overlapping of opaque and transparent parts.
      • Of course:
        • Document it
        • Create a robust library: That allows the maximum of transparencies in the system combining everything.
        • Create examples for 2D and 3D games.
    • Max. Polygons and lighting
      • Again XL2 has set the bar here already very high. But he himself says that something more can be done.
      • Honestly, what I think is necessary is to have some open libraries that standardize the use of this part in SS. At the homebrew level. And to be able to combine all the processors in the best possible way within a standard pipeline. For example, like the PS1 GTE, which had well-designed and specific macros. Have something similar for the use of the SCU-DSP or SH2 as DSP.
    • Max. Resolution BPP FPS
      • I am a little stubborn I know. Some when you read it, you will say: You can’t! But to be able to have 512×256 in 16bit mode on VDP1. Any hardware trick or secret registry? Some like the ones that the great Charles MacDonald discovered.
    • Dynamic Skeleton Animations
      • These types of animations are expensive for these systems. They were seen in many AAA games. Like EA sports. Fighting games used it. But a fast open bookstore I have not seen. I think it would be useful for the homebrew community. In the last titles of PS1 it was seen in many 3rd person or even 1st use this type of animation so spectacular.
    • Render-to-texture
      • A big challenge:
        • Make a library to be able to use it with both VDP1 and both VDP2.
        • Getting effects of:
          • Giant TV.
          • “Full-screen effects”: Fades, distortions, pseudo-motion blur …
          • “Refractive effect” like the ninja of Metal Gear Solid 1 on PS1.
          • “Environment mapping” as crystal in Tomb Raider 1 or other assets in TR2 on PS1.
          • “Shadow mapping” like Crash 3 and Tony Hawk’s Pro Skater on PS1.
    • FMV DCT
      • Well, here are three challenges:
        • Getting Cinepak + ADK and having an open source player. To be able to replace in game translations or new games.
        • Get to make a codec and player for Duck Truemotion 1 for SS. Since the codecs that are public are limited without 24BPP mode, for example. To be able to replace in game translations or new games.
        • Get to make a DCT-based codec like EA or Softdec optimal for SS. And try to achieve the MDEC quality of PS1.
    • Sound
      • ADPCM +FX in SoundRAM
        • ADPCM in general: Getting make a codec and optimal open source player like ADX, maximum 3 streams and data loading. That use the available processors to unzip. To be able to use it in new games.
        • Being able to have FX in ADPCM on the SoundRAM like the PS1 to be able to have more sound and more quality on the SoundRAM. It seems that in time some developer did something.
      • Chorus / Reverb easy
        • Being able to use the chorus / reverb DSP effects easily for scene developers.
    • Dynamic CD loading of data during game play
      • Open source and optimized for CD use in the system taking advantage of its enormous capabilities.
    • I’m sure he will leave me more things. But there is still my current vision today.

References:

(Not everything, I will try to complete it)

 

Blogs:

https://news.ycombinator.com/item?id=10963796

Games database:

http://SEGAretro.org/

http://psxdatacenter.com/

Online documentation:

SEGAxtreme

antime.kapsi.fi

SEGAretro

Exodus emulator hop the Japanese online documentation

Forums:

Anandtech:

Exophase at AnandtechForums

SEGA-16:

http://www.SEGA-16.com/forum/showthread.php?26920-Games-with-3D-graphics-running-at-60-fps-5th -Generation-Consoles

Youtube:

SEGA Saturn Graphic In-depth Investigations (English / French subtitled)

https://www.youtube.com/watch?v=f_OchOV_WDg

SEGA Saturn Video Formats (English / French subtitled)

https://www.youtube.com/ watch? v = ev7x8MwLq2A [

Glossary:

(to finish, not important now)

* LOD: Level Of Detail. Create several models of different detail, number of polys, for a specific model. To replace depending on the distance to the camera. This effect is perfectly visible in FIFA 98.

 

End, finally XD

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

Very, very, long entry warning. In this post I have used a lot of information, complex and in some ways imprecise. It is possible that I have made errors of interpretation or understanding. I will try to correct everything that arises.

In this spreadsheet you have the data that I have collected from 323 games. Of the approx. 1200 titles in total. Which are 20% approx. of the total.

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 color lighting
  3. The complicated thing I: Smoothness 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 II ball: SD / HD screen resolution
    3.3 The complicated I – EXTRA III ball: Tessellation / LOD scenario / Mip Mapping
  4. The complicated II: FMV screen complete and quality color
    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

5.1 The most complicated thing – EXTRA I Ball: Transparencies + Gouraud =” Table FOG “/ Depth Cueing

As already we have spoken before combining transparency with Gouraud gave rise to very interesting and spectacular effects. But undoubtedly one of the most striking was this: Table FOG “/ Depth Cueing

On PSX we can read as possible effect or even see games with effects of” Table FOG “. It was not actually a feature as such on the machine. to be able to calculate half-Transparencies very efficiently (in various modes and layers) and to be able to do Gouraud shading, like SS It combined both effects on the unique Frame buffer of the PSX, to achieve a practically the same “Table FOG”. Accessible by the developers through a function called “Depth Cueing” used by the GTE.

In the SS, which is what interests us, was it possible? The answer is YES. Finally, already in version 3.0 of the SEGA SGL, it was included a function in the same way as PSX. Calling even the same.

It was done in a similar way. As in everything in SS, using the VDP1 or VDP2 or adding both. There is some game that does it very well. In the case of the Saturn, it lacks single frame buffer, and its mode constraints s transparency. The effect is not as spectacular as that of PSX, but in essence, again, it’s the same. It worked as follows:

The farthest polygons were taking on a color similar to a horizon or background color. And when they approached the clipping of the horizon (popping area or generation of the stage), they faded with a fog color (usually black or white) with a transparency of the VDP1 or using the mesh mode. Or in the best of cases using the half-Transparency VDP1> VDP2, seen in Sonic R. The sum of gradient color similar to the background plus the use of transparency or mesh, gave the sensation of being lost in the horizon as if was fog.

A small improvement from the previous one, was in addition to giving a gradient color depending on the distance to the horizon. Add gradient on the polygon with Gouraud shading, thus softening the color in transition even more to the background. If we add to this the transparency of the Gouraud values, the fading is total. Here again we find that the SS did, with its limitations. And that PSX achieved it with better final quality.

Of course, the fades with the SS transparency, which is not at the triangle level, and which in the case of the VDP1 generated calculation errors, did not show a perfect final finish. If they used the mesh, better in one way (performance) worse in another (aesthetic). But essentially on PSX the same was done. In the best case in SS, adding to the use of VDP1, the transparency of VDP2 is finally used, which is the case of Sonic R, the effect is clean and also with gradual transparency when using the possibility of up to 8 simultaneous the 32 alpha levels of this chip. The effect is very smooth, the best. The question remains whether it was possible to use the “as is” mode to get the levels to the maximum, 32 possible. Using the Gouraud in the VDP1 so that later with the VDP2 mixture it interprets these brightness levels as transparency levels thanks to the additive mixture.

Other games only used the color gradient up to the final color of the horizon. And there they stopped drawing the polygon. It is a simpler and less spectacular effect. But less expensive for the machine. On PSX it was also used in the same way. If the background is very dark or with a flat color, without texture. The use of half-Transparency could be eliminated, since it did not contribute anything and it is an expensive process.

We also have the case of using a VDP2 Screen, normally an RGB, a horizon gradient, using the option Line Color Screen Insertion to simulate this effect. Which could define what Screen or Screens would affect. The effect is limited and very flat. But at the pixel level, per line. And it can be used in conjunction with the Color Calculation Function to make transparency on multiple layers. Being able to add this to another normal VDP2 layer transparency (CC VDP1 included and its variants).

Finally there are also cases that use an even flatter and simpler effect using the VDP2. What is to use a Screen with transparency superior to the background. It appears in games where the camera does not rotate on its normal axis or where the fog is far away or in the “3D” background. I’ve only seen it in a few games.

In the end it is about concealing the “popping” in the best possible way. Today, it is still used, much less … but the generation of geometry is not infinite in any system.

Was this disadvantage finally resolved?

We could say YES. Although, in the absence of easy implementation from the start, there was no unified approach. Resulting in disparate results.

I have come to see it in 37% of the total number of games analyzed. Most of them with VDP1 only 50%. Some with the VDP1 + VDP2 reaching 45%. And also only using the VDP2 in some of its forms by 5%.

Now let’s move on to a list by type and chronological date:

3D effect games using VDP1:

  • 1994
    • Gale Racer
  • 1995
    • Panzer Dragoon → Palette change and LOD.
    • Robotics: Cybernation Revolt
    • Bug!
    • Off World Interceptor Extreme
    • Touge King – The Spirits / High Velocity: Mountain Racing Challenge
    • Dragon Ball Z: Shin Butōden
    • Hi-Octane
    • Black Fire
    • Devil Summoner: Shin Megami Tensei
  • 1996
    • GunGriffon
    • Panzer Dragoon II Zwei
    • Magic Carpet
    • Shellshock
    • Lifescape – Seimei 40 Okunen Haruka na Tabi Disc 1
    • Lifescape – Seimei 40 Okunen Haruka na Tabi Disc 2
    • Dragon Ball Z: Idainaru Dragon Ball Densetsu
    • Starfighter 3000 (Star Fighter)
    • Alien Trilogy
    • NiGHTS into Dreams
    • Shockwave Assault
    • Blam Machinehead
    • Dark Savior
    • Exhumed (E) / Powerslave (U)
    • Space Hulk: Vengeance of the Blood Angels
    • Tunnel-B1
    • Tomb Raider
    • Street Racer (Extra)
    • Hardcore 4×4
    • Bug too!
    • Black Dawn
    • Shining the Holy Ark
  • 1997
    • Die Hard Trilogy
    • Scorcher
    • Crypt Killer
    • Gundam Side Story 3 Kidou Senshi Gundam Gaiden III: Sabakareshi Mono
    • Independence Day
    • Doom
    • Touge King the Spirits 2
    • Krazy Ivan
    • Sonic Jam → World 3D Area
    • Zero4 Champ Doozy J Type-R
    • Bulk Slash
    • Lifescape 2 – Body Bionics – Kyoui not Shouuchuu Jintai
    • Söldnerschild / Soldnerschild
    • NBA Action 98
    • Steep Slope Sliders
    • Duke Nukem 3D
    • Devil Summoner: Soul Hackers
    • Sonic R
    • Quake
    • Courier Crisis
  • 1998
    • Only Crisis
    • Panzer Dragoon Saga
    • Stellar Assault SS
    • GunGriffon II → Gouraud 3D objects
    • Baroque
    • Akumajo Dracula X: Gekka no Yasokyoku (aka: Castlevania: Symphony of the Night)
    • Code R

Games with 3D effect using VDP1 + VDP2:

  • 1996
    • GunGriffon (1996-03) → Flat polygons with transparency in VDP2?
    • NiGHTS into Dreams (1996-07-05) → VDP1> VDP2 cc + ratio 8x Polygon flat degrade horizon over RGB0
    • Street Racer Extra (1996-11) → Depth cueing with transparency VDP1 + VDP2 in near clipping.
  • 1997
    • Doom (1997-03-26) → Depth cueing VDP1 + VDP2.
    • Bulk Slash (1997-07-11) → Only in some levels on the VDP2 layers like Sonic-R. In the rest possibly against the Back Buffer.
    • Sonic R (1997-11) → in the last circuit, which is transparent integer. Does it have fewer levels of gradient in the fade or does it not?
  • 1998
    • GunGriffon II (1998-04) → Flat polygons with transparency in VDP2

Games with effect in 2D / 3D using VDP2: Line Color Screen Insertion (Hard to detect, approximate list):

  • 1994
    • SEGA GAME SAMPLE 1 → Windows + screens and flying carpet .
  • 1995
    • Panzer Dragoon 1995-03-10
    • Wing Arms 1995-09-29
  • 1996
    • Guardian Heroes 1996-01-26
    • GunGriffon 1996-03-15
    • Panzer Dragoon II Zwei 1996-03-22
    • Dragon Ball Z: Idainaru Dragon Ball Densetsu 1996-05- 31
    • NiGHTS into Dreams 1996-07-05
    • Decathlete / Athlete King 1996-07-12
    • Battle Arena Toshinden URA 1996-09-27
    • Street Racer (Extra) 1996-11-16
    • Sega WorldWide Soccer 97 / Victory Goal ’96 1996-11- 29
    • Shining the Holy Ark 1996-12-20
  • 1997
    • Shinrei Jusatsushi Taroumaru 1997-01-17
    • Gundam Side Story 3 Kidou Senshi Gundam Gaiden III: Sabakareshi Mono 1997-03-07
    • Independence Day 1997-03-15
    • Doom 1997-03-26
    • J League – Go Go Goal! 1997-05-30
    • D-Xhird 1997-05-30 → Some Scenarios
    • Sonic Jam 1997-06-20
    • Bulk Slash 1997-07-11
    • Thunder Force V 1997-07-11
    • G-Vector 1997-10-16
    • Sega Worldwide Soccer 98 / J. League Victory Goal ’97 1997-10-16
    • J.League Pro Soccer Club or Tsukurou! 2 1997-11-20
    • Sonic R 1997-11-21
  • 1998
    • Panzer Dragoon Saga 1998-01-29
    • Dragon Force II 1998-04-02
    • Savaki 1998-04-16
    • Gungriffon II 1998-04-23
    • World League Soccer 98 1998-06 -05
    • Radiant Silvergun 1998-07-23
    • Pro Yakyuu Greatest Nine ’98 Summer Action 1998-08-06

Games with 2D / 3D effect using VDP2: Screen with superior transparency:

  • From TV Animation Slam Dunk: I Love Basketball → Effect in park
  • D-Xhird→ Level with fog in the background.

Again I am left with a selection of three games, which are good representatives of this section and as games for the system:

  • Blam MachineHead

    Released on 1996-08-30 is a game from the 3rd wave of developments third party European. In this case, Core Design and its components already demonstrate an outstanding knowledge of the machine. A game with a really powerful 3D engine, but with base decisions thinking of PS1 and PC that clearly harm the final finish. Although it was first released on SS, 2 months earlier. We do not know if as part of the first agreements that SEGA had with Core Design, such as for the Tomb Raider. We also can’t know how it hurt this too, being released earlier. But this Blam Machinehead does seem to be well polished, although it can be improved.

Blam Machinehead has a motor that smoothly moves at least 800 textured quads and Gouraud seen on screen. Maybe more. Approximately 1,100 calculated. Of which approximately 100 quads seen are from the vehicle and its weapons. It is true that at 20FPS totally stable, possibly blocked by Vsync. All this at 352×224 points.

We see no trace of subdivision in terrain or LOD in features although clipping appears to be similar to that of the Tomb Raider for terrains and features. So not with the dome, which is always drawing. On the other hand, the clipping of the rotated map is very well accomplished by playing with the VDP1 clipping windows.

For the lighting part, the engine shows lighting in the vehicle and in the weapons dynamically, plus one lighting per source. Possibly in enemies and entities there is also basic lighting by source. The stage shows pre-calculated lighting with Gouraud.

It has a really remarkable drawing distance. Plus Depth cueing’s black smoothing makes poping almost imperceptible most of the time. It is true that PS1, being exactly the same, is better. The main cause is, as I said before, basic decisions that were made thinking more about PS1 and PC, and that, as usual, were detrimental to the SS version. It is true that SS was out of the norm. But it was not so difficult to do the same well in SS. I mean the “dome”. The “dome” in 3D games is the total background. In many it is usually 2D, more in SS, but at the time with PS1 they mainly began to see more background in 3D. With cylindrical, spherical, or textured cube shapes that simulate being spherical. In this case, this entity is a basic entity that is repeated in all the scenarios only changing the color and the Gouraud gradients. So far the SS can do it without problem. This Gouraud geometry is now on top of a flat overall background with a color gradient. The first geometries simulate mountains, buildings or clouds in the twilight of the distance. The second is the gradient of the sky. The first on the second both on PC and PS1 have a transparency, to show the total background and mix everything very efficiently and thus save a great texture or textures for it. It is also faster than moving and drawing all this with textures. But the problem is that they use exactly the same geometry as for the other versions, that is, with many triangles. And also in the absence of a transparency for 3D that work they use the mesh mode. Well. As there are no transparency gradients in these two final layers, Depth Cueing in the lower area does not melt against black or background gradient. If not against the stippling of the dithering mesh, leaving this final effect less efficient. Besides that this dome is always being drawn, with this large amount of wasted redrawing. For the SS it is a total waste. Because he is doing Gouraud in triangles, which makes him throw fillrate in quantity. This dome could have been converted to quads well, first. Second, having used a gradient in the final background with the VDP2 Back screen, and finally using Sprite’s transparency with VDP2 of these quads with Gouraud against the Back Screen. All this would have been infinitely lower cost for SS and would have looked the same as on PC and PS1. It would even have allowed to raise the FPS to 25FPS or 30FPS, the drawing distance or the resolution of the textures of the stage from 24×24 to 32×32. This dome could also have been made with the RGB0 layer of the VDP2, as in Exhumed, with the final transparency on the Back Screen the same, but it is true that if it had been a solution 100% adapted to SS, and not something more valid for all versions. Finally there is also the problem that using the transparency of the VDP2 for the UI could have mixing problems. But using the VPD2’s extended color calculation mode correctly (as in Sonic R), in theory both layers of the VDP2 could have been seamlessly mixed.

The rest of the transparent elements, including billboards such as flames or flares, make use of the mesh mode. It is true that in this game they are on other elements of the VDP1 all the time, but strangely the developers do not use it at all. Maybe thinking you had a fillrate problem on VDP1. When really the problems come more from the misuse of the east, and also most likely from the CPU, in its transformation and lighting code.

We see a use of the gradation calculation and color calculation function for the ratio and priority. In the case of the first one, we should perceive a smoothing in the horizontal lines both in the graphics of the VDP1 and in the layer of the VDP2. But it doesn’t work because the developers didn’t properly configure the VDP2 logs for it. Of the second I really do not know what they use it for, or what their intention was. Since the only thing they could do is some element of the VDP1 make it transparent against the only layer they are using for the UI, or for the Back screen, but I can’t see what.

All of these cues, plus others we’ve talked about, may be the result of an early search for better solutions for the game. But all of them unfinished.

For the sound part, they made use of the SEGA 2.x driver. The Core Design team is not complicated. And it does not use the extra DSP possibilities, which would have looked so good in this game. Like the reverb or echo, which were almost certainly used in the PS1 version. Although we do see a typical use of DSP for CD-DA playback for music. Neither at the sound level FX we see great advances. It seems that they put all the sounds per level into the Sound RAM, in raw mode. Surely half the quality, or less, than on PS1 to fit everyone.

There may be a possible use of CPU render to VDP1 Frame Buffer on loading screens. I’m not sure though.

The kinematics are all full screen, with good compression. At 320×200 at 24FPS. The sound however remains in mono PCM at 22254 Hz. With a bitrate of 1800kbps peak. 1400 for the video stream and 356 kbps for the audio. There was still some room for a little more sound quality. All this shown in the VDP1 by means of a distorted sprite at 15BPP.

The use of the hardware is remarkable. Using 2xSH2 for FMV and 3D. We can see a typical use of the SCU-DSP in FMVs and 3D of up to 20% of memory and 17.4% of records. The game uses 70% LRAM and 80% HRAM. Up to 95% of the VRAM of VDP1 and finally of the VRAM of VDP2 60% and CRAM 60%.

  • SEGA WorldWide Soccer

    97/98 Launched on 1996-11-29. Being a game of the 3rd wave of developments Japanese first parties. SWWS 97 is a great soccer game for the SS. Aquila Team was charge of this particular saga and already showed a great mastery of the use of the machine. Even more in making use of its transparency capabilities, like few others in the system.

In my point of view we are before the title of the Victory Goal saga that marked an important point. It marked the maturity of one of the SEGA CS teams that best used the machine and specifically in this genre. It is true that there were other important and good titles in SS. But for SEGA, this was their star soccer title. With the next SWWS 98 they only added, league mode, and improved other minimal aspects.

SWWS 97 moves at 352×256 at 15BPP exceptionally, at fully stable 30FPS. At 60FPS in menus even with 3D. It is true that the polygonal load in this game is not high and there is no lighting during matches either. During which we are talking about 500 quads seen, making use of up to 2 levels of LOD for players and shadows.

If we can see 3D lighting in the menus. When we select the stadiums, with a light source. Also on the flags before the game.

But if this game stands out technically and this team is in the intelligent and precise use of SS capabilities for transparencies. In games we can see a large number of them and used intelligently to make them work as well as possible. So we can see native and transparent transparencies on the VDP2 working at the same time and almost without problems in the Screens and through the shared mode between VDP1 and VDP2. In the latter we can see its use mainly in the shadows of the players, but also in the splash of water when it rains and the shadow of the ball. VDP2 transparencies can be seen used for rain, field radar, UI signs, or menus.

Special mention to the use of the insert mode on the Line Color Screen or LCS. In this case to simulate the haze towards the distance on the playing field. It is seen only in day mode. This effect is missing in FIFA 98, which was on PS1, but Climax in the SS version did not integrate it. As we can see in this SWWS it is totally possible. In addition to having seen it in many other games as we have seen.

In the menus we can see how it is also used for button shadows or selection square backgrounds or the UI. I have also been able to see the use of the extended color calculation mode or ECC, but not in matches. Add as a curiosity that I have not been able to see where it is actually being used, since I have not seen any place where 2 or more Screens of the VDP2 are overlapping. And the other detail is that the Aquila Theme runs away from using the mesh mode of the VDP1. But in the menus in the player editing part when, two windows overlap. In scaling animation they use mesh mode, possibly to prevent transparency from this cover to the bottom. It is still curious that these with the knowledge they demonstrate would not have avoided it in other ways. If you already had the ECC mode activated they could have used it for one element to do it with the native VDP2 and another one with the VDP1> VDP2 with the ECC and thus mix it with the VDP2 ECC. Or use the transparency of the VDP1 for the two elements and both send them through the VDP1> VDP2 mode.

As a final note, such is the use of the machine they make. Which is one of those few games in the catalog in which all the Screens of the VDP2 are being used, with the majority of active and used functions. Both in menus and during the 3D game, it is spectacular without a doubt.

The sound as in most first party titles is superb. In this title we also have the use of CD-XA and ADPCM in an extra way. In addition to MIDI music with active DSP reverb and echo effects. Making use of the SCSP-DSP in the menus of 60% memory and in 3D game up to 30%. Of course they also make use of CD-DA tracks. Comments can be seen that they are in individual files. In SWWS 98 they packaged everything in a single file, I suppose to speed up access to the flight in the matches and minimize the stops for searches on the CD on the fly, typical in these cases.

At the time the intro of this game shocked me. At 320×176 and 15FPS. With ADPCM stereo sound. The truth is that it is very good. Although the compression in Cinepak is upgradeable, too many typical codec artifacts are seen and they tarnish the end result. Not so in version 98 that sets the bar really high. That reaches 320×224 also has 15FPS, but now in PCM, even stereo at 22050hz, a great quality for the system.

The use of the machine is remarkable as we have been saying. Use 1xSH2 for FMVs, while 2xSH2 for the rest of the game. SCU-DSP signals typical of 20% memory and 17.4% Registers are seen. Possibly for transfer of audio or data stream. RAM usage is 95% for LRAM and 90% for HRAM. The VRAM usage of the VDP1 reaches 80%. While the VRAM of the VDP2 reaches 90 and that of the CRAM 95%.

  • Sonic R

    Released 1997-11-21. Being a game of the 4th wave of European developments from a Second partys.

We are before a true miracle. Well, the SEGA mascot has been lurching from before the release of SS. Up to 3 different Sonic 3D titles are known to be on the way: One in 32x and two in SS. But we can thank SEGA Europe that it was able to carry out this Sonic 3D, and also with a company and leader in high-level programming: Traveller’s Tales. We are possibly one of the best titles in the system. And it is also a Sonic, and we could say that even “original” being a racing game. Built in just one year, and converted from a Formula 1 game originally to compete against Bizarre Creations’ PS1 F1 96. John Burton and his team made a true masterpiece.

If it is true that the TT itself is in charge of the also unique Sonic 2D isometric that came out on SEGA machines. And that for the SS version a fully 3D bonus was included. And there is also the 3D map mode of the Sonic Jam of the Sonic Team itself. But as a game thought entirely in 3D, this is the only Sonic we can consider.

Running at 30FPS like a rock at 352×224 dots of resolution in 16BPP color mode on VDP1 and equal output resolution and maximum color depth for VDP2. With an incredible amount of on-screen geometry. It is the game with more quads painted and calculated on the screen and stable system FPS. Peaks of about 1500 quads on display. All said for both one and two players on split screen.

The use of both VDPs is masterful. The VDP1 is fully used: Flat polygons, normal sprites, scaled sprites, distorted sprites. In different types of color depth. Gouraud shading in static and lively color. Different modes of color calculation. half-Transparency used with great intelligence: Speed ​​trail (with a minimum of redrawing error), shields … Mesh mode used only in extreme cases: Shadows, smoke … In the case of VDP2 the use is at the same height. Something really weird to see in SS. Most games focus their use on the VDP1, and not excellently as it is the case, and almost completely forget the magnificent VDP2. This is not the case as we speak. John Burton puts up to two infinite shots on screen at a maximum possible resolution. Use backgrounds with animated parts. And of course all the possibilities of transparencies that it gives. Both its own per screen for UI elements, as well as special ones such as the Color Line Insertion, even animated for the waves. Color calculations and ratio with VDP1 to achieve an effect of depth cueing with magnificent fading, with up12 levels. And for the ripple effect in the water when the character is underwater. Adding the use of the Extended color mode for the color calculation function, but in this case fully functional and well used, mixing up to 3 layers of the VDP2.

In addition to everything exposed. John still has more surprises for us. Illumination with 1 dynamic parallel light with source and Gouraud color in all characters. Of course the stages are illuminated with color and Gouraud, but in this case they are bake lights.

But there is still more. John Burton’s team went further. In the absence of UV coordinates in VDP1. John Burton commissioned a teammate to implement via SH2 assembler a triangle rasterizer with affine projection and UV coordinates similar to the PS1’s GPU for use in Sonic R for Ambience Map effects. And he did. Finally I don’t use it extensively, just in: the R 3D of the logo on the initial screen, the 3D head of Sonic rotating during the loads and in the 3D position number of the limit switch. But the idea was to use it also for Sonic Metal. There it is.

It should also be noted that Sonic R makes use of the 3D sound capabilities of the SS SCSP-DSP chip. In this case the Qsound implementation. Possibly for echo or reverberation in tunnel or closed areas. I have not been able to verify it 100%.

We end with the use of Hardware. As it could not be otherwise, it is excellent. The SH2 pair plus SCU-DSP is being used for the entire 3D pipeline. In this game reaching one of the highest figures: 80% of Memory and 57% of Registers used. Presumably Sonic R is close to using 100% of the process on the SH2 Slave when it is using its software 3D renderer. As we have said, use the SCSP-DSP processor in this case we see up to 90% of the memory used. On the part of the main memories. It is at 85% combined use of the main RAM. In 85% of the VDP1 and 85% of the VRAM of the VDP2 and 60% of the CRAM.

5.4 The most complicated – EXTRA II ball: Reflections in floors / Flat surfaces.

It is a subject that has been attracting attention progressively. When I have discovered how the SS draws, and how they used it in the games of the moment, I was asking questions. One that was in crescendo was Why are there no reflections in basketball or ice hockey games?

Because if I had seen them in games like Panzer Dragoon before looking at Basketball or Hockey games. But it is that only two Basketball games have this effect. That is, the reflection plus the shadows.

In those of Hockey none. They have transparent shadows, but no reflections. The one with reflexes is NHL 97 but they are Mesh. Some Basketball games had at least also transparent shadows like NBA Live 97.

Like everything related to “transparency” in SS, the problem was that it was not simplified, “clear” and accessible to developers. If it had been really simplified and accessible through the libraries and SDK, they would have used it more.

Was this disadvantage finally resolved?

Sadly NO. As I say only one basketball game did. When in fact, from my point of view, everyone could have. Same with Hockey.

I have come to see it in only 3.4% of the total number of games analyzed. When as we see for the VDP2 and in many games it is a totally possible effect and free at the performance level.

Well let’s go with a chronological list of what I have been able to find:

Games with 3D reflex effect using VDP1 + VDP2:

  • Panzer Dragoon Zwei (1996) → Reflection Water and underwater
  • Linkle Liver Story (1996-03-15) → Reflection Water
  • Shining Force III (1997) → Church Scenario 3 or Premium. Seen in videos and images, I could not verify it.
  • Ten Pin Alley (1997) → Reflection park
  • Mass destruction (1997) → Reflection Water
  • Panzer Dragoon Saga (1998) → Reflection Water and underwater

Games with 2D / 3D reflex effect using VDP1 + VDP2:

  • From TV Animation Slam Dunk: I Love Basketball (1995)
  • Slam ‘n Jam ’96 Featuring Magic & Kareem (1996)

Games without the reflection effect, worst possible, but with 2D / 3D shadows using VDP1 + VDP2:

  • NHL Powerplay 96 (1996)
  • NHL All-Star Hockey’ 98 (1997)
  • NHL 98 (1998)

We turn again to analyze three games that are representative of this point:

  • Panzer Dragoon Zwei and Saga

    Released on 1996-03-22 and 1998-01-29 respectively. Panzer Dragoon Zwei and Saga are the second and third part of the saga in SS. 3rd and 5th wave games respectively from a Japanese First party developer. We can see an important use of the machine in 96 and extraordinary in 98.

Note that both games share technology. It is curious because the difference between the two is approximately two years. But analyzing both in detail the data is there. Dynamic color lighting is present in both games. Creative transparency effects with VDP2 or 3D sound using SCSP DSP. Even the sound driver version is the same with a slightly different build date but from 1996. They use the available processors and memories in% the same or very similar. The use of the Cinepak codec is also the same. When at this time there were SEGA games using ADX and Cinepak with ADK for more quality. Even the use of VDP2 for FMV is the same.

Let’s go into detail. As we said, both games have dynamic lighting with a source plus Gouraud in color. Also flat dynamic lighting in some entities. And for supposed lighting baked in stages with Gouraud and flat. Both have Depth cueing with the VDP1 and with color palette changes with the CRAM of the VDP2.

Both games run at fairly stable 30FPS. In 3D cinematics on Zwei it even reaches 60FPS. In both games the charge of quads is similar around 500 quads, maybe more in battles with many enemies, bullets or very large enemies. In the Zwei cinematics over 300 quads. In the series on some very large 3D maps you can see drops at 15 / 20FPS. Otherwise it is quite stable. In terms of resolution, both games run at 352×256 in the 3D parts and in the HD menus at 704×256, with a clarity that still surprises today. Although the game is in 15BPP mode, the content of textures and patterns is usually between 4BPP and 8BPP for both VDP1 and VDP2. Of course both games follow in the wake of the first in the use of the infinite planes of VDP2 to recreate huge spaces as could only be seen in SS: Deserts, clouds, seas …

Zwei already in 1996 made it clear that when you wanted to the SS could put transparency without blush on the screen. Especially underwater effect and reflection of the enemy of the caves in the second episode, if I remember correctly. Of course they both use the Color and Ratio calculation transparencies with the elements of VDP1 and finally mixed by VDP2. In various effects from: Zwei’s forest level shadows, underwater elements in both games and many others. As a curious fact for lighting the bonfire in the tent. Of course the full screen transparency effect of the VDP2 is used for different weather effects, cloud cover on map or magic. Also in many elements of the game UI.

On the other hand the half-Transparency of VDP1 is also used. But in this case I have not seen it in the Zwei, if in the Saga. It is used for many particles and billboards in a very intelligent way from: Smoke, shots, explosions, magic particles … Both on the 3D map and in battles.

When the spoken transparencies cannot be applied, the Andromeda team has to resort to mesh mode as we usually see in many other games, so we can see it in: Character shadows, various particle effects or on the radar …

As I said before both games use Cinepak + PCM for FMVs. The sound quality is the same: 32000 Hz, 16bit, Mono. For my taste a waste for the quality of the Soundtrack and the sound in general not being able to have it in Stereo. They differ in the resolution and FPS of the image stream. Zwei has less resolution but more FPS and Saga backwards. But from my point of view a waste of CGI quality. This saga should have used Duck or at least Cinepak + ADX to have a quality close to Wachenröder or Lunar 2. Finally highlight as a detail that these are the few titles that use the scaling of the VDP2 in the FMV to be able to take better advantage of the total area from the screen.

Noting that one of the extra docs the developers left on Panzer Dragon 1. The sound programmer said he was left wanting to use 3D sound. But that for the next occasion I would use it.

◆エンド前にカゼ.

今回はできなかっ3Dサウンドとか使っ.

サターンのサウン,と反省し つ つ 次 回 に 乞 う ご 期待。

サ ウ ン ド 担当 ： 澤 田 朋 伯

◆ It cost me a lot, I caught a cold before the end, but I could safely finish it.

I couldn’t do it this time, but I would like to use 3D sound next time.

I’m sure we can do even more amazing things with the Saturn sound, so please look forward to next time.

Head of Sound: Tomoharu Sawada

So it was. In both Zwei and Saga we see a great use of SCSP-DSP. Both in reverb effects and in MIDI sound and music in general. Thus we can see a use of up to 90% of the DSP memory of the sound. Plus .exb file signs per track. Files of the compiled code of the sound DSP. The quality of the sounds that you could see is from PCM at 11025 Hz mono.

The use of the hardware is excellent. Using 2xSH2 for both FMV and 3D. With typical SCU-DSP usage signs of 30% and 26% in memory and registers respectively. On the other hand we can see a use of the main memory at 70-80%. From the VRAM of the VDP1 of 80-90%. In the VDP2 I have seen slight differences. In the PD: Zwei 55% of the VRAM of the VDP2 and 90% of CRAM. In the PD: Saga of 80% of the VRAM of the VDP2 and 70% of the CRAM.

  • From TV Animation Slam Dunk: I Love Basketball

    Launched on 1995-08-11. Slam Dunk is a game from the 2nd wave of Japanese Third party developments. And I have to say that a development of a superb quality to be so early in the system.

BEC Co. Ltd which is the company that is accredited as developers of this title. They are still a division of Bandai. They were in charge of the most known IP of Mangas. Another great title of them is Dragon Ball: The Legend.

It is not a game with a large quad load, about 400 quads, but strangely it goes at 15FPS like FMV. At a resolution of 320×224 15BPP. I get the feeling that they wanted this to be the ultimate FPS goal. Because the feeling, for various details, that technically they are going well.

What really catches the attention of this title is the implementation of the reflection effect that it has on the court. That is not seen in the rest of basketball titles or the like. And this game shows it as entirely possible. Also making very clever use of color ratio calculations for the VDP1 elements on the VDP2 alongside the specular gloss blend in another layer of the VDP2. All this against the court using RGB0. And without ever using the extended color calculation mode, it feels like everything is getting mixed up. It really works very well. To end the transparency issue, also point out that they use the half-Transparency of the VDP1 in a very correct way for the glass board, which is always on elements of the VDP1.

We can highlight that it may be one of the first titles that use the SEGA InVision library, for MIDIS. The music of the game the truth is that it sounds very good. Regarding the use of the SCSP-DSP there are clear signals up to 60% memory, and I have the feeling that the sounds in the stadiums are heard with echo or reverberation.

I have to say that the FMVs of this title seem superb to me. Seriously, the quality and the quantity is very good. It has 288×216 scaled on the VDP1a full screen, 30FPS and PCM 22256 Hz 8-bit Stereo. It surprises me mainly because of how early they are in quality. And at the time similar titles in SS made quite worse videos, even from the same Bandai the first Dragon Ball Z or Rayman of Ubisoft.

The use of hardware, IMHO, is magnificent more meritorious as a Third party and at such an early stage of system development. The use of the processors is total. The 2xSH2 for both 3D and FMV. And also in 3D the SCU-DSP is being used in some important figures, 95% memory and 44% records. Regarding the use of memories, we are 95% of the LRAM and 65% of the HRAM. The VRAM of the VDP1 reaches about 90% usage. The VRAM of the VDP2 at 80% and the CRAM at 70%.

  • Mass Destruction

    Launched on 1997-11-20 as a game from the 3rd wave of European developments. For me this title is especially remarkable because it is remarkably well resolved for the SS and also the other versions. It has not been prioritized in some more than others. And a job has been done to make them look the most similar and correctly on each support. What should be. Just note that it came out two months apart from the PS1 version, and that only one programmer is credited for the SS version. All in all, as I say for me the best version.

It seems that the NMS team did not have much life, but at least with quality. It can be seen that they were professionals with a long journey, even from 8bits. Skilled at playing low-level code and creating graphics in different circumstances. SS was positively benefited by this. And also in this Mass Destruction you can see all your knowledge. A direct action game with little details, but that make the apparently small games big and durable in time.

Running at a resolution of 320×224 at 15BPP although the graphics are mostly at 8BPP, just like the PS1 version. But at constant 60FPS and if slowdowns, against the PS1 version is not so smooth, perhaps this at 30FPS. Which is not bad either. The ground quality also in SS is clearly superior, since the RGB0 of the VDP2 is capable of drawing perspective perspective-corrected 3D plans with very high detail per tile. PS1 couldn’t match this without extreme sacrifice. It is also not a game that draws many quads on the VDP1, in this case around 300 quads.

This game does not have dynamic lighting, you can only see a pre-calculated lighting in some elements such as palm trees or objects with flat polygons.

This game makes excellent use of the transparency possibilities of SS. Only one downside can be put, not having implemented transparency in buildings as in PS1 totally possible, just by sending the entire building and to the tank under RGB0 with CC + ratio as the reflections they make in the water, it would have been enough. But hey, on the contrary, we have those reflections in the water that are not on PS1 or PC and that are very spectacular. NMS also makes use of the MSB On mode for some shadow transparencies. And of course from the normal layer VDP2 transparencies for the UI, even animated, masterfully.

Mass destruction introduces a use of low-sounding but existing DSP. 20% memory usage. The music is mainly CD-DA although there is also some in MIDI.

NMS appears to have implemented its own code for FMVs, which appears to be the same for all versions. Giving 8BPP remarkable quality at an unknown FPS amount, but I estimate it to be 15 / 25FPS.

The use of hardware as we have seen in remarkable. At the processor level, 2xSH2 is being used for 3D and FMV. On the part of memories, the main one reaches a use of 70% in LRAM and 80% of HRAM. 80% of the VRAM of the VDP1. And finally 90% of the VRAM and CRAM of the VDP2.

6. The most complicated II: Render-to-texture

This point has been another one of the last additions that I have made. In the course of this maximum delving into the machine. I have seen in a few numbered titles, something that a priori could not believe. Well, in my eyes, it was a Render-to-texture effect. Something that was born practically with PSX and its unified buffer. Which was later seen and used in GPUs on later PCs and consoles.

But how could this be? Theoretically it is “impossible”. Because the SS has completely separate “two buffer areas”. And read them during the pipeline, if it can be very expensive in cycles.

But there are games where we can clearly see how the screen image of that moment is captured and then 3D graphics are made, which is effectively drawing the VDP1. In other words, they are quads and textures.

Finally we can differentiate in this case several possible ways to do it:

A) Render Buffer (Case type PSX): Take something from the FrameBuffer of VDP1 or Screen of VDP2, inside or outside the drawing area, to reuse it in a pattern / texture for the VDP1 or VDP2. And create a concrete effect to all screen or in part via hardware or software. Doing part of the effect with hardware is less expensive for the system. Doing an extra process by software greatly increases the cost (more time) for the system.

B) Render CPU and / or SCU-DSP: Where the CPU / SCU-DSP draws something internally (Process and RAM) and transfers it directly to one / s texture / s, to the Frame Buffer of VDP1 or to a Screen of VDP2. Example: Sonic R

C) Render CPU and / or SCU-DSP with Read + Write in the FrameBuffer of VDP1: This is the most aggressive and complicated method of all. It involves reading the FrameBuffer, inside or outside the drawing area, at runtime, internally processing (CPU and RAM process) what you want and drawing on it. You need the operation or function you want to perform to be extremely fast, since the time to do it is very short. We talk about a few more. If it goes too high it will stop the game too much causing severe slowdowns. Example: Scorcher.

D) Reading the VDP1 FrameBuffer + CPU / SCU-DSP + RAM Process + Reading the VDP1 Frame-buffer + Final writing in the VDP1 Frame-buffer: This is the most complex and expensive method that I have been able to document. I’ve only seen it in Die Hard Trilogy in the third game, the car game. The team uses it to make half-transparency additives in sparkles and explosions / fire. They look beautiful. The item to “process” is drawn at the end of the command list outside the drawing area. My intuition tells me, that inspired by the original PS1 code. They do a kind of Render-to-texture like they did for the radar of the first game, which is to read the frame-buffer to use it as a texture and do a hardware process. But in the case of SS they actually go through the VDP1 Frame-buffer three times, which is a snap. Which for the PS1 is already an expensive process, despite having a unified frame-buffer, with access to 32-bit words and a little more bandwidth to go to more Mhz. In SS the memory is faster, quite a lot. But accessing 2 more times and adding an extra process in the CPUs for the effect via software, is already a hyper risky action at the performance level. So much so, that when you have 20 or 30 particles on screen occupying a large area, the performance drops to a digit. I would like to end by praising the team’s work, because despite the lack of ports. It does not stop seeing good intentions to go further with the machine, in many aspects. Perhaps the lack of budget + timing necessary for the complexity of the system, again played against the SS version.

Was this disadvantage finally resolved?

Yes and no. Yes, because as we speak, there are games that do it. But NOT because it is not documented by SEGA and there is not even a library for it. At least that I have found. As such, we can find said “feature” applied in a different way, with different objectives and results.

What I have not found is literally a case of the type: Giant TV screen.

The remaining question is whether it would be possible at low resolution, without penalizing much in FPS to achieve this effect. Since on PSX there was no penalty, up to a point. According to @XL2 that I asked on the Segaxtreme forums, it would be entirely possible at low resolution. In fact in Burning Rangers or the same in its 3D engine it does it for the transparency layer similar to how they did it in Burning Rangers too.

The Render Buffer cases found in games published at the time are clearly “Static” for the most part. With obvious pauses before the effect (even on PS1 depending on how). We would be talking that to perform them the CPU would have to completely stop the graphic pipeline.

Except as we say the Burning Rangers case. Also in Grandia in battles, but I’m not entirely clear. Where there are no stops.

I have also seen something very similar in many games, to render the FMVs or in some loading screens, although I have left it out of the following list.

I have come to see the use of this technique or very similar in 11.4% of the total number of games analyzed. It really surprised me. Since he thought it was impossible for the SS because of the design of its graphic pipeline. But I was happy to see that it is possible, at the same time, I was sad that SEGA did not facilitate it again. Perhaps we could have seen it more since it allows very spectacular effects.

We are going to see a chronological list and by type of technique used with what we could find:

A) Render Frame-Buffer to:

All the complete frame of VDP1 + VDP2 → To elements of VDP1

  • Rayman (1995) → Final loading level screen with one more fade animation with 3D elements. 320×224 resolution the same as the original in all layers and VDPs.

All the frame or partial of the VDP1 → To elements of the VDP1

  • Loaded (1996) → Game background in Pause / Inventory menu. Same 352×224 resolution as the original in several elements.
  • Welcome House → Game Background in Pause / Inventory menu, with mask pixels to correctly display the VDP2 background. 320X120, Half resolution “Y” Render.
  • Akumajo Dracula X: Gekka no Yasokyoku (aka. Castlevania: Symphony of the Night) (1998) → Photo effect in-game intro at 320×216 resolution, does it pretty fast.
  • Genso Suikoden (1998) → Effect in Full Screen Battles. Like PS1 but poorly implemented, with silly problems. At 320×240 possibly, I have not been able to verify it, it seems that it is relatively slow.

All the frame or part of the VDP1 → To one layer of the VDP2

  • Tomb Raider (1996) → 3D game background in Pause / Inventory menu 352×256. It does it very fast.
  • NBA Live 97 (1997) → 3D game background in Pause / Menu options 320×240.
  • Burning Rangers (1998) → Layer of transparent elements and mask (black) at 160×122.
  • Arcana Strikes (1997) → VDP1> VDP2 Appears to send sprite data with the same resolution as original VDP1 → NBG1
  • Grandia (1997) → In battles, the sprite characters that are drawn in VDP1 are transferred to VDP2 NBG1 and, therefore, the transparency effect is used in VDP1> VDP2. It appears that it only transfers VDP1 data that is out of date or paused. The only animated data is drawn on VDP1 at this time.

B) CPU / SCU-DSP Render to:

A Layer (Bitmap or pattern / pattern / s) of the VDP2:

  • BIOS menu (1994-11-22) → Background stars space.
  • Cyberia (1996-01-01) → All 2D and FMV are rendered by the CPUs and sent to NBG0 of the VDP2.
  • Shellshock (1996-04) → 3D Mode 7 Ground as Firestorm: Thunderhawk 2.
    • PassThrough of VDP1 primitives for assets, enemies, and particles.
    • CPU + VDP1> VDP2 from Elements.
  • Hexen (1997) → Map-Scenery BSP Engine Software raster render
  • Tempest 2000 (1997) → Blur effect, very slow FPS
  • Amok (1997) → 3D Voxel Engine
  • Shining Force III (1997) → SCU-DSP Render to Texture VDP1 and VDP2 Texture Procedural gradient to VDP1 and / or pattern / pattern / sa VDP2 screen

A Texture / Pattern of VDP1:

  • Firestorm Thunderhawk II (1995-11) → 3D Mode 7 Most degraded soil horizon
  • Sonic R (1997) → Environmental Map effect
  • Shining Force III (1997) → SCU-DSP Render to Texture VDP1 and VDP2 Procedural Gradient Texture to VDP1 and / or pattern / pattern / sa VDP2 screen

C) Read / Write to / to the FrameBuffer of VDP1.

  • Rayman (1995) → Particle Blast when you pick up items.
  • Scorcher (1997) → Fixed red and blinking white haloes.

D) Reading the VDP1 FrameBuffer + Process CPU / SCU-DSP + RAM + Reading the VDP1 Frame-buffer + Final writing in the VDP1 Frame-buffer.

  • Die Hard Trilogy (1997) → Billboard: Flashes, colored flashes with Gouraud and explosions

Finally again I am left with three other of the best games in this section. What they would be:

  • Firestorm: Thunderhawk 2

    Being released on 1995-11-08. It is a title of the 2nd wave of developments for the system. Virtually 1 year after launch. Core Design had already shown since the 8bits to have a more than guaranteed tradition in everything it did. And its members with all that extensive experience already in 95 testify to this with each launch. It was a game developed in parallel for PS1 and PC in just 3 months, as its developer tells it in a short twitter conversation that I had with her, thanks Sarah:

“The versions of Saturn and PS1 took 3 months to create, and the PC version took another month. The game was C-coded, with machine code subroutines where needed for speed.

I should add that I had to code a new 3D engine from scratch, using 3D polygon hardware for objects and most of the floor, with the distant floor represented by a software routine I had developed based on the MegaCD ASIC. ”

Sarah Jane Avory

The game runs at typical SS resolution of 320×224 at 15BPP although the graphics content is between 4 and 8BPP. At fully stable 20FPS. It is a game that caught my attention because it does not show the typical drawing commands in the Yabause VDP1 debugger. Displays tons of Normal Sprites at 8BPP small. And on the other hand it can be seen how the Mode 7 rotated flat floor is not being drawn by the VDP2 with an RGB0 layer. All this added up made me think that everything was drawn by software. But when you put the emulator in OpenGL you can see how the graphics go up in resolution and you can even appreciate the use of Gouraud and Mesh typical of VDP1. I don’t know exactly how Sarah programmed VDP1, but she’s using it. What is rendered by software as she confirms is the Mode 7 floor with a Depth Cueing effect in addition. Which in your next project, Fighting Force, if I use VDP2 for it. If you use RGB0 for the background rotated according to the tilt of the camera. It could also be doing a render-to-texture on the radar that we see inside the cabin or the 3rd person camera.

F: T 2 does not have dynamic lighting of any kind. If you have bake lighting on terrains and features, using Gouraud or Plane smoothing.

The music in the game is on CD-DA track. Although we can see 35% DSP usage of sound, I don’t know exactly why.

F: T 2 has a frankly very good FMV. It can already be seen that Core was quite used at the moment due to her previous stint on Mega-CD. The intro has a very good quality at 320×200 at 15FPS, the sound quality is good but in mono.

Finally the use of the hardware is very good. Already using 2xSH2 for both FMV and 3D. Typical signs of use of the SCU-DSP are seen. From the use of memories we can see up to 85% in the LRAM and 45% in the HRAM. 95% of the VRAM of the VDP1. And 22% of the VRAM of the VDP2 and 90% of the CRAM.

  • Amok / Scorcher

    Being both releases from the 3rd wave of developments Third party on 1997-01-17 and 1997-03-01 very close. Both from a USA company but with teams from other places. We find these two titles being developed internally by two different Scavenger teams: Lemon and Zyrinx both with components from Denmark from the Amiga demo-scene. In the case of Amok everything points to being one of the technical demos that were previously shown for and on the 32X. It can also be deduced by the size of the final games and by a series of technical details in both games.

Let’s start chronologically with Amok. Really under my opinion it is a game for the shocking moment. The voxels, which have always been the poor brother of 3D, have always liked and surprised me. It is also a type of 3D that is not cheap to process either, and that in the RISCs of the SS goes so well it seems to me a great achievement. Well, in fairness, Amok does voxel and classic 3D processing, since 3D entities are processed as a raster of textured triangles. We can also observe Depth cueing towards the bottom by software in all the elements.

On the transparencies in this game the solution via software has not been used, an implementation of the mesh or screening type has also been chosen. If we can promptly see the use of VDP1 transfer for radar in the UI. And in the least the transfers of the VDP2 with CC.

Amok runs at 320×224 at 16BPP on the VDP1 elements and on software render which is on the VDP2 and the background of the VDP2 at 8BPP. This game goes 30FPS, sometimes counted down to 25 or 20FPS. It is not possible to know how much geometry is on the screen.

The sister version of PC is practically identical. At least in the main features and drawing distance. Although it asks for a minimum of an Intel i486DX2, the recommended was the Intel Pentium at 100MHz. Possibly in a 320×200 to 8BPP mode with scanline the DX2 would be fine. But going up to 640×480 from 8BPP to 16BPP would already need a good Pentium and perhaps not with that it would go as smoothly as in SS. On PC the transparencies are real alpha all by software instead of mesh as in SS.

Sound level uses CD-DA for music, hence perhaps the possible use of SCU-DSP for something besides SCSP-DSP in 35% of memory.

Although there is no FMV as such, there is some full screen animation for the Logo. Possibly RAW image loaded on the fly.

The use of Amok hardware is remarkable. Using 2xSH2 for 3D. With signs of use of the SCU-DSP as we speak typical 25/26% for Memory and registers respectively. And using even the sound DSP as we have also commented. At the memory level we can see a use of 85% of the main RAM available. A very low use of the VRAM of the VDP1 over 45% and an irregular use of the VRAM of the VDP2. In this case, 95% of the VRAM and 55% of the CRAM. I don’t know exactly how it can take up so much VRAM, when you are only using two layers and one of them at 8BPP.

In this case Scorcher is a post-apocalyptic racing game. Where you can easily see that it shares code with its sister version of PC.

We can see above all as a key detail about the SS version, the use of real alpha transparencies via software in some elements on the screen. In this case, blinking white or solid red flashes on some tracks. These are drawn onto the VDP1 framebuffer itself by the CPU. We can verify this by seeing that this does not appear as a drawing command in the VDP1 debugger in Yabause. And also with how the effect looks, being a very smooth multiplicative blend against the data drawn from the VDP1. Finally leaving the typical black spot against the areas of the Framebuffer that have not been drawn and reserved for the VDP2 in subsequent stages. Finally we can corroborate the nature by software when observing in the real console that when we are very close to these flashes occupying a large part of the screen, the console takes a long time to process it and the frame rate drops very abruptly with this effect it is on the screen.

Native SS “transparencies” are also used, both those of VDP1 and VDP2. For those of VDP1 we can see them very well used in the effects of smoke particles: green or gray. With quite a few overlapping on-screen particles and textures of considerable size. For the use of transparencies of the VDP2, we can see the typical use in a layer with Color Calculations with Ratio. In this case in the first circuit in an RGB1 layer to represent the moving clouds in the sky.

Graphically we are facing a game that is being rendered at 16BPP in all its elements on the screen of VDP1 and the backgrounds of VDP2 at 8BPP. At 320×224 at 30FPS most of the time with 600 quads on display normally. Only with falls as I commented when the camera passes near the flashes made by software. The PC version is practically identical. Only that it has a 640×480 mode, having the menus and the game twice the resolution. And giving option to render to 8BPP or 16BPP. Clearly this second most prohibitive for the time on PCs at the time which required a minimum of an Intel Pentium. Finally with the same transparencies but more precise and without the SS problems.

The game uses Gouraud on all elements of the stage. It also has a colored light on them. And it makes use of Depth Cueing towards black.

The level of use of the processors is remarkable. Using the 2xSH2 for the 3D and with signs of use in the SCU-DSP of up to 25% of Memory and 26% of registers. It makes use of CD-DA music and MIDI music, using the memory of the SCSP-DSP up to 60%.

The use of memories is from Scorcher is remarkable. The main RAM usage is at 80%. The one of the VRAM of the VDP1 in 95%. And the VDP2 of 55% for both VRAM and CRAM.

Finally, I would like to point out that @Zyrobs via comments commented that Scorcher could be downloading and downloading graphic data from the VRAM of the VDP1. I have not been able to contrast this data, in such a way if it were so. It would be another great technical milestone for this game along with the process of real transparencies via CPU and writing / reading of the Frame-buffer at drawing and execution time.

  • Hexen

    Hexen was first released on 1997-03-31. Strangely 3 months earlier than on PS1. And we could say that better port, narrowly the truth. From this port, also from the Doom engine, I am in charge of another totally different team for GT than Doom. Rage the UK team yields the baton to ATOD a team from Sweden. These choose a totally different path, with its pros and cons.

The game is rendered at 320×224, more than on PS1 at 256×224. Both at 15BPP, but actually with graphic data between 4 and 8BPP. In SS it runs in the average stays between 25 and 30FPS. In the largest at 20FPS, it can drop to 14FPS in very large and deep rooms. On PS1 it goes even worse, strangely. As a curiosity in very small stays it can reach 60FPS. It looks like you have FPS unlocked like the Duke Nukem 3D from PS1.

At the level of elements on the screen it is not high, over the 100 quads maybe more. Keep in mind how Hexen renders SS the Doom engine this time. The developers chose to write the entire part of the wall, floor and ceiling drawing by software and processed by the 2xSH2, and then send it to the NBG1 of the VDP2 as a background at 8BPP. With a cost in the resolution of the textures, which are practically half. On the other hand, the typical sprite elements are drawn by the VDP1 and the VDP1 in turn draws black quads to make a mask and sometimes walls to hide the sprites. VDP1 is also used to illuminate sprites using Gouraud color for background lighting and fading or Depth Cueing. It also uses the half-Transparency + Gouraud CC for particle effects such as smoke, so it only blends with the few elements that VDP1 draws and not against most VDP2. In addition to using a really expensive VDP1 CC like this half-Transparency + Gouraud. Anyway, it is appreciated that at least they used the transparencies in this “Doom”.

Needless to say, the performance problem of this Hexen, as in the Doom, but much less. It is on the CPU side. VDP1 is not experiencing anything on this port.

This game has the typical Doom lighting, although without being perfectly implemented as it should. Hands / weapons don’t seem to receive enlightenment, in Doom at least they do. In the sprites it is somewhat erratic, it seems that if in the lightning of the beginning, but later in dark areas of the dungeons not. However in PS1 as in Doom, if the correlation is seen perfectly.

The sound in this game has the curious. We can see a sound library written by Virtually Unreal Ltd. for Probe, for the use of ADPCM in SFX, which I already saw in Alien Trilogy and Die Hard Trilogy. Could it be that you are using FX ADPCM sound? I do not know. On the other hand we see the typical SEGA driver. If we can see a typical sound DSP usage of 35% memory.

The quality of the FMVs in this version is remarkable. Using Cinepak + PCM. But with high quality. 320×200 at 30FPS, and the audio stream is pretty fair at 22254Hz 8bit Mono. Also rendered in VDP1.

The use of the hardware is quite good. The main memory is at 70% use. The VRAM of the VDP1 by 80%. And the VRAM of the VDP2 in 40% and the CRAM also in 40%.

7. The hard thing to “see”: Sound Effects with Reverb and / or Echo

We are finished. When I get hard to “see,” it’s actually “hearing.” But I mean, it is / was difficult to find SS games where we can perceive, “see”, a change of sound when changing places. However on PSX I remember it perfectly. It hurt even more in ports, where I missed it even more. And as with the graphics, I didn’t understand why it wasn’t there.

Before going any further, I would like to make it clear that the use of Echo or Reverb can be perceived in many SS MIDI melodies in your notes and compositions. Even in some sound effects or jingles. For me a clear example of this are the main melodies of Shining Force III. But let’s say, ambient sound or with examples of rooms or tunnels, I have not been able to find.

In this research where I have been able to understand the machine to its limits, including the PSX. I have seen that this aspect wanted to deal with it. It is still curious, more so when in the sound specifications of SS from the beginning it is clear that it can do this effect.

When you dig into the official documentation and SDK, you understand what happened. When in PSX the effect of marras was accessed with a simple function in its development library, without more. In SS, apart from using a function that in this case uses the digital DSP capabilities of the custom Yamaha sound chip for SS. The development team had to have the “Linker” and the “eLinker (3D Sound)” which was extra development software to load these effects into their projects.

Again we find how Sony simplified the same masterfully. Where SEGA gave a sound chip with a DSP for fully programmable effects, that is, a beast. It also mixed sound up to 32 FM and / or PCM channels. In addition to combining them in the form of MIDIs, which were created with the “SEGA Sound Library” first and later with the “CyberSound SDK”. All this governed by a dedicated 16bit M68000 CPU for all this.

The issue was that to get the most out of the sound chip, you had to go through the SEGA box and buy the extra hardware to the basic development. We are talking that the SS could have 3D sound. Through the DSP of its sound chip. Crazy for the time. Really. But SEGA and / or Yamaha do not know, they preferred to try to monetize this part of the console a little more, loading it to the devs. These that were already passed with the rest of the “extras” of the console, it is not surprising that they will pass to get more out of this beast of the sound chip.

But as we say, next to this, something as simple as echoing or reverberating in a tunnel or in a room. In SS it was very expensive in every way. And on PSX extremely cheap and simple. With the same SDK and with a function where you already had the effect at hand.

And here the crux of the matter. This could translate into that only large companies could afford such an outlay. While all, small and large in PSX used it, giving added value compared to the SS, when it could do it in excess or better.

It is possible that at the end of life, tricks or software could load effects modules without hardware. Or that even I have misinterpreted it. And it could from the beginning. Or that even SEGA came to facilitate it with the latest development kits.

We are talking, possibly, about the chip that was first started to be developed for SS. Of the documentation available is the one with the oldest date, since 1993. It is curious, that it was not 100% ready for launch, with one of its most powerful features 3D sound.

I’ve been looking at the Sound Tools. And I’m still in shock! I thought you could only use the “Linker” and “eLinker” with a Sound Board or Sound Box. But it seems (because I have not tried it) from what I have seen in the basic use of the tools and reviewing official manuals, it could be used without extra hardware.

What has really shocked me is the topic of Qsound and Yamaha3D. The “eLinker” is the one that has them available, apart from other modules present in the “Linker” but with more options. The one that interests us the Reverb module. In both “Linker” has the basics apart from the preset according to type of “room”.

Today I know a little more about the great sound of the SS. I confirm major issues, such as checkout facing developers. It was indented by SEGA and Yamaha. I understand that the Hardware was not essential, but to access these features you had to have the software and the Apple MAC, at least. It was already an investment. And if you also wanted the advanced module, pay something more. And even royalties, 30 yen put by title. Or so I have understood when translating the legal texts.

In the documentation it is said that as of 02/28/1995 it was not yet available. And the oldest date of the documentation in this regard is 03/08/1995 of the eLinker. These dates mean that it could not be used for the launch, and that it was still in development during the pre-launch and first wave of games. And that I am here for the second wave with the SEGA 1.31 driver, delaying its use, knowledge and customer perception in games.

While on PSX the final sound characteristics were out.

Finally add. That all these tools for the sound DSP are programs optimized by Yamaha. It also seems that there was the possibility of programming directly on it, with an assembly language that SEGA documents further on.

Was this disadvantage finally resolved?

YES and NO. Yes, because the SS hardware was fully capable. In fact more capable than the PSX. No, because at least I have not clearly seen (heard) the use of it in many, clearly only in SEGA Rally in the tunnel of the second level. And for this analysis some more that I will list later as possible.

I can list games where at least QSound or Dolby Surround are known to be used, which are two sound technologies where there are Reverb or Echo values. In which levels or parts I do not know, the truth.

I have come to detect, in some cases clearer and in others less, up to 9.6% of the total number of games analyzed.

I’m sure you should see more. But with the current emulators it is the most I could determine.

It is true that I have detected sound DSP activity in the vast majority of titles, in many over 35%. In which I know the effect is used about 90%.

Here is the list of what I found:

Games where it seems that there are:

  • Stellar Assault SS → Start intro
  • Touge King – The Spirits (1995-11-10) → In tunnels97/98
  • Sega WorldWide Soccer→ Only in menus. Music + voices in music all with echo and reverb
  • Robotics: Cybernation Revolt
  • From TV Animation Slam Dunk: I Love Basketball
  • Touge King – The Spirits / High Velocity: Mountain Racing Challenge
  • Linkle Liver Story
  • Panzaer Dragoon Zwei → areas with tunnels or caves
  • Dragon Force
  • Mortal Kombat II
  • The Story of Thor 2 / The Legend of Oasis / Thor: Seireioukiden
  • Fatal Fury 3
  • NiGHTS into Dreams
  • NBA Action 96
  • PriCla (Princess Clara) Daisakusen
  • Sega WorldWide Soccer 97 / Victory Goal ’96
  • NBA Jam Extreme
  • Shining the Holy Ark
  • Drift King Syutokoh Battle 97 / Shutokou Battle ’97: Tsuchiya Keiichi & Bandou Masaaki (1997-02-28) → In tunnels
  • Manx TT → In tunnels
  • Touge King the Spirits 2 (1997-04-18) → In tunnels
  • Sky Target
  • Salamander Deluxe Plus Pack
  • Söldnerschild / Soldnerschild
  • Super Robot Wars F
  • Super Robot Taisen F Kanketsuhen
  • Devil Summoner: Soul Hackers
  • NBA Live 98
  • Devil Summoner Soul Hackers: Akuma Zensho Dainishuu
  • Panzer Dragoon Saga → Sure, .exb files and in the first room the steps and fx resonate alongside music.
  • Burning Rangers → In game 3D.Music and voices all with echo and reverberation
  • Techno Motor
  • Dragon Force II
  • Code R (1998-07-09)
  • Radiant Silvergun

QSound – 2D Games

  • X-Men: Children of the Atom (1995)
  • Street Fighter: The Movie (1995)
  • Arthur to Astaroth no Nazomakaimura: Incredible Toons (1996)
  • Ide Yousuke Meijin no Shin Jissen Mahjong (1996)
  • Street Fighter II Movie (1996)
  • Super Puzzle Fighter II Turbo (1996)
  • Tenchi wo Kurau II: Sekiheki no Tatakai (1996)
  • Mega Man X3 (1996)
  • Night Warriors: Darkstalkers’ Revenge (1996)
  • Street Fighter Alpha (1996)
  • Street Fighter Collection (1997)
  • Marvel Super Heroes (1997)
  • Cyberbots: FullMetal Madness (1997)
  • X-Men vs. Street Fighter (1997)
  • Pocket Fighter (1998)
  • Marvel Super Heroes vs. Street Fighter (1998)
  • Vampire Savior: The Lord of Vampire (1998)
  • Street Fighter Zero 3 (1999)
  • Dungeons & Dragons Collection (1999)

QSound – 3D Games

  • Madden NFL 97 (1996) → Announced but not verified.
  • NiGHTS into Dreams (1996) → Announced but not verified.
  • SEGA Rally Championship (1995-12) → In Tunnel 2nd Level.
  • Sonic R (1997) Tunnels → Announced but not verified.

Dolby Surround

  • FIFA Soccer 96 (1995) → Announced but not verified.
  • Road Rash (1996) Tunnels → Advertised but not verified.
  • Shockwave Assault (1996) → Advertised but not verified.
  • Madden NFL 98 (1997) → Announced but not verified.
  • Croc: Legend of the Gobbos (1997) → Proven release.
  • FIFA Road to World Cup 98 (1997) → Announced but it seems that in the end not included
  • World League Soccer ’98 (1998) → Announced verified.

As usual we are left with a team that represents this point well:

  • SEGA Rally Championship

    Launched on 1995-12-29. I distinctly remember seeing this game launching in Europe around the same time. I arrive at the video game store in my town “Legend”. At that time the PS1 had already conquered many people with Tekken and Ridge Racer. Against the VF1 and Daytona USA 1, they looked worse in comparison. I even remember that Shinobi X and Bug came out! That they raised their spirits a little with Saturn in that early war. Against lost battles of Rayman’s intro and the first Dragon Ball Z, clearly inferior in SS compared to PS1. But Sega Rally when it got on and it looked like the arcade, smooth and with the same graphics (very much alike let’s really be honest at the time). All mouths were closed. And suddenly the Saturn had the momentary lead over PS1.

Sega Rally was an arcade that became classic, at the level of Outrun, just out. SEGA was at that time touched by the hand of God. And this arcade was one of his incredible successes. The Model 2A board was already hitting hard at the time. And well, it doesn’t take long to get to our houses. It developed in less than a year. Considering that the arcade came out on 02-1995. With the luck that at this point the SDKs were already somewhat more mature, not like in the case of Daytona USA.

AM3 led by Tetsuya Mizuguchi achieved a perfect conversion. With licenses of course. The original resolution was 496 x 384 and for SS they maxed out in its 15BPP 352×256 mode. Possibly it could have gone to 640×480 at 8BPP since this game has no lighting with Gouraud. If it has some kind of lighting, which I don’t believe either, it is flat, which can be reproduced in 8BPP with paddles. And that also all your graphic information is 4BPP or 8BPP in color. Anyway. Sega Rally in SS runs at fully stable 30FPS. Giving a sensation equal to the original in everything, movement and physics. Coming to put on screens 900 quads without problem. On the other hand, VDP2 is being used for the UI and for the background of the horizon rotated with RGB0.

This is one of the few games that we know for sure that Qsound is using available via hardware in the SCSP-DSP. Positioned sound and reverberation in tunnels is easy to perceive in-game. And surely it is thanks to this. We see high-sound DSP usage up to 70% of memory. As a curiosity there are three different sound drivers in this game:

– sddrvs.dat: @Driver Ver-1.31 06/95/20 SATURN (S) sampleNao Kas V0.00c

– esddrvs.dat: @Rally 10/18 Nao SATURN (S ) CHECK Nao V0.07 Kas V0.00c

– p2sddrvs.dat: @Driver Ver-1.40 SATURN (S) CHECK Nao V0.07 + 10/18 Kas V0.00c

The use of hardware as it could not be less is outstanding. 2xSH2s are being used, and typical usage signs of SCU-DSP are seen. On the other hand, the use of main memory is 80% LRAM and 70% HRAM. The VRAM of the VDP1 is used in 85% while the VDP2 is in 60% of the VRAM and 60% of the CRAM.

  • NiGHTS into Dreams

    Released on 1996-07-05. I also have the memory of seeing this game recently arrived at the video game store in my town, with the 3D controller, if I remember correctly. Well what I do remember were the owner’s fights to play it (Mari Paz) with her partner of the moment (Fernando). Look, if I remember correctly, at that time the Ristar was hitting hard there too and so Maripaz had a better time.

Anyway, talking about NiGHTS is talking about Yuji Naka’s second attempt to get him to play the lottery as with Sonic. It was close, you have to admit it, but it did not reach Sonic. NiGHTS has personality and charisma. But as a game it does not finish being defined as clearly as Sonic at the time. Technically it is faultless for Saturn and the moment. And at the art level, it is brutal. Capture the childlike essence of dreams. But as a 3D game and for the moment, perhaps the public was expecting a platform in some way. And of course a Sonic. Perhaps all of this added up made NiGHTS a temporary thing. And not memorable. I even have a better memory of Ristar at the time as a pet than NiGHTS. I don’t know, it’s my impression.

NiGHTS is the only game in which I have been able to perceive that it does a load while it is running 3D graphics or processes. A kind of transparent charge, like Crash Bandicoot does before entering the levels or the C: SoN charge between parts of the castle. I don’t know if there are more examples in SS, on PS1 we know some more like the Soul Reaver itself.

NiGHTS is almost at the maximum possible resolution of the VDP1 in 15BPP mode: 352×240. The maximum is the variant pal 352 x 256. Still it is very good. The game runs at fully stable 30FPS at all times. And the maximum amount of on-screen geometry is around 700 quads of which 90% have Gouraud for bake or depth cueing or dynamic lighting. All 3D elements have a Depth cueing function, but 3D elements using Gouraud and billboards using a color palette change.

NiGHTS has Gouraud multi-color and source-source dynamic lighting. Only in the main characters, but it is still extremely spectacular for the moment and the machine. Maybe one of the reasons for the good performance even with lighting is that the NiGHTS engine is using the SGL libraries, possibly the 2.x that already had dynamic lighting,

Transparencies / ECC / LCS-Ins The Sonic Team was not going to stay I cut trying to put the Sega Saturn to the limit. And since they did not go for all with the transparencies. This makes use of all the possibilities that the machine gives. Thus we can find half-Transparency of the VDP1 in some billboard elements.

The transparency capabilities of VDP2 are also used extensively, from transparency by layer in NGB1 over the background. Or even better with the color and ratio calculation feature with elements from VDP1 over VDP2. Here it is used for example for VDP2 RGB0 plane fading effect on enemy phases. Or cool effects like a final enemy that becomes invisible against the total background of the VDP2 giving a portal or disappearing aspect to another dimension. This last effect is achieved using the extended color calculation function, which allows for blends between more layers. They may even have used the Line Color effect inserted in the start menu. But this one is more difficult to detect since no emulator points it out in their debuggers.

Of course the mesh mode of the VDP1 is used extensively in 3D elements and even simulated in the VDP2 in the NBG3 layer for the Nights vortex effect.

The sound in NiGHTS was not neglected. We can see in the driver that the main programmer (A.Miyazawa) takes care of it. Not typical SEGA sound driver authors. It uses CD-DA music, but also MIDI using all the channels of the sound chip in addition to DSP effects. On the other hand, this game is listed as one of the few that Qsound uses, the truth is that it is difficult to perceive during the game. Finally the possibility that you use some sound with ADPCM. Since on the CD we can see .adp files that are ADPCM files from the SS SBL library.

Where I am sure I know that ADPCM is used for the FMV audio stream. NiGHTS is the first, it sounds really good and also this Stereo. On the image side, the compression of the image stream is medium, showing the compression artifacts more than the intro’s great CGI deserves. The resolution is very good 320×200 approximately. Possibly at 15FPS. Since it is not a standard SEGA CPK container. If you can see the version in the header in this case Film 1.08. It is rendered in a VDP2 layer at 24bits of color which does not lose colors. As a final curiosity, add that NiGHTS is one of the few games that is in CD-XA format, with the second track in MODO2 / 2352. And .adp and .cpk tracks cannot be read normally in this CD format. Which also already indicates that it is ADPCM XA secure.

The use of the hardware is superb. Use 2xSH2 for both FMV and 3D. According to a Segaxtreme user using 100% of the SH2 slave at specific times. There are weak signs of SCU-DSP usage, possibly for transfer from Bus-A. We are talking about the LRAM at 95% and the HRAM at 90%. The VRAM of VDP1 at 95% and that of VDP2 at 70%. Finally, the CRAM of the VDP2 is at 75%.

  • Shockwave Assault

    Released on 1996-07-05 as a 3rd wave development by a developer from the USA. Shockwave Assault is still a medium port of an original 3DO title, possibly the best version. After a year it was simultaneously ported for PC / PS1 and finally for SS with half a year of difference with respect to the previous ones and almost two years with respect to the original. At least the advantage was that it came out with the original missions plus the expansion. That in the other versions they were sold separately.

At a resolution of 320×240 at 15BPP like the other versions. Although that color depth is only reached in the VDP2 layers in VDP1 the elements are mostly in 4BPP LUT. The motor uses Gouraud for Depth cueing but not for lighting. Which is present bakeada in the other versions. Also as a curiosity to add that the engine has 3 levels of subdivision or LOD in the field with mip-maps (16×16 / 32×64 / 128×32). It is present in all versions. The game runs at fully stable 30FPS with approximately 400 quads on screen.

The only transparency in this game is the peephole.

On the other hand it is possible that we can have a render-to-texture in the mini FMV and in the radar with map that is seen in the cabin in a layer of the VDP2.

One of the most interesting things about the title is that one of the little ones where the Dolby Surround symbol appears in the game itself. We really don’t know if this is in the audio streams of the dialogues or the cinematics. Or if it really is built into the sound processor DSP. What we do see is the memory usage of the DSP at 35%. Music is mainly CD-DA. Using a fairly old sounding SEGA driver version 1.31 on 06-20-95.

The FMVs of this game are magnificent they are at 320×224 15FPS with a generous bitrate of 1700 kbps, very close to the resolution of PS1 320×240, but of course the PS1 codec is superior in colors and artifacts as usual. The original material already has a very good quality. And the work done with the Cinepak codec is one of the best in the SS catalog, it seems that the PC version shares the same videos. The sound stream also in this Cinepak is excellent, we are talking 22050 Hz at 16 bits and in Stereo. The only downside is that these are rendered on the VDP1 losing the codec’s final color quality. The codec used for the small mission start clips is unknown, although it has very good color and compression quality.

The use of the hardware is correct. Using 2xSH2 for FMV and 3D. With typical signs of SCU-DSP use (25% memory and 26% registers). On the part of the reports, the use of the main ones is at 75% of LRAM and 90% of HRAM. 90% of the VRAM of VDP1. And 20% of the VRAM of the VDP2 and 65% of the CRAM.

7.1 The difficult thing to “see” – EXTRA I Ball: ADPCM and CD-ROM XA

I was finishing, but almost finishing my investigation, I have come across one last interesting “feature” in this particular war: PSX vs SS. Audio compression for FX or Music sounds during gameplay. As we already know the main difference between the PSX and SS sound hardware, is that the first one decompresses and reproduces ADPCM by hardware. While SS PCM.

This topic is even more curious because the rest of the competition, CDi and 3DO, could unzip ADPCM by hardware. In the case of 3DO through the DSP I have seen in its SDK that it was fully supported. On CD-i just like PSX or SNES, completely native. The Jaguar also had a fully programmable DSP, but it doesn’t seem like it gets to the 3DO, nor have I seen any traces of implementation in its SDK.

As a curiosity I have been able to see how years ago in Arcades multiple systems already used ADPCM in some type of quality, not close to CD but acceptable. The earliest of SEGA itself on System16 in 1985. Taito followed SEGA in 1988 with his Taito B badge. The next that I have seen earlier was Microprose in 1990. Highlighting the case of SNK in his famous MVS also in 1990 And later Konami or Data East in 1991. It is curious that SEGA did not have a hardware ADPCM system, although it was partially like its System16 sister.

The advantages of using ADPCM are several. Less space, up to 4 times less, quality practically identical to a PCM. Few resources to decompress. It could be accessed on the fly and stream from the CD. Looping faster and cleaner than CDDA, the latter is still a raw PCM or AIFF. To be able to store more sound on CD-ROM or RAM. To be able to have music or long sounds with low space and high quality. Disadvantages had. It was still a proprietary technology, it seems not very expensive. But few more.

As we can see, again Sony did better in this regard. But it didn’t take SEGA (middle) to fix this situation. Offering from almost the launch (late pre-launch) of the console on its SBLs (from 1994-10-14 before a CSK / CRI development since 1991) first and shortly thereafter also on SGLs, the power unzip an ADPCM or CD-XA stream using CPU unzipping and simple libraries for programmers. All this means, that again, it couldn’t be leveraged for launch during pre-launch development, and first wave of games. This has already left for the second wave, delaying its use, knowledge and customer perception in games. While on PSX he was also from start and pre-launch.

With which CPU or how many ADPCM unzipped with the SBL library? Most certainly with any of the two SH2. In the documentation it is not clear. If you talk about a cost of between 4% to 33% of process for qualities between 11 kHz mono to 44 kHz Stereo.

Comparing the ability to read the flight on the CD-ROM with PS1. PS1 can with up to 8 ADPCM streams (Stereo = 16 mono streams) to 2x hardware CD-ROM. SS on the contrary only 1 ADPCM steam (Stereo = 2 mono streams) to 2x CD-ROM. By hardware it can with up to 2 PCM streams (Stereo = 4 mono streams) to 2x CD-ROM. In the latter it makes sense against PS1 because ADPCM against PCM is 4 times less. Therefore, with the same CD-ROM bandwidth, the SS has a 4 times higher limit when reading PCM.

Someone could say because if reading ADPCM which is 4 times less data, it can only play 1 stream. And the explanation is that SS has to read the ADPCM, save it in memory, and then unzip it via CPU, the PCM results store it in sound memory and reproduce it. Doubling or tripling, if not more, the process with respect to PS1. I suppose that the implementation of the SBL library achieved this result with sufficient robustness and performance guarantee for the moment. Although theoretically, from my point of view, the SS could decompress and reproduce, at least 3 mono streams in ADPCM. More, reading the CD-ROM on the fly I find it complicated. In memory perhaps it could with some more, if they are small files, maximum 4 or 5.

Everything exposed and theorized numerically depends both for PS1 and SS, on the quality of the streams. A stream at 8000hz is not the same as one at 44100hz. The normal was between 11025 Hz and 22050 Hz. Also the standards at 18900 Hz CD-XA Mode C and 37800 Hz CD-XA Mode B. With a standard bit depth of 4bit, which is equivalent to 16 bit real.

On the other hand, Duck’s ADPCM implementation had two qualities. The 4-bit standard and a 3-bit standard that further lowered the kbps for equivalent qualities. We really don’t know how much processing the decompression was taking for the SS. It should be very little, since we found FMV with Duck’s ADPCM using only an SH2 for video and audio.

Already in 1997-98 with the help of CSK / CRI, which already took care of ADPCM in the SBL and SGL library. ADX development, which is an ADPCM, but highly optimized and with better features. ADPCM support for SS software has reached its maximum. We don’t know if it gave the ability to unzip multiple sound files at once from RAM, which would put the balance even more in balance with the PSX. What it seemed to be doing is unzipping up 3 stream on the fly(one of them including data, that is, loading a level while reading another one of stereo music for example) reading from the CD, being able to read several tracks within the same file and make loops without noise, typical of CD- Audio. Minimizing the use of the CPU (about 1%) and the memory for its reproduction. More than enough the truth. Using, I am almost sure, the SCU-DSP for decompression as I have been able to perceive in games that use ADX for streaming or FMV like: Burning Rangers or Lunar 2. Or at least for data transfer between buses.Lastly, it should be noted that the third parties also developed their own file formats and ADPCM “like” decompressors, for sounds or music for SS. Cases like EA, Probe, SNK … maybe some more, but they are the only ones that I have been able to see with clear data. The funny thing about the case is that they were possibly the first SS titles to use ADPCM, both (Alien Trilogy and Road Rash) in mid-1996, a little over a year and a half after the release of SS. The first First party game with ADPCM was NiGHTS on the same date 07-1996. There may be a previous one, but I could not see it.

Was this disadvantage finally resolved?

YES and NO. As we say, YES because SEGA in its basic SDKs (SBL) provided a library to decompress ADPCM and CD-XA, even a stream. Later using the CRI SDK even better, but it is possible that it would be another case of paying more in order to have this feature. The latter I do not know for sure.

Also as we have said, it is seen in many 3rd party games as there is use of ADPCM or XA. I suppose to facilitate the ports or developments between PSX and SS.

AND NO, because we are not aware of CRI ADX, it gave the possibility to reproduce several sounds in the SoundRAM at the same time, and because the decompression is not supported by hardware. Or at least I have no record or I do not know I get to use the SCU-DSP or the same M68x in some effective way in parallel.

Ideally, from my point of view, SH1 in the CD-Rom block on bus A would be the ideal candidate to decompress the ADPCM and send it to the SCSP. Due to its power, dedicated memory and access to CD-Rom reading in the first instance. But the difficulty in using it was enormous because the ROM that controlled it would have to be overwritten first and only doing this was titanium, impossible not but extremely complicated.

What has become clear and practically certain to me is the use of the SCU-DSP by the CRI ADX decompressor, but this is still my assumption when seeing the use of it in many games with ADX such as Burning Rangers.

Another question that remains on this path for me is. If in any audio with ADPCM in SS I get to apply the Filter “Low Pass / High or Pass / Band Pas”, which also had the SCSP-DSP through its modules such as Echo or Reverb. Like the PSX. This filter, “Low or High Pass” was very useful with the ADPCM waves to clean them and get the most of their quality. If they couldn’t hear the sound quite metallic. Although I am almost sure, because I have detected in many videos or games that use ADPCM code in the SCSP-DSP. And to finish with SCSP-DSP, I am left in doubt as to whether it would be possible to use it to decompress ADPCM + Low Filter inside this unit, similar to the DSP of the 3DO. Even if it was a part of the ADPCM.

To finish comment that both Probe (Alien Trilogy) and SNK (Metal Slug) make use of ADPCM in FX sounds.

What we can see in these two cases is that the synchronization is not entirely perfect with delays when starting or ending a sound. It may be a bug with fix, or it is not the best option to use ADPCM for FX. And I know better option to reserve it for long Speech, short voices or ambient music / sound.

I could not go without talking, even if only briefly, about the sound drivers for the SCSP. We can see that the vast majority of all developers used SEGA drivers. Many interestingly early or very outdated versions, even of the first development kits. However, the first parties of course went almost with the most current. And the second parties also with newer drivers. More towards the end and the big companies use the best versions and some companies even have their own driver, or perhaps a customized one. As is the case with Game Arts, Capcom or some internal SEGA studios such as Red and AM2. I expose a small list with theversions official SEGA driver and years that I have seen, they may be missing:

Year D / M   Ver.  New
1994 10/13 1.14 * ADPCM SBL
1.24
1.25
1.27
1.28
1.29
1.30
1995 06/20 1.31 3D Sound
1.33
2.00
1996 01/25 2.04
2.08
2.09
2.08
2.09
07/02 2.10
1997 07/08 2.20 * ADX

I have come to detect the use of ADPCM during the game, not FMV, in 11.2% of the total number of games analyzed. Perhaps few, but many more than the truth expected.

Here is the list of what I found:

Possible ADPCM games:

  • Gex (1995-12-18)
  • Gundam Side Story 3 Kidou Senshi Gundam Gaiden III: Sabakareshi Mono (1997-03)
  • Rockman X4 (Mega Man X4) (1997-08)

Nearly confirmed

ADPCM games: SBL:IMA ADPCM

  • Magic Knight Rayearth (.ADP)(1995-08-25) → ConfirmedDialogues
  • Neon Genesis Evangelion: 1st Impression (1996-03-01) ← Confirmed CD-XA MODE2 / 2336
  • Kuusou Kagaku Sekai Gulliver Boy (adpcm.dat) (1996-03-22) ← Dialogues
  • NiGHTS into Dreams (.ADP) (1996-07-05) → CD-XA MODE2 / 2352
  • Sega WorldWide Soccer 97 / Victory Goal ’96 (1996- 11) ← Confirmed CD-XA MODE2 / 2336
  • Samurai Shodown RPG (1997-06-27) ← Confirmed XA Multistream
  • Sonic Jam (.ADP) (1997-06-20) ← Confirmed
  • Shinsetsu Samurai Spirits Bushidou Retsuden (1997-06-27 ) ← Confirmed ADPCM XA Multi-stream voices
  • Ten Pin Alley (.ADP) (1997-11-15) → Confirmed
  • Kidou Senkan Nadesico – Yappari Saigo wa Ai ga Katsu (.ADP) (1997) ← Confirmed
  • Super Robot Taisen F (. XA) (1997-09-25) ← Confirmed CD-XA MODE2 / 2352
  • Neon Genesis Evangelion 2nd Impression (.ADP) (1997) ← Confirmed CD-XA MODE2 / 2336
  • SEGAta Sanshirou Shinkenyugi (.XA) (1998) ← Confirmed
  • Sega Ages – Phantasy Star Collection (.ADP) (1998) ← Confirmed. Music. Fx possible.
  • Sega Ages – I Love Mickey Mouse – Fushigi no Oshiro Daibouken & I Love Donald Duck – Georgia Ou no Hihou (.ADP) (1998) ← Confirmed. Music. Fx possible.
  • Marvel Super Heroes vs. Street Fighter (1998-10-22) (.ADP) ← Confirmed

EA ADPCM:

  • Road Rash (1996-07-26) ← Confirmed. Music.
  • Andretti Racing (.ADP) (1996-12-20) ← Confirmed. Speechs.
  • Soviet Strike (eng_xa.res) (1997-02-17)97/98
  • Crusader: No Remorse
  • FIFA(1997) ← Confirmed. .STR
    • 22Khz Mono Electronic Arts EA-XA 4-bit ADPCM v1 (mono / interleave) 94 kbps
  • NBA 97/98 (1997)
  • Madden)
  • Nascar 98 (1997)

OKI ADPCM

  • Akumajo Dracula X: Gekka no Yasokyoku (aka: Castlevania: Symphony of the Night) (1998-06)
  • Genso Suikoden (1998-09)

ADPCM Unknown:

  • Metal Slug (ADPCM.BIN) (1997-04-04) ← FXs almost certainly. CD-DA music?
  • Croc: Legend of the Gobbos (.XA) (1997-09-17) ← ADPCM Argonaut?

Confirmed ADPCM games:

ADPCM for FX Sounds from Virtually Unreal for Probe.

  • Alien Trilogy (1996-07-04) ← FX almost certainly.
  • Die Hard Trilogy (1997-02-28) ← FX almost certainly.
  • Hexen (1997-03-31) ← Not confirmed

CRI ADPCM ADX:

  • Deep Fear (1997)
  • Grandia (1997) → use of SCU-DSP
  • Burning Rangers (1998) ← Dialogues and music. → use of SCU-DSP
  • Baroque (1998)
  • Wachenröder (1998)
  • Code R (1998-07-09)
  • Lunar 2 – Eternal Blue (1998) ← Dialogues and music → use of SCU-DSP
  • Device Reign (1999)

IMA ADPCM Standard:

  • Street Fighter Zero 3 (1999) ← Music. FX?

Duck Audio ADPCM:

  • Most games with Duck codec for FMV in their audio stream.

Finally, as we have been doing throughout this journey, let’s keep a last trio of chosen to exemplify this point with a few good games that used it in SS:

  • FIFA 98

    Development of the end of the 4th wave. Posted on 1997-12-17. We can see how the third partys already had a remarkable control of the machine, in this case Climax in charge of this port.

In this FIFA, the problem as in other ports is not how the machine is used, because it is doing very well. If not the level of finish and polish end of the game. Being a port of the PC and PSX versions, which was also subcontracted to another external team, it caused that as in FIFA 97, this FIFA 98 did not do justice to the machine, nor to the large sum of work in each of its sections made by the external team. Less time for full development. No time to redo parts to run correctly on a different system like SS. Perhaps starting later and with the project data overdue. But with a similar or very close release date. All this can be seen in small details or total loss of great features that were in PC / PSX, and that SS could have had without any technical problem, such as: Meteorology (implemented at the selection level, but not visually), final adjustments in animations and menus, proportions of 3D assets, camera positions and visibility, Dolby sound (announced but not the final game), ground with horizon gradient (totally possible with the VDP2 and seen in WWS for example) and taking Some magnificent FMVs (of the best in the system) have scaled them to full screen (totally possible through the VDP2 zoom).

However, as we say Climax shows that he knew the machine and in FIFA we can find how they take advantage of all the available processors according to the situation. For FMVs as usual with EA codecs, in this FIFA with a video at somewhat less than apparent resolution, but equal quality. Apparent because it is still at the top of the codec in SS 304×144, but when reproduced in 352×256 SS mode it seems even smaller. Using the 2xSH2 + SCU-DSP combo, the latter using 70% memory and 39% registration of the SCU-DSP. Possibly I know this using the SCSP DSP for some kind of sound filter. Which in the video is most likely PCM.

Already in the 3D engine part, in this FIFA, we did not find use of clear SCU-DSP, there is a program in memory but SSF does not indicate that I am using it. 2xSH2 is used for 3D. Perhaps the SCU-DSP is being used for the decompression of comments or ambient sound, which are almost certainly in EA’s proprietary ADPCM format. But this is an assumption of mine today. We keep finding signs of SCSP-DSP usage in the 3D engine, possibly for the same sound filters. Because I miss or reverb I could not clearly perceive it. Also curiously this game was advertised on its cover as Dolby Surround, but afterwards there is no trace of it within the game.

Detail that LOD models are used for players and shadows, helping the game run between 20 / 25FPS on open fields. I have not been able to quantify the number of polygons in this FIFA, but we could say that it will be between 1,000 and 1,200 minimum quads (maybe more), if we count the RGB0 equivalents, it would be about 768 more. This game could be over 2000 quads. On PSX I have seen maximum figures of 6,000 triangles, about 3,000 equivalent quads.

On the covered fields during normal play it also stays at 20 / 25FPS, however in replays the FPS drops to around 12FPS when the Crystals are in the foreground with the VDP1 half-Transparencies filling the entire screen or even with others elements that are overlapping behind.

As a curious note, distant Crystals only have Gouraud. The closer they are, these pass to Gouraud Shading / Gouraud Shading + Half-transparent. Climax looked for a way to minimize the burden of this effect.

Yes, FIFA 98 uses VDP1 transparencies a lot, and quite well. We have a use of transparency VDP1 in the pause UI and TV signs without artifacts as they are orthogonal rectangles but without working against the elements that are in VDP2. Like the field on RBG0, the shadows of the players, and some parts of the field lines. These last two features using transparency from VDP1 to VDP2.

As a curious fact in this game the developers use the transparency of VDP1 to VDP2 with the shadows in a very original way. Shadows are Quads with Gouraud, and the gradient values ​​resulting from Gouraud himself are then used with the VDP2 color and ratio calculation values.

The use of memories in this game is remarkable. Reaching 70% of main RAM, 95% of VDP1 and 60% of VDP2.

The menus are in high resolution HD 704×256, although the VDP2 backgrounds are 512×256. You haven’t taken full advantage of the VDP2 for the menus. I even have my doubts, if they could have used VDP2 transparencies instead of the mesh.

As a final curiosity to point out the use of VDP2 bitmap at 1024×256 in the startup licenses. I have rarely seen that mode used. Although it seems that the image is not at that resolution really, or it has not adjusted well at least.

  • Deep Fear

    Released 1998-07-16 This is already a 5th wave game. Last year practically in Europe and the USA. In Japan there was still up to three more years of life, of technical development perhaps less 1 or 2 maximum.

Deep Fear is the Resident Evil 2 that didn’t make it to SS. Or so I saw it at the time. Technically it is very far from the Capcom saga. But SEGA produced an exclusive product of remarkable production quality (dubbing would not fall into this XD category), not perhaps also in technical quality, but well something is something.

Running at a resolution of 320×256 15BPP although the graphic data is at 4BPP on VDP1 and 8BPP on VDP2. at stable 30FPS. With remarkably modeled and textured models. With somewhat robotic animations. I have come to see about 700 quads on the screen, maybe more. VDP2 is used for backgrounds, UI, and inventory.

The game has Gouraud font lighting with color on all 3D characters and entities. Dynamics when there are shots. And there are not many light sets during the game either.

It is strange that this game does not use absolutely not a single possibility of transparency of the machine. Weirder even though for example in the shadow of the characters it would have been totally possible as in Resident Evil, as well as very easy with the color calculation function plus ratios with elements of the VDP1 over the VDP2, the backgrounds mainly. The only “transparency” effect that we can see is the change of color offset for the alarm, underwater or gas effect. For the rest a pity, a type of game that gives to show off these

The sound, saving the dubbing is very good. Using ADX for music and dialogue at excellent quality. I think also some bigger sounds like doors. Showing very high signs of DSP usage over 90%. With almost total security to echo and reverberate the stages. The sound driver used is version 2.01 of April 1997.

The FMVs in this title are very numerous. The quality of them is remarkable. And the perfect Duck codec choice. It is used in its 16BPP mode, but frankly it is perfectly compressed, the dithering is almost negligible and the artifacts practically non-existent. The image and sound quality used is a perfect agreement to be able to put all the immense quantity of video in a single CD. At 320×176 at 15FPS with a framerate of 1200Kbps plus the audio stream with the Duck ADPCM 4bit codec at 22050 Hz Stereo. Rendered on VDP1 all CGI work looks great on the SS.

The use of hardware at these heights of life of the machine is very high. The two 2xSH2s are being used for both FMVs and 3D. There are strong signs of SCU-DSP usage, in this case up to 60% memory and 18% registers, possibly for ADX audio. On the part of memory, 55% of the LRAM and 75% of the HRAM are used. Up to 65% of the VRAM of the VDP1. And 45% of the VRAM and 45% of the CRAM of the VDP2.

  • Street Fighter Zero 3

    Released 1999-08-06. It is already one of the last titles developed for the system. You could count it as a game of the 6th wave of developments of a Japanese team and in this case of a great Third party… of a great saga. And of a game that cannot run on a better system than the SS.

SFZ3 has been ported before on PS1, almost a year earlier. But the SS version used the 4MB expansion cartridge, which already has more RAM, and got a version almost identical to the arcade and superior to the PS1. Both in number of graphics and load times.

The resolution is 352×224 at 15BPP although the original content is at 4BPP over the 24bit CRAM of the VDP2, the original is at 384×224 this resolution is not supported by SS. So they chose the maximum and closest to the original. PS1 however is at 368×224 in between the two. PS1 anyway supports the resolution of the original arcade, possibly to save memory they decided to lower it somewhat. The game runs at 60FPS perfectly. No more than 400 quads are seen on the screen.

This game does not have transparency in its original version. If so in its PS1 version. In SS there is some transparency in the initial menus, but the rest of the game uses mesh mode for transparencies like in the arcade.

The sound look like any Capcom title and even more so in an SF it is awesome. We also found that they are using IMA ADPCM Standard. I really don’t know if it’s the SBL implementation or some kind of license Capcom acquired. What I can say is that the sound quality is brutal. I also do not know if I also use it for FX, possibly for voices almost certainly. The driver does appear to be the SEGA official. One of the latest versions I have seen 2.2.0 July 1997. We can also see incredible MIDI music usage in the menus. Finally we can see a DSP memory usage of up to 35%. We can also perceive a reverb or echo effect during the game, you may be using the DSP for it.

The only FMV in this game is the Capcom logo at the start. A mythical animation. Cinepak + PCM quality is perfect: 320×224 30FPS plus PCM 44100Hz 8bits Stereo on the VDP2.

The use of hardware is brutal. Of course 2xSH2 is used for both FMV and 2D play. The main RAM is 60% LRAM and 75% HIRAM. The VRAM of VDP1 at 95% and the VRAM of VDP2 at 95% and the CRAM at 95%. Of course occupying the expansion cartridge.

9. The difficult thing to “load”: Loads the game without stopping

In the final section of this investigation. And with the shadow of the always Castlevania SotN, I decided to look at this feature. Later on seeing an interview to the main developer of Crash Bandicoot for PS1 and a video of Digital Foundry about Soul Reaver, I thought again about the subject and tried to investigate. Later also by @zyrobs comment in one of the posts.

I also remember that @XL2 was dealing with SEGA’s official load/CD library for SS. And although at first it did not get good results. He managed to load at full system speed in the end. Level loads in your game are very fast. And he fills up a lot of RAM in various wells.

In conclusion we could say that the SEGA library was fast, but perhaps better documentation, examples and of course access to the source code are missing.

Was this disadvantage finally resolved?

In this case as in another in SS. Sadly not. Despite having a fairly competent but closed library for CD loading. The most daring developers did not have it easy, to be able to use it together with the ADPCM decompression or upload or download of graphic data.

Perhaps this is why we find Castlevania’s infamous case of cargo aisles that are not. XD

But like everything in SS again, it was possible. Even more here. SS had a super powerful CD-Rom block. Without having hardware ADPCM capability. It had a powerful processor and memory where no other system had. In fact in many games where the loads are “normal” the SS does it much faster. Even loading even more data than on other systems.

There is another area to explore for the homebrew and the scene.

I really do not know games that have dynamic loading in SS in a totally safe way, here is a possible list:

  • NiGHTS into Dreams.
  • Grandia, possibly.
  • According to @zyrobs Scorcher, he charges on the fly during the race. I am not so clear the truth.

However at least the following are known on PSX with complete certainty:

  • Soul reaver
  • Crash Bandicoot
  • Castlevania: Symphony of the Nights
  • Most likely more.

Conclusions:

The clearest. SS and PSX were (or are, depending on how you look at it) two extremely similar machines at the end of the day. Both in the final and / or real figures. As in the way of doing things. Other consoles from that time also shared ways of doing things as we have seen.

In this way, I have been able to break many myths on both sides. And now more than ever, I appreciate all the work of the people behind the companies that brought about this historic moment.

I would like to point out that it is not a matter of lamenting anything, but of solving doubts, or trying to find out where the SS did not arrive, could or could arrive.

As we see after all this research. SS was a great machine. Domestic SEGA engineers literally did everything they could and knew. SEGA was SEGA again and gave it their all. In ambition there was no one like them, perhaps even today but much less.

What I am clear about is that the product of what they did, even today. It has both a unique look and sound. There is no console that looks and sounds like the SS. With its pros and cons. Coupled with the absurd complexity within it. I think it is the perfect machine for mischievous and curious minds. And for an almost infinite homebrew.

Otherwise, it is a console that I recommend, of course, to anyone. With unique titles, a lot of originality and fun to offer. With 2D games and very good conversions. In addition to exclusive and of course great 3D games.

Also from here to thank the community for their support, there are many more, here is a list:

And recommend participating and supporting emulation projects like:

Thank the current and historical developers. I would like to signalize, Thanks to this commit, I have been able to see the “polygons” on the screen of the games.

Thanks to Yaba Sanshiro I have been able to determine the FPS of many games.

In its latest versions it is easy to see the use of the configured CRAM color mode, the use of the gradation function and LCS Insertion. And also with the wireframe mode the tessellation or subdivision or LOD.

Or open source SDKs, there may be more, here is a list:

Epilogue:

  • I am going to pause this personal project. I will do there any updates and corrections that I already have prepared. Especially in the first part and second part. But I don’t know when exactly.
  • I will now dedicate myself to making 3D and 2D art for the SS homebrew community. And another great project;) that I have quite developed.
  • I have thought about the possibility of making a book of all this. Several people have asked me directly. If there are more interested people leave me a comment in the post or send me a message through the form. Right now I have almost 230 pages in the master document. And hundreds of images in my archive. By laying out and adding some of the tables that are online, there could be a nice book with a minimum of 400 pages, about 500 calculations. Of course the idea would be to edit it in Spanish and English. I would look for a professional translator for it. But for now let’s see the interest you have and I’ll be seeing.
  • There have been games to analyze more deeply or pending games in its entirety or a large part: About 90 of the 324 totals. It’s something that doesn’t really concern me. If someone wants to help, all they have to do is request access to the online table and edit it. If I see something very interesting, I may update it. In principle in the short term I do not think.
  • There are still things to discover. Thanks to the emulation with their debuggers, this possibility of getting where I don’t know once did is a reality. And now with the retro SS scene so alive it’s even more likely.
  • I have questions to notable developers in SS. I have a list of programmers, technicians and artists. With specific doubts. Who knows … From
  • My point of view there is still room to reach and break technical milestones. Also I see them as goals that homebrew can set and break, because SS has this capacity. Given its complexity and power in many of its parts. I will make a list under my humble vision:
    • Best BR trick: resolution and clipping.
      • It is true that XL2 has already passed it. But as more challenges I see:
        • Raise the resolution, not to the maximum but something more.
        • Improve the clipping and overlapping of opaque and transparent parts.
      • Of course:
        • Document it
        • Create a robust library: That allows the maximum of transparencies in the system combining everything.
        • Create examples for 2D and 3D games.
    • Max. Polygons and lighting
      • Again XL2 has set the bar here already very high. But he himself says that something more can be done.
      • Honestly, what I think is necessary is to have some open libraries that standardize the use of this part in SS. At the homebrew level. And to be able to combine all the processors in the best possible way within a standard pipeline. For example, like the PS1 GTE, which had well-designed and specific macros. Have something similar for the use of the SCU-DSP or SH2 as DSP.
    • Max. Resolution BPP FPS
      • I am a little stubborn I know. Some when you read it, you will say: You can’t! But to be able to have 512×256 in 16bit mode on VDP1. Any hardware trick or secret registry? Some like the ones that the great Charles MacDonald discovered.
    • Dynamic Skeleton Animations
      • These types of animations are expensive for these systems. They were seen in many AAA games. Like EA sports. Fighting games used it. But a fast open bookstore I have not seen. I think it would be useful for the homebrew community. In the last titles of PS1 it was seen in many 3rd person or even 1st use this type of animation so spectacular.
    • Render-to-texture
      • A big challenge:
        • Make a library to be able to use it with both VDP1 and both VDP2.
        • Getting effects of:
          • Giant TV.
          • “Full-screen effects”: Fades, distortions, pseudo-motion blur …
          • “Refractive effect” like the ninja of Metal Gear Solid 1 on PS1.
          • “Environment mapping” as crystal in Tomb Raider 1 or other assets in TR2 on PS1.
          • “Shadow mapping” like Crash 3 and Tony Hawk’s Pro Skater on PS1.
    • FMV DCT
      • Well, here are three challenges:
        • Getting Cinepak + ADK and having an open source player. To be able to replace in game translations or new games.
        • Get to make a codec and player for Duck Truemotion 1 for SS. Since the codecs that are public are limited without 24BPP mode, for example. To be able to replace in game translations or new games.
        • Get to make a DCT-based codec like EA or Softdec optimal for SS. And try to achieve the MDEC quality of PS1.
    • Sound
      • ADPCM +FX in SoundRAM
        • ADPCM in general: Getting make a codec and optimal open source player like ADX, maximum 3 streams and data loading. That use the available processors to unzip. To be able to use it in new games.
        • Being able to have FX in ADPCM on the SoundRAM like the PS1 to be able to have more sound and more quality on the SoundRAM. It seems that in time some developer did something.
      • Chorus / Reverb easy
        • Being able to use the chorus / reverb DSP effects easily for scene developers.
    • Dynamic CD loading of data during game play
      • Open source and optimized for CD use in the system taking advantage of its enormous capabilities.
    • I’m sure he will leave me more things. But there is still my current vision today.

References:

(Not everything, I will try to complete it)

 

Blogs:

https://news.ycombinator.com/item?id=10963796

Games database:

http://SEGAretro.org/

http://psxdatacenter.com/

Online documentation:

SEGAxtreme

antime.kapsi.fi

SEGAretro

Exodus emulator hop the Japanese online documentation

Forums:

Anandtech:

Exophase at AnandtechForums

SEGA-16:

http://www.SEGA-16.com/forum/showthread.php?26920-Games-with-3D-graphics-running-at-60-fps-5th -Generation-Consoles

Youtube:

SEGA Saturn Graphic In-depth Investigations (English / French subtitled)

https://www.youtube.com/watch?v=f_OchOV_WDg

SEGA Saturn Video Formats (English / French subtitled)

https://www.youtube.com/ watch? v = ev7x8MwLq2A [

Glossary:

(to finish, not important now)

* LOD: Level Of Detail. Create several models of different detail, number of polys, for a specific model. To replace depending on the distance to the camera. This effect is perfectly visible in FIFA 98.

 

End, finally XD

15 comments

  1. Pingback: Sega Saturn to the limit (IV) | David Gámiz Jiménez | Portfolio and Personal Site
  2. Pingback: Sega Saturn to the limit (I) | David Gámiz Jiménez | Portfolio and Personal Site
  3. Pingback: Sega Saturn to the limit (II) | David Gámiz Jiménez | Portfolio and Personal Site
  4. Pingback: Sega Saturn to the limit (III) | David Gámiz Jiménez | Portfolio and Personal Site

  7. Pero que pedazo de artículo, jamás creí encontrar algo así en español, llegue accidentalmente buscando info de los codecs de video de la SS, al recordar el opening del juego Burning Rangers, que se ve increíble para la media de intros en la SS y tenia la impresión de que era SoftDec + ADX (era Cinepak + ADX) quedé sorprendido de que ya se implementara en la SS, siendo mas familiar en la Dreamcast.

    Recuerdo que hay unos juegos tipo Anime/Eroge en la SS, que tienen los videos mas limpios y prefectos en el sistema, ojala su hubiesen utilizado en los demás juegos que usaban Anime en sus intro o videos in-game.

    Quiero un Libro!!!
    me encantan los libros de temas técnicos de consolas/pc retro y con imágenes!.

    Saludos desde un rincón lejano llamado Chile

    Reply

  8. So you’re actually going to write a thesis about Saturn, wow !

    “GunGriffon (1996-03) → Flat polygons with transparency in VDP2?” : yes, they seem to use that for the depth fog effect on the VDP2 background.

    “Sonic R (1997-11) → in the last circuit, which is transparent integer. Does it have fewer levels of gradient in the fade or does it not?” : the last circuit doesn’t use the progressive fading of sprites in the sky background (NBG0), because NBG0 is blended with 2 different ratios with RBG0 (the emerald shine) which is behind it :
    – 31:1 by standard color calculation when NBG0 is the top layer, when it isn’t behind sprites, which make RBG0 almost invisible (you can see it very faintly if you look carefully in dark areas of NBG0).
    – Half transparency by extended color calculation when NBG0 is the 2nd layer, when it’s behind sprites.
    If the programmer had enabled the progressive fading of sprites, the half transparency blend of NBG0 and RBG0 would have become progressively more visible as the sprites faded, making RBG0 very visible in an area where the sprites are almost not visible. This wouldn’t be coherent since the emerald shine should fade with the emerald track drawn with the sprites.

    Doom doesn’t use the line color screen for depth queing, it blends VDP1 graphics with a black NBG.

    On the contrary, Steep Slope Sliders is doing it’s depth queing effect by blending polygons with the Line Color Screen.

    Some more games that do (basic) render-to-texture :
    – Bug too ! : VDP1 frame buffer used as VDP1 texture in pause screen.
    – Virtual Hydlide : VDP1 frame buffer transferred to VDP2 layer in menu and map screens.

    The sprite framebuffer itself can generally be considered a type of render-to-texture since VDP2 post-processes it to add graphics and effects. The framebuffer can even be transformed when it’s a rotation type. In that case, VDP1 applies an affine transformation using part of VDP2 rotation parameter A, when it streams the framebuffer pixels to VDP2. Some examples :
    – Capcom Generation Vol.4 : 90° rotation and downscale in all the games with screen mode 1 or 2.
    – Hang-on GP : horizontal stretch, and rotation when turning.
    – Power drift : rotation when turning.
    – Shienryu in Sega Saturn mode : 90° rotation and downscale.

    About Sega rally, “VDP2 is being used for the UI and for the background of the horizon rotated with RGB0.” : the background is indeed displayed on RBG0 layer, but strangely it rotates only in the US version of the game, when using the cockpit view. In the later PAL and japanese versions, it only scrolls. Special stuff : the background moves at 60 fps, whil the rest of the graphics runs at 30 fps.

    About Nights :
    – “Transparencies / ECC / LCS-Ins” : I haven’t seen any situation where ECC can actually work in that game, either there’s only one layer with color calculation, or the background layer is in palette format and the color ram is in mode 1.
    – “Or cool effects like a final enemy that becomes invisible against the total background of the VDP2 giving a portal or disappearing aspect to another dimension. This last effect is achieved using the extended color calculation function” It’s standard color calculation of the final boss polygons with background NBG0. There’s certainly some palette swap occuring on NBG0 which make it look like it’s animated.
    – “El primer juego First party con ADPCM fue NiGHTS por la misma fecha 07-1997” : Ah, some spanish for a change ! Nights was released in 1996.

    Some games that load during gameplay (having a Saturn with CD led helps to check that) :
    – Crimewave : loads graphics, makes the game stutter a bit especially when using the larger view.
    – Galactic attack : loads only between levels, but manages to do it with smooth animation that transitions from one level to another.
    – House of the dead : loads music and ennemies textures, which get corrupted if the CD drive is in bad shape.
    – Mystaria : loads characters animation before each fight.
    – Panzer dragoon zwei : loads at some point during level, or before boss fight.

    Reply

  10. Debo ser uno de los más devotos de Saturn (tengo varias y una sin abrir desde el 94). Leí cada palabra de cada artículo. Alucinante. No encuentro cómo describir el trabajo que has hecho. ¡Quiero ese libro pero ya!

    Reply

    1. ¡Gracias Germán! ¡Disculpa acabo de ver el mensaje! 🙂 Sobre el libro. Bueno, lo sigo teniendo en mente. Pero entre el curro y la vida, está parado. Cuando tenga un hueco me pondré a terminar de corregir y añadir lo que quiero. Y a buscar formas para publicarlo. 😉

      Reply

  11. Tengo curiosidad por una conversión de recreativa de Taito (un simulador de trenes): Densha de Go! en PSX y Densha de Go! EX para Sega Saturn, las dos versiones normal y EX también existen en recreativa aunque no tengo claro las diferencias.

    En cualquier caso la placa arcade Taito JC parece estar basada en los bastante extendidos Texas Instruments TMS para hacer arcades en 3D en la época, los he probado en MAME pero no en emuladores de consolas.

    Pero hay un par de cosas que me han parecido interesantes:

    1-Mirando videos, la versión PSX me dá una sensación de como se mueve todo en pantalla extraña, la versión Saturn me pareció ese “como se mueve todo en pantalla” mas cercano a la recreativa original, quizas porque se basan los dos sistemas en quads aunque uno sea en vectores y otro en sprites deformados?.

    2-Creo que es el único juego de recreativa 3D no basado en las placas arcade de Saturn o PSX que a veces tuvieron alguna conversion entre ellas, ej “NBA JAM Extreme” o “Ray Storm” de sistema arcade basado en psx pero portados a Saturn. Digo esto porque hubiese sido interesante que más juegos de este tipo con TMS 3xxxx (Taito y Mydway) o las primeras placas arcade 3D de Konami, por decirlo de alguna manera “sistemas imparciales”.

    Reply

  12. Enorme contribución para los amantes de Saturn, muchas gracias. La verdad es que me cuesta entender algunos conceptos de todo lo que has expuesto, pero quiero felicitarte por publicar este trabajo de investigación. Me encanta esta consola y me ha encantado también leer (parte de) tu artículo.
    Apoyo la idea de que saques un libro, ¿Sega lo respaldaría…?
    ¡Un saludo!

    Reply

    1. ¡Hola Gorka! ¡¡Muchas gracias!! sobre todo por leerte, incluso lo que has podido, el tocho que me marque. Es una consola y compañía apasionante. ¡Y qué tiempos! Sobre el libro, ya me gustaría, pero la verdad es que a día de hoy lo veo complicado, no por SEGA no se suele meter en nada de aporte de fans, sino por la vida! jejejej, pero no lo descarto. ¿Cuál parte es la que más te ha gustado? ¡Un saludo! 🙂

      Reply

  13. Perdona el retraso en responderte. Y no hay de qué.
    Aquella época fue especial, recuerdo probar la demo de Daytona USA que me venía con la Saturn y quedarme embelesado mirándola… En un período de transición de las 2D a las 3D había mucha experimentación y el salto generacional se notaba.
    ¿Que qué parte me ha gustado más…? La que he entendido, ¡ja, ja, ja!
    Me ha parecido muy instructiva tu indagación en los polígonos por segundo que podía mover Saturn, con sección dedicada a Sonic R y todo; me encantaba este juego, me lo compraron por Navidad y no paraba de jugarlo. Aunque reconozco que tardé en dominar el control, esas transparencias en los fondos y el resto de efectos gráficos me dejaron boquiabierto.
    También he leído la parte de las transparencias en Burning Rangers. Ese juego me pareció muy entretenido (y corto), con gráficos que iban un paso más allá y es bueno encontrar información sobre cómo consiguieron que Saturn pusiese todo aquello en pantalla. Leí en alguna parte que el Sonic Team utilizó uno de los procesadores de sonido para tareas de cálculo y así liberar las CPU principales para que la consola pudiera con más carga.

    Nada más de momento, seguiré leyendo tu artículo. ¡Un saludo!

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.