7 ms·

The Sega Saturn and Transparency

173 points by city41 11y ago

bobbles 11y ago
Wow that's a great indication of the composite cable reducing quality, I've never really seen an example of that before
- simoncion 11y ago
  > Wow that's a great indication of the composite cable reducing quality... Yes, but... Double Fine has this Let's Play series with video game developers called -IIRC- Devs Play. One of the first videos is a playthrough of Aladdin and The Lion King on the Sega Genesis. One of the comments that the guy who worked on both titles makes is that you have to keep in mind the target display device [0] when evaluating the art and VFX choices for a given game. The art for both games -but Aladdin in particular- is really gorgeous, but loses a fair bit of its beauty when viewed as hard-edged pixel art on an LCD screen. The hard-edged pixel art that we see on modern sets is likely not at all what the art and effects teams who worked on these games intended. Their design decisions took into account the blurring effect of the target display device. [0] Namely, NTSC/PAL CRT TV sets.
  - to3m 11y ago
    I've seen a few 1080p videos (via Dolphin) of a Wii game I worked on a few years ago, and something similar applies. All the cut corners, ignored bugs and LOD distance settings were chosen assuming 640x480. All much easier to spot at 1080p :(
    - voltagex_ 11y ago
      What do you think of Dolphin and its team as a console dev? I expect you have to keep pretty far away from that stuff, the same as ReactOS/WINE had to stay away from MS source code years ago.
- bane 11y ago
  Or rather increasing quality. Precision != quality in many cases. Low-quality audio/visual mediums are often preferable over ultra-precision ones in many cases e.g. a common technique with guitar music is to distort the sound it makes.
  - DominikR 11y ago
    Very true. I actually paid 400$ for an XRGB mini video upscaler not mainly because it could convert the output from 240p or 480i to 1080p, but because it can also add scanlines which actually reduces precision by a lot. Yet it increases quality because these games were back then developed to work best with old CRT TVs that could only show interlaced video.
giovannibajo1 11y ago
Last year, I wrote a fairly complete Genesis (MegaDrive) emulator in C++, for education purposes, that contains a full VDP emulation. The VDP in Megadrive is the father of the VDPs on Saturn, so you can have a look to see how it works: https://github.com/rasky/genemu https://github.com/rasky/genemu The code should be quite easy to read, as I wrote it to be close to what the hardware does, without any additional complexity for optimizations.
- city41 11y ago
  Thanks for this, I'll definitely take a look. I like straightforward emulators for learning how hardware works.
- anonbanker 11y ago
  If you're the rasky of PSX emulation fame, thanks for this new emu. Been a fan for years.
  - giovannibajo1 11y ago
    Yup that's me, and thanks, I didn't know I had fans :) Another little thing I'm currently working on is a Nintendo DS emulator written 100% in Go: https://github.com/rasky/ndsemu https://github.com/rasky/ndsemu This is very early stage, it boots the BIOS but barely boots any game and they're all very garbled. The nice thing is that I'm emulating graphics fully in parallel with goroutines, so the GPU runs in parallel with CPU. They even potentially access the same memory (VRAM) and I didn't put any mutex/lock there, as theoretically the undefined behavior is similar to what happens in the real hardware... :) I'm curious to see if the strategy pays and I'm able to complete the emulator like this. I'm going to also emulate sound in this way. As for optimizations go, the approach is a little bit different: I had to optimize things here and there to work around (many) Go compiler deficiencies and achieve decent speed. So the code is less "barebone" than Genesis, and that adds up to the fact that the hardware is vastly more complex per-se. I've also factored out generic code in the "emu" sub-package, that is a collection of generic emulation-related classes/packages that could be reused for different emulators in Go.
