A trip to the Past: Castlevania SOTN porting

[Nesh]

Castlevania Symphony of the Night was a brilliant achievement on the PS1. Probably the most beautiful 2D game on the console.

The Saturn version (released in Japan only) came with a lot more content including Belmond and Maria as playable characters too.

Now there were significantly visible differences in the visuals in the very first minutes.
The question is why did the Saturn version suffer from dips during some undemanding scenes even though it was more capable with 2d visuals.

I came across this link where someone claims that the game was led on the PS1 and then directly ported to the Saturn. Since PS1 wasnt as capable with 2D the game was designed on a 3D engine (hence why the Saturn was straggling). Thats something that my mind cant quite understand.

http://www.vgmuseum.com/mrp/cv-sotn/documents/nocturne-port.htm

The Playstation (henceforth PSX) cannot do 2D. "But," you say, "I've played 2D games on the Playstation. Of course it can do 2D. I've even seen specifications for the 2D capabilities of the Playstation in FAQs and other sources." This is misleading. The games you have played appear to be 2D because they are flat, not because they are 2D. While the Saturn has distinct hardware for displaying and processing 2D sprites and other 2D elements, the Playstation does not. In order to represent a 2D game, the PSX must have a 3D engine that creates a polygon, textures one side of it, and then keeps that side facing the same direction and manipulates that polygon as if it was a sprite. This means that doing 2D on the PSX is really just doing flat 3D. The specs you've seen in FAQs and on the net, then, are an estimation of the ability of the PSX to pretend to be doing 2D. This is unlike the Saturn, which has separate 2D and 3D capabilities that can be mixed when needed or utilized separately. In order to create Dracula X on the Playstation, the incredible 2D-looking game that it is, the programmers had to create a custom 3D engine. The theory, then, is that the Saturn Dracula X is a port of the PSX's 3D engine with modifications rather than a game reprogrammed to properly utilize the Saturn's 2D and 3D capabilities. While the Saturn version of the game has extra content and some reprogrammed or changed special effects, the engine itself was a direct port and the graphics were not effectively modified or touched up as a result.

How much truth there is in this and how exactly does this work? Can flat textured polygon surfaces be such a good substitute to sprites?

 

[Shifty Geezer]

Yes. That's basically what a sprite is - a quad of texture data that's transformed by the same vector maths. The result is a very flexible system and seamless integration between 2D and 3D components, and even 2.5D. Things like parallax scrolling with 2D sprites can be camera based in 3D for better accuracy. Something like Street Fighter's parallax floor could be created now with the same sprites but a quad for the floor with perspective-correct texture and no banding like the original.

 

[Nesh]

Yes. That's basically what a sprite is - a quad of texture data that's transformed by the same vector maths. The result is a very flexible system and seamless integration between 2D and 3D components, and even 2.5D. Things like parallax scrolling with 2D sprites can be camera based in 3D for better accuracy. Something like Street Fighter's parallax floor could be created now with the same sprites but a quad for the floor with perspective-correct texture and no banding like the original.

In Symphony there isnt much in terms of parallax surfaces going on. There is almost none if any. There are a few 3D objects in the background that are in extremely few places..

So are the character models and environments in the game the exact same method used as any other 2D game? Or is it something different? Should the Saturn have more trouble rendering it than the PS1 assuming its the latter? And is this supposed to free memory enough that the PS1 runs 2D assets better than the Saturn itself?

 

[Shifty Geezer]

I don't know the game, but that's pretty much certain unless they mixed 3D. The characters are a series of bitmaps and you just swap which bitmap is visible at any moment. I can't comment on why the PS1 version runs better than the Saturn version, but your quote sounds plausible to me. If the Saturn version doesn't use the 2D hardware and just renders the game in 3D also, that'd account for slowdowns. Using 3D for 2D won't free memory. If anything it'll consumer a little more as you'll have a depth vector as well as horizontal and vertical vectors. In terms of the assets though, it'll be identical. You'll have colour and alpha/stencil whether sprites or quads.

 

[function]

