Software transparencies on the Jaguar

[SlidellMan]

I was wondering if the Jaguar was capable of transparency effects a la the Super NES and 3DO? I know that the Sega Saturn could only do it in very limited amounts.

[aminor00]

I don't remember any games having transparency even when it *should* have done.

 

For example, Doom on PC had transparent pink dogs and other demons. I don't remember them on the Jag at all whereas on the PS1 I recall transparency being used for the pink dog things quite a lot.

 

Sent from my SM-G930F using Tapatalk

[+BitJag]

http://gdurl.com/RDth

 

The jag can do an assortment of overlay effects that simulate what alpha transparency can do. The AVP hud is an example of this, and also the shadows in some of the 2 player fighter games do this as well.

 

http://gdurl.com/U0ZW

 

The domes in Missile Command 3D seem to be using a combination of dithering and an overlay effect, which is a fair approximation of what alpha blending might look like in a similar scenario.

 

There is obviously a hardware implementation for clipped transparency (a 0 or a 1). But if I had to make a guess, there probably isn't a hardware implementation for float precision alpha transparencies (I am not sure if this is even the right terminology for what your asking...). I don't understand all the intricacies of how that works, but it seems like something could be done at the software level to pull it off, but at a processing cost too large to be practical for a game.

 

https://youtu.be/lvwUwuTzZGY?t=1m37s

 

One game that still fascinates me is the use of overlay effects used for transitioning menu elements in and out in BattleMorph's main menus. Pretty smooth stuff, and to the layman, looks like they are using alpha blending.

[Zerosquare]

The hardware does not support alpha-blending.

 

There's an add/subtract mode that can be used to add highlights/shadows and create translucent graphics, but it only works in CRY colorspace (which is specific to the Jaguar) and is less versatile than standard alpha-blending.

[tschak909]

CRY colorspace? That's a new one for me.

 

-Thom

[Swansea_Mariner]

Sounds like something out of a Clive Barker novel!

[sd32]

Whats the effect used for the transparent car windows in Club Drive?

 

Edited October 2, 2017 by sd32

[SlidellMan]

So, I take it as a "yes".

[Punisher5.0]

I was wondering if the Jaguar was capable of transparency effects a la the Super NES and 3DO? I know that the Sega Saturn could only do it in very limited amounts.

I always found it to be interesting that Sega didn't take transparencies serious until the Dreamcast. For me the checkerboard effect looks terrible. I'd rather it just be nothing than that.

[+Stephen]

Whats the effect used for the transparent car windows in Club Drive?

 

I can't imagine it would be hard to do colour calculations in software for that awesome 10 polygon car. The little Atari 8-bit could damn near pull that game off.

[VladR]

So, I take it as a "yes".

If by "Yes" you mean doing the per-pixel computations, then sure - you could do the alpha blending on jag in software.

 

It's not really the computation that would slow it down (that's just few instructions on GPU). The problem is the bandwidth - first you must read the pixel from framebuffer, recompute, and then store the same pixel. Which was already written into RAM before. So, you're hitting same RAM location multiple times (not a good thing on jag, generally).

 

There are simple alpha blending effects that could run on jag in 60 fps, say in an screen area of 80x120. The problem is, not much else would, before the framerate would dive.

 

As for the Club Drive example, unless they're doing something very wrong (could be, if it was rushed), that transparency - in that screen area - shouldn't really take more than 20-33% of a frame time, so not a big performance impact in given framerate.

[SlidellMan]

@VladR: So I also take it as it would require a lot of planning and code optimization for processing speed?

[VladR]

@VladR: So I also take it as it would require a lot of planning and code optimization for processing speed?

Depends. If it's just for a menu / UI, performance doesn't matter much. But if it's supposed to happen each game frame, then you gotta put some limitations asap.

 

Of course, it doesn't hurt much to loose half of a frame, if your frame rate is 10. You'll just drop to 9 when doing transparency and nobody will notice.

 

But if you are at 60 fps, then loosing half of frame will mean drop to 30 fps. And you'd never hear the end of that

 

Of course, it's not impossible to design something that could run at 60fps with some transparency, but then you would have to sacrifice a lot of the 4 Kb just for that effect as to keep things running fast on jag, you gotta keep processing, while blitter is blitting, which means adjusting algorithm accordingly (not always easy) and reserving a lot of precious 4 Kb just for two needed buffers.

 

But that means you can't do Op list on Gpu, and 68k will choke up on just few bitmaps, unless you do OP list double buffering on 68k, which you can do just fine during frame time.

 

Except then you find out you already spent on 68k 20-33% of frame time just on Op list and as Gpu is busy shuffling blitter and syncing two buffers, not much performance is left on 68k for else other than some simple 2d gameplay.

 

Now, the Gpu would not spend much time on doing the alpha blending. Some decent area could be computed in , say, 20-40% of frame time. That leaves a lot of performance available for game. But you already filled 4 KB with two buffers, blending code and some default Gpu routines.

 

So, the only way is to start caching the code back and forth each frame-which costs about 15% of frame time if you want to keep things at 60 fps.

 

And since you are generally done computing alpha blending for temp buffer before blitter is done blitting, you wait a bit.

That shit adds up across all scanlines of the rectangle you were processing and by the time you blit the code back and forth, you wasted the frame and are now on the brink of falling down to 30 fps.

 

Now if you are good with 30 fps, you don't have to use 2 buffers, hell - you can just straight process the bitmap right at the destination, ignore blitter complications, and still have a lot of 4 KB left for some gameplay code or even OP list code.

 

