Strange. Seems to work fine for me. (ykhwong's build, March 8th). Can you paste your dosbox.conf ?

Indeed, Ykhwong's build works, regular CVS does not.

So, what would be the likely difference between Ykhwong's build and the CVS/0.63 builds? Differences in actual sourcecode, or compiler differences? I'm assuming sourcecode, in which case, how does one track it down?

Compiler shouldn't make a difference, but vasyl's patches
change the vga/svga system at a lot of points.
The vga bios emulation isn't the problem, don't know more.

Oddly enough, it is something else. I've tested the executable with CVS with my patch only and it shows the same problem as pure CVS. There are more than 20 patches in ykhwong's build, most can be excluded. It can be side fix in D3D, OpenGLHQ, or vertical retrace sync. The rest are hardly related, although it may be side effect of one of three patches in "Improvements" section: http://ykhwong.x-y.net/bbs/zboard.php?id=compile.

It doesn't seem to work with 31.3 ykhwong's cvs. It also does not work with my build so it's not d3d or openglhq as I include those.

Use my stable build (Jan.30.2006) to fix the bugs.
I have no idea why the bugs disappear.

I suspect that it might be my font patch, which you (ykhwong) included only once, before it was rejected because it contained data from a commercial VGA card, which of course is really a no-no for open source software.

In most real VGA cards only the leftmost 7 pixels are used in most characters of the 8x16 font. But in dosbox, several characters (M,m,W,w,X,Y and some more) use all 8 pixels.

Probably the application in question draws text in graphics mode, using the leftmost 7 pixels of VGA characters from emulated ROM.

I've recreated the patch "by hand" (drawing the new characters myself) so it should be without legal hassels now. I'm attaching it here. Maybe you could try this patch, and then see if the problem goes away. If yes, I'll try resubmitting the patch.

I found the reason why. Use dynamic core to fix the bugs. 😀
It seems to work on all other cvs builds.

I set core=dynamic in my older builds, but I don't do that any more for compatibility.

TeaRex, I have applied your font patch till now.
Thanks for a new patch.

Ok, so then my guess was obviously wrong. Glad you found the real fix.

interresting.
by disabling dynamic opcodes it should be possible to determine where it comes from

Most likely the flags.

They require the rotate opcodes to return flags on full-rotates.

I suspect that it might be my font patch, which you (ykhwong) included only once, before it was rejected because it contained data from a commercial VGA card, which of course is really a no-no for open source software.

Well, it would still be okay in the US, because bitmapped fonts are not copyrightable (and if we're talking old VGA cards, it's a bitmapped font).

Yeah, but I figure DOSBox wants to be legal around the world, and well away from any "gray" areas. So Qbix was IMHO right to reject it.

Anyway the new version of the patch does the trick just as well and has no such legal problem. I just converted the fonts to a bitmaped graphic, loaded them into the GIMP, looked at the 8x14 font already in DOSBox (which doesn't have the problem of too wide characters) and simply redrew the too wide 8x16 characters following that model (but of course a bit taller).

The original problem with the text getting truncated is fixed by the "Dynamic" switch. I suspect the gaps in the lines and the text issue were the same. The characters in this program are drawn, rather than being pulled from a font file. They can be scaled somewhat arbitrarily.

Thanks for the detective work, everyone. I'm off to hunt for more bugs, but they are getting harder & harder to find...