I don't think Street Fighter 2 used parallax for the floor, I think it used line scrolling of a background layer - at least it did on the MD and I think the arcade was the same, going by memory. It was very smooth and very clean and was a fantastic pseudo-3D effect and it was used in quite a few MD games. With the Saturn and PSX I don't think you could do line scrolling as they used frame buffers, and so they had to use polygons or ideally on the Saturn its amazing plane processor.

In something like Street Fighter Alpha, the Saturn used its plane processor (which had its own memory) to draw both the perspective correct scrolling floor and the most or all of background. The main graphics chip just drew the sprites, and the plane processors dedicated memory freed up more system memory to use on animation frames, which is probably why Saturn beat em ups had better animation than their PSX counterparts.

If you weren't using the Saturn's background layers and plane processor then it could be at a disadvantage compared to the more powerful PSX, and for SOTN it might not have been possible to use them to achieve the same results that the PSX's more flexible hardware could easily manage. That'd my guess anyway, but I could easily be wrong.

 

[archie4oz]

Can flat textured polygon surfaces be such a good substitute to sprites?

Yes, as Shifty mentions (although oversimplifies with lack of historical perspective), that's fundamentally what sprites are nowadays. Historically speaking, they were simply two-dimensional objects that could manipulated independently of the memory bitmap of the display. In the days before frame-buffers, you had line-buffers and sprites were just "entries" on the scanline who's parameters were stored in registers or caches (hence why you had hardware that supported N of sprites) that would DMA the object data while the scanline was being drawn (thus relieving the CPU of said tasks). As hardware advanced you could store more parameters for sprites so you could do things like move them vertically, scaling, rotations and transparency. Eventually transistors got cheaper and frame-buffers started trickling into the consumer space sprites started becoming essentially 2D bitmaps that you manipulated by one or more control points. By the time you got to the Saturn and Playstation; from a hardware perspective, these machines were essentially drawing distorted sprites for "3D".

If the Saturn version doesn't use the 2D hardware and just renders the game in 3D also, that'd account for slowdowns. Using 3D for 2D won't free memory. If anything it'll consumer a little more as you'll have a depth vector as well as horizontal and vertical vectors. In terms of the assets though, it'll be identical. You'll have colour and alpha/stencil whether sprites or quads.

You really can't "not use the 2D hardware". There is no "2D" or "3D" hardware (well actually you could call VDP2 "2D" hardware since it just manages background planes), both had graphics processors that drew a range of primitives (lines & quads on the Saturn, points, lines, & triangles on the Playstation).

With the Saturn and PSX I don't think you could do line scrolling as they used frame buffers, and so they had to use polygons or ideally on the Saturn its amazing plane processor.

VDP2 (Saturn) did support line scrolling.

If you weren't using the Saturn's background layers and plane processor then it could be at a disadvantage compared to the more powerful PSX, and for SOTN it might not have been possible to use them to achieve the same results that the PSX's more flexible hardware could easily manage. That'd my guess anyway, but I could easily be wrong.

Well you couldn't *not* use VDP2 since you needed to feed through it and it also controlled the CRTC, but you're on the right track. As it was, the Playstation, Saturn and N64 were so wildly different from each other that games developed for one platform rarely ported well to another (which is why I snicker inwardly when I see bickering over porting between PS3 and 360).

The main graphics chip just drew the sprites, and the plane processors dedicated memory freed up more system memory to use on animation frames, which is probably why Saturn beat em ups had better animation than their PSX counterparts.

