"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.
Man, Blast Processing is not what I thought it was. . . .
Moderators: BigEvilCorporation, Mask of Destiny
-
- Interested
- Posts: 48
- Joined: Thu Feb 17, 2022 1:14 am
-
- Interested
- Posts: 48
- Joined: Thu Feb 17, 2022 1:14 am
Re: Man, Blast Processing is not what I thought it was. . . .
Someone just posted the images from the demo, so I figured I'd add them here:
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?
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?
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Re: Man, Blast Processing is not what I thought it was. . . .
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."
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
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
-
- Interested
- Posts: 48
- Joined: Thu Feb 17, 2022 1:14 am
Re: Man, Blast Processing is not what I thought it was. . . .
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.Chilly Willy wrote: ↑Thu Dec 15, 2022 10:47 pmBlast 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."
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
Last edited by iNCEPTIONAL on Wed Jan 04, 2023 8:52 pm, edited 1 time in total.
-
- Interested
- Posts: 48
- Joined: Thu Feb 17, 2022 1:14 am
Re: Man, Blast Processing is not what I thought it was. . . .
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 2288 colours on-screen as standard (2047 visible colours 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 too), 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 512 blending 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:
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. 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.
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.
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:
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. 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.
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.
Last edited by iNCEPTIONAL on Sun Sep 08, 2024 6:39 pm, edited 6 times in total.
-
- Interested
- Posts: 48
- Joined: Thu Feb 17, 2022 1:14 am
Re: Man, Blast Processing is not what I thought it was. . . .
Since I'm here, here's a few more representative SNES-accurate standard 8bpp images I recently made using Rilden's Tiled Palette Quantization tool just to see how good they could look at a minimum before any other tricks are employed:
Of course, you'd need to scroll the screen to see the full images on SNES, loading in the new tiles on the fly.