DirectDraw deadly spikes

[Barbie]

To get an overview of a map I often use the ghost mode. I tried this with the map MH-SkaarjDungeon-HORROR and instantly got a GPF:

MH-SkaarjDungeon-GPF.jpg (25.95 KiB) Viewed 2522 times

I broke the problem down to some (64) brushes formed like a spike. If you fly around in this map and have set DirectX for rendering, a GPF is thrown. It does not happen with OpenGL or software rendering.
Now I'm interested in if it is a problem of my windows installation or a general problem of DirectX 11. Therefore you can download that small map (45 kB), fly around and tell me if you also get a GPF - thanks.
Map preview:

[Red_Fist]

I always use openGL, directX looks pasty and too bright brights, too dark darks, dunno just don't look right.

But does it mess up using openGL ?

[JackGriffin]

This happened in an old MH map, same scenario. I can't remember the map, it was one of those older Godz maps with a Queen as the final boss. The last room room was full of spikes and it played fine unless you looked up- instant lockup. I ended up removing the spikes to get it to stop. My guess is no one is going to crash with your test map but if you added a couple of light actors it will make some of them crash. Zonelight doesn't stress like light actors creating a lightmap does. More light will probably mean more crashes.

EDIT: I just had to know....I downloaded the map and ran it on openGL. Rock solid. I switched off of openGL, still rock solid. Added a light at each end, one high and one low. Then I rebuilt the map and jumped back in. GPF'ed.

[Barbie]

Thanks for testing - now I know that the problem cannot be my Windows installation.
Concerning the 64 spikes I noticed that if you remove some of them, the GPF will not occur. Maybe the magic number "64" causes a problem - who knows.

[JackGriffin]

B, I think it's as simple as just too many polys in too small an area on an engine that's just too old.

[Dr.Flay]

Unless you have changed it, you are editing with the software renderer, so it will always look different to both the DX and GL renderers.
Change your Windowed render mode to be the same as what you use to play.

You have not said which DX renderer you are using, though you seem to have a DX11 card.
The original UT renderers are for DX5-7 cards, and Kenties DX11 renderer is only a "proof of concept"
Use DX9 or 10 renderers.

If the lighting and colours differ between DX9 and GL then you are still using the defaults, or renderers from different sources or eras.
Change them both to use the same settings, and you will get the same lighting etc.
Use DX and GL renderers from the same branch/project, or any comparisons are pointless, and only spread miss-information.

[JackGriffin]

'Misinformation'?....Maybe a little much. It's just guys comparing information and results to some light testing. No reason to condemn that I think?

[MrLoathsome]

Cap it at 63? (Or whatever value fails to crash...)

[sektor2111]

I did not figure any crash. It's an ON-Line issue or Local or Both?

[attachment=0]TestD3D9_32Bit_1024_768.jpg[/attachment]

[Barbie]

But does it mess up using openGL ?

Just read first posting again... ^^

Added a light at each end...GPF'ed.

In my installation that test map already throws a GPF without any additional light.

You have not said which DX renderer you are using

I'm not an expert in video processing stuff - I've just chosen what UnrealTournament.exe has offered. Do these information of UnrealTournament.ini clear that up?

UnrealTournament.ini

[Engine.Engine]
GameRenderDevice=D3DDrv.D3DRenderDevice
...
[D3DDrv.D3DRenderDevice]
Translucency=True
VolumetricLighting=True
ShinySurfaces=True
Coronas=True
HighDetailActors=True
UseMipmapping=True
UseTrilinear=False
UseMultitexture=True
UsePageFlipping=True
UsePalettes=True
UseFullscreen=True
UseGammaCorrection=True
DetailTextures=False
Use3dfx=False
UseTripleBuffering=True
UsePrecache=True
Use32BitTextures=False
DescFlags=1
dwDeviceId=4992
dwVendorId=4318
Use32BitZBuffer=False
UseVertexFog=False
UseAGPTextures=False
UseVideoMemoryVB=False
UseVSync=False
Description=NVIDIA GeForce GTX 750 Ti

Cap it at 63?

Yes, that would be my last resort. But if I fix that map by modifying it I want to be sure that it is fixed for every (valid) client installation, not only for mine and who knows if 63 spikes will crash another client?

It's an ON-Line issue or Local or Both?

Because the GPF is raised depending on rendering device it must be a problem of presenting map's content on the screen and therefore client side only. (I've run into the GPF online first.)

I did not figure any crash.

Did you look at the spikes in different angles by flying around a bit? Not in Editor but with UnrealTournament.exe and setting DirectX for rendering.

Thanks all for testing this so far,
Barbie

[sektor2111]

Speaking about that MH map in cause I did not figured display issues even fooling with RMode setup (I hate dark I feel eyes bleeding). Aside, you simply have awake me up again. Gotta rewrite Killed, some bullshit creature there uses SpecialDamage (special dumbness I guess, nothing special). For sure If I have a killer and doing a call into engine for processing kill message I get Engine.GameInfo.Killed.Accessed None 0113 and I'm suspecting this crap:

Code: Select all

		if ( (DamageType == 'SpecialDamage') && (SpecialDamageString != "") )
		{
			BroadcastMessage( ParseKillMessage(
					Killer.PlayerReplicationInfo.PlayerName,
					Other.PlayerReplicationInfo.PlayerName,
					Killer.Weapon.ItemName,
					SpecialDamageString
					),
				false, 'DeathMessage');
			bSpecialDamage = True;
		}

I don't even see any check for "Killer.PlayerReplicationInfo" but is stupidly called, and neither for Killer.Weapon (perhaps this is wrapped in message I'm not wasting time to check), but now I'll get mad and I think I'm gonna totally skip this ENGINE.U because I have a couple of display issues in console... for this "horror" Level.

OpenGL is not one of my favorites, d3d9 for me seems more cute and seems to have a good performance.

[papercoffee]

You have to turn those BSP spikes into semi-solids. I am about 90% positive that it will work (but take it with a grain of salt, been years...).

The explanation: solids make BSP cuts, semi-solids receive BSP cuts. A BSP cut is pretty much the same thing as splitting a poly in two, and the more polys a BSP surface has, the more nodes it has to handle, the more unstable it gets.
Making those spikes solid add tons over tons of BSP cuts to the point the engine cannot handle them anymore.

Mappers are generally afraid of semi-solids, because they hear all this horrible stuff about them, but they're there to be life savers as a matter of fact, they're just not understood very well by the community.

[JackGriffin]

He needs to get his ass back over here. He's sorely missed.

[sn260591]

This problem only occurs with d3ddrv. Barbie, follow advice of Dr.Flay and change the renderer.

[papercoffee]

He needs to get his ass back over here. He's sorely missed.

At least should he not use me as a delivery boy .... j/k

You can always mail him or contact him over moddb or unrealtournament.com <=also pretty inactive there. but he will answer you.