Picture of Sega's 3Dfx-based 'BlackBelt' console

Not so sure about that. Was vf3 the only model 3 port to dreamcast? It had something like half the graphical quality of the model 3 version, and I'm not sure if any dreamcast games ever exceeded virtua fighter 3 arcade in graphics.(haven't had enough experience with vf3 arcade to decide....that harley davidson game was ugly though)

VF3tb was the first Model 3 conversion to DC, but certainly not the only one. basicly, it looks roughly half as good as the arcade because, a.) it was coded in about 6 months. b.) it was pre-first generation software, being coded on Katana Step 4 dev kit with around half the performance of the final PowerVR2DC silicon (i think) c.) it was coded by Genki, and not AM2.

other Model 3 conversions to DC:

Sega Rally 2
Virtua Striker 2 '99 (possibly the NAOMI version)
Sega Bass Fishing
Virtual On 2 (VOOT)
Fighting Vipers 2


the port of VOOT to Dreamcast, which looks 90-95% the same as the arcade, shows the Dreamcast was capable of handling Model 3 ports if enough time and effort was spent on it. I think Sega Bass Fishing looks roughly the same as the arcade also. VF3 and Sega Rally 2 were first or pre-first generation software that was very much rushed. Dreamcast is capable of surpassing Model 3 noticablly ,in some areas, when the right effort is put in. yes, there are areas where DC does not match Model 3 (the use of anti-aliasing, steady 60fps framerates with all effects on)
 
archie4oz said:
Was vf3 the only model 3 port to dreamcast? It had something like half the graphical quality of the model 3 version, and I'm not sure if any dreamcast games ever exceeded virtua fighter 3 arcade in graphics.

Wow, these are some seriously rose colored glasses! VF3tb was a total pile of crap as a port, and Soul Calibur was far more graphically impressive (and that was an up-port from the Model 12). The only real nice thing about the model 3 boards (preferably the later variants) was having a dedicated geometry engine... In any case the DC pretty much owns the Model 3...

BTW, what's the setup performance for a Voodoo2/3? I know the CLX setup performance is pretty spiffy (well in excess of what the SH4 can feed it)...

I never had any experience with vf3tb on dreamcast, all I know is it didn't look as good as vf3 in the arcades.

What's setup performance mean? I'm not familiar with the term and couldn't find any information on it. If you mean the polygon rate, I've heard clx could do around 5-8, and the voodoo3 could do 6 with the 2000, and 8 with the 3500.

BTW, it may not be quite fair to compare model 3 with all effects on to the dc, sincec wouldn't the dc have more raw power if model 3 gets effects for free? And I didn't know voot was a model 3 port, I thought more like model 2....I like the game, but it's not very good looking at all. Simple textures and effects, and polygon amount isn't that high. Also, 2 player goes into ultra small screen mode I think.(may have had an option to stretch out the image though)
 
I think he's referring to triangle setup performance. something that Voodoo2/Banshee/Voodoo3 and PowerVR2 did, that Voodoo1 and PowerVR PCX1/PCX2 did not do (3Dfx said Voodoo1 did 2/3 of the triangle setup)


about VOOT, it was indeed a Model 3 game. Model 3 Step 2 actually. and you could link 2 DCs together so each player has a full screen just like the arcade. it's probably the most impressive Model 3 to DC conversion/port. And I explained why VF3tb didn't look as good as the arcade. still DC VF3 was closer to the arcade Model 3 VF3 than VF2 on Saturn compared to the Model 2 VF2. in otherwords, DC Model 3 conversions were closer to the arcade than Saturn Model 2 conversions.
 
Fox5 said:
I was referring to the actual voodoo3 chip was finished after pvr2dc.

Yes, I know that, but the basic design of the chip is still going back to the very first voodoo. Just like the geforce 4 have similarities stemming way back to the tnt.

And how old was the voodoo graphics chipset?

As it was released in 96 I believe it had to have been completely finished & debugged by then.

That's not true.
It was at the time.

No, V3 never had 22-bit color, it was a 16-bit device through and through in 3D mode.

Or can you tell the difference between halflife running in 16bit on a voodoo 3 and halflife running in 32 bit on a tnt2?

Was too long since I played anything on a V3, I couldn't say with any certainty, but that still doesn't mean the V3 have 22-bit color, because it does not.

Not in official 3dfx drivers as far as I know, but 3rd party drivers did add the options.

Look... The chip itself can't do proper trilinear, much less aniso, so it doesn't matter what checkboxes the driver presents.

