The modex should be faster, aspect friendly, and as compatible with other video cards as 0x13?

Yes, if the card can do 320x200 it can do 320x240. I may just change the default to be 320x240.

I bet it runs fast in PCem, too. Many users try the different video emulations/bioses and they'll have a chance to test their different system configurations.

Is net_udp.c still used by Q2Dos?

I can tell you on real hardware if youre doing VGA modes it mostly makes no difference. Maybe on very old computers there was a difference. But once you get into that P1 and P2 range the framerates all seem to be about the same. I have a slew of different PCI and AGP cards and experimented with that for a while.

This also reminds me, I tested the banked code on a P3 550 and there was no performance penalty between using banked 640x480 and LFB 640x480.

On net_udp.c: Only for a *nix port, which we haven't made a makefile for, but you should be able to generate a *nix binary if you really want to. The game already compiles windows binaries just fine.

That's very good news. With all your work on q2dos, I think I'd run it on Windows, too, over any other port. Even if just for stability, given all the debugging work.

That's interesting on the video versus cpu bottleneck in performance. The banked modes was also useful in the path to modex, I think.

Yup, it helped me learn a few things about how to set video registers and such. Compiling the static linked build (haven't maintained separate dynamic builds in a long time) is easy. Just install VS6 and compile from the .dsw files in msvc directory.

I didn't know that was available, the static build for Windows. I'll give that a run for sure. Thanks.

Maraakate wrote:

I may just change the default to be 320x240.

Seconding this. You should as that's quake2's canonical resolution

ggorts wrote:

I guess I shouldn't be surprised that there isn't a subforum here for NTVDM. 😀

Yeah, because originally NTVDM WAS one of the main focuses, so it didn't need a subforum, it WAS the forum. 😁

The NTVDM support of VOGONS forums basically turned into the following:
The Guide -> DOS: "Getting old DOS games working.": DOS
VDMSound General: "General information and assistance with VDMSound.": VDMSound General
VDMSound Development: "Developer's Forum, for discussion of bugs, code, and other developmental aspects of VDMSound.": VDMSound Development
Speedset: "Problems related to Speedset.": Speedset

That's right, "The Guide -> DOS" was originally intended for all sorts of discussion of NTVDM compatibility hacks and game patches and whatnot, back in 2002. It was "PC Emulation" that was intended for actual emulator discussion. But after several years of having absorbed the DOSBox support forums, it all started blending together (lazy moderators... heh.) These days if you posted something NTVDM-related in "The Guide->DOS", the first questions you'd be asked would be a. why aren't you running it in DOSBox and b. you should try building a retro PC to run it properly, haha! 🤣

leileilol wrote:

Maraakate wrote:

I may just change the default to be 320x240.

Seconding this. You should as that's quake2's canonical resolution

Done, compiling now and will upload shortly.

ggorts wrote:

The modex should be faster, aspect friendly, and as compatible with other video cards as 0x13?

Also, it won't be any faster because it does have an extra 12800 pixels to draw. You can see this by setting 320x200 and 320x240 LFB if the card supports it. And with the planar modes Abrash came up with some custom ASM code because there's apparently a performance hit with having to switch between the planes. With his code, on my P2 400 it appears to be about the same level of performance between a 320x240 Mode-X and 320x240 LFB which is good.

Stiletto wrote:

That's right, "The Guide -> DOS" was originally intended for all sorts of discussion of NTVDM compatibility hacks and game patches and whatnot, back in 2002. It was "PC Emulation" that was intended for actual emulator discussion. But after several years of having absorbed the DOSBox support forums, it all started blending together (lazy moderators... heh.) These days if you posted something NTVDM-related in "The Guide->DOS", the first questions you'd be asked would be a. why aren't you running it in DOSBox and b. you should try building a retro PC to run it properly, haha! :lol:

The solutions to running older games seems to have changed over time in a way unforeseen. :) With MS removing features intentionally and unintentionally, it seems that there is another schism developing by which operating system version is running.

Also, I still have nt4compatible.com bookmarked, but I think someone has taken it down and left us in the lurch!