rjzzleep 11y ago
Funny a few days ago I was playing around with OpenEmu and was trying to remember a game I couldn't remember for a long time(Panzer Dragoon). While doing that I found a nice article that talked about how the Saturn was a vastly superior console and how Sega panicked and completely destroyed itself with that specific console. I also remembered the sad story of how I modded my saturn to play panzer dragoon and then left it in my basement when I moved. http://www.theguardian.com/technology/2015/may/14/sega-saturn-how-one-decision-destroyed-playstations-greatest-rival http://www.theguardian.com/technology/2015/may/14/sega-satur...
- ac2u 11y ago
  Rumour has it that while the Saturn was superior on paper, it was really because rumours of the PSX caused SEGA to double up on processors, meaning more performance but harder to tool up for more parallel based development. Funnily enough we see Sony repeat the same mistake in the PS3, doubling down on a chip architecture aimed at parallelism (cell), while most developers expressed frustration adapting. Didn't really hurt Sony in the big picture though as much as it hurt SEGA. By the time SEGA got so much right in the Dreamcast era, they were already swimming upstream thanks to the ground they lost with the Saturn.
  - pjmlp 11y ago
    One of the things that sold developers to PSX was that Sony took a huge effort to provide a great SDK with the console, something unusual from the other vendors. This was another reason they got lots of flame with the PS3, as not only was it hard to program for, the SDK wasn't that great. Hence why they spent around two years time bringing out a great graphics debugger developed with input of teams like the Gran Turism one, and a middleware for prototyping ideas, PyreEngine.
    - SuddsMcDuff 11y ago
      As I understood it, Sony provided some really nice C libraries in their SDK. While Sega initially expected developers to write games in assembly language. Years later Sonic Team released SGL 2.0, a much nicer high level C API which showed the true potential of the Saturn, but it was too late to claw back the lead Sony had built up.
bhouston 11y ago
Very cool. I wonder if it is possible for the emulators to understand that mesh sprites are semi-transparent and draw them last in the buffer of interest and blend it on top within that buffer. I suspect these games are so specialized in their effects that this would likely screw things up thogh.
- city41 11y ago
  Actually Yabause does that if you use its OpenGL graphics interface instead of the software interface. It interprets the mesh command as 50% transparency. I used Yabause to grab the VDP2's layers when writing this, and at first I was a little stumped when the spotlights weren't meshes :)
- anonbanker 11y ago
  Final Burn and MAME both have the capability to render mesh sprites as transparent. I've used it to great effect on Street Fighter Alpha 3.
