you’ll have to build a test program to look @ the mouse. I just vaguely recall mice count their measurements in mickeys. (haha).

I’m not too worried about the sound just yet. But it’d be nice to have sound on my xeon.

Yes, I belive you that with djdev 2.03 it works. I also tried your binary from 15.6. and it connects to server and I can play fine.
But for my other project I need to keep quite recent libC so I used djdev 2.04 many years ago and now a month ago moved to 2.05. Maybe I have some backup of older djgpp toolchain but there must be a way to fix it to move forward. I hope that someone from djgpp groups could help with it. I never worked on djdev I just use it… I suspect some constant in some header are defined differently in quake2 and wattcp or so…

Yes, ct mouse driver provides wheel functionality (it /O parameter is used) and the mouse library have to be modified to be able to read such event. But I didn’t tried in Hexen II yes if it works there.

About WSS – can you try some real HW? What changes Ruslan did on it? I don’t know him. I don’t know if someone else touched WSS sourcers for recent 2 years except that DMP used WSS to add HDA support for their Vortex86EX (86duino) but as it’s not maintained they didn’t send back.

Its DJGPP’s 2.05 libraries that conflict with wattcp. Downgrade to 2.03, and it’ll work fine. I use GCC 2.95.3 of all ancient things, and it works fine.

I don’t know about the mouse wheel, I guess it’s a matter if the driver supports the mouse. I’ve been messing with WSS, and the good news is that I can load and unload OK. The bad news is that I only get noise. Hopefully Ruslan will share his modifications (GPL and all that) so we can all benefit.

I tried the mouse wheel functionality but doesn’t work for me – I cannot bind it in custom config. While in Arachne works fine.

Then I tried the networking (under real DOS, I luckily have NIC driver) and as you said I got ioctl error 🙁
http://rayer.g6.cz/1tmp/quake2tcp.png
But it was able to get a server list so it cannot be completly wrong.

I tried so hard many hours tonigt but didn’t make it working. First to tell I rather use GCC 4.8.4 because GCC 5.1.0 may introduce aditional issues like different inline behavior between c11 and c99 (issues with ntohl where extern __inline__ need to be updated to _EXTERN_INLINE to add __attribute__ ((__gnu_inline__)) for proper GCC version). So with 4.8.4 + djdev 2.05 I had less problems but…

I 1st tried to use my wattcp 2.2 release 10 that I compiled 2 years ago with current djdev 2.04 and gcc 4.7.3. I tries various test programs like ping, trace… that came with library and it worked. I linked this libwatt.a with quake2 and it gives same ioctl errors. I tried it to recompile with my current 4.8.4/2.05 but the same.
2nd I found wattcp 2.2 release 10 source and lib packages in djgpp repository: ftp://ftp.delorie.com/pub/djgpp/beta/v2tk/
and again I tried linking and then full configure and compiling but still the same.

So it lead me to think about the problem is not in wattcp itself but in quake2 networking code that interfaces wattcp library and it may happen that it compile differently with 2.03 and 2.04/2.05.
Anyway because of different error codes always the right version of wattcp have to be used against djdev version – I mean the djgpp.err file. We really shouldn’t mix 2.03 and 2.04 libs and code.

Are there some other libraries that quake2 use dependent on wattcp? I think curl maybe so I recompiled it too but still the same.
So I’m out of ideas what else to try.
Of course one should grab all the bunch of warning that occurs during quake2 compilation and carefully analyze them if some are related to wattcp code…

I also found hardcoded resolution constants and redefined them to
#define MAXWIDTH 1920
#define MAXHEIGHT 1200
New modes was found and works 🙂

Yes, finds functionality changed. Look at the DJGPP mail list, a week or so ago someone recommended another way to do it that worked OK.

If you get it compiling OK test connecting to servers, because Jason had trouble with ioctl.

hm, there’s no dj_err.c anyway in your package…
So I simply copied djerr.204 -> djgpp.err and this sort of redefine errors has gone. It still produces a lot of various warnings (types, signedness, unused vars, uninitialized vard) but the q2.exe is done.

Also make clean doesn’t work. I guess that instead of
find ./ -name ‘*.o’ -exec rm {} \;
there could be used some racursion parameter to rm ro delete all *.in the tree.

Aha, the bracket eater, well I mean
#include_next [sys/cdefs.h]
where [ is arrow brackets

Grr, the line should be
#include_next

I found that djgpp.err is generated by dj_err.exe from wattcp\util\ and it seems to be recompiled with djdev 2.05 but I don’t have installed slang library to do so and cannot find the prebuilt, sh configure from sourcers fail as usually… :\
But I could fix djgpp.err manually for now…