Maraakate wrote:

ggorts wrote:

The modex should be faster, aspect friendly, and as compatible with other video cards as 0x13?

Also, it won't be any faster because it does have an extra 12800 pixels to draw. You can see this by setting 320x200 and 320x240 LFB if the card supports it. And with the planar modes Abrash came up with some custom ASM code because there's apparently a performance hit with having to switch between the planes. With his code, on my P2 400 it appears to be about the same level of performance between a 320x240 Mode-X and 320x240 LFB which is good.

That's a good result. I incorrectly thought that mode-x is universally faster, but that must only apply to cases wheres special objects are drawn which utilize the advantages of the planar mode (I think something about using 1 byte in a way to draw 4 pixels instead of 1). In this case the mode is used as a general framebuffer, so as you said, it must be similar in speed to the LFB mode of same dimension, or even slower with the plane switching counteracted by any ASM speed-up. :)

I spend quite a while just testing all your improvements to q2dos, I noted a lot of fixes to all the components. It's running great!

Attempting to fix the aspect thing. The relevant function is R_ViewChanged in ref_soft/r_misc.c

So far 320x200 aspect is proper, but every other mode is screwed. Still hacking at it locally.

Colored lighting definitely not included since i'm prototyping this in a win32 ref_soft I have lying around

EDIT: Much better now. 320x400 works, no other modes are screwed.

EDIT2: Here's the new R_ViewChanged. Plop this in your DOS version source whereever it may be, can't be arsed to setup djgpp and try it out myself
It could be faster (i.e. doing what Quake does, assigning a precalculated aspect value to every initialized video mode)

