Experimental Build

[ZachTank]

Hey, when I try to run this on Crossover 8.0 it gives me:

Invalid memory entry!

[eddywright]

I did a fresh XP SP3 install on an older PC with an nvidia mx440 video card. The stock exe worked fine with a steady 60fps, the new exe held close to 75fps.  The only bug I've found so far with this setup is leaving a mission and going back to the menus, the display doesn't stay at 640x480, it jumps to 1680x1050 (native resolution) with the 640x480 bz display in the upper left corner. The stock exe didn't do this.

Graphics look good, gameplay is smooth and no issues with textures so far.  Glad to see the mouse pointer fixed finally

Eddy

[Ultraken]

I've gotten a report of markedly lower framerate on some machines, and I'm not sure why.  I'd need to do some profiling, but that's hard to do remotely. 

I changed the mouse pointer thing (for now) because I was tired of having to set my cursors back all the time.   

[Dx]

Ok, profile sent.  Hope i did it right....

[Ultraken]

Definitely a good start!

[eddywright]

I did a fresh install of BZ on my Vista64 PC and tweaked it til the stock BZ exe ran OK. I have some graphic issues but the game plays smoothly. I dropped in the new EXE and kept everything else the same but I get the DEP error others have reported.  I tried to add Bzone.exe to the exception list but Vista won't let me do it.



I can't get around this using the new EXE file.

Eddy

[Ultraken]

I'll try it locally, but my release build doesn't even start for me.  It blows up in the application compatibility layer.  The internal build is fine, though.

[eddywright]

I finally got around DEP, I had to turn it off in the boot options. With DEP off, the new exe causes an unhandled exception regardless of the compatibility mode or render.cfg settings if hardware is enabled. Software mode works only in a window but seems to work fine. The framerate is over 300 with everything set to max. Full screen software mode will work for a few seconds then freeze.

Test system is Vista64 with 4gig of RAM and nvidia 8800GTX. Stock BZ and BZE work fine with this setup.

Eddy

[Ultraken]

OK, thanks for trying it for me.  My guess is that some combination of Visual C++ 2008 and August 2009 DirectX SDK mess up both DirectDraw and Direct3D.

I created a test application based on one of the DirectX tutorials in order to learn Direct3D 9, and so far it's a lot easier to set up than previous versions of Direct3D.  I have a "model" using static vertex and index buffers along with a world transform matrix, and an "effect" using dynamic vertex and index buffers in world space.  I'm going to investigate texture mapping, dynamic lighting, various render states, and screen-space rendering as well.  I also need to handle D3DERR_DEVICELOST and D3DERR_DEVICENOTRESET events.

[eddywright]

Sound like a good approach, if you need any testing done with your test application on different hardware, I'm sure you'll find volunteers here.

Can you add some debug code to help isolate where the conflict is?  I do a lot of embedded system programming and when I have a similar problem, I add debug logging throughout the program until I find the problem. I'm sure that's a lot more work in a program this size, but it can provide a lot of good information.

BTW - The crash occurs right at the point of launching the hardware 3D view. I didn't mention that in the previous post.

Eddy

[Ultraken]

I know exactly where the crash happens, just not why.  Execution of the Execute Buffer fails deep inside the D3D library, presumably indicating a problem with D3D itself but it's certainly possible it's getting passed bad data from the application.  Execute Buffers are just terrible, though, so I'm more inclined to just chop out that entire system in favor of the far-simpler D3D9.

[Red Devil]

I just noticed that a lot of people are dividing their karma by -0, so maybe that is why things are misbehaving...

[eddywright]

I know exactly where the crash happens, just not why.  Execution of the Execute Buffer fails deep inside the D3D library, presumably indicating a problem with D3D itself but it's certainly possible it's getting passed bad data from the application.  Execute Buffers are just terrible, though, so I'm more inclined to just chop out that entire system in favor of the far-simpler D3D9.

Seems like D3D should provide some sort of error logging but other than the general application crashed log entries, I didn't find anything specific to D3D in the event logs.

Replacing it seems like the logical choice - fix the problem and make it more current in one move.

Eddy

[Ultraken]

I was going to enable the debug version of D3D, but it only affects D3D8 and D3D9 interfaces.  That's not so useful right now, though it'll be plenty useful later.

[Scout]

I just noticed that a lot of people are dividing their karma by -0, so maybe that is why things are misbehaving...

Also Ken, thanks, it's looking like the holiday season will be merry indeed..

Looking forward to some bomber colli with Trinity