quote:Original post by valles
Is there any difference between an alpha blend as just a flat color without a texture that would somehow make it different?

[edited by - valles on June 4, 2003 1:40:22 AM]

1) Depends on your SetTextureStageState() calls, i.e. what YOU have asked the API/hardware to do.

2) In terms of actual blending, no there's no difference. Obviously having alpha in a texture gives you per-pixel control over alpha.

3) If you don't use any texture for colour AND alpha, then you save a texture lookup and potentially a texture unit so you might see performance benefits IF your bottleneck is in that area.

Are you seeing a particular problem or is this just a curiosity?

--
Simon O'Connor
Creative Asylum Ltd
www.creative-asylum.com

[edited by - S1CA on June 4, 2003 5:50:18 AM]

Actually I have noticed substantial increases in framerate using only diffuse-alphablending polygons over using texture-based alphablending. Try it yourself: Create a nice big quad taking up the screen and compare SELECTARG1:DIFFUSE vs MODULATE:TEXTURE & DIFFUSE.

~CGameProgrammer( );

quote:Original post by CGameProgrammer
Actually I have noticed substantial increases in framerate using only diffuse-alphablending polygons over using texture-based alphablending. Try it yourself: Create a nice big quad taking up the screen and compare SELECTARG1:DIFFUSE vs MODULATE:TEXTURE & DIFFUSE.

Although it is of course entirely hardware and particular bottleneck dependent. The first key thing you should always do is identify the bottleneck(s) in YOUR app on YOUR target hardware.

The difference that disabling texturing makes WILL vary depending on what''s going on with the rest of the pipeline. It''ll make very little difference for example if vertex throughput or frame buffer bandwidth is your bottleneck. It''ll make a substantial difference in a contrived (IMO) test application. A normal app comes somewhere inbetween.

In practical terms, I''d still disable texturing for a depth write pass for example. I wouldn''t disable it if caused bad batching.

quote:Original post by S1CA

quote:Original post by CGameProgrammer
Actually I have noticed substantial increases in framerate using only diffuse-alphablending polygons over using texture-based alphablending. Try it yourself: Create a nice big quad taking up the screen and compare SELECTARG1:DIFFUSE vs MODULATE:TEXTURE & DIFFUSE.

Although it is of course entirely hardware and particular bottleneck dependent. The first key thing you should always do is identify the bottleneck(s) in YOUR app on YOUR target hardware.

The difference that disabling texturing makes WILL vary depending on what''s going on with the rest of the pipeline. It''ll make very little difference for example if vertex throughput or frame buffer bandwidth is your bottleneck. It''ll make a substantial difference in a contrived (IMO) test application. A normal app comes somewhere inbetween.

In practical terms, I''d still disable texturing for a depth write pass for example. I wouldn''t disable it if caused bad batching.

Yes it is hardware-dependent, but every single game I''ve played had major slowdown when a texture-alpha-blended billboard was close to the viewer, regardless of whether it''s Half-Life, Quake 3, UT, GTA3, or my engine, so I wouldn''t say it only happens in "contrived" applications.

Specifically, in my engine going from diffuse to texture put the framerate from ~27 to ~19. I had about 20 polygons of varying size in front of me though, as it was a hacked example -- I took my fireball code and made the fireball hover in midair, and then I fired it and observed the framerate. I changed the blending from (srcalpha/invsrcalpha, modulate texture*diffuse) to (srcalpha/one, selectarg1 diffuse) and tried it again.

~CGameProgrammer( );

quote:Yes it is hardware-dependent, but every single game I''ve played had major slowdown when a texture-alpha-blended billboard was close to the viewer, regardless of whether it''s Half-Life, Quake 3, UT, GTA3, or my engine, so I wouldn''t say it only happens in "contrived" applications.

Out of interest, how did you determine that this was a result of those apps blending with their polygons with textures as opposed to simply being FILLRATE BOUND?

Screen sized, alpha blended quads will suck up fillrate and therefore kill framerate, entirely regardless of whether they have a texture applied or not. Indeed fillrate is one of the most common graphics bottlenecks on any platform.

quote:Specifically, in my engine going from diffuse to texture put the framerate from ~27 to ~19. I had about 20 polygons of varying size in front of me though, as it was a hacked example -- I took my fireball code and made the fireball hover in midair, and then I fired it and observed the framerate. I changed the blending from (srcalpha/invsrcalpha, modulate texture*diffuse) to (srcalpha/one, selectarg1 diffuse) and tried it again.

Yep, your app, your test hardware. I don''t actually think we''re disagreeing at all here - I''m just pointing out that although you''re likely to see "some" performance benefit, you won''t always see "significant" benefit from turning off textures. Particularly in an app which has a fully loaded frame (i.e. an average frame from a game) or a bottleneck in a different place.


BTW: your texture(s) wasn''t being minified (with respect to screen space area) anywhere without mipmapping being used was it?, or trilinear filtered?

The texture was a very simple 16x16 "glow" which was close enough to take up most of the screen, so it was definitely stretched, not shrunk. I know of the slowdown you''re talking about, though I can''t remember the reason for it.

~CGameProgrammer( );