1/*
2===============
3R_ViewChanged
4
5Called every time the vid structure or r_refdef changes.
6Guaranteed to be called before the first refresh
7===============
8*/
9void R_ViewChanged (vrect_t *vr)
10{
11	int		i;
12	float pixelAspect, screenAspect;
13
14	r_refdef.vrect = *vr;
15
16	r_refdef.horizontalFieldOfView = 2*tan((float)r_newrefdef.fov_x/360*M_PI);;
17	verticalFieldOfView = 2*tan((float)r_newrefdef.fov_y/360*M_PI);
18
19	r_refdef.fvrectx = (float)r_refdef.vrect.x;
20	r_refdef.fvrectx_adj = (float)r_refdef.vrect.x - 0.5;
21	r_refdef.vrect_x_adj_shift20 = (r_refdef.vrect.x<<20) + (1<<19) - 1;
22	r_refdef.fvrecty = (float)r_refdef.vrect.y;
23	r_refdef.fvrecty_adj = (float)r_refdef.vrect.y - 0.5;
24	r_refdef.vrectright = r_refdef.vrect.x + r_refdef.vrect.width;
25	r_refdef.vrectright_adj_shift20 = (r_refdef.vrectright<<20) + (1<<19) - 1;
26	r_refdef.fvrectright = (float)r_refdef.vrectright;
27	r_refdef.fvrectright_adj = (float)r_refdef.vrectright - 0.5;
28	r_refdef.vrectrightedge = (float)r_refdef.vrectright - 0.99;
29	r_refdef.vrectbottom = r_refdef.vrect.y + r_refdef.vrect.height;
30	r_refdef.fvrectbottom = (float)r_refdef.vrectbottom;
31	r_refdef.fvrectbottom_adj = (float)r_refdef.vrectbottom - 0.5;
32
33	r_refdef.aliasvrect.x = (int)(r_refdef.vrect.x * r_aliasuvscale);
34	r_refdef.aliasvrect.y = (int)(r_refdef.vrect.y * r_aliasuvscale);
35	r_refdef.aliasvrect.width = (int)(r_refdef.vrect.width * r_aliasuvscale);
36	r_refdef.aliasvrect.height = (int)(r_refdef.vrect.height * r_aliasuvscale);
37	r_refdef.aliasvrectright = r_refdef.aliasvrect.x +
38			r_refdef.aliasvrect.width;
39	r_refdef.aliasvrectbottom = r_refdef.aliasvrect.y +
40			r_refdef.aliasvrect.height;
41
42	xOrigin = r_refdef.xOrigin;
43	yOrigin = r_refdef.yOrigin;
44	
45// leilei - Aspect stuff nicked from Q1
46	pixelAspect = 1.000 + (1.3333 - ((float)vid.width / (float)vid.height));
47
48	screenAspect = r_refdef.vrect.width*pixelAspect /
49			r_refdef.vrect.height;
50	verticalFieldOfView = r_refdef.horizontalFieldOfView / screenAspect;
51
52
53// values for perspective projection
54// if math were exact, the values would range from 0.5 to to range+0.5
55// hopefully they wll be in the 0.000001 to range+.999999 and truncate
56// the polygon rasterization will never render in the first row or column
57// but will definately render in the [range] row and column, so adjust the
58// buffer origin to get an exact edge to edge fill
59	xcenter = ((float)r_refdef.vrect.width * XCENTERING) +
60			r_refdef.vrect.x - 0.5;

61	aliasxcenter = xcenter * r_aliasuvscale;
62	ycenter = ((float)r_refdef.vrect.height * YCENTERING) +
63			r_refdef.vrect.y - 0.5;
64	aliasycenter = ycenter * r_aliasuvscale;
65
66	xscale = r_refdef.vrect.width / r_refdef.horizontalFieldOfView;
67	aliasxscale = xscale * r_aliasuvscale;
68	xscaleinv = 1.0 / xscale;
69	yscale = xscale * pixelAspect;	// leilei - aspect stuff
70	//yscale = xscale;
71	aliasyscale = yscale * r_aliasuvscale;
72	yscaleinv = 1.0 / yscale;
73	xscaleshrink = (r_refdef.vrect.width-6)/r_refdef.horizontalFieldOfView;
74	//yscaleshrink = xscaleshrink;
75	yscaleshrink = xscaleshrink*pixelAspect; // leilei - aspect stuff
76
77// left side clip
78	screenedge[0].normal[0] = -1.0 / (xOrigin*r_refdef.horizontalFieldOfView);
79	screenedge[0].normal[1] = 0;
80	screenedge[0].normal[2] = 1;
81	screenedge[0].type = PLANE_ANYZ;
82	
83// right side clip
84	screenedge[1].normal[0] =
85			1.0 / ((1.0-xOrigin)*r_refdef.horizontalFieldOfView);
86	screenedge[1].normal[1] = 0;
87	screenedge[1].normal[2] = 1;
88	screenedge[1].type = PLANE_ANYZ;
89	
90// top side clip
91	screenedge[2].normal[0] = 0;
92	screenedge[2].normal[1] = -1.0 / (yOrigin*verticalFieldOfView);
93	screenedge[2].normal[2] = 1;
94	screenedge[2].type = PLANE_ANYZ;
95	
96// bottom side clip
97	screenedge[3].normal[0] = 0;
98	screenedge[3].normal[1] = 1.0 / ((1.0-yOrigin)*verticalFieldOfView);
99	screenedge[3].normal[2] = 1;	
100	screenedge[3].type = PLANE_ANYZ;
101	
102	for (i=0 ; i<4 ; i++)
103		VectorNormalize (screenedge[i].normal);
104
105	D_ViewChanged ();
106}
107
108

By every other mode you mean the weirdo 320 modex modes? All 4:3 stuff should be normal.

by every other mode I meant EVERY other normal mode. 320x240, 640x480 etc. but that's moot now as it's fixed. 😀
This was prototyped on msvc6+q23.21, I changed 400x300/512x384 to 320x200/320x400 to help test that and tried to keep the changes self-contained and as simple as possible.

leileilol wrote:

by every other mode I meant EVERY other mode. 320x240, 640x480 etc. but that's moot now as it's fixed.

Have you seen the latest source I already made a hacky solution to the issue. I took Q1s code but the aspect shifting is only applied to 320x200. It looks like you tried what I originally tried to do... take Q1s aspect code and just apply it but I noticed all the modes got fucked this way. I guess xscale and yscale, etc. have new math that are depending on straight up 4:3.

