I took the unix timer code, and got that working (not surprising, NeXTSTEP still is 4.3 BSD at heart), and I fixed enough of the key bindings so it’s getting playable. In addition I went back through the WinQuake source and pulled out the BSD networking and that works great. There was a sound driver in there for the next, but it lacks the output functions…. So it would seem that’s the last thing to hack through for a more ‘complete’ Quake experience.. well that & the mouse.
I’ll probably dig around to find out how to make one of those nifty NeXT packages, and release a test version since it’s playable ‘enough’…
At least the video is kind of working… Right now I’m still using the cannibalized stuff from the UAE project’s port to NeXTSTEP. This is what I used for Frontier, although I’d like to think I’m getting a slightly better handle on it. Right now I just have to figure out why my keyDown & keyUP handlers are not working…. And implement the timer so it doesn’t run at warp speed. With the timer in place it should be able to do network play.
I suspect this would be FAR too slow to play on the m68k,Sparc or HPPA hardware but then who knows… My monitor for my m68k is broken so I can’t run it to find out…
This runs VERY fast on Qemu 0.90 I may have to rewire some stuff to run in on my whitebox, but I have a feeling I’m going to have to re-install… I forget where I left off on my NeXTSTEP setup on the old P4.
Anyways that’s what I have for the last few hours….
Ok, the machine I’m going to test this on, is a Vista x64 machine (I know I just couldn’t be bothered to upgrade it yet).
The CPU is an Intel Core2 Quad Q9300 running @ 2.50Ghz, with 8GB of ram.
The “Windows Experience Index” is 5.9 (It’s 5.9 across the board).
I’m using a redo of the SDL port of Quake 1 as a benchmark. You can download it here.
Unzip it somewhere, and I’ve tried to make this pretty easy to follow… There are precompiled EXE’s for various CPU’s and Visual C++ levels.
To build, setup your CLI with the VC environment variables, then simply cd into ‘ezquake\build’ and run:
nmake -f quake.mak
If you have Visual C++ 2.0 (I forget if I needed this for 4, and I just don’t feel like installing 5.0 right now) you may need a slight ‘hack’ to undefine some things that just don’t exist in the winmm.dll setup with the vc2.mak/b2.cmd .
And this should produce an EXE with the /O2 flags for a generically built maximum speed optimized EXE. If your make has issues, you can try the build.cmd file which just blindly compiles the thing one at a time…. It should work as well.
Then to test the exe, simply cd into the ‘ezquake\test’ and run:
..\build\quake -nomouse +timedemo demo1
Anyways, now for some interesting test results:
Visual C++ 2 x86 619.4 FPS
Visual C++ 4 x86 689.1 FPS
Visual C++ 6 x86 631.2 FPS
Visual C++ 2008 x64 375.7 FPS
Visual C++ 2008 x86 400.6 FPS
Visual C++ 2010 x86 772.2 FPS Visual C++ 2010 x64 949.5 FPS
I’m blown away with just how fast this new version of Visual C++ is.
Ok, my friends say I’m insane to have bought this… but I couldn’t resist.
It’s a DEC Alpha 221164 machine, with 64MB of ram, and a 4GB disk!
It’s the best technology of 1996-1997!
So I’ve gone ahead and installed Windows NT 4.0 on the beast… at 600Mhz it’s pretty dammed fast… considering how old it is. Although I suspect a Pentium III I found in the garbage with a 1Ghz cpu is 2x faster…..
But at any rate, this is a DEC Alpha, the long time geek cpu of dreams etc…
What makes this slightly useful for me, is that I do have Visual C++ 4.0 & 6.0 for the Alpha. So at least I can build *SOME* stuff to run on the thing….
So I’ve been fighting the compiler, and it seems it’s default blended optimizations do *NOT* work on my machine.. I’m sure this will be fun down the road. However it seems setting the target cpu to the 21064 produces ok code.. I’ve got to bench the stuff, but at least my exe’s are not crashing.
So what have I manage to produce today so far?
unzip is a major one.. It’s hard to use a machine today without it.
The other thing I’ve manage to get running, is Quake! I’ve included my source & project trees as it was a feisty little thing to build..
I’m currently building & testing over terminal services so I don’t know what the speed is on the console… Also, this build does not include networking… I’m sure the winsock code will work just fine, I’m just not in a good position physically to test it, as Quake1 will *NOT NAT* correctly.. Also the SDL sound doesn’t actually output anything, so I’ve built it with the null sound driver..
I’d love to get that m68k->C build of frontier elite to go on the Alpha but I’m afraid my 64mb of ram will be a major constraint..
I know this isn’t much of an emulation thing, as the only emulator that possibly can run Windows NT for the Alpha costs upwards of $16,000 USD… It’s cheaper to score an alpha on ebay for $100 USD.
Well here is the screen shot…
I know it’s not much to ‘look’ at, but the pallet is correct, because it’s a real Alpha!.. Unlike the MIPS thing.
Well I started playing some more with the Quake source, looking to get a dedicated server at least running on Windows NT 3.1 . The problem is that every time someone connected I got this error:
SV_ReadClientMessage: NET_GetMessage failed
And they were disconnected. Some digging thru the source code revelaed that they were being dropped because they had ‘timed out’. But they did not timeout, the real cause is that the null_sys driver is TOO FAST!!! So this gave me a good excuse to re-use my failed SDL build for NT 3.1 (it has no video) but the timer works great! So with a little fun with the linker & Visual C++ 1.0 I managed to get it running!
I’ve put the source and build script for building the dedicated quake server here
The SDL.lib will probably link with every version of Visual C++, but I’m no promising. Also it wont work video wise on NT 3.1 so don’t get all excited.
Anyways no I havent put one on the internet… I dont know if there are enough people even slightly excited about quake… but it’s FYI….
Well I started this off hoping I could get Quake running on Windows NT 3.1 … I’m almost there I have the null version running just fine. However I’m not all that great with DIB programming so I was looking thru SDL and saw that it has a WINDIB driver!
So with a LOT of tweaking through SDL 1.2.13 I got it to compile with Visual C++ 1.0!! However it is lacking one critical call, the CreateDIBSection api call in GDI is not present in NT 3.1. So remembering all the MIPS stuff as of late, and that I have Visual C++ 4.0 which should easily support this call, I first got it running with Visual C++ 2.0 on the i386 (Under XP of all things). So it was just a matter of building the source, and making sure there is no errors, uploading it to the emulator, and rebuilding for the MIPS.
And after 30 minutes, I got my exe, and it ran!
I’ve included a link for any other MIPS people out there that want to play quake. I haven’t built the networking as I was having issues with my network earlier and couldn’t get it working…
And the source code with all the bits is right here.
In this build I’m not building SDL as a DLL or static library, but rather compiling Quake right into the source. Now that SDL is running on the MIPS, and possibly other Win32 OS’s (I have yet to test Win32s… I suspect the inherent threading in SDL will prevent it, but could the DBI calls be made directly stripping out SDL…?) but who knows, I think anything past 3.51 would work.