Attached patch and DOS quake binary which includes dynamic color lighting. Based on modified code from qbism's SVN repository (note that the dithering table was not compatible with DOS in its current form and was removed).

Edit: attached another quake binary which supports fog, but this is an experimental version and not for general use. It is untested because I do not have a playable map with fog.

Edit2: removed test binaries (b59+experimental fog and b59+dlights).

interesting... does this run better on the same hardware compared with ID's engine?or a "beefy" 🤣 P-II machine is required?

It depends on the map size and which features are active. 😀

Attached patch and quake binary which includes qbism's dynamic color light with dithering, brush model fix, and fog. The fog patch is untested. This version, qs8 DOS-5, also contains refinements to the color lighting and fog features, so this is the version to download for testing. If there are any software errors, then an older version may help isolate the cause.

Edit: updated the attachments (7/4/14) to include additional bits of qbism's SVN code (up to Release #89).

Edit 2: removed binary since there is a newer build below.

Attached patch and quake binary which include improvements to the lighting and clipping code (qbism super8 SVN repository). The fog code is untested. This is version qs8 DOS-6 (quake will report as version DOS-5, but the modified date on this binary is 7/6/14). If there are any software errors, then an older version may help isolate the cause. Instructions are in the above posts.

I don't expect to add further features because of performance and stability in-game. However, this version requires testing for bugs on different maps. If any bugs exist, then please test with an older version to help isolate the cause. It would not be too difficult to revert back to older versions of source code.

This qs8 DOS-6 version also supports some of the very large custom maps, but others have long file names which are not supported in DOS. This is for single player only, although it may be possible to disable many of the features via console parameters so that multiplayer is working properly.

Edit 2: removed binary since there is a newer build below.

tried the latest build posted, it behaves way worse than the original engine on a p200mmx machine... seems this is targeted to beefier pcs

Not surprising really, Qbism targeted recent Core architecture by default. and never had an opportunity to do low-end testing. He couldn't see the drawback for sacking the assembly code

Attached an optimized build along with corresponding patch. Backup the original quake binary and cwsdpmi files, and then replace with those in the attached archive. Also, replace the super8.cfg with that in the archive. This version is for testing only and it has better performance.

Edit 2: removed binary since there is a newer build below.

Hi, this is my first time here. I finally got a chance to try your build on dosbox. It's amazing to see colored light on the DOS platform. I was able to build this with djgpp within dosbox (by renaming vsnprintf.c to 'vsnprint.c' due to 8 char filename limit). BTW, could a current full source code be posted? I attempted to apply the various patches in order but had some rejections.

Certain chunks of current super8 source would be beneficial, version190 on svn. The newer lighting calculation looks much better, and the drawspan functions are a tad faster.

The asm D_Drawspans16 and some of the other span functions could be brought back. It would likely be faster in DOS depending on how DJGPP optimizes the hand-tuned C functions. It would be interesting to see a comparison.

Sorry the patches didn't apply cleanly. Attached is an updated patch which applies against the source code in the original post and updates it to DOS-6o.

I tried the new lighting code but it generated a binary which reported a page fault error.

Attached a 2nd optimized build (DOS-7o) along with the corresponding patch. Backup the original quake binary and cwsdpmi files, and then replace with those from the attached archive. Also, replace the super8.cfg with that in the archive. This version is for testing only and it has better performance.

Edit 2: removed binary since there is a newer build below.

Attached another optimized build (DOS-7o-2) along with the corresponding patch. Updated runtime library from djgpp 2.03 to 2.04 and also included working music playback by CD audio (uses console commands not the menu items).

Backup the original quake binary and cwsdpmi files, and then replace with those from the attached archive. Also, replace the super8.cfg with that in the archive. This version is for testing only.

Edit: removed binary since there is a newer build below.

In a quick test, this is running faster. CD music is working.

leileilol wrote:

Not surprising really, Qbism targeted recent Core architecture by default. and never had an opportunity to do low-end testing. He couldn't see the drawback for sacking the assembly code

True, although now I've got access to a P4 XP machine for testing. (realizing Pentium 4 isn't exactly super-retro...) Recently asm is added back as a compiler switch option. A bit off-topic but may be helpful here.

Updated test build to DOS-8, including a built-in memory extender (wdosx) which replaces the external use of the cwsdpmi memory extender. Seems to increase in-game responsiveness. Also, adapted the music menu items for the updated cd audio function. Last, removed the unused fog code which should improve load times.

Refer to above posts on running the binary and other instructions.

Edit: removed the attached "qs8 DOS binary (build DOS-8 + no fog + wdosx memory extender)".

Depends on which Pentium 4. Willamette is 'super retro' because it's their hype backlash era when it didn't live up to Pentium III performance, except for optimized applications that did not exist at all at the time.

also truth you're calling your binaries "qbsim" 😀