seibelj 11y ago
Whenever I see a highly technical article on HN with many upvotes and few comments, I know it will be quality. Nothing much needs to be said, it stands on its own. Great work.
danso 11y ago
Meta-offtopic: What a nice title in this day and age of SEO-optimized clickbait headlines (e.g. You'll Never Believe The Hack Sega Saturn Used to Make a Spotlight in the Mega Man Games!)...admittedly, I clicked because I don't know the author (or his blog) and had no idea what "Transparency" meant...I figured it about Sega obfuscating specs/sales figures, and that this was going to be another retrospective on how Sega lost the console war. I was wrong but didn't feel misled...the article is indeed about transparency...I just didn't think how an old console achieved transparency effects would normally be a topic for a blog post today (unless it's for a very very old system, like the NES, in which it is fascinating to learn how effects were achieved back then)...It's great to read indepth inspection of such "little" effects, the workings of which often illustrate fundamental concepts about computing. Also OT: I had never heard of Wintersmith, which the author uses for his blog, but it looks like a pretty capable Jekyll-like site generator in node: http://wintersmith.io http://wintersmith.io
wk_end 11y ago
Even though it's linked to at the bottom, I can't help but be irked that the content of this writeup - even the specific examples - is basically stolen wholesale from someone else's youtube video [1]. The VDP laying simulator is new and cool, and admittedly having this info in blog form rather than as a youtube video provides value, so it's not as though this isn't a worthwhile post or anything...but I wish the author was more forthright about what this actually is. Calling the original video merely "an inspiration and source of lots of information" is borderline intellectual dishonesty. [1] https://www.youtube.com/watch?v=f_OchOV_WDg https://www.youtube.com/watch?v=f_OchOV_WDg
- ethbro 11y ago
  Be that as it may, I can always read text. I can't always sit and watch a YouTube video with sound. Furthmore, YouTube is pretty terrible for searching. /annoyed at the "Let me turn three sentences into a YouTube video" phenomenon
- city41 11y ago
  I asked the video creator if I could write a post based on his video, and he agreed. I just fleshed out the thank you section a little more and added a disclaimer to the top.
mikepavone 11y ago
This article is not entirely accurate. VDP1 is perfectly capable of rendering half-transparent sprites on top of each other. It was somewhat problematic for 3D games as the drawing algorithm resulted in some overdraw depending on how the quad was warped and there was a pretty big performance penalty, but for 2D games neither seems like an issue. The problem is when you want to use VDP2 for more than just displaying the frame buffer that VDP1 writes to. VDP1 only supports half-transparent mode when drawing in 15-bit color, but VDP2 only supports per-pixel translucency in indexed mode. So you can either have sprites be translucent with respect to each other or translucent with respect to VDP2 background layers, but not both. The best workaround is to just use VDP1 for everything. I'm not sure why you wouldn't in a cross-platform 2D game given that it would be most analogous to what you needed to do on the Playstation. It didn't have any dedicated hardware for backgrounds so you needed to use textured triangles for everything.
- city41 11y ago
  Sounds like you worked on the Saturn back in the day? I'm just a fan of the console. I believe what you are referring to is addressed in Low Score Boy's video where he shows transparency between sprites but not VDP2 layers [1]. [1] https://www.youtube.com/watch?v=f_OchOV_WDg&t=6m52s https://www.youtube.com/watch?v=f_OchOV_WDg&t=6m52s
  - mikepavone 11y ago
    > Sounds like you worked on the Saturn back in the day? Heh, I was only 11 when the Saturn came out. I've been involved in the Sega homebrew/emulation community for a long time though. Mostly focused on the 16-bit stuff, but I've toyed with the idea of working with the Saturn and read some documentation.
wtracy 11y ago
The main thing that surprised me in this article was learning that the Saturn had eight processors. Was that an outlier for consoles at the time?
- kevingadd 11y ago
  Yes. Though it was certainly common for consoles to have more than one processor (you usually had a handful of special-purpose cores), eight is pretty excessive.
- hias 11y ago
  This is why a Saturn emulator was thought to be impossible for a long time. I just looked around and there seem to be some Saturn emulators around, but I did not test them and do not know how good they work - does anybody know? :-)
  - Grazester 11y ago
    There is only one truly good emulator and that is SSF. The others may only emulate a percentage of some of the processors accurately. SSF is by an unknown Japanese author that some believe may have worked at Sega on the Saturn.
compactmani 11y ago
I use my Sega Saturn with RGB Scart and a custom line doubler (for use with a modern TV). I actually find the mesh to be a charming SS feature if you will. Very cool article.

173 points by city41 11y ago

bobbles 11y ago

Wow that's a great indication of the composite cable reducing quality, I've never really seen an example of that before

simoncion 11y ago
> Wow that's a great indication of the composite cable reducing quality... Yes, but... Double Fine has this Let's Play series with video game developers called -IIRC- Devs Play. One of the first videos is a playthrough of Aladdin and The Lion King on the Sega Genesis. One of the comments that the guy who worked on both titles makes is that you have to keep in mind the target display device [0] when evaluating the art and VFX choices for a given game. The art for both games -but Aladdin in particular- is really gorgeous, but loses a fair bit of its beauty when viewed as hard-edged pixel art on an LCD screen. The hard-edged pixel art that we see on modern sets is likely not at all what the art and effects teams who worked on these games intended. Their design decisions took into account the blurring effect of the target display device. [0] Namely, NTSC/PAL CRT TV sets.
- to3m 11y ago
  I've seen a few 1080p videos (via Dolphin) of a Wii game I worked on a few years ago, and something similar applies. All the cut corners, ignored bugs and LOD distance settings were chosen assuming 640x480. All much easier to spot at 1080p :(
  - voltagex_ 11y ago
    What do you think of Dolphin and its team as a console dev? I expect you have to keep pretty far away from that stuff, the same as ReactOS/WINE had to stay away from MS source code years ago.
bane 11y ago
Or rather increasing quality. Precision != quality in many cases. Low-quality audio/visual mediums are often preferable over ultra-precision ones in many cases e.g. a common technique with guitar music is to distort the sound it makes.
- DominikR 11y ago
  Very true. I actually paid 400$ for an XRGB mini video upscaler not mainly because it could convert the output from 240p or 480i to 1080p, but because it can also add scanlines which actually reduces precision by a lot. Yet it increases quality because these games were back then developed to work best with old CRT TVs that could only show interlaced video.

giovannibajo1 11y ago

Last year, I wrote a fairly complete Genesis (MegaDrive) emulator in C++, for education purposes, that contains a full VDP emulation. The VDP in Megadrive is the father of the VDPs on Saturn, so you can have a look to see how it works: https://github.com/rasky/genemu https://github.com/rasky/genemu The code should be quite easy to read, as I wrote it to be close to what the hardware does, without any additional complexity for optimizations.

city41 11y ago
Thanks for this, I'll definitely take a look. I like straightforward emulators for learning how hardware works.
anonbanker 11y ago
If you're the rasky of PSX emulation fame, thanks for this new emu. Been a fan for years.
- giovannibajo1 11y ago
  Yup that's me, and thanks, I didn't know I had fans :) Another little thing I'm currently working on is a Nintendo DS emulator written 100% in Go: https://github.com/rasky/ndsemu https://github.com/rasky/ndsemu This is very early stage, it boots the BIOS but barely boots any game and they're all very garbled. The nice thing is that I'm emulating graphics fully in parallel with goroutines, so the GPU runs in parallel with CPU. They even potentially access the same memory (VRAM) and I didn't put any mutex/lock there, as theoretically the undefined behavior is similar to what happens in the real hardware... :) I'm curious to see if the strategy pays and I'm able to complete the emulator like this. I'm going to also emulate sound in this way. As for optimizations go, the approach is a little bit different: I had to optimize things here and there to work around (many) Go compiler deficiencies and achieve decent speed. So the code is less "barebone" than Genesis, and that adds up to the fact that the hardware is vastly more complex per-se. I've also factored out generic code in the "emu" sub-package, that is a collection of generic emulation-related classes/packages that could be reused for different emulators in Go.

