Direct 3D 9.0c Quake

[Monster]

Any chance on testing it on a 9800gx2 ? :O No clue why i'm having that weird problem, I have latest video card and DirectX drivers. Maybe my card is TOO new for direct3d...

[mh]

OK, hopefully I'm going to have a solution in the next release... lots of crossing of fingers here.

I've suspected for a long time that DirectX was doing a lot of multithreaded stuff behind the scenes, despite being told at startup time NOT to; and given that a Direct3D 10 card is a multithreaded GPU, I also suspect that something weird, wonderful and undocumented (or obscurely documented) is happening here, even with Direct3D 9.

The next release should resolve all of that. Unfortunately I've short arms and deep pockets when it comes to graphics cards, so I can't personally test it.

I have however created an "Emergency Refresh 2" package, which contains the relevant updates. Grateful if those who have been having issues could check it out:

http://sourceforge.net/projects/direct3dquake/

[MeTcHsteekle]

Unfortunately I've short arms and deep pockets when it comes to graphics cards, so I can't personally test it.

HAHA i get it;
that's not what i have though, i'm just poor

oh and did you ever find the issue for the map rotation on bigfoot?

[revelator]

8800gtx nvidia 768 mb ram no problems

had to install latest directx but that was about it

[mh]

Got to test on an Intel 965 a day earlier than expected. It ran beautifully, no issues or glitches at any resolution. The fastest of the Intels I've tested so far.

One thing that happened which I did not anticipate was that the driver is capable of flipping the screen from a landscape mode to a portrait mode, so the best fullscreen resolution came out at 800x1280 rather than 1280x800. I think what I might do there is sort the mode list by width, then height, rather than take them in the order Direct3D gives them to me; meaning that these modes will still be available if you really want to use them, but you will need to explicitly request them.

Also, it gave me the best mode suitable for windowed use as 1024x768, which is not really suitable at 1280x800 as the taskbar will overlap part of the window. I obviously need to do some GetSystemMetrics calls for SM_CXMAXIMIZED and SM_CYMAXIMIZED and compare to that, rather than relying on the standard desktop resolution when determining which modes are suitable.

[=peg=]

Hmm yeah..

Today i tried on this crappy old p3 1ghz with 256mb ram and a Nvida Geforce2

All versions (1.0 1.1 1.1patch1 1.1patch2) started in 1600x1200 res wich made the pc reboot as soon as the renderer was started.. which is kinda evil!

But all worked fine on 1.1patch1 and 1.1patch2 in 640x480 res
(i ripped the quake.rc and demo's from pak0.pak and started with -width 400 -height 300 -bpp 32 to prevent the reboot)

I did notice some z-fighting however on e1m1 (the elevator to the secret quad), using fov 130.
It only happened when i was moving and i think its only the overlapping lightmaps.. (see below)

The lava textures on brushmodels work fine! (see below)

Oh and it was good to see that the gun-in-hand renders as it should on fov 130 (r_drawviewmodel 1), contrary to most gl-based engines!

[mh]

Oh and it was good to see that the gun-in-hand renders as it should on fov 130 (r_drawviewmodel 1), contrary to most gl-based engines!

You noticed!

That's creeped me out for a long time, and I made a deliberate effort to fix it.

Sorry about the reboots, by the way. I don't have a GeForce 2 but I suspect you might have a video RAM limitation there. I put a lot more stuff into video RAM than GLQuake used to, and 1600x1200 needs almost 16 MB for the color buffer and depth buffers alone, before we even load any textures! I've been lazy and not checked the HRESULT from Device->CreateTexture...

I should also do a more accurate check on video RAM (what's reported by the D3D caps can be wildly off, to say the least) and scale back the default mode if it seems we're limited.

___________________________


Update - just tried it on another Intel 965 and I got the "melting walls"... at least now that I can reproduce it I stand a chance of fixing it!

____________________________


Update 2 - that was the quickest one ever. It's a bug in Intel's software T&L engine; switching to HARDWARE_VERTEX_PROCESSING makes it all go away. Unfortunately that was the mode in which certain NVIDIAs locked up, so we'll have to see if my multithread fixes affect anything there. Won't be able to check that myself till late this week though.

I wonder... the other 965 I tested had an OEM-installed older driver, while my driver (and I assume yours) came direct from the Intel website.

[Tomaz]

I've been following this for the last couple days and I must say that if you need to turn on Software T&L on nVidida cards then youre doing something weird somewhere.

Some might know and some might not know but my job is to code a D3D engine and teach how to use it at a game company / game developer school, and I use D3D9 and have never had any issues with hardware T&L or any problems with D3D being multithreaded.

If you need any help then fell free to ask and I'd be happy to help you out. After 2 years of coding D3D 8h/day I hope I know enough to help you sort out most of the oddities you find.

[mh]

What a nice offer.

I might give you a call sometime then, especially if the NVIDIA thing doesn't work out (my feelings on this echo yours, but my startup is totally standard, so I'm a bit baffled) but right now I'm enjoying figuring things out for myself - more than half the fun of doing this, don't you think?

One question actually - I'm running LockRect (with D3DLOCK_NO_DIRTY_UPDATE) on lightmaps (in the managed pool) and leaving them locked for the entire map, then using AddDirtyRect each frame (this only went in today - not related to any other weirdness) - am I mad or is this an OK thing to do?

[metlslime]

It's a bug in Intel's software T&L engine; switching to HARDWARE_VERTEX_PROCESSING makes it all go away. Unfortunately that was the mode in which certain NVIDIAs locked up...

hmm, and d3d is supposed to be better supported than ogl?

[mh]

It's a bug in Intel's software T&L engine; switching to HARDWARE_VERTEX_PROCESSING makes it all go away. Unfortunately that was the mode in which certain NVIDIAs locked up...

hmm, and d3d is supposed to be better supported than ogl?

I actually got that a bit backwards, it was an OEM driver that caused the problem. Grabbing the latest from the Intel website fixed it.

[mh]

1.2 is out.

http://mhquake.blogspot.com/2008/12/12-released.html

A lot of new stuff in this, so expect some bugs.

[kempie]

I'm using a GF6800 - wateralpha doesn't seem to work properly (only on teleporter surfaces rather than water). Some HOM type artefacts on thin vertical surfaces (check apertures to water below in floor of easy hall in start map). Image quality otherwise is superb and speed has jumped another 20 - 40 frames at 1920x1200. Menu is very slick- nothing fancy but very functional

Also, the lightning beam is not rendered at all for either lightning gun or Shambler. Still have the muzzle lightning but not the long beam

Just superb!

Cheers, kempie

[mh]

Okeydoke, I'll check that one out.

I also broke mapshots right at the very end while cleaning up the viewport code, so for now, and until 1.3 is out, a mapshot will be of a small square region at the top left of your screen.

[MeTcHsteekle]

hehe i tried taking a screen shot of the swirly sky thing you have and it crashed almost instantly, but no big deal[unless i want DQ screen shots of map n mods ]

also i noticed you fixed the map change thing yay . and that the scoreboard has colors yay