Also, I went ahead and added the 3d camera to the extended options menu and added CVAR descriptions for them. Will upload new binary shortly.

In any case, apart from Abrash himself, I wonder how many could even use ASM to outperform the C compiler in order to correct for special effects.

Thanks for the 3d camera additions! I think it's a benign feature and I think some mods can use it.

Also can you update the first post to point to this download link: https://bitbucket.org/neozeed/q2dos/downloads … S_EXE_LATEST.7Z

Thanks

Of course.

Maraakate wrote:

That's the other issue and I'm sure leileilol has ran into the same problems. If you start fooling with the software renderer it really pays to know ASM which I know nothing about. On modern computers it's not such a big deal, but for the target machines I'm aiming for (about the same target hardware as original Quake 2) it can become a huge setback.

I know nothing about ASM either and I tried to retain as much Abrashness as I could. Engoo was still playable on Pentiums with 8->RGB->15->8 lookup colored lighting and the ASM DrawSpans. It even compiled for DOS until around when I started to fix 15bpp colored lighting and add water reflections. Given my horrid pipeline with DJGPP (A Win98SE VirtualPC VM used for compiling) I didn't bother fixing that and time was slipping. I haven't tried the latest optimized lookup table colored lighting code on Pentium, but it does certainly fly on Pentium M.

Apologies for sidetracking the thread a little with my featurecreep anecdotes, there's little places where I feel like I could discuss software renderer stuff at all nowadays. Also there's little places in Q2 where you could even stick Engoo code in anyway, I did try with lighting, which Qbism then forked off and completed the thing. I didn't like it because I hacked model lighting to take a ambient color blend on a mono model instead of a true lighting blend which looks really ugly please disregard the overbrights as the lighting looks better in software after it's shifted down and gammaed like q2 gl through 3dfxvgl and I wanted to see results immediately ok i think i'm done now carry on dosq2ing goodluck with the pentium target which should be possible as SiN did it

Many of the quake2 math functions are resolved by gcc and the djgpp libraries. However, an alternative is here: https://github.com/jwhitham/Quake-2/commit/8e … 8ae3c37edb98d60. The functions are in assembly language and may be worth trying to compare the performance to without. Also, he has another patch to use single-precision floats for some of the functions in the quake2 code here: https://github.com/jwhitham/Quake-2/commit/7a … c7ccfcad64b3052.

Update: seems quake2 is dependent on djgpp math.h and libm. Use of libc math led to low fps in-game, even though the timedemo runs as expected. The single-precision patch did not show a significant effect, but I added it anyways.

Second, the TGA textures are working well in the skybox and elsewhere. I wonder whether any dithering issues are related to a 32-bit TGA image rather than 24-bit which the code asks for. It could be that the 32-bit TGA wouldn't load, but I have not verified yet.

Along these lines, there are textures which seem to appear as mirrors in Action Quake 2 maps, particularly "museum" for one of the sculptures in-game. This occurs in both gl and software renderer mode.

Update: verified using a map editor that the sculpture in "museum" is actually correctly textured.

Also, it may be worth making a note of this "animated textures" patch (actually tuned for opengl): https://github.com/jwhitham/Quake-2/commit/52 … acf95aa1853ccf2.

Started to experiment with banked SVGA mode so that Q2Dos runs in Windows NTVDM. Attached is an incomplete patch which results in a single complete image to screen (using dosbox-x). It may provide hints toward a 640x480 banked mode.

A good start but I am confused about:

int todo=307199; //307200;

and

regs.x.es = (ptr2real(pinfoblock) >> 4) & 0xFFFF;
regs.x.di = ptr2real(pinfoblock) & 0xf;
__dpmi_int(0x10, &regs);

/* quit if there was an error */
if (regs.h.ah)
return;

I went ahead and added some partial code (does nothing yet), by adding qboolean isBanked to use your codebase if it is indeed banked. However, is there some way to detect a banked supported mode?

Also, you need to get me specific examples of this slowdown with different math libraries so we can look into it.

Also, recently sezero found out that I was accidentally using the old broken Rhapsody code for Hunk management. He fixed it to use linux code and now the game usually can run in 48mb RAM (minus larger mods). Memory management is a lot better now. Naturally, this build is already uploaded.

There was also a bug using OpenGL's WAL code that was screwing up the mipmapping that has been fixed alos.

Okay, I got banked mode working in 640x480. It's only an option if the mode is already available in LFB. You have to use -bankedvga to test it. I have to figure out how to set the total view display properly (your code is hardcoding it to 640x480 presently so any other mode is that window size) and to make a banked VGA mode table as well.

Maraakate wrote:

A good start but I am confused about: […]
Show full quote

A good start but I am confused about:

int todo=307199; //307200;

and

regs.x.es = (ptr2real(pinfoblock) >> 4) & 0xFFFF;
regs.x.di = ptr2real(pinfoblock) & 0xf;
__dpmi_int(0x10, &regs);

/* quit if there was an error */
if (regs.h.ah)
return;

I went ahead and added some partial code (does nothing yet), by adding qboolean isBanked to use your codebase if it is indeed banked. However, is there some way to detect a banked supported mode?

Also, you need to get me specific examples of this slowdown with different math libraries so we can look into it.

It was coded for 640x480 to control other variables that may break it testing, such as "vesa detection". It seemed like the vesa detection was harder to implement than the actual drawing! I see now you made great progress, thanks!

