No, last I checked they used OpenGL, as SSN said.FoxBlitzz said:
OpenGL problem
- Thread starter phazon sonic
- Start date
- Status
SSNTails
What part of 'RETIRED' don't you understand?
FoxBlitzz said:
It's a fault of the programmer. To do a fade in hardware, all you need to do is have two images, and adjust the alpha values of one of the images until the alpha value is completely transparent. You can do this in both Direct3D and OpenGL. It's a really elementary operation, and if a 3D package doesn't support such a simple case of alpha blending, then it doesn't deserve to exist.
I'd venture a guess that the Mac version of Bugdom uses OpenGL (through QuickDraw on OS 8/9), since that's the only way to achieve 3D graphics on the Mac. (If I remember right, the whole Mac OSX interface is runs through it).
If ( cardIsCompatibleWith(DirectX) ) then cardIsCompatibleWithOpenGL = Most likely;
John Carmack won't write Direct3D. Ever.
By the way, Logan and Alam have indeed made a Direct3D plugin for SRB2, and guess what? *drumroll*..... it looks just like the OpenGL one.
OpenGL and Direct3D filter down to the same commands that get fed to your video card. Load a texture. Place vertices at 303,3285,284; 393,523,621; 482,621,7274. Transform, project, draw to the buffer, copy buffer to screen. Repeat.
*coughsegasaturncoughmeshtransparenciescough*SSNTails said:
Sorry 'bout that, nasty cough I have of late.
Anyway, if transparencies are so easy to do... why do we wind up with what seems to be semi-transparent FOFs that show black behind them instead of the level? You know, the sides that don't work. Even if my description's far off, you know what it looks like.
SSNTails
What part of 'RETIRED' don't you understand?
Shadow Hog said:
That's alpha blending in 3D. Screen fades are 2D. 3D alpha blending is a whole other bag of mess that you even see a lot of console/commercial games cheat on rendering.
And yes, 3D alpha blending is ESPECIALLY coder-dependent. You can't render translucent polygons in the depth buffer. You have to depth sort them yourself against all the other polygons in your scene (if you want to do it right), which, depending on the position of what you're drawing, creates some really insane collision math. That's why it's such a pain and why SRB2's sucks balls.
SRB2's software mode gets away from having to do such fancy maths because it's not a 'real' 3D renderer.
SSNTails
What part of 'RETIRED' don't you understand?
Sik said:A problem is that you must render opaque polygons BEFORE translucent polygons, otherwise anything before them isn't drawn at all. But, as far as I know, this is a bug of DirectX, not OpenGL.
It's not a bug.. it's how the depth buffer works. Whether you're using DirectX, OpenGL, Glide, or some other custom Xbox or Gamecube API, you have to sort all of the translucent polygons yourself.
*) Draw all opaque things
*) Set depth buffer to read-only
*) Sort translucent polygons (you don't have to sort them if you only use 50% alpha, but for all other values you MUST sort for it to look right)
*) Draw all alpha things
- Status