Here is what is currently in the code and works OK, but not perfect.

1void R_ViewChanged (vrect_t *vr)
2{
3	int		i;
4	float	screenAspect, pixelAspect; // FS: From Q1
5
6	r_refdef.vrect = *vr;
7
8	r_refdef.horizontalFieldOfView = 2*tan((float)r_newrefdef.fov_x/360*M_PI);
9 	// Knightmare- catch 5:4 modes pushing top and bottom clips beyond screen buffer
10 	if ( (r_refdef.vrect.width != r_newrefdef.width || r_refdef.vrect.height != r_newrefdef.height)
11 		&& (((float)r_newrefdef.width / (float)r_newrefdef.height) < (640.0f/480.0f)) )
12 	{
13 		float	x;
14 		x = r_refdef.vrect.width/tan(r_newrefdef.fov_x/360*M_PI);
15 		verticalFieldOfView = 2*(r_refdef.vrect.height/x);
16 	}
17 	else
18 		verticalFieldOfView = 2*tan((float)r_newrefdef.fov_y/360*M_PI);
19 	// end Knightmare
20
21	r_refdef.fvrectx = (float)r_refdef.vrect.x;
22	r_refdef.fvrectx_adj = (float)r_refdef.vrect.x - 0.5;
23	r_refdef.vrect_x_adj_shift20 = (r_refdef.vrect.x<<20) + (1<<19) - 1;
24	r_refdef.fvrecty = (float)r_refdef.vrect.y;
25	r_refdef.fvrecty_adj = (float)r_refdef.vrect.y - 0.5;
26	r_refdef.vrectright = r_refdef.vrect.x + r_refdef.vrect.width;
27	r_refdef.vrectright_adj_shift20 = (r_refdef.vrectright<<20) + (1<<19) - 1;
28	r_refdef.fvrectright = (float)r_refdef.vrectright;
29	r_refdef.fvrectright_adj = (float)r_refdef.vrectright - 0.5;
30	r_refdef.vrectrightedge = (float)r_refdef.vrectright - 0.99;
31	r_refdef.vrectbottom = r_refdef.vrect.y + r_refdef.vrect.height;
32	r_refdef.fvrectbottom = (float)r_refdef.vrectbottom;
33	r_refdef.fvrectbottom_adj = (float)r_refdef.vrectbottom - 0.5;
34
35	r_refdef.aliasvrect.x = (int)(r_refdef.vrect.x * r_aliasuvscale);
36	r_refdef.aliasvrect.y = (int)(r_refdef.vrect.y * r_aliasuvscale);
37	r_refdef.aliasvrect.width = (int)(r_refdef.vrect.width * r_aliasuvscale);
38	r_refdef.aliasvrect.height = (int)(r_refdef.vrect.height * r_aliasuvscale);
39	r_refdef.aliasvrectright = r_refdef.aliasvrect.x +
40			r_refdef.aliasvrect.width;
41	r_refdef.aliasvrectbottom = r_refdef.aliasvrect.y +
42			r_refdef.aliasvrect.height;
43
44	xOrigin = r_refdef.xOrigin;
45	yOrigin = r_refdef.yOrigin;
46
47	if(r_newrefdef.width == 320.0f && r_newrefdef.height == 200.0f) // FS: Special hack for 320x200
48	{
49		pixelAspect = 0.9; //(float)r_newrefdef.width / (float)r_newrefdef.height;
50		screenAspect = r_refdef.vrect.width*pixelAspect /
51			r_refdef.vrect.height;
52
53		verticalFieldOfView = r_refdef.horizontalFieldOfView / screenAspect;
54	}
55	else
56	{
57		pixelAspect = 1.0f;
58		screenAspect = 1.0f;
59	}
60

61// values for perspective projection
62// if math were exact, the values would range from 0.5 to to range+0.5
63// hopefully they wll be in the 0.000001 to range+.999999 and truncate
64// the polygon rasterization will never render in the first row or column
65// but will definately render in the [range] row and column, so adjust the
66// buffer origin to get an exact edge to edge fill
67	xcenter = ((float)r_refdef.vrect.width * XCENTERING) +
68			r_refdef.vrect.x - 0.5;
69	aliasxcenter = xcenter * r_aliasuvscale;
70	ycenter = ((float)r_refdef.vrect.height * YCENTERING) +
71			r_refdef.vrect.y - 0.5;
72	aliasycenter = ycenter * r_aliasuvscale;
73
74	xscale = r_refdef.vrect.width / r_refdef.horizontalFieldOfView;
75	aliasxscale = xscale * r_aliasuvscale;
76	xscaleinv = 1.0 / xscale;
77
78//	yscale = xscale;
79	yscale = xscale * pixelAspect; // FS: From Q1
80	aliasyscale = yscale * r_aliasuvscale;
81	yscaleinv = 1.0 / yscale;
82	xscaleshrink = (r_refdef.vrect.width-6)/r_refdef.horizontalFieldOfView;
83//	yscaleshrink = xscaleshrink;
84	yscaleshrink = xscaleshrink*pixelAspect; // FS: From Q1
85
86// left side clip
87	screenedge[0].normal[0] = -1.0 / (xOrigin*r_refdef.horizontalFieldOfView);
88	screenedge[0].normal[1] = 0;
89	screenedge[0].normal[2] = 1;
90	screenedge[0].type = PLANE_ANYZ;
91	
92// right side clip
93	screenedge[1].normal[0] =
94			1.0 / ((1.0-xOrigin)*r_refdef.horizontalFieldOfView);
95	screenedge[1].normal[1] = 0;
96	screenedge[1].normal[2] = 1;
97	screenedge[1].type = PLANE_ANYZ;
98
99// top side clip
100	screenedge[2].normal[0] = 0;
101	screenedge[2].normal[1] = -1.0 / (yOrigin*verticalFieldOfView);
102	screenedge[2].normal[2] = 1;
103	screenedge[2].type = PLANE_ANYZ;
104	
105// bottom side clip
106	screenedge[3].normal[0] = 0;
107	screenedge[3].normal[1] = 1.0 / ((1.0-yOrigin)*verticalFieldOfView);
108	screenedge[3].normal[2] = 1;	
109	screenedge[3].type = PLANE_ANYZ;
110	
111	for (i=0 ; i<4 ; i++)
112		VectorNormalize (screenedge[i].normal);
113
114	D_ViewChanged ();
115}

