Regarding the VDP1 fillrate calculation equation:
k + (x * y * l) + (y * n)
– k is the setup time, the amount of time it takes to read the draw command, set up all the internal registers, read the gouraud shading table (if there is any), set that up, etc. Playstation should also have a value for this, but I don’t know the exact figures.
– x / y are the sprite (texture) dimensions. Important to note that since this is a 2 dimensional values (X * Y), it includes the pixel overdraw.
– n is, according to Steve Snake, an approximate of the sdram cycle miss penalty. It is not an exact calculation, but a good enough general approximation.
– l is 3 cycles, for reading a texture, processing a texture, and writing a texture pixel. If you draw untextured polygons, you should only have 2 cycles here because you only need to process and write a pixel, no need to read textures. But this is just conjecture.
I think what the VDP1 does is, use 1 cycle to read a texture to internal register, 1 cycle to process it, and 1 cycle to write out the data from internal register to framebuffer. This is very inefficient. Yes, this does cut the max fillrate to less than 9,56 MPixel/sec. I don’t know why it does this, maybe a limitation due to the nature of SDRAM, or they just didn’t knew how to do it otherwise. This also explains why semitransparency can be so extremely slow. But for semitransparency, the “up to 6 times” figure may have been a best case versus worst case comparison, best case being untextured pixel, worst case being textured, gouraud shaded, semi-transparent pixel.
I don’t know exactly how the Playstation textures, but from the fillrate numbers it is evident that it can draw a textured pixel in 1 cycle (33,8 MPixel/sec). Maybe this was due to it using VRAM which is double ported (later SGRAM which could simulate this), maybe because it was just a better chip, maybe both.
For the 66MPixel value, it can only achieve this by directly copying pixels in memory without processing. I don’t know if the lack of processing is what doubles the speed, or the fact that such data is always rectangular so it can make 32bit read/writes safely. But you get no shading, no lightning, no deformation, only copy rectangular textures at twice the speed.
By the way you can do gouraud shading in 8-bit palette mode for Saturn. You have to use red colour only gouraud shading on a palette pixel. The 5 bits for the red shading correspond to the palette entry of the pixel. So this way you can ramp up/down the palette index using the VDP1, doing hardware lightning. The downside is that you have to pre-calculate the lightning gradients in the palettes, losing you colour count. The upside is that you can change the lightning colour by updating the palette. I think the cubes in the CD player do this to change colour.
You could even set custom colour gradients, like inversions, to do crazy things like simulate bump mapping. But only one tech demo of that exists.
I don’t think CPU usage can be measured in a percentage, because you also need to spend time using the bus or copying data. Maybe using the Slave SH2 or the SCU DSP at 100% would have made the Master SH2 too busy to process their data, leaving it less time to crunch numbers. A single usage percentage would not account for this. You also need time to upload draw commands to the system. And memory usage is even trickier because half the main memory is slower, and you might not have anything relevant in your game code for that, so you leave parts of it empty.
The percentage calculation is also misleading for texture usage, because textures and draw commands share VRAM. Have too much of one, and the others will suffer. You will end up needing to upload commands twice per frame or upload texture more often between frames, and while you do that, the VDP1 can’t draw anything (you are hogging the VRAM from it by uploading). So you have to balance things out, which leads to lower memory usage on average, to allow for higher peak values in poly count.
Great job on writing up a list of which Saturn games use which texture modes! That’s really fascinating!
And for the most graphically impressive Saturn games, I’d recommend you check out Scorcher. It uses very detailed and colourful textures (easily Playstation quality texturing), semitransparency (rectangular only to avoid the pixel overwrite bug), and decent speed. It is also one of the only games to use both rotating playfields of the VDP2, one of them being transparent. I think each level uses more textures than what fits in the memory, and the game is uploading it dynamically, which explains both the checkpoints and why sometimes they take longer than usual, and a very rare bug where if you race too fast, the game stops texturing for a second. For shading, it only has static pre-baked lightning on the level textures (plus fogging), but nonetheless it looks great because it has so many colours on screen.
Nice article. Emulators certainly are a great way to better understand how these games where programmed, and how they performed.
However, you should use caution when measuring the framerate of a game in an emulator : they are not accurate enough to match exactly the framerate of the same game on a real console. For example, you list Panzer Dragoon Zwei as 20 FPS, but on console it runs at 30 FPS in game and 60 FPS during cutscenes.
Also, I would add another feature that games could use to push the console to the max : using the higher clock rate of 28 MHz instead of the default one at 26 MHz. Increasing that chock makes both SH2, VDP1, VDP2, SCU and their memory faster. VDP2 displays automatically 10 % more pixels horizontally (352 instead of 320 in SD), but you don’t have to draw the additional pixels. That way you can cover the same screen area than at the lower clock rate, but with more cycles per pixel.
Strangely enough, all 3 Lobotomy Software FPS run at the lower clock rate. There’s always room for improvement, even in well programmed games…
Yo tengo una duda respecto a porque Sega Optó por el bendito SH-2 Teniendo otras opciones. Lo ideal hubiera sido un Motorola 68040 a 33Mhz o PowerPC 601.
Creo que les hubiera salido más barato usar un CPU a 66Mhz que lanzar la Saturn con esos dos SH-2 en 1994.
Lo mismo paso con Dreamcast que siguieron con el bendito SH, ya en ese momento había otras CPU Mejores en el mercado como: los Pentium II, Los AMD, Nec, IBM PowerPC G3, entre muchos para elegir.
Para mí gusto la Sega Dreamcast así tal cual está diseñada es una consola para 1997 cuánto mucho. Porque después de ese año sacarla sería un problema tecnológico con las muchas tecnologías que había y mejores.
Mmm no estoy tan de acuerdo con algunas cuestiones, es muy cierto que Sega debió optar por una sola CPU, ir por Hitachi y su SH es algo que comenta Hideki Sato en una entrevista traducida por la gente del foro Sega-16, pero básicamente era por la relación precio-potencia (su unidad MAC era algo interesante), para lo que querían en ese momento estaba bien, después llegó Sony y al ver que se quedaban cortos metieron de todo, sin embargo con respecto a las opciones de Cpu veo lo siguiente:
– Un 68040 parecía la opción lógica y continuista (en su versión LC sin FPU tal vez, sino sería más costoso), pero para encargarse ella sola de la geometría como que no le dá, es como el 486.
– Un PowerPC 601 era demasiado costoso para una consola, estaba al nivel del Pentium I, incluso el PowerPC 603 era costoso aunque más posible, en verdad la opción ideal para una consola creo que era el PowerPC 602 a 66 MHz, pero se anunció recién para Marzo de 1995.
– Sega podría en todo caso haber retrasado la consola un año y usar el Hitachi SH-3 a 60Mhz, también se anunció en Marzo del 95 si mal no recuerdo. Hubiera dado mejores resultados que la dupla compleja de SH-2.
– El MIPS r4200 o r4600 podrían ser opciones, aunque siendo más costosos que los SH, incluso que el SH-3 y el 4600 algo más que el 4200.
– Al contrario de lo que piensas, el SH-4 para la época es una buena Cpu, además consumía poco y era barata. Coincido con lo del timing de que era para 1997 y como muucho 1998 en el resto de mercados, pero por ejemplo si bien a nivel enteros era como un Pentium I, sí, en coma flotante superaba bien al MIPS R5000, Pentium II y al PowerPC 750 (de hecho Nintendo pidió mejoras en ese aspecto a IBM cuando usaron una versión de esta CPU en GameCube), hablamos de un tiempo en el que aún las CPU se encargaban de la etapa geométrica y para esto el chip de Hitachi estaba mejor preparado que algunas de sus contemporáneas.
Mmm no estoy del todo de acuerdo, sin duda Sega debió optar por una única CPU, pero en una entrevista a Hideki Sato traducida por la gente del foro Sega-16, el SH2 se eligió por su relación precio-rendimiento (la unidad MAC era interesante e importante para la etapa geométrica). Con respecto las demás opciones:
-El Motorola 68040 sería la opción más continuista, es como un 486, aunque en su versión LC ya que con FPU es más costoso, sin embargo ella sola para la geometría no daría el mismo rendimiento que un SH-2.
-El PowerPC 601 sería demasiado costoso para una consola, era equiparable al Pentium I, incluso el 603 era costo aunque más posible. Realmente el PowerPC 602 me parece la opción ideal para una consola, pero se anunció recién en Marzo de 1995.
-El SH-3 sería una mejor opción que la dupla de SH-2, pero implica también retrasar la consola un año, ya que se anunció también a comienzos de 1995.
-El MIPS r4600 era otra opción, disponible para 1994, pero más costoso que un SH-3.
Con respecto a Dreamcast, era bastante bueno para su época el SH4, coincido en que debió ser para 1997 (que fue cuando lo anunció Hitachi) y en el resto de mercados máximo 1998, comparativamente a lo que había en su época:
-En enteros rendía como un Pentium I, sí, pero en coma flotante vencía sin problemas a contemporáneos como el Pentium II, PowerPC 750 (de hecho Nintendo solicitó a IBM mejorar ese aspecto cuando usaron una variante para Gamecube) o el MIPS R5000. En una época donde aún la geometría se procesaba desde la CPU, el SH-4 iba mejor que estos en ese aspecto, con instrucciones específicas para esa etapa.
Mmm no estoy del todo de acuerdo, sin duda Sega debió optar por una única CPU, pero en una entrevista a Hideki Sato traducida por la gente del foro Sega-16, el SH2 se eligió por su relación precio-rendimiento (la unidad MAC era interesante e importante para la etapa geométrica). Con respecto las demás opciones:
-El Motorola 68040 sería la opción más continuista, es como un 486, aunque en su versión LC ya que con FPU es más costoso, sin embargo ella sola para la geometría no daría el mismo rendimiento que un SH-2.
-El PowerPC 601 sería demasiado costoso para una consola, era equiparable al Pentium I, incluso el 603 era costo aunque más posible. Realmente el PowerPC 602 me parece la opción ideal para una consola, pero se anunció recién en Marzo de 1995.
-El SH-3 sería una mejor opción que la dupla de SH-2, pero implica también retrasar la consola un año, ya que se anunció también a comienzos de 1995.
-El MIPS r4600 era otra opción, disponible para 1994, pero más costoso que un SH-3.
Con respecto a Dreamcast, era bastante bueno para su época el SH4, coincido en que debió ser para 1997 (que fue cuando lo anunció Hitachi) y en el resto de mercados máximo 1998, comparativamente a lo que había en su época:
-En enteros rendía como un Pentium I, sí, pero en coma flotante vencía sin problemas a contemporáneos como el Pentium II, PowerPC 750 (de hecho Nintendo solicitó a IBM mejorar ese aspecto cuando usaron una variante para Gamecube) o el MIPS R5000. En una época donde aún la geometría se procesaba desde la CPU, el SH-4 iba mejor que estos en ese aspecto, con instrucciones específicas para esa etapa.
Mmm no estoy del todo de acuerdo, sin duda Sega debió optar por una única CPU, pero en una entrevista a Hideki Sato traducida por la gente del foro Sega-16, el SH2 se eligió por su relación precio-rendimiento (la unidad MAC era interesante e importante para la etapa geométrica). Con respecto las demás opciones:
-El Motorola 68040 sería la opción más continuista, es como un 486, aunque en su versión LC ya que con FPU es más costoso, sin embargo ella sola para la geometría no daría el mismo rendimiento que un SH-2.
-El PowerPC 601 sería demasiado costoso para una consola, era equiparable al Pentium I, incluso el 603 era costo aunque más posible. Realmente el PowerPC 602 me parece la opción ideal para una consola, pero se anunció recién en Marzo de 1995.
-El SH-3 sería una mejor opción que la dupla de SH-2, pero implica también retrasar la consola un año, ya que se anunció también a comienzos de 1995.
-El MIPS r4600 era otra opción, disponible para 1994, pero más costoso que un SH-3.
Con respecto a Dreamcast, era bastante bueno para su época el SH4, coincido en que debió ser para 1997 (que fue cuando lo anunció Hitachi) y en el resto de mercados máximo 1998, comparativamente a lo que había en su época:
-En enteros rendía como un Pentium I, sí, pero en coma flotante vencía sin problemas a contemporáneos como el Pentium II, PowerPC 750 (de hecho Nintendo solicitó a IBM mejorar ese aspecto cuando usaron una variante para Gamecube) o el MIPS R5000. En una época donde aún la geometría se procesaba desde la CPU, el SH-4 iba mejor que estos en ese aspecto, con instrucciones específicas para esa etapa.
Utilizamos cookies para asegurar que damos la mejor experiencia al usuario en nuestro sitio web. Si continúa utilizando este sitio asumiremos que está de acuerdo.
Genial, superinteresante. Gracias mil!
Regarding the VDP1 fillrate calculation equation:
k + (x * y * l) + (y * n)
– k is the setup time, the amount of time it takes to read the draw command, set up all the internal registers, read the gouraud shading table (if there is any), set that up, etc. Playstation should also have a value for this, but I don’t know the exact figures.
– x / y are the sprite (texture) dimensions. Important to note that since this is a 2 dimensional values (X * Y), it includes the pixel overdraw.
– n is, according to Steve Snake, an approximate of the sdram cycle miss penalty. It is not an exact calculation, but a good enough general approximation.
– l is 3 cycles, for reading a texture, processing a texture, and writing a texture pixel. If you draw untextured polygons, you should only have 2 cycles here because you only need to process and write a pixel, no need to read textures. But this is just conjecture.
I think what the VDP1 does is, use 1 cycle to read a texture to internal register, 1 cycle to process it, and 1 cycle to write out the data from internal register to framebuffer. This is very inefficient. Yes, this does cut the max fillrate to less than 9,56 MPixel/sec. I don’t know why it does this, maybe a limitation due to the nature of SDRAM, or they just didn’t knew how to do it otherwise. This also explains why semitransparency can be so extremely slow. But for semitransparency, the “up to 6 times” figure may have been a best case versus worst case comparison, best case being untextured pixel, worst case being textured, gouraud shaded, semi-transparent pixel.
I don’t know exactly how the Playstation textures, but from the fillrate numbers it is evident that it can draw a textured pixel in 1 cycle (33,8 MPixel/sec). Maybe this was due to it using VRAM which is double ported (later SGRAM which could simulate this), maybe because it was just a better chip, maybe both.
For the 66MPixel value, it can only achieve this by directly copying pixels in memory without processing. I don’t know if the lack of processing is what doubles the speed, or the fact that such data is always rectangular so it can make 32bit read/writes safely. But you get no shading, no lightning, no deformation, only copy rectangular textures at twice the speed.
By the way you can do gouraud shading in 8-bit palette mode for Saturn. You have to use red colour only gouraud shading on a palette pixel. The 5 bits for the red shading correspond to the palette entry of the pixel. So this way you can ramp up/down the palette index using the VDP1, doing hardware lightning. The downside is that you have to pre-calculate the lightning gradients in the palettes, losing you colour count. The upside is that you can change the lightning colour by updating the palette. I think the cubes in the CD player do this to change colour.
You could even set custom colour gradients, like inversions, to do crazy things like simulate bump mapping. But only one tech demo of that exists.
I don’t think CPU usage can be measured in a percentage, because you also need to spend time using the bus or copying data. Maybe using the Slave SH2 or the SCU DSP at 100% would have made the Master SH2 too busy to process their data, leaving it less time to crunch numbers. A single usage percentage would not account for this. You also need time to upload draw commands to the system. And memory usage is even trickier because half the main memory is slower, and you might not have anything relevant in your game code for that, so you leave parts of it empty.
The percentage calculation is also misleading for texture usage, because textures and draw commands share VRAM. Have too much of one, and the others will suffer. You will end up needing to upload commands twice per frame or upload texture more often between frames, and while you do that, the VDP1 can’t draw anything (you are hogging the VRAM from it by uploading). So you have to balance things out, which leads to lower memory usage on average, to allow for higher peak values in poly count.
Great job on writing up a list of which Saturn games use which texture modes! That’s really fascinating!
And for the most graphically impressive Saturn games, I’d recommend you check out Scorcher. It uses very detailed and colourful textures (easily Playstation quality texturing), semitransparency (rectangular only to avoid the pixel overwrite bug), and decent speed. It is also one of the only games to use both rotating playfields of the VDP2, one of them being transparent. I think each level uses more textures than what fits in the memory, and the game is uploading it dynamically, which explains both the checkpoints and why sometimes they take longer than usual, and a very rare bug where if you race too fast, the game stops texturing for a second. For shading, it only has static pre-baked lightning on the level textures (plus fogging), but nonetheless it looks great because it has so many colours on screen.
Muy interesante. Esperando con ansias las siguientes partes jeje
Nice article. Emulators certainly are a great way to better understand how these games where programmed, and how they performed.
However, you should use caution when measuring the framerate of a game in an emulator : they are not accurate enough to match exactly the framerate of the same game on a real console. For example, you list Panzer Dragoon Zwei as 20 FPS, but on console it runs at 30 FPS in game and 60 FPS during cutscenes.
Also, I would add another feature that games could use to push the console to the max : using the higher clock rate of 28 MHz instead of the default one at 26 MHz. Increasing that chock makes both SH2, VDP1, VDP2, SCU and their memory faster. VDP2 displays automatically 10 % more pixels horizontally (352 instead of 320 in SD), but you don’t have to draw the additional pixels. That way you can cover the same screen area than at the lower clock rate, but with more cycles per pixel.
Strangely enough, all 3 Lobotomy Software FPS run at the lower clock rate. There’s always room for improvement, even in well programmed games…
Yo tengo una duda respecto a porque Sega Optó por el bendito SH-2 Teniendo otras opciones. Lo ideal hubiera sido un Motorola 68040 a 33Mhz o PowerPC 601.
Creo que les hubiera salido más barato usar un CPU a 66Mhz que lanzar la Saturn con esos dos SH-2 en 1994.
Lo mismo paso con Dreamcast que siguieron con el bendito SH, ya en ese momento había otras CPU Mejores en el mercado como: los Pentium II, Los AMD, Nec, IBM PowerPC G3, entre muchos para elegir.
Para mí gusto la Sega Dreamcast así tal cual está diseñada es una consola para 1997 cuánto mucho. Porque después de ese año sacarla sería un problema tecnológico con las muchas tecnologías que había y mejores.
Mmm no estoy tan de acuerdo con algunas cuestiones, es muy cierto que Sega debió optar por una sola CPU, ir por Hitachi y su SH es algo que comenta Hideki Sato en una entrevista traducida por la gente del foro Sega-16, pero básicamente era por la relación precio-potencia (su unidad MAC era algo interesante), para lo que querían en ese momento estaba bien, después llegó Sony y al ver que se quedaban cortos metieron de todo, sin embargo con respecto a las opciones de Cpu veo lo siguiente:
– Un 68040 parecía la opción lógica y continuista (en su versión LC sin FPU tal vez, sino sería más costoso), pero para encargarse ella sola de la geometría como que no le dá, es como el 486.
– Un PowerPC 601 era demasiado costoso para una consola, estaba al nivel del Pentium I, incluso el PowerPC 603 era costoso aunque más posible, en verdad la opción ideal para una consola creo que era el PowerPC 602 a 66 MHz, pero se anunció recién para Marzo de 1995.
– Sega podría en todo caso haber retrasado la consola un año y usar el Hitachi SH-3 a 60Mhz, también se anunció en Marzo del 95 si mal no recuerdo. Hubiera dado mejores resultados que la dupla compleja de SH-2.
– El MIPS r4200 o r4600 podrían ser opciones, aunque siendo más costosos que los SH, incluso que el SH-3 y el 4600 algo más que el 4200.
– Al contrario de lo que piensas, el SH-4 para la época es una buena Cpu, además consumía poco y era barata. Coincido con lo del timing de que era para 1997 y como muucho 1998 en el resto de mercados, pero por ejemplo si bien a nivel enteros era como un Pentium I, sí, en coma flotante superaba bien al MIPS R5000, Pentium II y al PowerPC 750 (de hecho Nintendo pidió mejoras en ese aspecto a IBM cuando usaron una versión de esta CPU en GameCube), hablamos de un tiempo en el que aún las CPU se encargaban de la etapa geométrica y para esto el chip de Hitachi estaba mejor preparado que algunas de sus contemporáneas.
Mmm no estoy del todo de acuerdo, sin duda Sega debió optar por una única CPU, pero en una entrevista a Hideki Sato traducida por la gente del foro Sega-16, el SH2 se eligió por su relación precio-rendimiento (la unidad MAC era interesante e importante para la etapa geométrica). Con respecto las demás opciones:
-El Motorola 68040 sería la opción más continuista, es como un 486, aunque en su versión LC ya que con FPU es más costoso, sin embargo ella sola para la geometría no daría el mismo rendimiento que un SH-2.
-El PowerPC 601 sería demasiado costoso para una consola, era equiparable al Pentium I, incluso el 603 era costo aunque más posible. Realmente el PowerPC 602 me parece la opción ideal para una consola, pero se anunció recién en Marzo de 1995.
-El SH-3 sería una mejor opción que la dupla de SH-2, pero implica también retrasar la consola un año, ya que se anunció también a comienzos de 1995.
-El MIPS r4600 era otra opción, disponible para 1994, pero más costoso que un SH-3.
Con respecto a Dreamcast, era bastante bueno para su época el SH4, coincido en que debió ser para 1997 (que fue cuando lo anunció Hitachi) y en el resto de mercados máximo 1998, comparativamente a lo que había en su época:
-En enteros rendía como un Pentium I, sí, pero en coma flotante vencía sin problemas a contemporáneos como el Pentium II, PowerPC 750 (de hecho Nintendo solicitó a IBM mejorar ese aspecto cuando usaron una variante para Gamecube) o el MIPS R5000. En una época donde aún la geometría se procesaba desde la CPU, el SH-4 iba mejor que estos en ese aspecto, con instrucciones específicas para esa etapa.
Mmm no estoy del todo de acuerdo, sin duda Sega debió optar por una única CPU, pero en una entrevista a Hideki Sato traducida por la gente del foro Sega-16, el SH2 se eligió por su relación precio-rendimiento (la unidad MAC era interesante e importante para la etapa geométrica). Con respecto las demás opciones:
-El Motorola 68040 sería la opción más continuista, es como un 486, aunque en su versión LC ya que con FPU es más costoso, sin embargo ella sola para la geometría no daría el mismo rendimiento que un SH-2.
-El PowerPC 601 sería demasiado costoso para una consola, era equiparable al Pentium I, incluso el 603 era costo aunque más posible. Realmente el PowerPC 602 me parece la opción ideal para una consola, pero se anunció recién en Marzo de 1995.
-El SH-3 sería una mejor opción que la dupla de SH-2, pero implica también retrasar la consola un año, ya que se anunció también a comienzos de 1995.
-El MIPS r4600 era otra opción, disponible para 1994, pero más costoso que un SH-3.
Con respecto a Dreamcast, era bastante bueno para su época el SH4, coincido en que debió ser para 1997 (que fue cuando lo anunció Hitachi) y en el resto de mercados máximo 1998, comparativamente a lo que había en su época:
-En enteros rendía como un Pentium I, sí, pero en coma flotante vencía sin problemas a contemporáneos como el Pentium II, PowerPC 750 (de hecho Nintendo solicitó a IBM mejorar ese aspecto cuando usaron una variante para Gamecube) o el MIPS R5000. En una época donde aún la geometría se procesaba desde la CPU, el SH-4 iba mejor que estos en ese aspecto, con instrucciones específicas para esa etapa.
Mmm no estoy del todo de acuerdo, sin duda Sega debió optar por una única CPU, pero en una entrevista a Hideki Sato traducida por la gente del foro Sega-16, el SH2 se eligió por su relación precio-rendimiento (la unidad MAC era interesante e importante para la etapa geométrica). Con respecto las demás opciones:
-El Motorola 68040 sería la opción más continuista, es como un 486, aunque en su versión LC ya que con FPU es más costoso, sin embargo ella sola para la geometría no daría el mismo rendimiento que un SH-2.
-El PowerPC 601 sería demasiado costoso para una consola, era equiparable al Pentium I, incluso el 603 era costo aunque más posible. Realmente el PowerPC 602 me parece la opción ideal para una consola, pero se anunció recién en Marzo de 1995.
-El SH-3 sería una mejor opción que la dupla de SH-2, pero implica también retrasar la consola un año, ya que se anunció también a comienzos de 1995.
-El MIPS r4600 era otra opción, disponible para 1994, pero más costoso que un SH-3.
Con respecto a Dreamcast, era bastante bueno para su época el SH4, coincido en que debió ser para 1997 (que fue cuando lo anunció Hitachi) y en el resto de mercados máximo 1998, comparativamente a lo que había en su época:
-En enteros rendía como un Pentium I, sí, pero en coma flotante vencía sin problemas a contemporáneos como el Pentium II, PowerPC 750 (de hecho Nintendo solicitó a IBM mejorar ese aspecto cuando usaron una variante para Gamecube) o el MIPS R5000. En una época donde aún la geometría se procesaba desde la CPU, el SH-4 iba mejor que estos en ese aspecto, con instrucciones específicas para esa etapa.