I think it should be 307200, but I tried swapping it with 307199, too (these two values were used between different tutorials).

I saw this in the djgpp tutorials: regs.x.es = (ptr2real(pinfoblock) >> 4) & 0xFFFF;. However, it is possible that they made an error and the current code is correct. I don't know whether that register is masked for sure.

The math libraries: I tried removing libm and using libc only. The game runs as 1fps. :) I also tried removing the gcc built-in libs, given they don't refer to libc. I found both alternatives slower during the working demotest anyways, so even if they worked in-game, it may not be worth spending time on. It's a global problem discussed but perhaps an academic exercise at this time?

Maraakate wrote:

Also, recently sezero found out that I was accidentally using the old broken Rhapsody code for Hunk management. He fixed it to use linux code and now the game usually can run in 48mb RAM (minus larger mods). Memory management is a lot better now. Naturally, this build is already uploaded.

There was also a bug using OpenGL's WAL code that was screwing up the mipmapping that has been fixed alos.

I tried sezero's hunk management code and it seemed not as stable as the original. I tried several other code bits for that section, including Gilder's (spelling?) branch and arrived at what I think is a better alternative. It's attached, but against the older code in terms of patching.

I also didn't see much memory savings in sezero's patch, although the realloc function helped in some cases. The aq2 mod with bots still required 96mb or so, perhaps a 24mb savings, but I looked carefully and the realloc function seems redundant, but I am far from sure. The attached code may have the same savings.

Thanks for the mipmapping fix! I think I took that commit and tested it. Your TGA commits work perfectly! I tried many aq2 maps and they would have broken if there was any issue. I did start to look at WODX mod issue, but the WOD code is open source only? I could take a look at a model in one of the editors and see the problem if it's not already identified?

Maraakate wrote:

Okay, I got banked mode working in 640x480. It's only an option if the mode is already available in LFB. You have to use -bankedvga to test it. I have to figure out how to set the total view display properly (your code is hardcoding it to 640x480 presently so any other mode is that window size) and to make a banked VGA mode table as well.

That's great work! That's the key to running in full-screen ntvdm and dosemu/linux! I don't think ntvdm's support anything lower and they are missing registers for vesa, so they may not even pass detection routines (probably could use testing). :)

I'm not planning to add NTVDM or any other windows support for these reasons:
* Sound Blaster will not work right in it, there is no purpose.
* UCLOCK doesn't work right in NTVDM. This bring me also to:
* Using Linux clock will screw up and the clock speeds up/slows down randomly.

The only advantage I see is being able to not use an emulator so it would be much faster. Just make a bootable USB DOS if this your concern.

I fixed the viewsize window. Now a table needs to be added with common resolutions. I think 320x240, 640x480, 800x600 and 1024x768 are decent ones to support in banked mode.

In DOS, in theory you should be able to run univbe on an ancient card to get the banked modes. I'll have to look at quake 1 and see how they specifically hardcoded 320x240 banked mode to be added to the available modes list.

ggorts wrote:

I also didn't see much memory savings in sezero's patch, although the realloc function helped in some cases. The aq2 mod with bots still required 96mb or so, perhaps a 24mb savings, but I looked carefully and the realloc function seems redundant, but I am far from sure. The attached code may have the same savings.

There should be nothing wrong with this code. It's what is used for Solaris and I have personally tested it multiple times over on real hardware and it does save RAM. Run memstats to see.

ggorts wrote:

I did start to look at WODX mod issue, but the WOD code is open source only? I could take a look at a model in one of the editors and see the problem if it's not already identified?

WOD-X I don't believe has a source code release. In any case, it's a problem specific to Whale's WOD with his over abuse of custom random models, skins, and textures. The worst part is I found crashes sometimes but can't reliably reproduce them. It may take a long time to find a specific issue that triggers it. He also has bad WAL and skin.pcx files that don't care about proper translucency. When I talked to him about it he basically laughed at me for using software mode.

That's very helpful information on the lack of emulation. At least the banked modes will have some use. I can find the vesa modes and the mode-x may have a FAQ associated with it.

I wouldn't be surprised if those custom models and such also cause issues in Windows. There is a way to set a parameter in Q2Dos code where the null pointers are not causing a page fault. That may be interesting to try and verify whether that helps?

I only tested in dosbox, but I found the above patch to be efficient and report similar memstats to the current one.

Edit:
I see you already have these modes: https://en.wikipedia.org/wiki/VESA_BIOS#Modes … defined_by_VESA.
640×480 800×600 1024×768 1280×1024
257 (0101h) 259 (0103h) 261 (0105h) 263 (0107h)

This may help toward mode-x: http://www.brackeen.com/vga/unchain.html.

For now we'll keep the Solaris as sezero has more experience with such things. Unless you can prove specific instability and performance decrease examples compared to the Solaris code.

I was looking at that tutorial earlier. Quake 1 already has this code, I was unsure of it's purpose but good to know. My plan is to just hardcode 320x240 using that method (if I can figure it out!) and have the other SVGA modes as well by default. The SVGA modes should be no issue because the mode numbers are standard. I'm not going to bother adding in the exotic weird modes like 320x256, etc.

I agree. Also, thanks for adding the Quake 1 code for study. I'll look it over, too.