With some 3rd party drivers I was able to force it in all games. It sometimes worked.

Like I said, it was a bitch and nobody liked it. My Rage128 can also do edge AA, but software support prevents it from working properly. It's not a "real" kind of AA.

Wasn't in the drivers. I'm fairly certain it was something 3dfx released around the time the tnt was coming out

You must be thinking of bumpmapping instead. 3dfx wanted people to think their voodoos could do it, but what they offered wasn't proper dot3 bm but a multitexturing trick instead (emboss). The V2 (or 3 for that matter) never offered SSAA.

WHAT pixel shader-like effect?
The shininess on some objects in conker's bad fur day(such as the logo at the start)

That's environment mapping. Pretty much ANY 3D hardware can do that, all that's needed for that effect is a texture that wraps seamlessly in all directions and then changing the texture coordinates on a frame-by-frame basis.

Also various other effects.

Well, there's still nothing magic extra-special the voodoo chips alone can do through glide that no other chip can do except buggily through DX9... That's just prepostrous. Glide is nothing but a slimmed-down OpenGL API, and the voodoo series is a very simple and quite conventional rasterizer without any special tricks whatsoever. Even the TNT, which is a POS by today's standard, is considerably more feature-rich.

Looks like I was wrong about shadow buffers, it's hardware frame buffer used for shadows.

"Hardware frame buffer." :LOL: Look, by nature, framebuffers are hardware (ie: typically: memory chips), and what games is it you think use "hardware frame buffers" for shadows? Typically, shadows are made either with either a stencil buffer (which only vsa100 supports) or with shadow buffers, which no voodoo chip supports.

Just looked up mym old 3dmark scores, 195.9 megatexels fill rate

TEXEL, yeah. Not pixel...

32 bit internal color too

Internal, wtf? It uses internally what it uses externally, so that would be 16-bit.

(actually, the story I heard didn't mention sega at all, just that 3dfx had planned a lot more for the voodoo3 and cut it for cost reasons, but it's a nice story for a 3dfx zealot, right?)

:LOL: Yeah, haha. One's gotta have faith! :LOL: Anyway, V3 wasn't really meant to be in the first place, it was a product of bad management.
 
[wild speculation mode]

If 3Dfx had Rampage ready at the time it was supposed to be ready, sometime in 1999, I wonder if Sega would've changed their minds. surely Rampage would've been superior to any PowerVR2 solution with the possible exception of NAOMI 2. Rampage was reportedly VERY good. especially with the on-board geometry processing from the SAGE chip. Imagine a 1 SAGE, 2 Rampage rasterizer configuration. probably would've allowed BlackBelt to compete better with PS2 on the technical front. BlackBelt gets released in Japan and U.S. in 2000, instead of 1998/1999. 10-20 mpps with features. would be comparable to Xbox and GCN today. 1 SAGE geometry engine and 2 Rampage rasterizers may even have been comparable, perhaps even better than, NAOMI 2's ELAN geometry engine and 2 PowerVR2DC rasterizers. Although, there is little doubt that a 1 SAGE + 2x Rampage solution would've been too costly for a console. of and of course, even IF Rampage was on time, in 1999, that still would've been probably too late for Sega's timeline since they started making the real BlackBelt and Dural probably in 1996.

[/wild speculation mode off]
 
Megadrive1988 said:
[wild speculation mode]

If 3Dfx had Rampage ready at the time it was supposed to be ready, sometime in 1999, I wonder if Sega would've changed their minds. surely Rampage would've been superior to any PowerVR2 solution with the possible exception of NAOMI 2. Rampage was reportedly VERY good. especially with the on-board geometry processing from the SAGE chip. Imagine a 1 SAGE, 2 Rampage rasterizer configuration. probably would've allowed BlackBelt to compete better with PS2 on the technical front. BlackBelt gets released in Japan and U.S. in 2000, instead of 1998/1999. 10-20 mpps with features. would be comparable to Xbox and GCN today. 1 SAGE geometry engine and 2 Rampage rasterizers may even have been comparable, perhaps even better than, NAOMI 2's ELAN geometry engine and 2 PowerVR2DC rasterizers. Although, there is little doubt that a 1 SAGE + 2x Rampage solution would've been too costly for a console.

[/wild speculation mode off]

