Best of luck in your project!

ggorts_ wrote:

I think these are correct: grLfbReadRegionOrigin.

Yes they are. And the wrong changes are _critical_ mistakes.

szo wrote:

ggorts_ wrote:

I think these are correct: grLfbReadRegionOrigin.

Yes they are. And the wrong changes are _critical_ mistakes.

Especially in DOS where one mistake can really blow up in your face and can be hard to debug.

Thanks guys for looking into Glide support 😁
If successful this will probably be the first Glide "homebrew" project in quite some time...

Well, I tried one of the tutorial programs from http://www.voodooland.org/programming/Tuturia … rammierung.html and with a couple of windows-specific removals it works just fine. One of the sources has some code as well for TGA and PCX loading so I guess it's time to start trying to skeleton out ref_gl and see if I can get anything to draw when switching to that driver and exiting out.

Built Mesa3d (fxmesa/opengl) by djgpp204/gcc295 and attached an archive with the headers, libraries, and sample demos. This DOS build is specific for the Voodoo 1 and includes hardware acceleration as demonstrated by the included demos. For example, the djgpp204/gcc295 development environment can use the libgl.a library and header files to build software which uses an early version of opengl (confirmed by the header files).

Also, built a Q2Dos binary with the ref_gl and fxmesa statically linked. It builds without error but further modifications are required, such as adaptation of the linux initialization functions (glimp_*) for dos and modification of vid_dos.

I built mesa3d awhile ago for voodoo 5 and after I though I sorted all the glimp_* linux crud out the game would hard lock as soon as the mode was set. Now, I skipped entirely past the vid_dos stuff making sure my SVGA code wasn't clashing with it but r_mode would fail to set in that particular case. I think I tried addressing it directly with the appropriate glide routines but got the hardlocks so who knows.

In Quake 2's released source code there are two gl related files you probably want to use gl_fxmesa.c which is used for Mesa and Glide and qgl_linux.c

To be fair, I didn't even run the test programs so I may have built it wrong.

Thank you for the hints. It is helpful to confirm which functions are necessary, to avoid too much testing. It may be reasonable to log every function near to renderer initialization to find the cause. I wonder if it is possible to use the glut library to help initialize the renderer, even if glut is not useful after that step in the code.

Can you build a version for voodoo 5 with the test utilities and I can report back if they even work at all?

Another to check out is if nearptr_disable is being used at all, which I didn't check yet, but if it exists it will have to go because of the sound engine.

That's insightful. I haven't yet tested changes to the memory model.

Also, I'll work on that build for V5.

Another problem is long-term preservation of maps (and mods) which have modified "game" directories without availability of their source code changes. I think we have a workaround for many of these cases which involves the use of win32 q2dos with hdpmi/hxgui (soundblaster 16 only), where this combination is compatible with vanilla dosbox (and presumably pure dos).

Attached is the package which was built by VC42 and a single thread model. The q2dos binary is modified for hdpmi, but there is also the unmodified binary which is especially compatible with 9x inside dosbox (and probably PCem, too). It runs much faster and more stable than the vanilla versions of q2, although this is mainly attributed to q2dos itself.

This binary is for single player only, although some multiplayer mods with bots seem to work where the bot match is on the local computer only.

Two parameters are necessary to start q2dos in this way:
quake2.exe +set vid_fullscreen 0 +set vid_ypos 0

The other parameters for a custom map or mod are appended to the above command line, as typically done.

I already knew that you could run quake2 in hdpmi. The fact that only sb16 works and that it must be high DMA was part of the reason neozeed and I began porting it to DOS.

Have been testing qbism's software renderer code in q2dos and noted an issue with djgpp204/gcc295 versus djgpp205/gcc484. Some malloc errors were reported by the q2dos code while building with djgpp204/gcc295, so a VirtualAlloc error would occur where the memory allocation failed for some unknown cause. However, the djgpp205/gcc484 build would page fault instead. There are many reasons why this could occur, but it is worth noting where testing code changes which involve both memory allocation and error in a page fault; in these cases, it may be worth testing with djgpp204, too.

I think that the qbism software renderer is not yet compatible with dos. I've seen these errors before and they are usually associated with use of static arrays (or freeing memory without the corresponding malloc call). The static arrays may have to be reworked, but I'll leave this work to another. 😀

Also, I've been building the different versions of fxmesa/sst1 and noted that the C path produces better demo results than the ASM path, particularly in displaying the "quad". In addition, with my current build environment, it was problematic in building above cvg (such as h5) because of the threading model used. I haven't yet found source code for a simple opengl/glut game; this would be a good test of fxmesa before considering its use beyond demos (in dos builds by djgpp).

Weird, because the qbism software stuff is based on my engoo stuff which did work under DOS at one point (using a very old djgpp/gcc from 2000ish). Generally what it would need to malloc is a lookup table for 15to8 or 18to8, the latter which can be a little expensive. The surfacecache shouldn't need changing and neither should the drawspans.

I wouldn't recommend 15to8 because Quake2 has a lot of dark lighting that 15-bit precision will utterly destroy.

Attached qbism's deluxe software renderer (credits to leilei) for q2dos. However, it requires the "q2dos-w32.zip" archive posted above, which contains a special q2dos client and the required hdpmi/hxgui files for DOS compatibility. Once that special q2dos client is setup, then replace the software renderer (ref_soft.dll) with the one in the attached archive (ref_soft_deluxe.zip). This is for fast DOS systems, probably P4 or higher (no Abrash optimizations in addition to the colored lighting).

Using hpdmi kind of defeats the whole point. Youre just running WinQuake in DOS again. If you can figure out the malloc issues I can add the software renderer as an option... are they asserts or page faults pointing to mallocs or are they Z_Alloc errors?

Mainly page faults associated with the code additions in this quake2 renderer. The discussion above referred to a related quake1 renderer, and qbism made further changes to it, so I don't know that there is easily referenced code toward the port to quake2 specifically for dos (q2dos).

I was mainly testing this renderer's performance level by use of hdpmi; if the performance cost was minimal, then I would have continued the effort. I also was testing any memory constraints on the quake2 engine in dos, so any memory problems would be apparent in porting opengl code.

I thought that this was a quake 2 renderer. In any case, https://github.com/jwhitham/quake2, this project has an updated software renderer (non-optimzed) that I believe has options for colorued lighting and such. I assume it can be readapted with some small work as a separate renderer... though I haven't tried it or looked at it too much. If you're planning to fool with ancient DJGPP versions you'll need to come up with a stdint.h since this guy is serious about 64-bit compatibility.

That is a good idea to test his code.

Working on dynamically linked software renderer (qbism's web site) so it works with q2dos. The static build isn't useful except for testing.

Edit: removed test binary. Official releases of q2dos are available at their bitbucket web site.