You can, of course ignore all that, if you are willing to use dsp thus split the code across Dsp, Gpu and 68000.

 

Except, good luck syncing the dependencies across all 3 chips

[walter_J64bit]

I've got Club Drive time to play it! :thumbsup:

[swapd0]

I can't imagine it would be hard to do colour calculations in software for that awesome 10 polygon car. The little Atari 8-bit could damn near pull that game off.

 

It doesn't matter on the polygon count, it's about the number of pixels you're going to draw

[VladR]

 

It doesn't matter on the polygon count, it's about the number of pixels you're going to draw

Actually, Stephen is right.

 

The little 8-bit 1.79 MHz 6502 Atari is surprisingly fast, when it comes to fill-rate. I'm devoting my current coding spree (feel free to check A8 coding section on AA) to porting jag's flatshader to 6502 and actual pixel filling (current data set is ~12,000 pixels, 74% of full screen, 160x96) takes up only 6,450 out of 53,000 cycles. Note, that you have about 24,000 cycles available per frame in that resolution.

 

Which is just 12% of the whole 3D pipeline. The remaining 88% goes towards:

- 3D transform

- clipping

- edge line computation

- scanline traversal

- proper edge handling via bitmasks

 

The funny thing about those 12% is that if we're willing to reserve 4 KB more for the unrolled filling code loops (not a problem, as there's 128 KB available on 130XE), it can be brought down to 3,300 cycles. At which point, the filling would take just 6%, but currently there's no point in optimizing something that takes just 12% of all cycles (the effort should go towards optimizing those 88%, obviously).

 

 

 

I'm wondering, if there ever was a jaguar game/demo/prototype that was running in a 4-color mode (like A800's gfx mode):

- 4 colors ( 2-bit depth) means 4 pixels fit into a byte, instead of just 1 pixel (8-bit depth)

- thus, same amount of bytes written (the jaguar bandwidth problem) equals to 4x more pixels

- 352x4 = 1,408 -> We could thus keep same framerate in 1408x240, as in 352x240, because nothing else would change in the pipeline (other than doing logical OR for edges, but that's fast on 6502, let alone GPU)

- So, my wipeout flatshader codepath would run at the same framerate in 1408x240, it just would have 4 colors (but dithering can be used to bring more shades)

 

However, at 1408 resolution, the dithering could actually bring some very interesting visuals - actually Blitter has a register that has the byte mask used for writing, so Blitter could basically do Hires dithering for free for us.

 

There was a very brief period of time on PC, that had flatshading but in HiRes (I recall few flight simulators) - I always loved it much more than the grainy/pixelated texturing attempts, as the flatshading has its specific smooth, clean charm (if used properly, of course)...

 

 

 

I'm wondering how many people would actually prefer to trade much faster framerate for much less colors but in higher resolution in a Checkered Flag. I understand that press would just laugh at something like that, especially at jaguar's time, but still firmly believe that even on a console, it should be up to the player to choose his visual / performance preference, not up to developer...

[Punisher5.0]

Actually, Stephen is right.

 

The little 8-bit 1.79 MHz 6502 Atari is surprisingly fast, when it comes to fill-rate. I'm devoting my current coding spree (feel free to check A8 coding section on AA) to porting jag's flatshader to 6502 and actual pixel filling (current data set is ~12,000 pixels, 74% of full screen, 160x96) takes up only 6,450 out of 53,000 cycles. Note, that you have about 24,000 cycles available per frame in that resolution.

 

Which is just 12% of the whole 3D pipeline. The remaining 88% goes towards:

- 3D transform

- clipping

- edge line computation

- scanline traversal

- proper edge handling via bitmasks

 

The funny thing about those 12% is that if we're willing to reserve 4 KB more for the unrolled filling code loops (not a problem, as there's 128 KB available on 130XE), it can be brought down to 3,300 cycles. At which point, the filling would take just 6%, but currently there's no point in optimizing something that takes just 12% of all cycles (the effort should go towards optimizing those 88%, obviously).

 

 

 

I'm wondering, if there ever was a jaguar game/demo/prototype that was running in a 4-color mode (like A800's gfx mode):

- 4 colors ( 2-bit depth) means 4 pixels fit into a byte, instead of just 1 pixel (8-bit depth)

- thus, same amount of bytes written (the jaguar bandwidth problem) equals to 4x more pixels

- 352x4 = 1,408 -> We could thus keep same framerate in 1408x240, as in 352x240, because nothing else would change in the pipeline (other than doing logical OR for edges, but that's fast on 6502, let alone GPU)

- So, my wipeout flatshader codepath would run at the same framerate in 1408x240, it just would have 4 colors (but dithering can be used to bring more shades)

 

However, at 1408 resolution, the dithering could actually bring some very interesting visuals - actually Blitter has a register that has the byte mask used for writing, so Blitter could basically do Hires dithering for free for us.

 

There was a very brief period of time on PC, that had flatshading but in HiRes (I recall few flight simulators) - I always loved it much more than the grainy/pixelated texturing attempts, as the flatshading has its specific smooth, clean charm (if used properly, of course)...

 

 

 

I'm wondering how many people would actually prefer to trade much faster framerate for much less colors but in higher resolution in a Checkered Flag. I understand that press would just laugh at something like that, especially at jaguar's time, but still firmly believe that even on a console, it should be up to the player to choose his visual / performance preference, not up to developer...

100% agree about the last part. That's one reason why I like PC gaming.