I doubt they would have gone for this. It would have eliminated much of Sega's headstart over the PS2. Even with superior hardware they would have not been able to combat sony's hype, consumers still didn't trust Sega from their previous misadventures (Mega CD, 32x, to an extent Saturn). Also, sega were not very strong financially and a 2 rampage 1 sage combo would have been expensive if sega were trying to minimise losses. Wasn't that the suggested arrangement for the high end PC card?
 
If v3 was a product of bad management, what was voodoo5?

http://www.anandtech.com/showdoc.html?i=923&p=9
" many users are upset with 3dfx for only supporting 16-bit rendering. 3dfx's response has been that their internal calculations are processed with 24-bit accuracy and then dithered to 16-bit, providing something similar to a hypothetical 22-bit color output, however the market is generally not buying that response at all.
"
Thought it was 32 bit internal, guess it was just 24 bit internal. Matrox did the same thing, and so do all powervr chips, iirc correctly, except they also provided the option for external.

"Just looked up mym old 3dmark scores, 195.9 megatexels fill rate


TEXEL, yeah. Not pixel... "

When you're doing single texturing, isn't it the same as the pixel rate? I mean, isn't that the purpose of them having both a single texturing and multitexturing test, to see how high its pixel rate is, and to see how high its multitexturing test can be when provided with as many layers as the hardware supports? Besides, those neon250 cards were agp cards, I had a pci voodoo, at a bit of a disadvantage eh?(half the potential bus speed the voodoo card could support I think, but the neon250 used agp4x)

BTW, how come for both psx and n64, the glide plugins are generally more compatible, full featured, and faster? Just happened that the plugin authors are more fluent in glide?

Voodoo cards also support 8bit palletized textures, which I remember was a big deal to me and my friends back in the day. Not sure how many games actually used that, but it sucked for them to get their new geforce and have to play their game in software rendering.

Also, from the banshee feature list....
Per-pixel MIP mapping and alpha blending
Most accurate LOD calculations
Internal rendering calculations @ 32bpp
Programmable expotential and fog-table
Floating point Z-buffer to eminate z-aliasing
Dynamic environment mapping
Bumpmapping
Full speed Trilinear Mip mapping quality
Full scene "order independent" edge anti-aliasing
3D rendering up to 2k by 2k surface

So internal 32 bit, bumpmapping, trilinear, and I doubt they reduced the voodoo3's capabilities.

16 Bit Floating Point Z-buffer
Games are designed for 64k Z-values
Content Developers: 24/32-bit Z-values
32-bit Z will run at half the speed of a 16-bit Z
32-bit Z requires double the memory storage
Games require high frame rates, not long depth range
32-bit Z buffer is primarily useful for CAD applications
16-bit floating point Z is more precise than some 24-bit fixed point Z buffers
Banshee's 16-bit W-buffer implimentation has ~22-bits of integer accuracy

So does that mean it can still run 32bit games, but at half speed and twice memory storage? Also, it seems they use the 16bit floating point capabilities to emulate 22-24bit integer accuracy?

"For one, the Voodoo 5, like a number of Voodoo products before it, includes a post filter that modifies images after they're rendered, but before they're output to the display. You may have heard 3dfx advocates talking about "22-bit color" output from the Voodoo 3 a while back. In 16-bit color mode, the Voodoo post filter averages pixel colors together. This filter smoothes things out, but sometimes causes images to look over-filtered, smeary, or dirty; or it introduces line-by-line horizontal banding. In its "high quality" mode, though, the 3dfx post filter arguably improves 16-bit image quality. "

So 3dfx's higher quality 16bit does exist.

"Why not? Probably because the VSA-100 chip won't do trilinear filtering and single-pass multitexturing at the same time. Because single-pass multitexturing improves performance, I suspect 3dfx decided to cheat things a little by not enabling trilinear filtering in their OpenGL drivers. Doing so would hurt benchmark performance versus some competing cards, where adding trilinear is "free" thanks to their rendering pipeline configurations. "

So the choice is between single pass trilinear or single pass multi texturing...doesn't say it can't do multitexturing and trilinear though.
Also found one interesting thing while looking around, the radeon 8500 couldn't do anisotropic and trilinear at the same time. Judging by the rest of the voodoo's comprimises(well, voodoo3-5, voodoo1 and 2, believe it or not, did lack features the voodoo 3 had), it would probably be done in a similar way. Couldn't find any articles on the voodoo having anisotropic though.(though I did find one person complaining that they can't enable anisotropic on their voodoo3 because the performance hit is too great) Oh wait, n/m, look what I found....

