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.
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].
> 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.
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
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.
> 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).
> 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).
> 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.
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.
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.
I didn't have time to implement support for homebrew ROMs (in fact, I don't even know how they work -- I'm not into the NDS homebrew scene so I know close to nothing on how they are developed).
I would expect at least the BIOS to be needed, maybe the firmware is custom; it is certainly possible to emulate the BIOS via HLE (I know some emulators do it), but I find it a little outside of the scope of my projects. I might get to it, eventually.
I also dispute that owning a dump of a game/BIOS of a console you own is illegal, but that's a large discussion for lawyers :)
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.
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
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.
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.
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.
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.
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.
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.
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 :)
> 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.
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 :(
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.
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.
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.
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
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.
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.
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? :-)
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.
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.