How 16-bit consoles constructed their graphics and what various terms mean

How 16-bit consoles constructed their graphics and what various terms mean | White_Pointer Gaming

Рет қаралды 3,122

Күн бұрын

Пікірлер: 26

@PinkPandaKatie 5 ай бұрын

A bit of clarification: When you say "HDMA allows Mode 7 to do cool tricks that it couldn't do on its own", technically, the only thing that Mode 7 *can* do on its own is an affine transformation: Translation, rotation, scaling, and skew. It can't actually do perspective transformation without HDMA changing the matrix registers on each line. HDMA is actually what most games use to change the mode itself since the mode register is one that it can access. Super Mario Kart is one example of a game that does manipulate the registers in the middle of the game using the CPU: In split-screen mode, it turns on forced blanking in the middle of the frame, then loads new sprites for the bottom half. This takes a few scanlines to complete, which is why there's a thick black bar separating the views. All of the other effects, including mode switching and perspective are done using HDMA.

@SlimXG 2 ай бұрын

For the Mega Drive, there's actually a specific benefit to performing DMAs during VBLANK. The VDP performs DMA significantly faster while the screen is disabled, which is most commonly the case during VBLANK.

@litjellyfish 27 күн бұрын

Is it really faster? Is it not just that because the DMA is not used to display the screen you have 10x more free DMA then. The end result just want to check as I can’t understand how DMA works

@SlimXG 26 күн бұрын

@@litjellyfish The 10x value may be off, since I see conflicting numbers from different sources. But performing a DMA transfer from the 68k's memory to the VRAM is significantly faster during VBLANK/when the display is disabled. There are various wiki pages that cover it. You should be able to find some by searching for "mega drive vdp dma"

@Bofner 4 ай бұрын

An interesting point about sprite flicker (at least on the Sega Master System, though I assume on most 8-bit onsole at least) : Sprite flicker is not an automatic process. On the SMS, sprites have different priorities, based on their location in the Sprite Attribute Table (SAT). Those with a lower address on the table, ie. $3F00 will be given draw priority over those with a higher address on the table, ie. $3FFF. So if there are 9 sprites on a single scanline on the Master System, only the first 8 sprites with the lowest SAT address will be drawn. The rest will actually be completely invisible. Sprite Flicker as we know it is actually something that has to be coded in by the programmer. This is usually done by shuffling around the addresses of each sprite in the SAT so that their priority is constantly shifting. This is viewed as flicker by the player. You can see this happening if you open up an SMS game in an emulator like Emulicious. I believe this is also how the Game Boy Color works, but the original black and white Game Boy determines the draw priority by which sprites have the lowest X coordinate, so I'm not sure how flicker would work on an old-school DMG Game Boy, or if it was possible. I'm not very familiar with the DMG library unfortunately. Interestingly, slowdown is ALSO something that doesn't happen automatically, and must be manually coded in by the programmer.

@loganjorgensen 2 ай бұрын

Also worth noting how V-blank came in different sizes per platform for hardware performance sake, why DOS gaming was 320x200 and Genesis was 320x224, or how few platforms actually were 320x240 or 240p in the 90s till much later in the decade. Same for the 4:3 anamorphic stretch varying too, which was a pain in the ass with cross platform development lol. I tend to only refer to "background tiles" and instead say "sprite blocks" just to make sure there is no confusion between both units rather than say "tiles" for everything in statements.😉

@n2oshotandironman 6 ай бұрын

Always wondered what all these terms referred to. Great video.

@ИгорьН-г3ф 2 ай бұрын

such a clear presentation)) thanks))

@adesignersperspective 6 ай бұрын

love this channel. also the lost vikings always needs more love!

@gtrzdaddy 4 ай бұрын

That was super informative and interesting! I can't wait to see more tricks and techniques of the retro gaming console development.

@ViperGTS737 6 ай бұрын

that was an awesome guide, thanks man

@andresdigi25 4 күн бұрын

amazing content

@AFourEyedGeek 25 күн бұрын

Why did you say that blast processing can only display 256 colours? I believe it can display any colour from the full palette, so all 512 colours on screen. However, the screen can only be 2/3rds full.