http://www.guru3d.com/voodoo3.htm
The Specs

Dual 32-bit texture rendering architecture
Single pass multi-texturing
Full hardware setup of triangle parameters
Support for multi-triangle strips and fans
Single Pass, Single-cycle bump mapping
Single Pass, Single-cycle tri-linnear mip-mapping
Alpha Blending on source and destination pixels
Sub-pixel and sub texel correction to 0.4x0.4 resolution
Per-pixel atmospheric fog with programmable fog zones
Full-scene polygon-based edge anti-aliasing
Floating point Z buffer
True per-pixel, LOD MIP mapping with biasing and clamping
Texture composting for multi-texture special effects
8-tap anisotropic filtering
Support for 14 texture map formats
8-bit palletized textures with bilinear filtering
Texture compression through narrow-channel (NCC) YAB format

It even have my beloved 8-bit palletized texture support! Oh, 8-tap aniso too.

Further down in the page, it says the voodoo3 supports a 4:1 compression ratio....using palletized textures and NCC. I'm guessing there's a reason this couldn't be used in every game like the dc's graphics chip's texture compression?

"Q: What is the highest color depth available for the 3D output? Is it still 16-bit color or has it been updated to 32-bit color? A: The Voodoo3 uses internal rendering calculations @ 32bpp with a proprietary compression algorithm to store results at 16bpp. This gives us the best of both worlds: high color depth and low memory bandwidth! "

"Q. Does Voodoo3 support anisotropic filtering?

A. When we launched at Comdex ‘98, this was primarily a software feature which we decided not to productize after having reviewed the resulting image quality that it provided.

Q. Does Voodoo3 support full scene anti-aliasing?

A. This is another primarily software feature that is under review.
"

Not sure what these mean, but the fsaa one goes along with what I remember from the super sampling program, it used the cpu to perform the supersampling.

"3Dfx Voodoo is one of the most successfull trademarks of the computer hardware industry, beaten only by the Apple Macintosh and IBM PC brand-names. Is the Voodoo 3 a product worthy it's name? We say it is. "

I can only laugh at this.... comparing the voodoo to two other failures, why not windows if they had such a high opinion of it? Oh well, I used to compare 3dfx to sega, and look how that turned out, sega nearly died too.
 
Megadrive1988 said:
[wild speculation mode]

If 3Dfx had Rampage ready at the time it was supposed to be ready, sometime in 1999, I wonder if Sega would've changed their minds. surely Rampage would've been superior to any PowerVR2 solution with the possible exception of NAOMI 2. Rampage was reportedly VERY good. especially with the on-board geometry processing from the SAGE chip. Imagine a 1 SAGE, 2 Rampage rasterizer configuration. probably would've allowed BlackBelt to compete better with PS2 on the technical front. BlackBelt gets released in Japan and U.S. in 2000, instead of 1998/1999. 10-20 mpps with features. would be comparable to Xbox and GCN today. 1 SAGE geometry engine and 2 Rampage rasterizers may even have been comparable, perhaps even better than, NAOMI 2's ELAN geometry engine and 2 PowerVR2DC rasterizers. Although, there is little doubt that a 1 SAGE + 2x Rampage solution would've been too costly for a console. of and of course, even IF Rampage was on time, in 1999, that still would've been probably too late for Sega's timeline since they started making the real BlackBelt and Dural probably in 1996.

[/wild speculation mode off]

You're assuming it had the same power it did when it almost released in 2001. Even then, a single chip rampage(which was the low end configuration, and 2 chips was either medium or high end) would be outperformed by gamecube(mostly since gamecube gets a lot of effects for free), but a dual chip rampage would have even outperformed an xbox with twice the memory bandwidth. Lets say a single rampage would have cost about as much as a voodoo3 sli(if such a thing existed), sega didn't go for a voodoo3 sli, so I'd think that was more than they were willing to pay.(though it would have offered incredible performance, which the sh-4 in the system probably couldn't utilize)
 
Fox5 said:
BTW, how come for both psx and n64, the glide plugins are generally more compatible, full featured, and faster? Just happened that the plugin authors are more fluent in glide?

Perhaps because there is only a rather limited pool of hardware using glide? It cuts out a lot of variables if you are only writing for one manufacturers cards (most of which are ultimately based on the same design), rather than every card under the sun. Besides is this even true? What exactly is missing from d3d and ogl renderers for epsxe for example?
 