The latest build is attached (qs8 DOS-9) along with an updated "super8.cfg" file. It is important to verify that the "fov" parameter is set to 90 and "snd_speed" set to 11025. These settings may be verified by viewing the super8.cfg file or the better method by viewing in-game (by typing the parameter name in the quake console). If you have a fast computer system, then the parameter "_snd_mixahead" may be changed to a lower value than 0.3, such as 0.15; it may produce a better sound. For typical systems, it is also suggested to set _vid_wait_override and vid_nopageflip to 0. The color lighting has several parameters, but two important ones are r_clcolorweight and r_clintensity; their values may be changed by 0.1 or 0.2 in either direction, but it is not recommended to change their values by a larger value, and verifying by restarting in an appropriate map with color lighting (such as e1m1).

I've tested other source code changes, such as reversion to assembly functions, but did not find a significant effect on performance. I now believe that the dynamic lighting and translucent water effects are the major bottlenecks in terms of performance and that they lessen any impact of some of the other assembly functions. The attached binary is fairly well optimized in this case and the impact of these added features is reasonable, perhaps the same impact of running vanilla quake without assembly optimization. It should be noted that these impacts vary within and between maps. These tests were done at 640x400 resolution, although it is possible to run at lower resolutions on slower systems.

Edit: attached patches (fpu precision and default particles); includes reversion to original particles, speed optimizations, and a correction to the ported color lighting code.

First of all, *bump*.

Second of all, I think that it would be an interesting project (that I would start if I had the time and/or skill) to try to write a quake engine specifically optimized for the 486. As I have heard, quake may well be the single most pentium-optimized game in existence. It would be cool to see what optimizations would be needed to make the game playable on lower end 486 hardware (meaning closer to 100 MHz than 133 MHz 😀 ).

Based on the Ultimate 486 Benchmark Comparison, I think that such an engine would be best suited by fixed point math, since the Pentium's ALU offered less improvement than its FPU.

meisterister wrote:

Second of all, I think that it would be an interesting project (that I would start if I had the time and/or skill) to try to write a quake engine specifically optimized for the 486.

I'd really like to see this. Here's some nice inspiration to get you going with someone doing an excellent job at 'porting' Quake2 to a inferior-to-486 computer 😀

Restricting resolution to <64K pixels like 320x200 allows the speed gain of fixed-point spans.

