Direct3D requires Alpha transparency for text.... Any workaround
by Nathan Gopen · in Torque Game Engine · 10/02/2002 (8:17 am) · 5 replies
One of the few gripes I have about the design of the torque engine is the use of alpha transparency for text overlays when using Direct3D. This has caused problems on some of my machines (generally ATI Rage Pro based video hardware that lacks the Alpha transparency support), that I had tried running Tribes 2 on, as well as my laptop which I am using to do game development. The actual terrains and models render fine, but the text just looks like garbled black blobs.
Does anyone have an idea of where in the code the text is getting rendered, and how I might change the code in my version to use a different technique?
Any pointers or other thoughts would be appreciated.
Does anyone have an idea of where in the code the text is getting rendered, and how I might change the code in my version to use a different technique?
Any pointers or other thoughts would be appreciated.
#2
But otherwise, should work. You can try changing the text/font generator to not fill in pixels with alpha, or you can poke around with the rendering code to only use one alpha mode.
Come to think of it, I would imagine if the alpha wasn't working that you'd still get characters, just with black blocks around them -- the text should still be colored properly. If it was black text, then that wouldn't show up, of course... ;)
d
10/02/2002 (7:57 pm)
to the best of my recollection, the Rage Pro does alpha just fine. however, it might have problems combining multiple alphas (like the text has alpha AND the text tris are using vertex alpha too).But otherwise, should work. You can try changing the text/font generator to not fill in pixels with alpha, or you can poke around with the rendering code to only use one alpha mode.
Come to think of it, I would imagine if the alpha wasn't working that you'd still get characters, just with black blocks around them -- the text should still be colored properly. If it was black text, then that wouldn't show up, of course... ;)
d
#3
This occurs with my Compaq Armada laptop, with an ATI mobility RAGE AGP, 8 Meg video. Similar problems occured with Tribes 2 on my desktop with an 8 Meg ATI all-in-wonder Pro (The original All-in-wonder line, basically a RAGE PRO chipset). I now have a 32 meg ATI Radeom which does not have that problem. I don't think it's related to the amount of memory, though, (or at least it shouldn't be), as all the texture-mapped terrain and objects seem to work fine.
Any advise would be greatly appreciated. I'd like to do a lot of my game development on my laptop, even if it's not the optimal target for playing the end product... and I need some sort of legible text, even if it's not the prettiest!
(By the way, OpenGL doesn't work at all. It display the text fine in the startup menu, but when it loads the level, it crashes).
10/05/2002 (8:35 pm)
To clarify exactly what I mean, I uploaded a screen shot showing the garbled text. It is here.....This occurs with my Compaq Armada laptop, with an ATI mobility RAGE AGP, 8 Meg video. Similar problems occured with Tribes 2 on my desktop with an 8 Meg ATI all-in-wonder Pro (The original All-in-wonder line, basically a RAGE PRO chipset). I now have a 32 meg ATI Radeom which does not have that problem. I don't think it's related to the amount of memory, though, (or at least it shouldn't be), as all the texture-mapped terrain and objects seem to work fine.
Any advise would be greatly appreciated. I'd like to do a lot of my game development on my laptop, even if it's not the optimal target for playing the end product... and I need some sort of legible text, even if it's not the prettiest!
(By the way, OpenGL doesn't work at all. It display the text fine in the startup menu, but when it loads the level, it crashes).
#4
The instruction at "0x690c0709" referenced memory at "0xcc486c86". The memory could not be "read".
When I go into the debugger, it says, "Unhandled exception at 0x690c0709 in torqueDemo_DEBUG.exe: 0xC0000005: Access violation reading location 0xcc486c86."
Continuing to debug, the crash occured in this function in terrrender.cc:
void TerrainRender::renderXFCache()
{
U32 count = 0;
while (count < mXFIndexCount)
{
U32 mode = mXFIndexBuffer[count];
U32 vertexCount = mXFIndexBuffer[count + 1];
glDrawElements(mode, vertexCount, GL_UNSIGNED_SHORT, mXFIndexBuffer + count + 2);
count += vertexCount + 2;
}
}
It occurs at the line "glDrawElements". It is the first time through the loop (count = 0). mXFIndexCount is 33, mode = 6, vertexCount = 6, mXFIndexBuffer is 0x1198848.
Any insight into this may be helpful as well. If I can get OpenGL to work, I am willing to go that route.
(I know, I know.... 8 Meg video is not in the System Requirements! But if it can work in that constraint, even if not optimally, it would be better for all of us....)
10/05/2002 (8:51 pm)
One note about the last post.... the "crash" that occurs with OpenGL is:The instruction at "0x690c0709" referenced memory at "0xcc486c86". The memory could not be "read".
When I go into the debugger, it says, "Unhandled exception at 0x690c0709 in torqueDemo_DEBUG.exe: 0xC0000005: Access violation reading location 0xcc486c86."
Continuing to debug, the crash occured in this function in terrrender.cc:
void TerrainRender::renderXFCache()
{
U32 count = 0;
while (count < mXFIndexCount)
{
U32 mode = mXFIndexBuffer[count];
U32 vertexCount = mXFIndexBuffer[count + 1];
glDrawElements(mode, vertexCount, GL_UNSIGNED_SHORT, mXFIndexBuffer + count + 2);
count += vertexCount + 2;
}
}
It occurs at the line "glDrawElements". It is the first time through the loop (count = 0). mXFIndexCount is 33, mode = 6, vertexCount = 6, mXFIndexBuffer is 0x1198848.
Any insight into this may be helpful as well. If I can get OpenGL to work, I am willing to go that route.
(I know, I know.... 8 Meg video is not in the System Requirements! But if it can work in that constraint, even if not optimally, it would be better for all of us....)
#5
I am going to look into fixing the problem.
-Dave
12/23/2002 (10:31 am)
For what its worth... I have the same problems on my ThinkPad with an S3 Graphics SavageMX graphics card. I am going to look into fixing the problem.
-Dave
Associate Melv May
To make this work without alpha you will also have to make changes to the \engine\dgl\gFont.cc/.h class.
I haven't gone through these classes in detail so I can't provide more information without further investigation but this is definately where you'd want to start.
Also note that this would change it for both D3D and OpenGL and not just D3D.
- Melv.