neozeed wrote:

oh I tried WSS, and it crashed out HARD... I just haven't had time to even start to see where it all goes wrong. it also locks on QEMU, and I haven't tested actual hardware yet.

In what usage WSS exactly crashed? I remeber there was some example playing a simple tone (should be in the package) and when choosing right soundcard it worked for me (intel ICH7 + Realtek ALC888). Did you tried that dos mplayer-does it crashed too? I understand that there may be issues with integration into game engine because of using INT handlers, timers, etc... And emulators may not always emulate correctly...

RayeR wrote:

Is there some Allegro mod that support newer soundcards?
You game porters, did you think about of using WSS http://rayer.g6.cz/download/wss.zip library for DJGPP (it's not my work, I just added some PCI IDs) that supports a lot of new intel HDAs? It was successfully used in mplayer dos port...

Some DOS sound drivers in Allegro slipped past quality control. With Adlib/FM bugged and SB Pro issues depending on the allegro version. Fortunately the source is there, so I fixed that. The MPU-401 driver works fine.
Later versions of Allegro support ESS Audiodrive and SoundScape. GUS support never got beyond planning. Finally there is a WSS driver, submitted by someone and then never properly tested on anything. It is on my todo list to fix this WSS driver one day, and then integrate it in my modified Allegro 3.0 here.
The file you mentioned may help yes, I actually already had it stored in my references folder.
So you are saying a slighly adjusted WSS driver works on intel HDA? What about Realtek I wonder..

Kinda off-topic, but someone's porting Quake 2 to the Atari Falcon, a machine with a 16MHz Motorolla 68030 😳 .

https://www.youtube.com/watch?v=7BBSOJudnvM

You can find more videos on his channel. Very impressive work.

Which by the way is crazy inspiring for some hardcore integer spans functions for 486 optimization.

Related, I tried to do a quake branch with bigger span subdivisions (32/64 pixels) but only got as far as having it working in C, couldn't hack it in ASM 🙁

Thought i'd poke this thread with part 4

http://virtuallyfun.superglobalmegacorp.com/2 … -to-ms-dos-pt4/

Still needs aspect forcing, because 320x400 looks freaking weird (expands the height too much)

leileilol wrote:

Still needs aspect forcing, because 320x400 looks freaking weird (expands the height too much)

You can make a branch then submit a pull request. Fooling around with aspect ratio and various shitty hardcoded values isn't my cup of tea.

We fixed the 320x240 planar mode only working on dosbox and voodoo cards. New version is available at: https://bitbucket.org/neozeed/q2dos/downloads … S_EXE_LATEST.7Z

Thank you. I look forward to using the updated binaries. I also recently tested crbot against your project and attached it. Patched against the "modified" original code here: http://arton.cunst.net/quake/crbot/. And original binaries here: http://arton.cunst.net/quake/crbot/CRBot114.zip (requires pak0 from q2ctf and *.txt files from CRBot114.zip). User accepts responsibility for use of archives.

Used this batch file for testing:
q2.exe +set game crbot +map q2ctf1 +set ctf 1 +set maxclients 8 +set deathmatch 1 +set cl_async 0 +set cl_predict 0

Edit: added optional patch to display short file names in crbot menu (dos only). This is for adding custom bots via the crbot menu only. The patch also includes a workaround for a limitation in dosbox where multiple wildcards are not recognized when searching files. An example is 'dir *.exe' versus 'dir *ymi*.exe'. These will find the same set of files which also affects the findfirst() function used in the menu code. However, I haven't verified whether this limitation is by design and inherent in an older version of dos.

What about on real dos based 386/486, any results compared to the same resolution Win based test? Should it run "better" compared the lack of the whole os?

don't

leileilol wrote:

don't

It will not run on a real dos system?

It will but the game barely chugs on a Pentium 1. You're just wasting your time.

The speed will probably be about the same, but there is one win32 ASM function for ref_soft that hasn't been ported to GAS and could give it a slight advantage. If it's borderline-unplayable already on Windows for you don't expect a miracle from Q2DOS.

hail-to-the-ryzen wrote:

Thank you. I look forward to using the updated binaries. I also recently tested crbot against your project and attached it. Patc […]
Show full quote

Thank you. I look forward to using the updated binaries. I also recently tested crbot against your project and attached it. Patched against the "modified" original code here: http://arton.cunst.net/quake/crbot/. And original binaries here: http://arton.cunst.net/quake/crbot/CRBot114.zip (requires pak0 from q2ctf and *.txt files from CRBot114.zip). User accepts responsibility for use of archives.

Used this batch file for testing:
q2.exe +set game crbot +map q2ctf1 +set ctf 1 +set maxclients 8 +set deathmatch 1 +set cl_async 0 +set cl_predict 0

Edit: added optional patch to display short file names in crbot menu (dos only). This is for adding custom bots via the crbot menu only. The patch also includes a workaround for a limitation in dosbox where multiple wildcards are not recognized when searching files. An example is 'dir *.exe' versus 'dir *ymi*.exe'. These will find the same set of files which also affects the findfirst() function used in the menu code. However, I haven't verified whether this limitation is by design and inherent in an older version of dos.

Thanks. I never personally played this mod but it's good to see you were able to easily port it.
Is it necessary to set cl_async and cl_predict to 0? Why did you do that? The QuakeWorld and Quake 2 engines have terrible movement when cl_predict 0 is set.

Maraakate wrote:

The speed will probably be about the same, but there is one win32 ASM function for ref_soft that hasn't been ported to GAS and could give it a slight advantage. If it's borderline-unplayable already on Windows for you don't expect a miracle from Q2DOS.

Ok, I wasn't expecting lot of speed obviously compared to the already slow 386/486 Quake dos experience. 😉

For kicks I put a Voodoo 1 in my P1 166 MMX machine and basically it's about as slow as ref_soft except that now you have the additional advantage the coloured lighting, etc.

I mainly followed the instructions in your porting guide. And I set cl_async and cl_predict to 0 for testing under low framerates (<7 fps). I recall that cl_predict=1 had less smooth gameplay in that case. Once the fps was at a playable rate, then it was not possible to see this effect. However, I was only testing one or two mods under the software renderer.

I also found it interesting in reading that the software renderer is much more tolerant to low framerates than opengl. I don't know much about this though.

cl_async will have problems if the framerate drops below net_maxfps CVAR. If you're on a computer that struggles to maintain 60fps on average set cl_async to 0.

Its shame that its not working with EMS, because lots of sound drivers are EMS only, otherwise its running fine in 1600x1200..

I tried Q2DOS with DR-DOS 7.0.1 its working fine, even in Virtual machines - Vmware / Virtualbox, but there is problem with timedemo, user input is always detected and timedemo ends right after start (with MS-DOS its fine).. I just wanted to compare DR-DOS and MS-DOS performance.. game speed on my overpowered Core 2 Duo + VIA 880 ultra MB.