The aspect looks very good on all intended modes.

I ran tests to determine the source of those fpu under/overflow errors in dosbox while "stress testing" q2dos and a custom test build (repeated game mod loading/unloading with maps). It's very likely that the fpu emulation of dosbox (given my settings) is not matching perfectly to real hardware and likewise this is an active issue on the github for dosbox-x (worked on by TheGreatCodeholio). This is obviously not occurring on real hardware nor is it expected to.

One possible reason is arithmetic stack overflow, but I have a solution that has worked so far. The cflags "-ffloat-store" and "-fexcess-precision=standard" are avoiding the error and the latter flag is recommended anyways to compile quake2 under GCC4 versions (given another set of test conditions). Some background is here:
http://blog.jwhitham.org/2015/04/gcc-bug-323- … o-heart-of.html
http://stackoverflow.com/questions/20869904/c … xcess-precision

The downside is a few percent performance cost of the flags, but perhaps these flags could be considered for builds intended for emulators where the fpu emulation is not tested against quake2. I don't suggest these flags as default ones, but perhaps commented out in a makefile as a reminder?

My other issue is not yet resolved. Dday mod causes a page fault when it is loaded and then the single player option is chosen. The mod doesn't support single player anyways, but some of the other tested mods do not have this issue. The symify technique with debugging symbols available in the binary does not show the error in q2, but the debugging information points to an "uninitialized pointer or missing call to malloc". I think one good solution is to prevent single player option where the dday mod is loaded. I can look into this further, but I hope I can share my results on these two issues. :)