1/*==============================================
2// Fixed-point D_DrawSpans
3//PocketQuake- Dan East
4//fixed-point conversion- Jacco Biker
5//unrolled- mh, MK, qbism
6//============================================*/
7
8
9static int sdivzorig, sdivzstepv, sdivzstepu, sdivzstepu_fix;
10static int tdivzorig, tdivzstepv, tdivzstepu, tdivzstepu_fix;
11static int d_zistepu_fxp, d_zistepv_fxp, d_ziorigin_fxp;
12static int zistepu_fix;
13
14#define  FIXPOINTDIV 4194304.0f //qbism- thx to Dan East, Jacco Biker 
15
16//524288.0f is 13.19 fixed point
17// 2097152.0f is 11.21
18//4194304.0f is 10.22 (this is what PocketQuake used)
19//8388608.0f is 9.23
20
21void UpdateFixedPointVars16( int all )
22{
23	// JB: Store texture transformation matrix in fixed point vars
24	if (all)
25	{
26		sdivzorig = (int)(FIXPOINTDIV * d_sdivzorigin);
27		tdivzorig = (int)(FIXPOINTDIV * d_tdivzorigin);
28		sdivzstepv = (int)(FIXPOINTDIV * d_sdivzstepv);
29		tdivzstepv = (int)(FIXPOINTDIV * d_tdivzstepv);
30		sdivzstepu = (int)(FIXPOINTDIV * d_sdivzstepu);
31		sdivzstepu_fix = sdivzstepu*16;
32		tdivzstepu = (int)(FIXPOINTDIV * d_tdivzstepu);
33		tdivzstepu_fix = tdivzstepu*16;
34
35
36	}
37	d_ziorigin_fxp = (int)(FIXPOINTDIV * d_ziorigin);
38	d_zistepv_fxp = (int)(FIXPOINTDIV * d_zistepv );
39	d_zistepu_fxp = (int)(FIXPOINTDIV * d_zistepu );
40
41	zistepu_fix = d_zistepu_fxp * 16;
42}
43
44void D_DrawSpans16_FP (espan_t *pspan)  //qbism from PocketQuake
45{
46	int count, spancount, spancountminus1;
47	unsigned char *pbase, *pdest;
48	fixed16_t s, t;
49	int zi, sdivz, tdivz, sstep, tstep;
50	int snext, tnext;
51	pbase = (unsigned char *)cacheblock;
52	//Jacco Biker's fixed point conversion
53
54	// Recalc fixed point values
55	UpdateFixedPointVars16( 1 );
56	do
57	{
58		pdest = (unsigned char *)((byte *)d_viewbuffer + (screenwidth * pspan->v) + pspan->u);
59
60		// calculate the initial s/z, t/z, 1/z, s, and t and clamp

61		sdivz = sdivzorig + pspan->v * sdivzstepv + pspan->u * sdivzstepu;
62		tdivz = tdivzorig + pspan->v * tdivzstepv + pspan->u * tdivzstepu;
63		zi = d_ziorigin_fxp + pspan->v * d_zistepv_fxp + pspan->u * d_zistepu_fxp;
64		if (zi == 0) zi = 1;
65		s = (((sdivz << 8) / zi) << 8) + sadjust;	// 5.27 / 13.19 = 24.8 >> 8 = 16.16
66		if (s > bbextents) s = bbextents; else if (s < 0) s = 0;
67		t = (((tdivz << 8) / zi) << 8) + tadjust;
68		if (t > bbextentt) t = bbextentt; else if (t < 0) t = 0;
69
70		//End Jacco Biker mod
71
72      // Manoel Kasimier - begin
73      count = pspan->count >> 4;
74      spancount = pspan->count % 16;
75      // Manoel Kasimier - end
76//count = pspan->count;
77		//	if (count >= 16)
78			//	spancount = 16;
79			//else
80				//spancount = count;
81
82      while (count-- >0) // Manoel Kasimier
83      {
84			// calculate s/z, t/z, zi->fixed s and t at far end of span,
85			// calculate s and t steps across span by shifting
86				sdivz += sdivzstepu_fix;
87				tdivz += tdivzstepu_fix;
88				zi += zistepu_fix;
89				if (!zi) zi = 1;
90
91				snext = (((sdivz<<8)/zi)<<8)+sadjust;
92				if (snext > bbextents)
93					snext = bbextents;
94				else if (snext < 16)
95					snext = 16;	// prevent round-off error on <0 steps from causing overstepping & running off the edge of the texture
96
97				tnext = (((tdivz<<8)/zi)<<8) + tadjust;
98				if (tnext > bbextentt)
99					tnext = bbextentt;
100				else if (tnext < 16)
101					tnext = 16;	// guard against round-off error on <0 steps
102
103				sstep = (snext - s) >> 4;
104				tstep = (tnext - t) >> 4;
105
106         pdest += 16;
107         pdest[-16] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
108         pdest[-15] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
109         pdest[-14] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
110         pdest[-13] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
111         pdest[-12] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
112         pdest[-11] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
113         pdest[-10] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
114         pdest[ -9] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
115         pdest[ -8] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
116         pdest[ -7] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
117         pdest[ -6] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
118         pdest[ -5] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
119         pdest[ -4] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
120         pdest[ -3] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
121         pdest[ -2] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
122         pdest[ -1] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
123         // Manoel Kasimier - end
124
125         s = snext;
126         t = tnext;
127         // Manoel Kasimier - begin
128      }
129      if (spancount > 0)
130      {
131         // Manoel Kasimier - end
132			// calculate s/z, t/z, zi->fixed s and t at last pixel in span (so
133			// can't step off polygon), clamp, calculate s and t steps across
134			// span by division, biasing steps low so we don't run off the
135			// texture
136
137				spancountminus1 = spancount - 1;
138				sdivz += sdivzstepu * spancountminus1;
139				tdivz += tdivzstepu * spancountminus1;
140				zi += d_zistepu_fxp * spancountminus1;
141				//if (!zi) zi = 1;
142				//z = zi;//(float)0x10000 / zi;	// prescale to 16.16 fixed-point
143				snext = (((sdivz<<8) / zi)<<8) + sadjust;
144				if (snext > bbextents)
145					snext = bbextents;
146				else if (snext < 16)
147					snext = 16;	// prevent round-off error on <0 steps from causing overstepping & running off the edge of the texture
148
149				tnext = (((tdivz<<8) / zi)<<8) + tadjust;
150				if (tnext > bbextentt)
151					tnext = bbextentt;
152				else if (tnext < 16)
153					tnext = 16;	// guard against round-off error on <0 steps
154
155				if (spancount > 1)
156				{
157					sstep = ((snext - s)) / ((spancount - 1));
158					tstep = ((tnext - t)) / ((spancount - 1));
159				}
160
161
162         pdest += spancount;
163         switch (spancount)
164         {
165            case 16: pdest[-16] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
166            case 15: pdest[-15] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
167            case 14: pdest[-14] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
168            case 13: pdest[-13] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
169            case 12: pdest[-12] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
170            case 11: pdest[-11] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
171            case 10: pdest[-10] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
172            case  9: pdest[ -9] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
173            case  8: pdest[ -8] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
174            case  7: pdest[ -7] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
175            case  6: pdest[ -6] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
176            case  5: pdest[ -5] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
177            case  4: pdest[ -4] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
178            case  3: pdest[ -3] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
179            case  2: pdest[ -2] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
180            case  1: pdest[ -1] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
181            break;
182         }
183
184		}
185	} while ((pspan = pspan->pnext) != NULL);
186}
187