I have to tidy up going from high res back to low-res but will push when I sort this out

That was fast, I just had time to test a single edit! :)

Edit: this is great!

Okay, pushed!

I may have pasted something wrong because I have the same pattern as one patch back. I'll verify, otherwise it could be dosbox?

Edit: i definitely missed a code bit! Recompiling...

the makefile needs the d_copy.s and other friends but it shoudl all be working OK. I've only tested in DOSbox, but going to test on my P2 now, i assume it works

EDIT: work properly on real hardware too.

I missed one bit. :) I should have a result...

I just pushed the code a few moments ago, the main change is all of that is dumped now and in set mode you have to set the VGA_height, etc. In endframe it goes to VGA_UpdatePlanarScreen(vid.buffer) now as well

It worked perfectly! I don't know how you fixed it up so quickly! I look forward to looking at your solution and how you called the asm.

That's waht I missed, the updateplanarscreen. I thought it was my patching, but I downlaoded the commit before the update. I updated my msg above, it works perfectly! :)

The timedemo reports good speeds and the aspect ratio looks much better than 320h. I wonder if there are any tweaked modes that are 1/2H. I'm sure the Dos folks will really appreciate the effort, too, since this mode I think runs on any vga card(?)!

Huh, so you passed the entire video buffer to abrash's asm and it works some kind of magic. :) The other advantage is the expectation of better performance over any C solution, too. I would think there is a 20% performance advantage over 0x13 mode, even with the resolution difference.

Well, he has an VGA_UpdateLinearScreen ASM function too which may or may not be faster than DJGPPs inline stuff. That requires more magic I'm not ready to play with yet.

I'm trying to see if I can come up with some solution to 320x200's botched aspect ratio.

Is the 320x200 aspect as intended? In the Windows client?

1if (width==360)
2  {
3    /* turn off write protect */
4    word_out(CRTC_INDEX, V_RETRACE_END, 0x2c);
5
6    outp(MISC_OUTPUT, 0xe7);
7    word_out(CRTC_INDEX, H_TOTAL, 0x6b);
8    word_out(CRTC_INDEX, H_DISPLAY_END, 0x59);
9    word_out(CRTC_INDEX, H_BLANK_START, 0x5a);
10    word_out(CRTC_INDEX, H_BLANK_END, 0x8e);
11    word_out(CRTC_INDEX, H_RETRACE_START, 0x5e);
12    word_out(CRTC_INDEX, H_RETRACE_END, 0x8a);
13    word_out(CRTC_INDEX, OFFSET, 0x2d);
14
15    /* set vertical retrace back to normal */
16    word_out(CRTC_INDEX, V_RETRACE_END, 0x8e);
17
18    screen_width=360;
19  }
20  else
21  {
22    outp(MISC_OUTPUT, 0xe3);
23  }
24
25  if (height==240 || height==480)
26  {
27    /* turn off write protect */
28    word_out(CRTC_INDEX, V_RETRACE_END, 0x2c);
29
30    word_out(CRTC_INDEX, V_TOTAL, 0x0d);
31    word_out(CRTC_INDEX, OVERFLOW, 0x3e);
32    word_out(CRTC_INDEX, V_RETRACE_START, 0xea);
33    word_out(CRTC_INDEX, V_RETRACE_END, 0xac);
34    word_out(CRTC_INDEX, V_DISPLAY_END, 0xdf);
35    word_out(CRTC_INDEX, V_BLANK_START, 0xe7);
36    word_out(CRTC_INDEX, V_BLANK_END, 0x06);
37    screen_height=height;
38  }
39
40  if (height==400 || height==480)
41  {
42    word_out(CRTC_INDEX, MAX_SCAN_LINE, 0x40);
43    screen_height=height;
44  }

That'd be great to see results on the lfb asm addition.

Edit: I just realized you have ability to switch mode-x resolution in a line or two (via functions).

Edit2: I think the magic bits for 160h are here: https://github.com/leilei-/Engoo/blob/master/ … Quake/vid_ext.c. Just for reference. :)

I'm not bothering with exotic planar modes. 320x240x8 is enough. The 320x200 aspect is wrong even in windows. The game was meant for 320x240 and the math is as such. I got something close to it, but not 100% it will do for now unless someone wants to fine tune the value to find the perfect number for it. Going to push it now.

I just saw that commit of yours. I look forward to trying the aspect correction and appreciate all your work! I also wondered, on a separate issue, whether it was ok for excluding multicast from the watt library? I recall(?) multicast functions in q2 or its mods, but maybe they are called from another part of the watt library?

those multicast functions in mods are taken care of internally by quake. they're different functions and don't stomp each other so you don't have to worry about that.

They're more or less meant to broadcast say a death message or whatever to every connected and spawned player.

I suspected, but I don't know much of the network libs. It will be fun to try out the banked and modex mode(s) today.

Edit: that makes sense on the msgs from the mods.

I mean, in theory you could add more modex modes to that function in vid_ext2.c if you really want, but I fail to see a point in rendering at 320x256 or 320x480. Even on a big CRT it looks like shit. If you can get 400x300 in LFB I think that's a good compromise between VGA and SVGA.

I don't think I'd run below 640h, but if I had a period correct system, like alot of folks here, then the modex mode is invaluable. It also brings the compatibility to those systems, as you said before.

If I had dosbox on a non-x86 and in normal core mode (it's slower), then the modex would allow it to run with proper aspect ratio. I should build a real Dos machine anyways.

Edit: yes, I remember looking at the other modes on a crt (when q1 was released) and it wasn't my first choice! Actually I recall I thought 320x200 was correct aspect and ran at that for a year or so.

Yeah, I tried taking the aspect ratio code from Q1 in R_ViewChanged but it made it worse. I guess xscale and other values have different math now and just assume a 4:3 aspect ratio.