rjzzleep 11y ago

Funny a few days ago I was playing around with OpenEmu and was trying to remember a game I couldn't remember for a long time(Panzer Dragoon). While doing that I found a nice article that talked about how the Saturn was a vastly superior console and how Sega panicked and completely destroyed itself with that specific console. I also remembered the sad story of how I modded my saturn to play panzer dragoon and then left it in my basement when I moved. http://www.theguardian.com/technology/2015/may/14/sega-saturn-how-one-decision-destroyed-playstations-greatest-rival http://www.theguardian.com/technology/2015/may/14/sega-satur...

ac2u 11y ago
Rumour has it that while the Saturn was superior on paper, it was really because rumours of the PSX caused SEGA to double up on processors, meaning more performance but harder to tool up for more parallel based development. Funnily enough we see Sony repeat the same mistake in the PS3, doubling down on a chip architecture aimed at parallelism (cell), while most developers expressed frustration adapting. Didn't really hurt Sony in the big picture though as much as it hurt SEGA. By the time SEGA got so much right in the Dreamcast era, they were already swimming upstream thanks to the ground they lost with the Saturn.
- pjmlp 11y ago
  One of the things that sold developers to PSX was that Sony took a huge effort to provide a great SDK with the console, something unusual from the other vendors. This was another reason they got lots of flame with the PS3, as not only was it hard to program for, the SDK wasn't that great. Hence why they spent around two years time bringing out a great graphics debugger developed with input of teams like the Gran Turism one, and a middleware for prototyping ideas, PyreEngine.
  - SuddsMcDuff 11y ago
    As I understood it, Sony provided some really nice C libraries in their SDK. While Sega initially expected developers to write games in assembly language. Years later Sonic Team released SGL 2.0, a much nicer high level C API which showed the true potential of the Saturn, but it was too late to claw back the lead Sony had built up.

bhouston 11y ago

Very cool. I wonder if it is possible for the emulators to understand that mesh sprites are semi-transparent and draw them last in the buffer of interest and blend it on top within that buffer. I suspect these games are so specialized in their effects that this would likely screw things up thogh.

city41 11y ago
Actually Yabause does that if you use its OpenGL graphics interface instead of the software interface. It interprets the mesh command as 50% transparency. I used Yabause to grab the VDP2's layers when writing this, and at first I was a little stumped when the spotlights weren't meshes :)
anonbanker 11y ago
Final Burn and MAME both have the capability to render mesh sprites as transparent. I've used it to great effect on Street Fighter Alpha 3.

seibelj 11y ago

Whenever I see a highly technical article on HN with many upvotes and few comments, I know it will be quality. Nothing much needs to be said, it stands on its own. Great work.

danso 11y ago

