Brian,

I've had to deal with "mystical, magical" problems myself, and they are always the most frustrating to solve.

I'm sorry to say that version 3.11 RC15 did not solve the problem.

However, I've been playing around with the hardware acceleration on my machine and I have some more info.

Originally, my machine was set with full acceleration enabled. With that setting, the problem occurs (but we already knew that). However, if I reduce the acceleration by one notch (it's a Windows slider with 6 hard notches on it) the problem goes away. The details of that notch read that cursor and bitmap accelerations are disabled, but all others are enabled. It continues on to read that the setting is for problems with the mouse pointer and corrupt images.

I need to use the program for a little while longer until I'm convinced that this work-around truly works. But since I could reliably reproduce it before and now cannot, it looks promising.

However, since I can reproduce this issue so easily, I'd be more than happy to keep working on this one with you until it's solved if you think that it's worth it. I know the value of a system where a "mystical, magical" problem can be reproduced at will.

Thanks for the info, Robert!! That give me a little more info to go on. I was *so* hopeful that RC15 would do it!!! At least knowing that hardware acceleration is involved gives me a direction in which to look. In the short-term, I'd be interested to know if switching video drivers affects the problem. You're running 5.0.2195.5012, which is not the 'recommended' driver. Can you try 5.00.2179.1 and see if it makes a difference? You can find the driver for the Rage XL here: 

<old link removed>

Robert,

One other quick thing.... Could you take a screen snapshot of the window where your hardware acceleration slider is located? If you could, please e-mail it to me at:

(bpence at celestialsoftware.net)

Thanks!

Brian,

I've emailed you the screen captures that you asked for.

According to my system information, I'm using version 5.00.2179.1 already.

Did you mean that you wanted me to try version 5.0.2195.5012?

Sorry, I got that reversed. Whichever you are using, try the other.

Your sys info from a previous post:

Driver Version: 5.00.2179.1
OS Name: Microsoft Windows 2000 Professional
OS Version: 5.0.2195 Service Pack 4 Build 2195

I got it reversed. I must have looked at OS Version when I wrote that post. Strange coincidence, that!

I thought that's what'd happened.

I tried the new driver (5.0.2195.5012) and got the old result. The characters are still cut off in full acceleration mode and fine with cursor and bitmap acceleration turned off.

Thanks for testing that.

I've put a bid in on EBay for one of these ATI cards. I'd like to try to identify a possible workaround, but I'll have to be able to reproduce the problem first.

I'm not happy having to tell people to disable hardware acceleration in order for my program to work. There must be a better way!! I'm not doing anything all that complicated.

I won the auction unopposed. $7.99. I’m not sure I’ll be able to do anything about fixing the problem, as it’s likely a driver bug, but I *know* I can’t fix it if I can’t reproduce it. I’ll keep you posted.

Brian,

I'm impressed. Your determination to resolve this problem even thought it might not have anything to do with your software is commendable.

There are quite a number of developers out there (I've worked with too many of them) that would just throw up their hands and say that it's not their problem and move on.

Once again....well done good sir!!

Robert,

It's probably a bug in the driver, but there may possibly be a work-around. If I'm passing something that the driver is not expecting, it may be reacting in an un-predictable way. It's possible that by adjusting the way the drawing code works, I won't hit the bug. We'll see. Device drivers can be funny that way.

For example, I had a condition in the serial connection code where I would occasionally send a string of zero bytes on the COM port. On most hardware, this would just return immediately without sending anything. However, on some USB->COM PORT adapters, this would crash the driver (and the program). It was easy to work around. I just don't call the send routine when the byte count is zero!! Because it had never come up before, there appeared to be an incompatibility between my program and the user's hardware. I really considered that a driver bug( the driver had obviously never been tested with a zero-length input), but it was something that my program could adapt to.

It's possible that this issue could be similar. However, I'll have to see under what conditions this error occurs. If it's reproducable and predictable, I might be able to work around it.

For now, just turn down the hardware acceleartion.

I'll keep you posted.