Hi all,

I've been fooling around with applying the Nomissoft 3D Advanced Graphics System (AGS) to Flight Assignment: Airline Transport Pilot Revision E (FA: ATP) in order to run at a resolution of 800x600.

I'm using the svga_S3 video display option (although I have tried fooling around with svga_ati_mach32/64 in dosbox-x) but with everything I've tried, across both dosbox and dosbox-x, I get the following error:

XGA: Wants line drawn from PIX_TRANS register!

This is accompanied by the display doing funny things, almost like the top half flipping to the bottom and vice versa which is repeated. The audio works ok.

I have managed to run this software successfully in an 86Box build, but would like to get it running in dosbox or dosbox-x for performance reasons.

Can anyone shed any light on this error and whether there are any suggestions I can play around with in the configuration file?

I did find the following but as best I can tell, this doesn't seem to have been addressed in dosbox-x:

TheGreatCodeholio wrote on 2022-03-28, 08:21:

I'm posting this here because while working on S3 and S3 ViRGE emulation I found something about the Trio64 emulation that SVN m […]
Show full quote

I'm posting this here because while working on S3 and S3 ViRGE emulation I found something about the Trio64 emulation that SVN might be interested in.

In the command word to draw a line, there is a bit that controls whether the line includes or omits the last pixel. The code as it was before my changes did not pay attention to that bit, which meant that the line was always drawn from x1,y1 to x2,y2 inclusive. The thing is, Windows 3.1 S3 drivers rely on that bit to draw continuous segments like polygons and circles as a series of short line segments, and by ignoring the "skip last pixel" bit, the line segments overlap by one pixel. This is especially noticeable in programs like Microsoft Word where when dragging a shape, it's outline is drawn with a XOR against the screen as you move since XORing a pixel twice restores the original value. I think it may also visually affect the "Curves and Colors" screensaver somewhat in Windows 98 as well.

According to Windows 3.1 driver behavior, there is an undocumented feature where the XGA rectangle command also obeys the "skip last pixel" bit, in fact poly lines in Windows 3.1 will look wrong if not handled there as well. S3 documentation says nothing about that.

I came across this while finishing the XGA line draw support for S3 ViRGE emulation. S3 ViRGE changed the accelerated line draw from a Bresenham type algorithm to a simple Y-major X delta fixed point DDA with 1 sign bit, 11 bits for the whole part and 20 bits for the fractional part (run over rise), so I had to puzzle that out to make it work. I think the reason they did that is so that 2D acceleration can have a 3D acceleration variant that uses an additional register for Z, and that kind of math can support 3D graphics as well as ViRGE cards have 3D acceleration. No 3D acceleration is implemented yet in DOSBox-X.

Is DOSBox SVN interested in a patch to fix XGA line drawing?

This appears to affect Windows more than anything, which I'm not using. I'm trying to use the program within DOS.

Thanks everyone, any help, insight and suggestions are very much appreciated.

Trent