Man, Blast Processing is not what I thought it was. . . .

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

Post Reply
iNCEPTIONAL
Interested
Posts: 26
Joined: Thu Feb 17, 2022 1:14 am

Man, Blast Processing is not what I thought it was. . . .

Post by iNCEPTIONAL » Mon Dec 12, 2022 6:35 pm

"The fact is that Blast Processing is such a hardcore, low-level application of the Mega Drive hardware that, astonishingly, it was never used in any shipping games and only in recent years has the technique been successfully mastered. And even then, its actual application in games is severely limited, with some interesting, but not exactly game-changing results ... But secondly, and perhaps more pressingly, Blast Processing essentially uses the entirety of the 68000's CPU time. You can run Blast Processing on a Mega Drive game, but you'd be unable to run anything with it ... So it's useless for standard cartridge games [other than for static high-colour images] ... Throughout the machine's lifetime, clever coding produced an almost generational leap in the effects seen in Mega Drive titles - but Blast Processing, unfortunately, wasn't one of them." - Eurogamer

Here's a video of what real Blast Processing is: https://www.youtube.com/watch?v=rvvL6S5Buiw

I guess this would make it more of a VDP thing than a CPU thing then, no? Kinda the opposite of what I would have thought based on Sega's marketing of Blast Processing back in the day. Either way, I definitely used to think it was something specifically related to making Genesis games run really fast, and certainly faster than the competition, rather than being able to make it display nicer looking static images.

I feel like I learn something new about these old consoles every day.

But, hey, the high-colour images do look half-decent for what they are, at least based on the clips in the video footage above. Although, it would be nice if I could find some examples of clean full-screen images of Blast Processing in action somewhere online to check out.

Note: I did try downloading the demo that’s linked in the Digital Foundry video, but it wasn’t working for me, and all I saw was a bunch of horizontal lines on the screen.

iNCEPTIONAL
Interested
Posts: 26
Joined: Thu Feb 17, 2022 1:14 am

Re: Man, Blast Processing is not what I thought it was. . . .

Post by iNCEPTIONAL » Thu Dec 15, 2022 4:51 pm

Someone just posted the images from the demo, so I figured I'd add them here:
1.png
1.png (19.01 KiB) Viewed 686 times
2.png
2.png (21.36 KiB) Viewed 686 times
3.png
3.png (24.72 KiB) Viewed 686 times
Nice to finally see Blast Processing in all its glory.

Does anyone know what the big bars of solid colour are at the bottom of the images?

Chilly Willy
Very interested
Posts: 2957
Joined: Fri Aug 17, 2007 9:33 pm

Re: Man, Blast Processing is not what I thought it was. . . .

Post by Chilly Willy » Thu Dec 15, 2022 10:47 pm

Blast Processing, the way Sega pushed in ads, was just marketing hype. The joke among programmers was to point to a chip on the PCB and tell folks "that's the Blast Processor." :lol:

The "blast processing" done by programmers of the time was to make use of raster timed interrupts to initiate DMA operations to change colors and/or tiles on the fly to extend what could be displayed. As the video showed, the underwater areas in Sonic. Also in Sonic, but not as easily discerned, tiles were replaced on the fly depending on where you were in the level to allow more objects in the levels than would fit in vram. You're using DMA to "blast" new info to the cram or vram or vsram to allow the display of "stuff" you might not otherwise be able to display.

As to using DMA to draw a display on the screen, I just tend to call it Direct Color DMA. Direct Color refers to the fact that each word being DMA'd is a direct color mode pixel, being BGR444 big-endian format. DMA because you're using DMA to move these direct color pixels to the background color register. No more, no less. For the Genesis by itself, this mode isn't really good for more than still images. You could use this for Visual Novels, for example, or turn-based games (card games, turn-based simulators, etc). It's much more useful with the Sega CD. One thing the Sega CD adds is two banks of 128KB of ram that can be flipped between the MD and CD sides. One bank of 128KB will be visible to the MD while the other is visible to the CD. 128KB is plenty of memory for showing a full screen Direct Color DMA image for the bank currently on the MD side. In the meantime, the CD side is updating the other 128KB block with the next screen to show. Then it flips the two banks and start the next frame.

MatteusBeus has some updated demos with the mode here: https://www.youtube.com/watch?v=eYYeGy47UJE

iNCEPTIONAL
Interested
Posts: 26
Joined: Thu Feb 17, 2022 1:14 am

Re: Man, Blast Processing is not what I thought it was. . . .

Post by iNCEPTIONAL » Fri Dec 16, 2022 12:03 am

