[showka]

[showka]

[showka]

Yes. In fact I wrote a 2D game engine that uses OpenGL, and if you want your game to take advantage of the 3D hardware there no other way to do it.

I was thinking about this last night, one draw back to doing 2D with 3D hardware is how texture memory is used. For example, most textures should not be larger than 256x256 pixels, even on newer cards. In the past, cards had lower limits, like 64x64. Strange things also happen if your textures aren't a power of two, strange things that can totally fuck up your alogirthms for showing 2D graphics without stretching them.

I created code that, from the outside, just lets you take any old bitmap and then create a sprite that has a position on screen and then cordinates for that bitmap. But within that code, things are more complicated. The bitmaps are sliced into as many textures as they need to have, those textures are expanded to be powers of 2, and then the sprite routines might have to draw multiple textured quads for what appears to be one sprite if the source image is more than 256 pixels in either direction.

I'd be willing to say that a PSX game from 1997 didn't take the time to create an abstract layer like this, because 1) having game code call a sort of library created just for handling the 2D geometery would slow things down a little bit compared to working with the graphics hardware, or structures that were used by the graphics hardware, directly and 2) the fact Nintendo had to flip the entire damn world in Twilight Princess to make Link right handed makes me think Japanese game coders prefer to make the game work rather than ensure they're code is set up to handle the possibility it might need to work differently one day. What I'm trying to say is that Symphony of the Night is most likely filled with code that is made for the 3D. Almost all the code for doing anything graphical, from how Richter's whip moved to Alucards after-images, was hard coded to work with flat polygons and small pools of texture memory.

One solution would have been to have created a system that acted like a facade of the PSX's 3D hardware, so it took data structures or interfaces that looked the same as what was used for the PSX's graphics and then passed them through some code that used the Saturn's 2D hardware. But this might have been prohibitively expensive in terms of time, there may have been so much PSX specific code in the game to make this impossible, or maybe how the Saturn dealt with 2D (especially with how the graphics were stored in memory) was so different that it would've slowed the game down.

So the only solution was to try and use the Saturn's 3D methods, or reprogram vast portions of the game, and while they were doing that they might as well have redrawn everything since even if they'd added the transparencies or gotten rid of the slow down the graphics would still look blocky. Since I've always heard the Saturn dev team was strapped for time, this probably was not an option.

Really, its kind of annoying to hear people chalk up the flaws in ports to developer laziness. There are severe differences between the archeticture of the PSX that would make porting the games difficult unless the original game was programmed from the start under the assumption that it might be ported. Given that no Castlevania title aside from SOTN ever had a direct port before, I can't see how it would have been.