Follow up on Visual C++ 2010

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

949 FPS in Quake1!
949 FPS in Quake1!

I’m blown away with just how fast this new version of Visual C++ is.

Well today I got my new Dec Alpha running!

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?

Well…

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…

Quake on the Dec Alpha

 

I know it’s not much to ‘look’ at, but the pallet is correct, because it’s a real Alpha!.. Unlike the MIPS thing.

Quake 1 fun

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

Quake for the MIPS (NT4)

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!

Quake 1.06 on the MIPS/NT
Quake 1.06 on the MIPS/NT

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…

The exe is available here.

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.