This (DOS) port is excellent! I believe there was a lot of work toward performance in colored lighting (in C language). I also like the filtering effect (N64?) and the other visual enhancements, although this port also includes additional audio features.

I know there is some cross-talk among these major quake1 projects. I was wondering the non-obvious differences between the DOS ports of qbism (build 46) and engoo (228d), particularly in reference to loading them in dosbox.

The current version *could* be fixed to work in DOS again, but that would require intense regression testing between various revisions (segfaults during lookup generation). The DOS version broke around when water reflections were added.

There was more optimization for colored lighting since 228d, since I reimplemented 15bpp colored lighting by using just only lookup tables.

I didn't realize the scope of the optimizations and the testing involved. A current dosbox build with patches is running engoo at a good frame rate, much higher than I expected while the colored lighting is active. I noted the testing and difficulty in reducing its color space. The many other optimized features are running especially well, such as the visually appealing filtering effect. It rivals the visual quality implemented for H2's renderer. I wonder if it is possible to backport the updated colored lighting code to the last robust DOS version. I also wonder if profile guided optimization is possible on a DOS build.

The only unique, interesting feature in DOS build 46 of QS, at least that I identified so far, is the raised memory handling for large maps, although this feature is not that necessary for use in dosbox. Also, I assume build 46's network code was not actively tested by others, whereas engoo has had a real DOS focus, so it must have had much more extensive network testing. His music additions are not crucial, so I thought that engoo is the definitive quake dos port, apart from using the original released by ID.

In case anyone wants to git fork or something, this is there.

Thanks for the information. I eventually built qs8 builds 46 and 53 after extensive modifications to source files and makefile, and I confirmed the segfault problem in the build with colored lighting. Increasing dosbox memory to 128mb helped to load quake when using the -mem switch, but the segfault problem could still occur. I assume that your binary is optimized and adding further features to the DOS port is not easily done without rewriting algorithms.

In the case of qs8, I had the different versions in source code. However, I noted your current versioning system is recent and 228d wasn't specifically present, at least that I could find. If the current optimization for colored lighting is significant, then I hope you would consider adding just that part to 228d, if it's at all possible and it's not expected to lead to segfaults. 😀

Edit: I made extensive changes and built the latest version of engoo for dos. It shows a page fault problem after generation of the lookup tables. 🙁 The output suggests limited memory as a cause, although I'd have to verify.

I am lost why it faults there as well since it seems to suddenly generate the 15bpp lookup twice. You'd probably have to do some process of elimination

I also wanted to detect the CPU speed at that part so it would skip the 18bpp generation by default and process the other lookup tables using the 15bpp lookup table if the CPU is less than 300mhz. on a 486, the 15bpp table generates quickly, but 18bpp adds minutes to startup

I think you provided excellent command line parameters for those settings anyways. I also built qs build 48 for dos, but this time I built it properly. 😀 It used your colored lighting code with possible modification (the start of e1m1 shows it best; verified r_coloredlights in console). I think this version has other code from engoo, too. If you're interested, I'll send it by PM.

I was planning on adding bits to this one since it built with assembler sources along with makefile and source file changes. It would be somewhat simple to add pieces one at a time from qs' SVN repository.

It built by this brief guide, excluding the source changes:

