Currently I can do a Visual Studio 2003 build of DirectQ that should in theory work on Windows 98; however there are Windows API calls that I use which are only available on Windows 2000 or higher (and DirectQ really does prefer to use the D3D10 shader compiler which is only available on Windows XP or higher) so a Windows 98 build is not a viable proposition any more. It's an interesting thing to test all the same, and gives the lie to the theory that more recent software from Microsoft is just slow and bloated. While 2008 does certainly produce a larger exe (1.3 MB vs 1 MB in the debug build; release will be smaller) it also runs about 25% faster.
No further comment necessary there, I think.
I'm looking forward to the day when I can just ditch Windows 2000 support and move to Visual C++ 2010; it's definitely a much nicer environment to work in, and it will be interesting to do performance comparisons with that. I am however waiting for SP1 of 2010 to come out, and also you would likely all need to upgrade your Visual C++ runtimes and DirectX versions (2010 isn't happy with older versions of the DirectX SDK), which wouldn't be a nice thing to do; at least for a while. I have done test migrations and have confirmed that DirectQ will compile clean and run well, but I can't make any performance comparisons right now as the last such build I made was about midway through 1.8.4.
Slow machine testing is a critical part of any DirectQ release, and I currently do test runs about twice a week. This normally just involves some timedemos, a quick run through an e1 map or two, as well as an occasional big map (just for laughs). It gives vital information on potential bottlenecks that just don't appear when you run on a faster machine, and is also great for testing fallback modes for when the latest and greatest hardware features aren't available.
The current slow machine of choice is a VMWare VM running Windows XP. This is configured with 512 MB of main memory, 128 MB of video RAM and a single CPU core, so it would be reasonably representative of the type of machine that was common enough maybe 5 years ago. It uses VMWare's video driver (no hardware virtualisation) which I guess is equivalent in speed to maybe a TNT2 (but with a more modern feature set) - I certainly seem to remember getting similar timedemo demo1 results (90-100 FPS at 800x600) back when I had a TNT2.
I also have a Windows 2000 VM which I've specced even lower, but very rarely use it. It's slightly faster than the XP box, but has something of a tendency to bluescreen. Some day I'm going to add a Linux box to the mix (is Ubuntu still the hip thing with the young things?) and try it out over WINE.
All in all there;s no conclusion and nothing really relevant here if you're tracking current progress with the engine, just some of my random ramblings. :)
Next time I'll probably have the RC2 release available for everyone to try. Till then.
Wednesday, July 14, 2010
Slow Machines, Visual Studio Versions, and More
Posted by
mhquake
at
12:53 AM
Subscribe to:
Post Comments (Atom)
7 comments:
I've never noticed it before so I feel kind of stupid for asking.
On the start map I can see the lavaball glow through the wall.
That is while in the normal hallway, on the wall to the right I can see an orange glow of the lava.
Is that standard/desired behavior?
Also how long has the console animated to transparent? I really like that.
Oh yeah and pixel shaders working, no more black level: )
Is there no edit post button? I feel like a jerkoff for triple posting
No edit button, damn you to hell Blogger!
The dynamic light shine through is standard GLQuake behaviour. It could be fixed so that surfaces facing away from the light aren't lit, but that looks even uglier as surfaces facing it (including the floor of the normal hall) will still be lit.
Console animating to transparent has been there for a good while now, not sure exactly how long though but it's been a few versions.
Great to hear that it's working with shaders for you now; all well on my 945 in work too.
Ubuntu is still approximately hip, yes. :) The 10.04 release is really good, but deviating too far from its out of the box experience still results in weird behavior that can only be sorted out with a good deal of internet searching and / or the assistance of a seasoned user. Thinking of doing some Wine testing, along the lines of "yo dawg, I heard you like Linux, so we put a Linux in your Windows, so you can emulate Direct3D through two OpenGL translation layers"? It's certainly ambitious, though I volunteer to test mhquake through Wine on my Slackware-running dual Athlon64 with a Geforce 9600GSO... I can submit ID1, hipnotic, and rogue timedemo data for multiple system configs in my house, if you'd like. All but the latter box run supported versions of Windows.
Good to see things are going so well on this project, as always.
Incidentally, I can also provide thorough Shrak testing since I actually bought it way back in 1997 and still occasionally play it...
10.04 went really odd on VMWare so I reckon 9 is a better bet for now - at least the keyboard works!
I'm not really expecting performance from this test, that would be quite daft (although it would be a pleasant surprise too). The real objective is to confirm that the thing works, to see if my shaders compile OK (I can always run without them if I can detect it's running under Wine), to see if my Windows API calls are happy with Wine and so on.
I'm always happy to have other folks testing this on their own systems so by all means feel free to give it a spin yourself. I can PM you links to in-progress builds via Q1 or I3D if you like, or you can just grab the main release if you prefer.
Thanks!
Post a Comment