Experimental D3D9 Build (2009-12-11)

[Ultraken]

Here we go again...

Battlezone D3D9

I put it on BetaDudes this time so downloads should be more reliable than hosting it on my NAS.

Changes:

• Added support for 32-bit frame buffer, enabled by default.  Disable in render.cfg "[D3D]" section with "Buffer32=0"
• Enabled dithering for 16-bit frame buffer
• Fixed fog color not getting set properly (e.g. in first Soviet mission)
• Turned off base address randomization so I can get meaningful results from crash reports
• Removed unused library dependencies
• Fixed calculation of v_mag_inv for small v_mag, which may fix some rare collision issues
• Fixed invalid floating-point operations in AI lateral movement, which should increase mission stability
• Added support for setting vsync, enabled by default.  Disable in render.cfg "[D3D]" section with "Vsync=0"
• Re-added support for setting Z-buffer, since removing it broke software renderering.  Hardware rendering is much faster with it enabled, almost 2x on my desktop computer.
• Switched seismic wave and explosion shake to Perlin noise.  The explosion shake is currently very weak, so it'll get tweaked later.

Usual reminders:
1. This build requires the Visual C++ 2008 SP1 Redstributable Package
2. If using a retail install, rename the "splash" folder to "splash_" to disable Windows 7's compatibility layer
3. If running on Windows Vista or 7, make the install folder writable
4. If having trouble, try the DirectX End-User Runtime Web Installer

[Commando]

Unfortunately there is no additional information.  Still get an error at addrexx 0000005.

'bzone.exe': Loaded 'C:\Windows\SysWOW64\msctf.dll'
Unhandled exception at 0x00a21c18 in bzone.exe: 0xC0000005: Access violation.
Debugger:: An unhandled non-continuable exception was thrown during process load
The thread 'Win32 Thread' (0x94c) has exited with code -1073741819 (0xc0000005).
The program '[3160] bzone.exe: Native' has exited with code -1073741819 (0xc0000005).

[Ultraken]

I managed to coerce a call stack out of the application, and the access violation occurs deep inside NTDLL.DLL as part of something ANET2.DLL is doing.  After loading debug symbols, the call stack indicated a validation failure inside AllocateHeap.  Unfortunately, the call stack trails off after that.

If this is an Activnet thing, it's going to be a hard problem to fix.

[Commando]

That sucks, and I"m assuming there is no workaround, even if it involved disabling MP.

[Dx]

Which anet2.dll are you using? (Size and date on the file)
Same for your winets2.dll.

[Ultraken]

That particular test was done with a BZ98 install since I was at work.
ANET2.DLL: 95804 bytes, 7/7/1998 3:58PM
WINETS2.DLL: 32768 bytes, 6/15/2004 9:24PM

[Dx]

Here's the anet2.dll that matches the winets2.dll you have.
anet2.dll
VS2008 dlls

[Ultraken]

That fixed it.  Awesome!   

[Dx]

Oh great! hehe

[Ultraken]

Looks like someone needs to update the BZ98 installer... 

Anyway, I'll start including that in future experimental builds.  I'm not sure why the original one would start for some people and not others, but I guess that will remain a mystery...

I noticed the new DLL was a lot larger.  Where did it come from?

[Dx]

The anet open source.
The activnet folder in the current build should be updated with the latest includes and libs aswell.

[Ultraken]

Is it the version of Anet from here?

I should make the Activnet a separate download since it's not going to be changing any time soon.

[Dx]

Yes.
It has one bad effect that i saw, it doesn't drop a player with 100 loss.

[Ultraken]

Ah.  How often does that happen, though?   

[Dx]

Here is the vs2008 updated dlls
VS2008 dlls

Whenever players ban each other.