VOGONS


Quake2 + Acebot for DOSBox (128mb)

Topic actions

Reply 420 of 862, by ggorts_

User metadata
Rank Newbie
Rank
Newbie

Best of luck in your project!

Reply 421 of 862, by szo

User metadata
Rank Newbie
Rank
Newbie
ggorts_ wrote:

I think these are correct: grLfbReadRegionOrigin.

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

Reply 422 of 862, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 423 of 862, by Stiletto

User metadata
Rank l33t++
Rank
l33t++

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

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 424 of 862, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 425 of 862, by _ggorts

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 426 of 862, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

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

Last edited by Maraakate on 2015-08-08, 15:17. Edited 1 time in total.

Reply 427 of 862, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 428 of 862, by _ggorts

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 429 of 862, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 430 of 862, by _ggorts

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 431 of 862, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 432 of 862, by _ggorts

User metadata
Rank Newbie
Rank
Newbie

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).

Reply 433 of 862, by leileilol

User metadata
Rank l33t++
Rank
l33t++

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.

apsosig.png
long live PCem

Reply 434 of 862, by _ggorts

User metadata
Rank Newbie
Rank
Newbie

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).

Reply 435 of 862, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

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?

Reply 436 of 862, by _ggorts

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 437 of 862, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 438 of 862, by _ggorts

User metadata
Rank Newbie
Rank
Newbie

That is a good idea to test his code.

Reply 439 of 862, by _ggorts

User metadata
Rank Newbie
Rank
Newbie

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.

Last edited by _ggorts on 2015-08-14, 03:08. Edited 1 time in total.