Silanda said:
Fox5 said:
BTW, how come for both psx and n64, the glide plugins are generally more compatible, full featured, and faster? Just happened that the plugin authors are more fluent in glide?

Perhaps because there is only a rather limited pool of hardware using glide? It cuts out a lot of variables if you are only writing for one manufacturers cards (most of which are ultimately based on the same design), rather than every card under the sun. Besides is this even true? What exactly is missing from d3d and ogl renderers for epsxe for example?

Don't think there's any features missing for psx, but the glide rendered are a lot faster. I don't know why either, there are things I could run full featured with glide on my voodoo3 that were unplayable with a d3d or opengl plugin on my geforce 3(though back then the drivers for the card really sucked, for whatever reason performance like doubled with later drivers), and still aren't as fast(though sometimes it's only when certain effects are used) on my radeon 9700 pro. It's not just that the glide plugins are 10 or 20% faster, they're faster than more powerful hardware using another plugin by quite a noticable difference. Though I did try a glide wrapper once on my radeon 9700 pro, not sure if it was faster than my voodoo3 with native glide(since it was running at a full 60 fps, which was good enough for me), but it was faster than d3d or opengl plugins, and tended to support more features, but not always, often visual effects would have errors or just not show up at all....and sometimes they were even effects that could be done with the other plugins.(perhaps voodoo cards had a faster way of doing the effects that newer cards don't support, and thus the d3d and ogl plugins are slower because they have to do more work to emulate the same effect? well, that could very well be true, since the d3d and ogl plugins I was using required ps2.0 capable hardware for those effects, and I haven't found any pre dx9 plugins that could do those effects)

BTW, one reason I claim a 3dfx powered console would have been more powerful than dreamcast...well it would have come out a year later. I think of dreamcast as coming out at the time it did in america, late 1999 when the geforce was just about to come out(and 3dfx could have produced a more powerful card at that time, many voodoo 3 cards would overclock over 200 mhz, and if 3dfx had just shrunk the die process the voodoo3 was on and focused getting the mhz up instead of thinking they could get voodoo5 out by christmas, they could have had a card about geforce power, but minus t and l), but the dreamcast came out in 1998 in Japan. I think of a 3dfx powered console as launching in in 9/9/99 worldwide, and it's rare that any company in the computer business can maintain a whole year's advantage on another company, especially a leader in the field at the time. At best, the chip in the dreamcast would be approximately equal to a v3.

However, I few things I found online:
The Blackbelt console was focused on ease of programming, and not power.(I guess sort of like gamecube?) It also allowed for quick conversions from PC to the console.(and not in the way windows ce did for dreamcast) Guess like an anti saturn?

Katana was more powerful most of the time than the prototype BlackBelts, but much more difficult and complicated to program for.

The number 1 reason BlackBelt was dropped was because it was more expensive. The number 2 is that it wasn't even close to the PS2 or GameCube in proposed power. No mention of how the final BlackBelt specs compared to Katana, but if the BlackBelt was more expensive or launched a year later than Dreamcast initially did, perhaps sega felt it was too much of a risk when they were already economically struggling, Katana's earlier release/lower price would matter more than any extra power, especially when it was far more powerful than anything else available at the time.

Katana gained an equally easy to use programming environment to the BlackBelt through the use of Windows CE. However, didn't Windows CE on dreamcast suck? Unless they managed to do quake 3 on it, then I don't recall any impressive games from it, even worms world party had framerate problems and they claimed they were unable to do the flame effects on it or something.(maybe it was just for balance reasons, or too hard to have while using a controller) Oh, and another reason why those comparisions between pcs with 500mhz processors running quake 3 and quake 3 on dreamcast aren't so invalid, dreamcast doesn't have to run a bloated OS, unless quake 3 on it was a windows ce port.
 
I've programmed Voodoo 1 and 2 at the glide level and I've programmed Holly (PVR2DC) and I also know Voodoo3 at the Direct3D level. So I probably can comment better than almost anybody here.

More importantly I've ran the same game on Direct3D on both a Voodoo3 and Dreamcast. Dreamcast wins hands down.

Why?
True 32 bit rendering, DC supports a accumulation buffer that enabled multi-pass effects at full bit resolution.
VQ compression, better quality and smaller than palettes
Modifier volumes, shadow were so easy
Clipping, the Dreamcast had 4 plane geometric clipping
High precision z-buffer without wasting valuable VRAM
Sort-indepedent transparency

That feature alone puts Dreamcast graphics chip up there with the all time greats.

Any idea that Holly (via Kamui or Direct3D) was harder to program than glide is rubbish, Kamui and glide were actually very similar, except under Kamui most of the calls were actual C Macros and placed data directly into the command stream.

The very things that made PowerVR a pain on the PC were what made it good on a console.

SEGA made the right choice with graphics chip for the Dreamcast, there was NO better out there at the time.
 
I agree with Deano on this one.

I didn't do much more than some initial engine work on DC, but considering the time frame it was a very impressive piece of kit, certainly more than a match for the suggested 3DFX part (which wasn't even a Voodoo 3).

