Sega Saturn

[Pleng]

I guess it depends what you class as perfect emulation.

Plays NiGHTS, DaytonaCCE and Sega Rally

 

[nikkopt]

HEY GUYS THESE ARE MY SPECS LOLZ!!!11one

Intel Core i7 965 (xtreme ED)
Patriot 6GB DDR3 1600MHz Viper CL8 Triple channel
2x SSD OCZ Vertex Turbo 128GB @ RAID 0
SSD OCZ Colossus 500GB
2x Shapphire HD5970 2GB Crossfire
Nvidia Quadro FX 5600 1.5GB

Already bought one ioDrive DUO 320GB from Fusion IO, to replace the main SSD's, it should arrive next week.

:rolleyes:

 

[Exophase]

Exophase, that's your cue

Oh boy!

As mentioned earlier in this thread, Yabause runs fairly poorly on Wii, which you can expect to be more powerful than Pandora.

Someone actually did both SH2 and 68k recompilers (although I don't know why anyone would bother with the 68k) for a PSP port of Yabause. I've never since heard performance figures, or even if it works at all, but the recompiler code itself looked good enough as far as far as recompiler code goes. If it actually works at all someone could attempt an ARM version, but again, I have no idea what performance will be like.

According to someone I know who has worked on Saturn emulation, VDP1 (the component that generates quads for sprites and 3D) is the most performance demanding element of Saturn emulation. Yabause has an OpenGL option for this, but doing it this way may be a substantial accuracy compromise. I don't know what about VDP1 that would make its emulation so demanding and I haven't succeeded in getting this person to explain it to me... from where I stand it doesn't appear to be doing much work per pixel. It's also not a conventional design, in that it's "forward mapping", meaning that it translates texture coordinates into screen coordinates instead of the other way around. I've heard that this generates perspective correct results, but I don't understand how this can be the case. There's some tricky logic for performing this without causing gaps to appear inbetween pixels, but it doesn't seem like it should be anything that would completely destroy performance.

 

[Mithrildor]

HEY GUYS THESE ARE MY SPECS LOLZ!!!11one

Intel Core i7 965 (xtreme ED)
Patriot 6GB DDR3 1600MHz Viper CL8 Triple channel
2x SSD OCZ Vertex Turbo 128GB @ RAID 0
SSD OCZ Colossus 500GB
2x Shapphire HD5970 2GB Crossfire
Nvidia Quadro FX 5600 1.5GB

Already bought one ioDrive DUO 320GB from Fusion IO, to replace the main SSD's, it should arrive next week.

:rolleyes:

ONTOPIC!

 

[Prometheus]

Thanks Exo - that tells me more than I knew before. :lol:

I had heard someone somewhere (I can't remember where right now, though) describing the Wii port as playable for some games, but as everyone knows, that's a highly subjective thing. Sometimes the definitions of it that I see absolutely astound me. :lol:

 

[nikkopt]

HEY GUYS THESE ARE MY SPECS LOLZ!!!11one

Intel Core i7 965 (xtreme ED)
Patriot 6GB DDR3 1600MHz Viper CL8 Triple channel
2x SSD OCZ Vertex Turbo 128GB @ RAID 0
SSD OCZ Colossus 500GB
2x Shapphire HD5970 2GB Crossfire
Nvidia Quadro FX 5600 1.5GB

Already bought one ioDrive DUO 320GB from Fusion IO, to replace the main SSD's, it should arrive next week.

:rolleyes:

ONTOPIC!

I was wrong about some parts
It's more like a C2D, 2GB RAM, Nv 9600GT :]

Oh, yes... sega saturn.. i love it

 

[Exophase]

Thanks Exo - that tells me more than I knew before. :lol:

I had heard someone somewhere (I can't remember where right now, though) describing the Wii port as playable for some games, but as everyone knows, that's a highly subjective thing. Sometimes the definitions of it that I see absolutely astound me. :lol:

*nod*

According to the Wiibrew wiki:

"Slow (owing to software video driver): 5-15 fps average. However, because the auto-frameskip is active always, some games run at playable speed. "

Unfortunately it's unclear if 5-15fps refers to the number of frames drawn or the number of vsyncs emulated. If it's the latter I think that qualifies as "too slow", but if it's the former then.. well, it depends on the emulated vsyncs/sec still. If it's reaching real-time speed (doubt it..) then skipping 75% frames isn't necessary that awful, although certainly far below ideal. Anything past this would probably be hitting diminishing returns in what you can gain speed on, so I doubt it's anywhere close to real-time.

 

[x68000]

I tried 8 original Japanese games and found big graphical and sound glitches in most of them. Emulation in the rest was nowhere near 100% accurate either.

Remember that i've played close to 900 Japanese Saturn games on original hardware so i'm a bit of a perfectionist, but tried to be fair when judging the games below:-

Stellar Assault SS - Blank Screen
Layer Section - Scalling glitches and speed issues
Taromaru - Massive slowdown after title screen and graphical glitches
Fantastic Pinball - Some Slowdown
Victory Goal '96 - Game freezes after menu screens
Silhouette Mirage - Ran quite well - but some slowdown
Daytona CCE (thanks pleng!) - Runs fine til you get in game, then lots of flickering in the background.
Kyukyoku Tiger 2 Plus - Weird scaling problem ingame and audio sync issues.

To be honest, i've yet to find an emulator which is near to 100% accurate, but i understand that many people unfamiliar with original hardware would be hard pushed to notice the difference.

 

[Dunny]

from where I stand it doesn't appear to be doing much work per pixel. It's also not a conventional design, in that it's "forward mapping", meaning that it translates texture coordinates into screen coordinates instead of the other way around. I've heard that this generates perspective correct results, but I don't understand how this can be the case.

Could it be just doing 1/Z interpolation? By converting to screen coords and storing the vertices' Z depths, I suppose you could do perspective correct texturing - but it seems an awful waste. Bear in mind that I was doing 1/z a very long time ago, I'm sure there's better ways of doing it now

D.

 

[Exophase]

Could it be just doing 1/Z interpolation? By converting to screen coords and storing the vertices' Z depths, I suppose you could do perspective correct texturing - but it seems an awful waste. Bear in mind that I was doing 1/z a very long time ago, I'm sure there's better ways of doing it now

D.

There's no "Z" in the primitive renderers on Saturn, PS1, 3DO, etc. You can't do perspective correct texturing unless you interpolate along a rational curve, and you have to know how far down the curve you are (ratio between difference in depth of object's end points and depth between camera and the furthest endpoint) in order to do this properly. I suppose a renderer could have taken these ratios straight instead of Z values, but these ones don't. They should be stepping purely linearly, so I don't know what the person was saying. It's true that it's stepping in a different space than a traditional renderer, but it's still linear to screen space.

 

[kingoddball]

WOOOOOO! Tech talk!! :huh: WHOOOHOOOO!! I love it!

 

[neko]

There's no "Z" in the primitive renderers on Saturn, PS1, 3DO, etc. You can't do perspective correct texturing unless you interpolate along a rational curve, and you have to know how far down the curve you are (ratio between difference in depth of object's end points and depth between camera and the furthest endpoint) in order to do this properly. I suppose a renderer could have taken these ratios straight instead of Z values, but these ones don't. They should be stepping purely linearly, so I don't know what the person was saying. It's true that it's stepping in a different space than a traditional renderer, but it's still linear to screen space.

There is no Z division, and the perspective distortion is pretty obvious in games like Panzer Dragoon Saga. Also there is no Z-buffer. Games sorted the polygons, drawing back-to-front.

 

[Shock-Socks]

i'm comin into this conversation a little bit late but i tested out the Yabuse port on my psp about a year back, and while i only got the bios up and running it was running very slow i'd say 5-7 fps MABY. but it was working, and with nearly triple the hardware specs i think a working port could be reasonable, not that i or anyone i know would be willing to code it.

 

[Exophase]

There is no Z division, and the perspective distortion is pretty obvious in games like Panzer Dragoon Saga. Also there is no Z-buffer. Games sorted the polygons, drawing back-to-front.

Yes, which is why what this person was saying about perspective correct texturing made no sense. It's nice to have someone confirm that that isn't the case; I haven't personally played any Saturn games except for PDS years ago on an emulator, and only for a few minutes.

All of this makes what this person said years ago very strange.. I haven't found the quote yet, but it was coming from someone who was otherwise very knowledgeable of Saturn hardware (hence why I didn't just ignore it). I think it could have referred to one or both of two things:

- Quads, while having more error overall due to a lower geometry subdivision, might not distort as obviously, ie buckling towards the center.
- The "mode 7" style rotated backgrounds with raster effects can be done with perspective correct if the plane is orthogonal to screen Y, ie constant depth per scanline. It's the same as on SNES or GBA; since the scanline transforms are controlled in software you can perform proper perspective division. I hear Saturn games used projected 2D layers for flat floors (and ceilings?) a lot, so they'd at least look right.

Lack of Z-buffering is the same as PS1, but was there any method on Saturn for hardware accelerating sorts? PS1 had somewhat crude Z-binning in its display list hardware. Full software sorting would have added quite a bit of overhead. With this and the DSP vs PS1's GTE Saturn was probably at a pretty substantial geometry disadvantage.

i'm comin into this conversation a little bit late but i tested out the Yabuse port on my psp about a year back, and while i only got the bios up and running it was running very slow i'd say 5-7 fps MABY. but it was working, and with nearly triple the hardware specs i think a working port could be reasonable, not that i or anyone i know would be willing to code it.

The port you tested is a vanilla one done by Sofiya-cat and isn't the one I'm referring to. The one I have in mind is much more recent, and to the best of my knowledge binaries weren't even released for it.

 

[Prometheus]

I was of the impression that the Saturn did have perspective-correct texturing, so I'm quite surprised to hear it being said that it doesn't (honestly, for all these years I've thought it had it, going on what I've seen) - it certainly looked that way. I can only speak from an end-user perspective, though.

An example springs to mind immediately, of a game that was available on both the Saturn and PlayStation, and the PSX release suffered from really noticeable texture zigzagging, whilst the Saturn one just didn't have any that I could see. It was Croc: Legend of the Gobbos, for what it's worth (both versions were done by the same team, so it's not like one was farmed out to someone else), if anyone wants to take a look.

 

[MDave]

This video shows how the nature of the quads don't suffer as much from perspective distortion as the typical triangles used in the same ps1 game.

Skip to 1:54, and watch the floor

http://www.youtube.com/watch?v=mRnW4xwvCrc&feature=related

That might be a bad example if the saturn port uses "mode 7" style rotated backgrounds for the floor, but I presume it doesn't for that game because you can see the edges of the platform the fighters are on, seem a bit polygonal with the way it aliases against the background

Also, I know it's wikipedia but it might be worth mentioning

if used correctly, the quadrilateral rendering of the Saturn had advantages. It could potentially show less texture distortion than was common with PlayStation titles, as demonstrated by several cross-platform titles such as Wipeout and Destruction Derby.

 

[Exophase]

I'm looking at some screenshots now.

I'm not sure if zig-zagging is how you would describe affine texturing over quads. It would definitely look a bit different, although I'm not exactly sure how to describe it. Here's an example:

http://i19.photobuck...-correction.png

But that only shows how it looks in the constant depth per y case.

It is possible for quads to be rendered perspective correct w/o a Z parameter if they're assumed to be rectangles in world space, but I doubt the Saturn did this. It'd be pretty expensive and would substantially limit your geometry.

 

[MDave]

I'm looking at some screenshots now.

I'm not sure if zig-zagging is how you would describe affine texturing over quads. It would definitely look a bit different, although I'm not exactly sure how to describe it. Here's an example:

http://i19.photobuck...-correction.png

But that only shows how it looks in the constant depth per y case.

It is possible for quads to be rendered perspective correct w/o a Z parameter if they're assumed to be rectangles in world space, but I doubt the Saturn did this. It'd be pretty expensive and would substantially limit your geometry.

I think it's because the VDP chip uses it's sprite engine for the quads so something internal must be going on there.

http://info.sonicretro.org/VDP1_32-bit_video_display_processor

Might find other useful info there.

 

[Exophase]

What are you answering? I know the VDP1 is used for sprites and quads. That doesn't mean that it'd be doing non-linear steps. I'm still going with non-perspective correct quad texturing until someone disproves this.

 

[wipeout2000]

Yabause

Goals for a 1.0.0 release

* Full "stock" saturn emulation. At the very least it should be "feature complete" (most major bugs should be fixed at this point too).
* Any external carts or peripheral do not need to be fully emulated at this point.
* Switchable SH2 Dynarec/Interpreter cores.
* Full debugging support.
* Speed should be high at this point (It's too tough ironing out those bugs with Yabause running slow).
* Save States.

List of things that need to be done yet

* OpenGL core needs rewriting to handle texturing better and to handle some of the more obscure features of the saturn.
o Profiling of the Carbon port shows that about 8-9% is spent on texture uploads, most of this in the driver changing the pixel format. Using pixel buffer objects and using the GL_BGRA texture format with the GL_UNSIGNED_INT_8_8_8_8_REV type should reduce this to almost zero.
* SCSP emulation is still missing DSP emulation.
* CD Block emulation is still missing a few odd commands.
* SCU still needs better DSP timing. Some registers might need better support.
* SH2 still needs SCI emulation.
* Eventually we're going to have to add support for multiple languages.
* And much more.

Yabause is still actively being worked on, so hopefully if someone works on the Pandora version and if the yabause team continues to speed up their emulator, we might have something that is playable. Also I heard that the Dreamcast version runs certain games at up to 15-20 fps so there might be hope yet.