Hud blitting

Started by
5 comments, last by Rainmaker 19 years, 6 months ago
I am working on a 3d project which uses DX9, and the team leader wants me to do the GUI/HUD rendering via blitting to the back-buffer (instead of in ortho mode). He thinks that should be at least just as fast as ortho mode. Is that true? One of the main issues that I can't seem to figure out is alpha testing or blending. Are either of those possible with blitting? How do most of you do HUDs and GUIs? Thanks.
Advertisement
Hi, I'm no expert but yeah I'm doing my hud with rhw quads, whereas everything else is in ortho or normal. Quads stay at the same point on the screen don't they, and you only have to use screen coordinates to position them?

edit
I have had the problem though of some of my world geometry coming through the quads, - don't know what to do about that, lol.
Quote:Original post by Rainmaker
He thinks that should be at least just as fast as ortho mode. Is that true?

Why trust random strangers when you can (and should) knock up a quick test and actually compare the results yourself.

And now to contradict myself - rendering a HUD with ortho quads will almost certainly be faster and more flexible than blitting to the backbuffer.
Quote:
I have had the problem though of some of my world geometry coming through the quads, - don't know what to do about that, lol.

I'm no expert on this, but if you turned off z write and drew it last, would this solve the problem?
thanks, I thought I was just going to have to live with it.
You mean, Z checking, not Z writing. ie,
device->SetRenderState( D3DRS_ZFUNC, D3DCMP_ALWAYS );
just before drawing your HUD.
...Or use untrasformed tri-strips, and make sure the w value is 1.0f. What I do is place all my HUD elements with coords in 1x1 space, then scale to match the current resolution.

Blitting to the back buffer is definitely slower than drawing any kind of geometry, because you're actually holding up the GPU with a Lock while you're copying stuff from system memory into graphics memory. The only advantage you gain from this method is getting to use aribitrary resolutions (as opposed to power of 2) that match the resolution of the display. But that can be as much of a pain as a blessing, because it means you have to create different versions of the graphics for every possible screen resolution, to avoid getting tiny, unreadable text, like the original WinQuake had. Not to mention, not all adapters support back buffer locking. Namely, I've heard complaints on the ATI 8500, I think it was. I'm not even sure what CAP represents this either.
VideoWorks Softwarehttp://www.3dpoolpro.com
Thanks. I had a feeling that was the case, but I had to ask first. Good thing the original code is still around.

Also, the DX font interface runs like molasses. Is there a way to bitmap it or something with a function call to get a speed boost? I suspect it would be wiser to write my own...

This topic is closed to new replies.

Advertisement