
The Sega Saturn and Transparency - city41
http://www.mattgreer.org/articles/sega-saturn-and-transparency/
======
mikepavone
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
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
> 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.

------
giovannibajo1
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.

~~~
mikepavone
> I wrote it to be close to what the hardware does

Your code is quite clean, but I'm not sure I'd say the rendering code is all
that close to what the hardware does.

For instance, the hardware does sprite rendering in 3 distinct phases (sprite
list is scanned for sprites on the current line and the first 20/16 are
recorded somewhere, the non-cached half of each of those 20/16 sprites is read
and then up to 40/32 tiles worth of pixel data is drawn to the line buffer.

Background layer rendering is a bit different too. The VDP actually renders an
extra 2 columns worth of background data (so 42 or 34 total) to enable fine
scrolling. Rendering takes place 2 columns at a time to what I believe is a 32
pixel ring buffer. The data in the ring buffer is composited with the data in
the sprite line buffer as it's output to the display. The "window bug" is just
a consequence of the 2 column coarse scroll granularity and the fact that it
literally replaces the Plane A draws to the ring buffer.

This is not intended as a criticism of your code. If you're only going for
scanline granularity, most of the above is of little consequence (apart from
the window bug) and would only add complexity. That said, I think my emulator,
BlastEm[0], is probably a better reference for low-level VDP behavior as it
has access slot granularity and mirrors the behavior above pretty closely. The
code has gotten a bit messy though. There's also Exodus[1], which has a quite
heavily commented VDP core (a bit too heavily for my taste, but I imagine
others may disagree).

[0]
[http://rhope.retrodev.com/files/blastem.html](http://rhope.retrodev.com/files/blastem.html)
[1]
[https://bitbucket.org/exodusemulator/exodus](https://bitbucket.org/exodusemulator/exodus)

EDIT: Fixed typo "line scrolling" should have ready "fine scrolling in the 3rd
paragraph.

~~~
giovannibajo1
> Your code is quite clean, but I'm not sure I'd say the rendering code is all
> that close to what the hardware does.

OK you're right, what I really meant is that my code is a clear description of
the basic hardware features and how they work, at the level of the detail
discussed in the blog post being discussed (OP). As you noticed, I'm not
emulating anything sub-scanline.

If you look at the precise_dma_fifo branch, I've attempted some sub-scanline
precision timing, while keeping the rendering at the scanline level. The
result is encouraging: for instance, the 512C "your emulator suck" screen in
Overdrive correctly works (at least in the PAL version IIRC). I think I hit a
limit with the way timing was computed in the CPU cores I was using, and then
dropped it for boredom. There were also a few regressions, visible in
Overdrive itself (which is almost perfect on master, with the 512C screen
being the big exception).

> I think my emulator, BlastEm[0]

Thanks for the reference, I'll have a look.

~~~
mikepavone
> The result is encouraging: for instance, the 512C "your emulator suck"
> screen in Overdrive correctly works (at least in the PAL version IIRC). I
> think I hit a limit with the way timing was computed in the CPU cores I was
> using, and then dropped it for boredom. There were also a few regressions,
> visible in Overdrive itself (which is almost perfect on master, with the
> 512C screen being the big exception).

Overdrive is tough. It has some nasty race conditions in it and of course the
512C scene requires a reasonable approximation of the reduction in sprite
capacity. I don't have it working 100% myself (wanted to get some other timing
related things tightened up before trying to chase down the cause of race that
doesn't happen on real hardware). I commend you on getting as far as you did.

The moose chase level of Mickey Mania is another good thing to check out as it
also requires emulation of the sprite capacity reduction.

~~~
giovannibajo1
That works as well, with a really small glitch which I'm not sure if it's
present on the real hardware as well. I _think_ my emulation of sprite limits
is correct.

------
wk_end
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
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

------
rjzzleep
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-
satur...](http://www.theguardian.com/technology/2015/may/14/sega-saturn-how-
one-decision-destroyed-playstations-greatest-rival)

~~~
ac2u
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
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
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
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
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 :)

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

~~~
simoncion
> 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
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_
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.

------
seibelj
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
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)

------
compactmani
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.

------
wtracy
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?

~~~
hias
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
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.