@Damaged7 6 ай бұрын

Splitting the screen into different modes? Never even occured to me lol.

@WhitePointerGaming 6 ай бұрын

It was done quite a lot!

@inceptional 5 ай бұрын

There's a demo out there where someone actually shows the SNES displaying seven out of the eight available backgrounds modes all running on-screen at once just by switching them down the screen. It's a fugly programmer art demo, but it's pretty technically impressive and shows some of the potential there.

@whamer100 2 ай бұрын

@@inceptionali think ive seen this before, but I can't remember what the name was

@inceptional 2 ай бұрын

@@whamer100 Yeah, I can't remember the name either.

@HouSlalom 2 ай бұрын

How did the Sega CD work?

@WhitePointerGaming Ай бұрын

It's explained in my newest video! :) kzbin.info/www/bejne/nXq5i42Zjp6peKM

@shinyhappyrem8728 25 күн бұрын

1:06 Technically one movement from the top left to the bottom right (plus VBLANK) is a field, and TVs usually draw 2 fields with their lines interlaced between each other, hence interlaced mode. Games usually cut the second field off prematurely so the next field is drawn over the first field; in that case a field is equal to a frame. 1:15 For normal TV broadcasts it's exactly 60/1.001 fields per second, Wikipedia has a nice section in the "NTSC" article on why/how they used that. For the progressive mode of the consoles it depends on how many lines they have in a field, and the exact duration of a line which depends on the dot clock frequency, usually a fraction of the system clock. The duration of a line may also not always be exactly the same, to slightly vary the NTSC color artifacts over two frames. Usually it's a bit faster than 60/1.001 fps because it draws half a line less per field. 2:29 Afaik the TV always moves the beam slightly downward at all times, both during active display and horizontal retrace. But that could very well be an implementation detail that could have varied over the years and between manufacturers. 3:47 Well, it doesn't involve the CPU executing program code for every byte transfer. The CPU could very well contain the circuitry ("DMA engine") that stops the program code, enables the source's "read mode" control line and the target's "write mode" control line, and then on every clock cycle just advances the respective address bus values. Afaik on the Amiga it's a dedicated "Copper" chip, while on the NES and SNES this is integrated into the CPU chip. 4:29 For games on ancient consoles like the Atari 2600 the game was basically drawing each scanline 'manually', so parallax effects would be very easy there too. Just CPU intensive, of course. 4:57 The NES had a feature that sets a bit in the PPU status register when an opaque pixel of sprite 0 overlaps an opaque pixel of the background. Games could use that to detect when a certain scanline was reached. 9:34 That's when the systems were released... Of course their development started a few years earlier. The WDC 65c816 CPU was released in 1985 while the SNES which used it as its CPU's core was released 5 years later. The NES is even more extreme: the MOS 6502 was released in 1975 and the NES in 1983. 10:55 Some games actually intentionally use that sprite hiding behavior. Afaik it's how the Mario games hide the portion of him that is already in a pipe, and in Zelda 1 how Link walks under the wall tiles when passing vertical doors in a dungeon.

@musaran2 6 күн бұрын

Caveats: 1:06 Number of scanlines and field alternance were dictated by TV raster standards and fixed. Consoles always output them all, only how they built it varied. Very common was to issue the same content on both fields, effectively spreading each pixel over 2 CRT scanlines. 2:29 The beam was horizontal when active, even on cheap TVs. This is verifiable on slo-mo footage of CRTs. 3:47 DMA is conceptually a co-processor dedicated to memory transfers. Being separate or integrated is a manufacturing detail. 10:55 Some games did hide sprites this way, emulators have to take care. But Mario3-in-pipe is hidden by another sprite, itself hidden behind the pipe.

@GerardMenvussa 23 күн бұрын

7:47 I always disliked how childish and toxic sega's marketing was back then. It did not do them any favour on the long run... At the end of the day, so called blast processing was some kind of palette swap, but on a per scanline level? Not sure if that is truly unique to the MD, swapping palette for specific areas of the screen is pretty common. But if doing it per scanline cannot be used easily in games, it becomes a pretty weak argument.