Nasty bitmap font bug : won't draw from backbuffer
Blitz3D Forums/Blitz3D Programming/Nasty bitmap font bug : won't draw from backbuffer
| ||
| I have a windowed Blitz program for setting up my software's options. I'm using Cyberseth's BMPFont lib (http://www.blitzcoder.com/cgi-bin/showcase/showcase_showentry.pl?id=cyberseth05162003013142&comments=no) to render text in a textbox. I clear the backbuffer, write the text to the backbuffer, then copy the backbuffer to a texture on a quad for the textbox with a call to this function... It works fine, until all of a sudden I've received a report and picture that shows it isn't working properly. Instead of writing text to the backbuffer and copying that to the textbox with lovely writing, the textbox shows the backbuffer with the UI drawn on. Either it's copying the backbuffer after the UI has been drawn, or is not clearing the biffer and writing the text, or it's copying the front buffer instead of the backbuffer. I need some info from the client on their system which will have to wait until tomorrow, but I'm wondering if anyone has any ideas or similar experience? Could some chipsets return the frontbuffer instead of the backbuffer in windowed mode, for example? I can see I'm not directly addressing the backbuffer prior to CLS and text-drawing operations, but I understand the buffer is still the backbuffer as that's how it works on the other computers tested. |
| ||
| Whats the specs of the machine in question? |
| ||
| Just got them. Pentium 4 3.6GHz CPU 1Gb Ram Windows XP Pro SP2 ATI Fire GL v3100 128mb GPU The fire GL is 9600 based I think. I guess that's like the nVidia Quadro's in being a professional card? Yes, looking at ATi's website it's a workstation GPU. Not much chance of me being able to test on that particular card! |
| ||
| hmmm, I see no reason why the code shouldnt work.... Other than perhaps putting a setbuffer(backbuffer()) in the function for safe keeping.. You could add a debug type command (like if a commandline switch is used) the first time this function is called, it saves the buffer (texture buffer) out to an image file to see what is being captured.. Wish I had a better answer for you, but the only addition I can think of is the setbuffer in this function to ensure your doing all you can. Since you dont have the ability to test that card, its hard to say where the problem lys. Perhaps putting that card on a knowns issues and non-compadible list for your app is your best option. |
| ||
| From what I hear, the FireGL series has low game compatibility. These workstation GPUs tend to have drivers optimised for OpenGL. I've tried to contact ATi but they make you jump through a zillion hoops and reply to queries without actually reading the question, instead just looking up the various options you ahve to select about problem type and giving a generic answer. It's probably a compatibility issue and it'd be fair to say FireGL and other workstation class GPUs aren't supported, but it's quite embrassing when you submit a program to a government body to ratify it for usefulness in the education sector, and the first computer they run it on has the mind-numbingly obvious bug. I'm sure that instills them with confidence in my programming capabilities! |
| ||
| Further, the program using the same method fullscreen works, so it appears to be a DirectX in windowed mode limit of the Workstation card. Not something most people here will have to worry about :) |
| ||
| How many other machines has your code been tested on? Have you tested the code with the desktop in both 16 and 32 bit modes (and possibly 24 depending on OS) on an ATI card? What textureflags is the texture being created with? |
| ||
| It's been tested on four PCs, with GeForce Ti4200, Old ATi Rage I think, one modern Dell with inbuilt 3D chipset, and a Radeon 9800 IIRC, without problems. The bit-depth is set from the desktop so that'll only have been tested on 32 bit. Texture flags are none (or rather, Blitz defaults). Here's a picture that shows exactly what's wrong...  In the textboxes the textures are copies of the backbuffer. There should also be white text from Blitz's text command in the middle between the Registration Key and the Options banner. I'm going to replace it with a 2D drawing method. In this example I just used my 3D quad-based UI interface from the program for a quick solution. Hopefully it'll have a better time with just 2D drawing ops. |
| ||
| I was referring to the current Desktops depth not the one specified in graphics3d as I'm thinking the most likely problem in your code is a problem dependent on the driver's DirectDraw implementation and may very well fail on all ATI cards running in 16 bit desktop mode. If it could be made to fail on consumer ATI cards it would obviously help with a workaround... |
| ||
| Did you make the variable font_gothic Global ? If not your code may point to space you don't expect and copies anything else instead of a Font... |
| ||
| @ skidracer : I don't know his desktop setting. Given he's got a 128 MB workstation card I'd be surprised if he's running 16 bit! But I'll be sure to get it tested on some lower bitdepth ATi cards too. @ RaGR : Yep, font_gothic is declared global in another linked library. Even if not that wouldn't explain why Blitz's text drawing function doesn't work either. Something I've experience creating the 2D drawn alternative, is Flip doesn't seem necessary. This is a point worth asking in an alternative thread... |
| ||
| In typical embarrassing fashion, I've just found my code has the same problem on my PC and it isn't just their GPU. I changed the text drawing to speed it up and was only testing on fullscreen, and didn't test my setup after that it seems. The Setup executable I'm using works though. I don't know if that was an earlier build or what. I'm confused, but at least I have a not-working computer that I can test and fix. |
| ||
| And to further embarrasment, it is fixed with a setbuffer Backbuffer() command on the textdrawing... |
   |