When the Playstation was released, it was quite different (or at least that's how I remember it). Before, we were dealing with low level hardware access (memory maps and registers), hardware reference docs and assemblers. All with the goal of building games where the screen was a relatively static display outside of some fancy background scrolling tricks, and focussed mostly on moving a lot of sprites around on screen. Outside of the handful of titles that tried to get creative with graphics by playing around with distorting sprites to create more flashy pseudo 3D effects, this mentality was burned in for a long time. Then along comes the Playstation and you're being told to write your games in C and use their libraries (which were immature and slow at the time), along with Sony eschewing anything 2D'ish looking as that looked "old fashioned" and 3D was the new hotness and Sony was really pushing to distinguish itself from it's competition thus you were being pushed into game designs that emphasized 3D (Toshinden really epitomized this). Thus the perception of the Playstation as a poor 2D game system arose. Things slowly changed as time passed. Once Sony exposed more of the hardware, and a lot of old habits wore off, we learned to take advantage of the hardware.

For instance, even though the Saturn had more memory and the benefit of smaller code density of the SuperH ISA, the main CPU bus was slower than what the Playstation had. Plus your computational capacity was spread amongst 3 separate processors (not to mention the interface to the two VDPs had half the bandwidth of the CPU bus) instead of the relatively simple monolithic ASIC of the Playstation. Also, once you learned how to leverage the MDEC more, you could pull off tricks like 2D scolling backgrounds by simulating them using primitive video textures (which the Playstation handled with aplomb).

 

[Shifty Geezer]

Yes, as Shifty mentions (although oversimplifies with lack of historical perspective), that's fundamentally what sprites are nowadays. Historically speaking, they were simply two-dimensional objects that could manipulated independently of the memory bitmap of the display. In the days before frame-buffers, you had line-buffers and sprites were just "entries" on the scanline who's parameters were stored in registers or caches (hence why you had hardware that supported N of sprites) that would DMA the object data while the scanline was being drawn (thus relieving the CPU of said tasks).

As yes, important historical technical difference. Alternatively to sprites, at least in Amiga parlance, were bobs which were bitmaps/'textures' drawn onto the display buffer. I don't know what the different consoles used for rendering images. Hmm, if sprites were scanline based than that explains why objects in R-Type on the SEGA Master System would disappear in stripes when things got busy.

 

[Nesh]

Yes, as Shifty mentions (although oversimplifies with lack of historical perspective), that's fundamentally what sprites are nowadays. Historically speaking, they were simply two-dimensional objects that could manipulated independently of the memory bitmap of the display. In the days before frame-buffers, you had line-buffers and sprites were just "entries" on the scanline who's parameters were stored in registers or caches (hence why you had hardware that supported N of sprites) that would DMA the object data while the scanline was being drawn (thus relieving the CPU of said tasks). As hardware advanced you could store more parameters for sprites so you could do things like move them vertically, scaling, rotations and transparency. Eventually transistors got cheaper and frame-buffers started trickling into the consumer space sprites started becoming essentially 2D bitmaps that you manipulated by one or more control points. By the time you got to the Saturn and Playstation; from a hardware perspective, these machines were essentially drawing distorted sprites for "3D".
.

So did the Saturn commonly drew distorted sprites for "3D" for its 2D games anyways? Castlevania was not an exception of the rule?
If this is the case, it makes me wonder if the explanation provided above explains why the Saturn was having difficulties with Castlevania since the Saturn was generally doing better with 2D.

Here is a video of the game. The first few minutes of the game are the most intensive areas in terms of using 3D objects and effects. So there I would expect the slowdowns as a natural occurrence compared to the PS1 version.

But the rest of the game (as you can see in the video) is not even using 2 background layers for parallax scrolling most of the time.
http://www.youtube.com/watch?v=9S6TvzUefDc&feature=related

 

[TapamN]

The main reason for the slowdown in the Saturn port of Symphony is that the original version was designed for a single CPU system, while the Saturn has two CPUs that are individually somewhat less powerful than the Playstation's single CPU. The SH-2's smaller 2 byte instructions can't do as much in one cycle than the MIPS' 4 byte instructions. The SH-2 has a worse shifting instructions, very tiny branch displacements (so you generally need to load subroutine addresses in a separate instruction before jumping to them), and two operand instructions instead of the MIPS three operand instructions. For the Saturn, you have to use two CPUs if you want to match or exceed the Playstation's one, and the Symphony port probably didn't use the extra CPU very well (if at all). They did use the Saturn's background processor for the 2D tilemaps, at least (I checked by using an emulator to disable background layers).

The Saturn draws polygons backwards from normal 3D hardware. Normally, you scan though the polygon and fetch texels. The Saturn scans through texels and plots pixels. Because of this, instead of the usual power-of-2 sized textures and arbitrary sized frame buffers that most hardware allows, the Saturn has power-of-2 sized framebuffers and arbitrary sized textures. Since textures have four corners, Saturn polygons must have four corners as well. But because of the way the Saturn draws its quads, Saturn textured polygon quads look close to being perspective correct, despite not needing a vertex Z.

The Saturn wasn't the only hardware to implement its textured polygons like this, the NV1 3D card and the 3DO also worked similarly.

There are three major drawbacks to the Saturn drawing polygons this way. One is that the UV coords for each vertex are fixed. You can't scroll, scale, or repeat a texture on one polygon (but you can fake it along one axis by storing multiple copies of a texture in RAM and tweaking the the texture start and height.) This makes applying textures to models much more fun! And if you need a triangle, you have to place two vertices at the same point and that makes for a weird, messy looking texture application since one corner of the triangle will have more texture samples than the other. You can minimize this by predistorting the texture, but then you waste RAM from repeating texels and still have a messy sample pattern.

Another is that the fillrate used for a polygon is max(size-of-polygon, size-of-texture), since the hardware always walks though each texel. The Saturn has some tricks to improve it, though; there's a mode to treat the texture as being at quarter resolution to speed up minification (which is why many Saturn have the texture suddenly drop resolution when the polygon gets farther away or a sprite shrinks) and there's a mode to have transparent spans of texels skipped over faster.

The third problem is that because of the imprecision of the plotting the Saturn does, sometimes the same pixel gets written to more than once. So if translucency is being used, some pixels will have the effect applied twice.

Another problem with translucent effects on the Saturn is that it has very few modes to do so; the only real blend mode (other than replace) is to average the texel and framebuffer (i.e. add and right shift. There is one extra mode for shadows that halves the brightness of the framebuffer under any opaque texels, but it doesn't use the actual color of the texture at all). It can't additively render a sprite/polygon onto the framebuffer like the Playstation. You can have the background processor additively or alpha blend backgrounds (32 levels) and the framebuffer with other background layers. Just not sprite/polygon onto sprite/polygon. (Sonic R is a good example of framebuffer alpha blending onto a background. Burning Rangers generates a quarter res. frame buffer containing transparent polygons with the CPU, uploads it to background RAM, and has the background processor add it on top of the framebuffer for its fire and glass. Silhouette Mirage shows off the problems of the asymmetry of the Saturn's blending operations; things like explosions are additively drawn over backgrounds, but switch to crosshatch dithering when they appear over other sprites.).

One of the main reasons the Saturn can do better 2D is that it has 512KB more video memory than the Playstation. The reason the Playstation has better textures in 3D is that the Saturn's video memory is segmented, with 512KB for sprites/textures and display lists, 512KB for frame buffers, and 512KB for the background processor. The Playstation only has 1 MB of video RAM, but has about ~700 KB of video RAM left for textures after the frame buffer. Having the separate background processor also saves the sprite/polygon processor a lot of fillrate; it can do up to four backgrounds at 704*480p; a peak of 80.5 mpixels per second saved (though most games would use 320*224p, which is peak 17.2 mpixels.) The Saturn version of Silhouette Mirage has more background layers than the Playstation version and has less repetition in them. It also has less color banding since the Saturn can use 24 bit color for its background palettes (or palettized framebuffer), while the Playstation version puts its backgrounds in its 15-bit color frame buffer.

 

[Grall]

at least in Amiga parlance, were bobs which were bitmaps/'textures' drawn onto the display buffer.

From what I've seen it described here at B3D (by who I can't remember now), Saturn sprites were essentially "bobs" (blitter objects), apparantly drawn directly into the frame buffer each frame.

It would seem they are not individual hardware objects like in every console from the Atari VCS up to the Neo*Geo.

Btw, some imba posts in this thread by Archie and Tapam! Thanks, guys. I love reading hardcore hardware porn!