S3/Virge

Discussion of development and patch submission.
Post Reply
rene
Posts: 7
Joined: Wed 05 Sep, 2018 1:30 pm

S3/Virge

Post by rene »

Hi Sarah,

thank you for your awesome emulator! While I run a whole Linux distribution (https://t2sde.org) I never came across it before :-/ I was using Qemu/KVM for cloud stuff, and dosbox for DOS things otherwise and was already thinking to add some early 3d accelerator support to either of them. So I do some educational Linux/GCC to DOS.com executable hacking and started to poke the S3/Virge some week ago: https://www.youtube.com/watch?v=fXJ11_wG_0U I noticed 3d lines are currently missing, I could probably work on a patch to support this or hand you a dos .com exutable triggering 3dlines if you prefer that (I tested it on an actual, real Virge/DX today). Unrelated: while my 2d lines work in your pcem, they currently do havoc / erratic things on the real silicon. I hope I find the cause soon, … when I do: would you be interested to tweak the 2d lines to match the erratic hardware behaviour, or did you already test the 2d lines enough with other software / os drivers to better not touch that part?

Thanks again, awesome software! & greetings from Berlin,
René

PS: The hw silicon Virge/DX 2d line drawing corruption are really strange, I wonder if it's 3d line engine has a defect. At least the vintage xfree3 driver also never apparently really used those, ... does someone have another real original Virge or later GX/2 around to run some test against? ;-)
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: S3/Virge

Post by SarahWalker »

3D lines aren't currently emulated because I never saw any software trying to use them. If you want to work on a patch to add them then feel free!

If we can identify the nature of the erratic 2D line rendering then it should be emulated, yes. I wouldn't be surprised if this is a hardware bug; something as (relatively) complicated as the ViRGE is likely to have many poorly documented hardware issues.
rene
Posts: 7
Joined: Wed 05 Sep, 2018 1:30 pm

Re: S3/Virge

Post by rene »

Hey! No matter what I tried today I could not get the /DX to render 2D lines properly. Your emulator works as I interpret the specs, but the hardware is skipping strangely over scaliness, which looks to me like an overflow. Naturally I would assume the values I write are sign inverted or off by something, but I tried plenty of variants, inversions, different fixed point shifts to no avail - I could not get it to do lines properly: Do you happen to have an actual card of those - or did you implement the emulation based on the spec and what what access you saw from software? Is the Windows driver using it on the /DX? If so I could install it and look on the register wires and compare with what I'm doing. Funny though that 3d lines work ,-) https://www.instagram.com/p/BnbEzq6BQ-_/

Unrelated I wonder how to get Descent started with the /DX, real or emulated. When I run this S3D TSR patcher the descent2 virge .exe only crashes, the very same way on real hardware as in pcem. I wonder how others got it to run, maybe it only works with Windows installed, and not pure DOS?
User avatar
leilei
Posts: 1039
Joined: Fri 25 Apr, 2014 4:47 pm

Re: S3/Virge

Post by leilei »

I only got it to work on Stealth3D 2000 because that's what my copy was bundled with. Never tried it on the Virge/DX real or emulated.
rene
Posts: 7
Joined: Wed 05 Sep, 2018 1:30 pm

Re: S3/Virge

Post by rene »

Finally found the culprit, YAY!!! I did not set the MONO pattern bit in the 2D line command, and this caused the real silicon to do this erratic overflowing, filling to the end of scanlines and skipping over appropriately every second. Strange things in silicon some designers do, ..! ;-) I will continue some more demo code and if I find time later this year implement the 3dlines in pcem, if noone else does it until then ;-) Thanks again and I also packaged it for others to emerge from source in #t2: https://t2sde.org/packages/pcem

PS: video of s3/virge gcc DOS low-level coding and hunting the actual silicon "bug", which ended up being a missing bit in the CMD register, ..: https://www.youtube.com/watch?v=Hsg1N4IqXac

PPS: also go the real /DX running with descent II, apparently this s3dsrvr/s3drun only work in windows, not in pure (MS-)DOS? https://www.youtube.com/watch?v=-djkOUvnRTg
rene
Posts: 7
Joined: Wed 05 Sep, 2018 1:30 pm

Re: S3/Virge

Post by rene »

I think I found some imprecision in the pcem emulated hardware clipping, given clip 0,0 639, 479 and a triangle start at 479 y_count 480 the code clips to 479 y_count scan lines (https://svn.exactcode.de/t2/trunk/packa ... irge.patch)?

--- ./src/vid_s3_virge.c.vanilla 2018-11-02 21:34:23.001923446 +0100
+++ ./src/vid_s3_virge.c 2018-11-02 21:36:33.253917430 +0100
@@ -2975,8 +2975,8 @@
z_offset -= s3d_tri->z_str;
y_count -= diff_y;
}
- if ((state->y - y_count) < s3d_tri->clip_t)
- y_count = state->y - s3d_tri->clip_t;
+ if ((state->y + 1 - y_count) < s3d_tri->clip_t)
+ y_count = state->y - s3d_tri->clip_t + 1;
}

for (; y_count > 0; y_count--)

This solves my off-by-one problem, but may overwrite some other memory, as this corrupts my hardware cursor - I do not have my actual real s3vige with me right now. But what do you think? My s3virge.pdf clearly specifies the clipping as inclusive (first, last pixel drawn)? I may have the same problem for the last x-pixel, but I have not yet finished to hacking on this guess this requires changing the x != xe, but making this conditions on xdir would be a bit performance degrading, ..!?

PS: I think this is visible in Descent 2, the top-most scan line appears to be black and right-most line of pixels do show random colours that are not directly related / uniform with the previous pixel. While the linked patch fixes my synthetic test case it core dump w/ Descent 2 (running pcem on Linux).
Post Reply