Messages

I'll see if I can do that.

(I may not have the authority to move topics around.)

I'll start tearing into the rendering system one of these days...

[Update:]

As an aside, the anonymity and lack of social cues of communication on the internet makes it all too easy for disagreements like this to spiral out of control into epic conflagrations.  People commit actions and post things online that they wouldn't dare face-to-face.  It's easy to be a complete dick to words on the screen.  It's much harder to be a complete dick to someone in person, though that doesn't stop some from trying.

On the other hand, Spock's profligate use of the banhammer to maintain "ideological purity" on his site isn't doing his cause any favors.  "The more you tighten your grip, Tarkin, the more star systems will slip through your fingers..."

Update: that second paragraph came across as much more incendiary than I intended...

I've actually been helping out a bit on other things, just not the renderer.  I plan to take a stab at it soon, though.   

Would losing it help with the W7 issue?

It would, though only indirectly.  The software renderer imposes a lot of constraints, and removing it would make a lot of things easier.

Would keeping it help in porting it to other OS's?

I doubt it, since large portions of the software renderer are tightly-wound assembler code. 

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.

That's a good point.  Gamespy servers would act as a neutral third party.

Raknet looks promising.  I had run across it before, was curious about it for my own game project.

BZ2 uses GameSpy, which has the huge advantage of not needing game-specific servers.

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.

The software renderer imposes a lot of structural constraints that I'd like to lift.  It's also a fairly large amount of code, so dropping it would shave an appreciable amount off the size of the executable for what it's worth.

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.

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.

There seems to be a bit of consternation over at battlezone1.freeforums.org, and I'd like to clear things up a bit.  I'm not going to get involved in this whole community split over BZ1, BZE, BZ2.  Development of the unofficial BZ2 1.3 patch brought me here years ago, and I plan to stay here for the duration.  I don't mean that as some sort of personal rejection, just a simple fact.

There has been a recent push to warn or educate me about Dx/Reaper and BZE, with the implication that I've been on the wrong side of the issue.  Regardless of how much that community despises Dx/Reaper, he has shown both dedication and maturity over the years I've been in contact.  I ask everyone to just chill out.  I'm an adult and I can take care of myself.  This isn't about one side or the other.

My primary objective is to get BZ1 working with modern development tools on Windows 7 since that's what I have at home.  I may add some other modernizations while I'm in there, but can't make any promises since my time is very limited.  I can't afford to get into a bunch of gameplay changes or feature requests, since that exactly the kind of time-sink that led me to burn myself out on BZ2.  The product of my effort will remain the same game everyone knows, just preserved for the future.

Though I care deeply about BZ1--it was my first shipped title--I return with considerable reluctance because I knew I would get pulled in all sorts of directions.  The "experimental build" has sparked considerable excitement in the community, but I think releasing it publicly was a mistake.  What's done is done, though.

The shadows are currently the lgt file for terrain and a sprite for objects right?

I probably should have distinguished between lighting and shadows to avoid confusion.
Terrain uses static lighting, stored in the lgt file.  I'd keep that to start with.
Objects use dynamic lighting, applied by a single directional light.  I'd move that to D3D.
Object shadows are ground sprites, which I'd leave intact since real shadows are very difficult to get right.

What texture file formats will be used in the new renderer for 24bit and alpha?

I have no idea. 

I may implement some sort of 32-bit MAP format, but that's a ways off.

but..if we drop hardware...we're all screwed

I think it that was a typo. 

And ken, isn't the transformation and lighting code a good thing? (the shadows and whatnot?)

D3D would be handling them instead of the application.