There were actually at least 3 different libraries available for dreamcast , Win CE, Kamui which was a well written low level library written by Sega (although they later removed what I felt to be the most useful rendering mode from it) and something called Darkness, which was at the level of here are the register addresses and some really incomplete documentation go for it.

At the Kamui level writing DC code was comparable to writing Glide code for 3dfx on a PC.
 
I've never heard the name Holly for PowerVR2DC.

Really?

Anyways it's the name of the whole package/chip not just the PVR core, TA, and all the various Bus IFs...


Dragon SDK, yech...

There were actually at least 3 different libraries available for dreamcast , Win CE, Kamui which was a well written low level library written by Sega (although they later removed what I felt to be the most useful rendering mode from it) and something called Darkness, which was at the level of here are the register addresses and some really incomplete documentation go for it.

Are you referring to Kamui or Kamui 2 (removed rendering mode)? I'd also toss in Ninja if you needed a more high level interface or were coming from a PC backround (and didn't want to go the Dragon route).
 
Really?

Anyways it's the name of the whole package/chip not just the PVR core, TA, and all the various Bus IFs...

neat. well maybe I've simply forgotten. but I didn't remember the name Holly when i saw it mentioned here.
 
archie4oz said:
I've never heard the name Holly for PowerVR2DC.

Really?

Anyways it's the name of the whole package/chip not just the PVR core, TA, and all the various Bus IFs...


Dragon SDK, yech...

There were actually at least 3 different libraries available for dreamcast , Win CE, Kamui which was a well written low level library written by Sega (although they later removed what I felt to be the most useful rendering mode from it) and something called Darkness, which was at the level of here are the register addresses and some really incomplete documentation go for it.

Are you referring to Kamui or Kamui 2 (removed rendering mode)? I'd also toss in Ninja if you needed a more high level interface or were coming from a PC backround (and didn't want to go the Dragon route).

Not sure when it got removed we did DC development very early and very late in the platforms lifetime.

They remooved the model that allowed direct submit of tri's to the TA. In favor of intermediate memory buffers, with DMA submission to the chip.

The problem I had with them removing it was that Dreamcasts cache didn't support read under write, so having to write back to memory meant that you couldn't effectively prefetch vertex data, which vastly increased transform times for simple verts. This would have been avoidable if you could have DMA'd to the scratch pad memory, but that didn't work either.

When I complained about the removal of the rendering mode, Sega provided me with a copy of Darkness which was basically a bunch of register equates, some bad sample code and some docs which noted a couple of hardware bugs that it was necessary to work around. I used it to do some initial graphics work on a product that was canned when sega pulled out of DC development.

I like playing around at the register level, I like to understand how something is working :), that and I'm a masachist when it comes to hardware. One the other hand I also like not having to if I'm just trying to test something.
 
With all the talk about PVR, how about "what if MS chose a variant of PVR, instead of Geforce3 for the Xbox"?
 
ERP said:
I like playing around at the register level, I like to understand how something is working :), that and I'm a masachist when it comes to hardware. One the other hand I also like not having to if I'm just trying to test something.

Hehe, that's cool. :) I guess this makes you unlike Carmack, who is a high-level algorithm whore instead. :D He'll gladly rewrite half his engine if it gets better in the process, but he'll only consider doing it in C++. :LOL:
 
DeanoC said:
Clipping, the Dreamcast had 4 plane geometric clipping
It couldn't actually do that* but it could do post projection XY screen region clipping and that, along with "near**" plane clipping (which was the SH4's responsibility) is probably all you typically need.

*though I suppose you could use modifier volumes to do some geometry clipping by making the "outside" region invisible - actually, that'd be quite powerful although it would burn fill rate.

**since depth vals were floating point, I guess "near" could be very close.
 
This thread is extremely informative and interesting. Why not have similar threads about PS2/GC/XB (now that this gen is near its end :D ). Megadrive what do you think?
 
Back
Top