Ho sentim, aquesta entrada es troba disponible únicament en English i Español.
Privacy Overview
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.
3rd Party Cookies
This website uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.
Keeping this cookie enabled helps us to improve our website.
Please enable Strictly Necessary Cookies first so that we can save your preferences!
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.