Meta-offtopic: What a nice title in this day and age of SEO-optimized clickbait headlines (e.g. You'll Never Believe The Hack Sega Saturn Used to Make a Spotlight in the Mega Man Games!)...admittedly, I clicked because I don't know the author (or his blog) and had no idea what "Transparency" meant...I figured it about Sega obfuscating specs/sales figures, and that this was going to be another retrospective on how Sega lost the console war. I was wrong but didn't feel misled...the article is indeed about transparency...I just didn't think how an old console achieved transparency effects would normally be a topic for a blog post today (unless it's for a very very old system, like the NES, in which it is fascinating to learn how effects were achieved back then)...It's great to read indepth inspection of such "little" effects, the workings of which often illustrate fundamental concepts about computing. Also OT: I had never heard of Wintersmith, which the author uses for his blog, but it looks like a pretty capable Jekyll-like site generator in node: http://wintersmith.io http://wintersmith.io

wk_end 11y ago

Even though it's linked to at the bottom, I can't help but be irked that the content of this writeup - even the specific examples - is basically stolen wholesale from someone else's youtube video [1]. The VDP laying simulator is new and cool, and admittedly having this info in blog form rather than as a youtube video provides value, so it's not as though this isn't a worthwhile post or anything...but I wish the author was more forthright about what this actually is. Calling the original video merely "an inspiration and source of lots of information" is borderline intellectual dishonesty. [1] https://www.youtube.com/watch?v=f_OchOV_WDg https://www.youtube.com/watch?v=f_OchOV_WDg

ethbro 11y ago
Be that as it may, I can always read text. I can't always sit and watch a YouTube video with sound. Furthmore, YouTube is pretty terrible for searching. /annoyed at the "Let me turn three sentences into a YouTube video" phenomenon
city41 11y ago
I asked the video creator if I could write a post based on his video, and he agreed. I just fleshed out the thank you section a little more and added a disclaimer to the top.

mikepavone 11y ago

This article is not entirely accurate. VDP1 is perfectly capable of rendering half-transparent sprites on top of each other. It was somewhat problematic for 3D games as the drawing algorithm resulted in some overdraw depending on how the quad was warped and there was a pretty big performance penalty, but for 2D games neither seems like an issue. The problem is when you want to use VDP2 for more than just displaying the frame buffer that VDP1 writes to. VDP1 only supports half-transparent mode when drawing in 15-bit color, but VDP2 only supports per-pixel translucency in indexed mode. So you can either have sprites be translucent with respect to each other or translucent with respect to VDP2 background layers, but not both. The best workaround is to just use VDP1 for everything. I'm not sure why you wouldn't in a cross-platform 2D game given that it would be most analogous to what you needed to do on the Playstation. It didn't have any dedicated hardware for backgrounds so you needed to use textured triangles for everything.

city41 11y ago
Sounds like you worked on the Saturn back in the day? I'm just a fan of the console. I believe what you are referring to is addressed in Low Score Boy's video where he shows transparency between sprites but not VDP2 layers [1]. [1] https://www.youtube.com/watch?v=f_OchOV_WDg&t=6m52s https://www.youtube.com/watch?v=f_OchOV_WDg&t=6m52s
- mikepavone 11y ago
  > Sounds like you worked on the Saturn back in the day? Heh, I was only 11 when the Saturn came out. I've been involved in the Sega homebrew/emulation community for a long time though. Mostly focused on the 16-bit stuff, but I've toyed with the idea of working with the Saturn and read some documentation.

wtracy 11y ago

The main thing that surprised me in this article was learning that the Saturn had eight processors. Was that an outlier for consoles at the time?

kevingadd 11y ago
Yes. Though it was certainly common for consoles to have more than one processor (you usually had a handful of special-purpose cores), eight is pretty excessive.
hias 11y ago
This is why a Saturn emulator was thought to be impossible for a long time. I just looked around and there seem to be some Saturn emulators around, but I did not test them and do not know how good they work - does anybody know? :-)
- Grazester 11y ago
  There is only one truly good emulator and that is SSF. The others may only emulate a percentage of some of the processors accurately. SSF is by an unknown Japanese author that some believe may have worked at Sega on the Saturn.

compactmani 11y ago

I use my Sega Saturn with RGB Scart and a custom line doubler (for use with a modern TV). I actually find the mesh to be a charming SS feature if you will. Very cool article.