1copy qbism build 48 source code into c:\Quake\
2copy development environment to c:\Quake\GCC\ (https://sites.google.com/site/rugxulo; DJGPP203.7Z)
3copy snprintf.c to c:\Quake\
4bash shell and other utils: bsh204br3.zip;fil41b.zip;sed421b.zip; ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/
5run xp cmd shell and then DJGPP.BAT from above development environment (xp ntvdm works, other windows may not)
6run bash (type bash)
7make -f MAKEFILE
8.lit files to \ID\maps\: http://www.quaketastic.com/upload/files/misc/ID1_LIT_Pack_14th_May_2009.zip
9to run game: quake -mem 46 -heap 100000

the qbismSuper8 lighitng methods are completely different than Engoo. qbism uses some intensity/hue lookup, incidentally the resulting lightmap looks similar to PowerVR PCX2 running Quake2.

I tried to add qs8 code bits to build 48, including commits #49 through #59, and they led to the page fault problem as discussed previously. It's caused by either the dithering table, turbulent8 asm, added audio asm, or another code fragment. I assume that adding new features is not easily supported by the DOS memory model.

Edit: with engoo v228d source code, and ability to reproduce a working dos binary, it may not be too difficult to find the differences between v228d and the current engoo version. Then, code bits could be added which correspond to the newer dynamic lighting code until reproducing (or not reproducing) the "duplicate generation of the 15bpp lookup table". I also should have mentioned earlier that the older v228d (dynamic) colored lighting only worked without the -no18 parameter - adding it led to inability to see world textures.

The colored lighting appeared very different between engoo and qbism, but I assumed that qbism employed some heuristic. In retrospect, your colored lighting method certainly seems closer to a realistic model.

Since adding any code fragments to qs8 build 48 (or engoo?) is causing page faults, and this has been reproduced a few times, it may be reasonable to think that both versions are running against limited memory. I've seen conflicting ideas as to whether another compiler would help a memory situation.

I'm sure this has been thought about, but is there a way, if it hasn't been done already, to employ the existing assembly code in any colored lighting code?

No, unless you somehow can study the differences between in r_surf.c's functions R_DrawSurfaceBlock8_mip0, and then compare Surf8.s, and try to apply the differnces of R_DrawSurfaceBlock8_mip0 and D_DrawSurfaceBlock888RGBX_mip0 to Surf8.s as a surf8rgb.s file.

Assembly scares me, which is why I didn't do that. I tried to retain as much of the assembly as I could however (DrawSpans16 being the important one to keep). Qbism excises assembly completely.

it's important to note the change of license on qbism if you're going to port code back. Qbism is GPLv3, Engoo is GPLv2 and I want to keep it v2.

In addition to colored lighting assembly, it could be possible to port fog to the assembly drawspans functions as well. My fog method is fast and simple enough to do this. Speaking of which, Qbism has fog but is slower because its method is by reading the screen pixels and their Z. My method uses a lookup table along the spans of models and walls, and this lookup table is generated on map load with a fog parameter specified

OT grumble: It should be possible to port Q3 to DOS as well... Q3A uses a QVM system for client/game/ui logic so there's less native code to deal with compared to Quake2, and TinyGL could possibly be beaten to become the software renderer. Several renderer-based changes would have to be done to fit closer to the memory restrictions like giving TinyGL indexed rendering, swizzling down all 24/32-bit textures to paletted on load, using vertex lighting only (saving memory for lightmaps which would look bad indexed anyway). "modern port stuff" like Ogg, Speex, SDL, etc. would need to be scrapped however.

Thank you for lighting the path. 😀 I now think the C compiler is producing fairly efficient machine code in most cases, although the x86 audio functions seemed to provide better performance, even if this is a subjective result. However, your method of using a lookup table, along with other heuristics, is a much preferable way to resolve any speed and memory issues. I'll try to look over those functions in r_surf and surf8.

That's a good suggestion to next examine the fog code. I appreciate the information on how the different fog methods work. If it's reasonable, I think we could test your fog code against the build, even if the result isn't released.

That's especially interesting on the possibility of porting Q3 to dos via TinyGL. It would be interesting to examine the software which currently uses TinyGL. Likewise, I have been wondering whether glquake could port to dos glide, although this must have been considered by others.

Trying to fix it a little.......

I went through many revisions. 243 is the last 'stable' DOS revision. 244 regresses it slightly with the addition of 24bit texture loading support (can be fixed in d_surf.c, conveniently located around the // DEBUG comment), but that's not the culprit for 277's crashes...

I need a good debugger to really find where this crash is happening. I can't seem to get started with RHIDE, and fsdb blackscreens when a crash happens...

Have you tried this method: http://www.delorie.com/djgpp/v2faq/faq12_2.html.

Very cool. Good job on this, I cannot wait to try it out!

More screenshots?

It's been released 10 months ago. I haven't really worked on this in 2014 at all, being focused on something else critical.

.

I honestly think I like the look of this over the darkplaces look.

Are you planning to add support for ogg, or other audio formats. I read in the text file cd audio can causes crashes.

I originally wanted to support mod/s3m/it/xm through the Dumb library, which would also lead the way for Ogg support since there's a dumb_ogg module for that (read: ogg music in dos)

Where's the damn crosshair!!! 😁

Man, this is *amazing* but there are some problems with reflections and BSP.....sometimes I got the reflection of entire map parts (not supposed to be reflected in the bloody murky quaky water 😁)