Chilly Willy wrote:
Thu Dec 15, 2022 10:47 pm
Blast Processing, the way Sega pushed in ads, was just marketing hype. The joke among programmers was to point to a chip on the PCB and tell folks "that's the Blast Processor." :lol:

The "blast processing" done by programmers of the time was to make use of raster timed interrupts to initiate DMA operations to change colors and/or tiles on the fly to extend what could be displayed. As the video showed, the underwater areas in Sonic. Also in Sonic, but not as easily discerned, tiles were replaced on the fly depending on where you were in the level to allow more objects in the levels than would fit in vram. You're using DMA to "blast" new info to the cram or vram or vsram to allow the display of "stuff" you might not otherwise be able to display.

As to using DMA to draw a display on the screen, I just tend to call it Direct Color DMA. Direct Color refers to the fact that each word being DMA'd is a direct color mode pixel, being BGR444 big-endian format. DMA because you're using DMA to move these direct color pixels to the background color register. No more, no less. For the Genesis by itself, this mode isn't really good for more than still images. You could use this for Visual Novels, for example, or turn-based games (card games, turn-based simulators, etc). It's much more useful with the Sega CD. One thing the Sega CD adds is two banks of 128KB of ram that can be flipped between the MD and CD sides. One bank of 128KB will be visible to the MD while the other is visible to the CD. 128KB is plenty of memory for showing a full screen Direct Color DMA image for the bank currently on the MD side. In the meantime, the CD side is updating the other 128KB block with the next screen to show. Then it flips the two banks and start the next frame.

MatteusBeus has some updated demos with the mode here: https://www.youtube.com/watch?v=eYYeGy47UJE
Thanks for that. Definitely helped me understand how things work a bit better. And it was nice to see that higher quality Sonic image in the video too, and without the big bar of colour as in the images above. The mode is actually a bit more limited than even I thought--I didn't think it had quite that much impact on the CPU and even the sound processor, plus the various other restrictions--but I think it could have some simple use for maybe a visual novel or whatever approach on Genesis like you said, or even just some cutscene images before a game level and the like.
Last edited by iNCEPTIONAL on Wed Jan 04, 2023 8:52 pm, edited 1 time in total.

iNCEPTIONAL
Interested
Posts: 26
Joined: Thu Feb 17, 2022 1:14 am

Re: Man, Blast Processing is not what I thought it was. . . .

Post by iNCEPTIONAL » Wed Dec 28, 2022 4:44 pm

So, I recently read/watched a bit more on the direct colour mode for SNES, and, unless I'm missing something, doesn't the stuff in the following link mean it would actually be able to display as many as 2289 colours on-screen as standard (2048 on BG1 alone in direct colour mode, plus an additional 120 on BG2 and another 120 for sprites that are both chosen from that 15-bit/32,786-colour master palette, as well as the single backdrop colour as well), and that's before any other things are applied like SNES' standard colour math, HDMA gradients on the backdrop colour, raster tricks and whatever pseudo effects, if I've understood it correctly:

https://youtu.be/5SBEAZIfDAg?t=275

It's rather disappointing that there doesn't appear to be any genuinely good example images on SNES that use this mode, or even just some that use the regular 8bpp 256-colours of Mode 3 along with some colour math combining the two layers and potentially sprites too, as well as HDMA backdrop colour gradients, additional raster tricks and so on. I mean, even the most basic/standard use of Mode 3 can produce results like this:

2.5.png
2.5.png (50.54 KiB) Viewed 392 times
3.5.png
3.5.png (38.57 KiB) Viewed 392 times
7.png
7.png (49.52 KiB) Viewed 394 times

And the SNES should be able to do all of this without any notable hit on the CPU or stalling the sound or whatever too, as in, it can do this during actual normal gameplay, still with two full overlapping parallax background layers and some sprites and so on (albeit with less unique background tiles than normal). As far as I can tell, the only thing to really consider here is how to manage the VRAM to the make the most of such a method.

Note: Although it mentions in the video that black and white aren't available in the direct colour background palette, they can still easily be achieved here in the BG2 and sprites palettes. So that's not as big a deal as I at least initially thought. Just something I figured would be worth mentioning too.

So, we have some lovely Blast Processed images on the Genesis now, and Turboxray recently posted some gorgeous high-res and high-colour images on PC Engine too, but I feel like the SNES is being woefully underrepresented in the dev scene with regards to this high-colour and high-res space, both in terms of what it can achieve purely with static images (or simple panning/scrolling ones) but also during normal gameplay when actually pushed to its limits.

Post Reply