A curious graphical error

[JoeCapricorn]

It works somewhat if Reflections are turned off... but sometimes the tops of the trees will pop in and out.

And the graphical error occurs with all vegetation, sometimes objects farther away are rendered in front of closer objects.

What DirectX did the original BZ2 use?

[Nielk1]

DX7 IIRC. If you try to use BZ2's old, and entirely correct, DX7 implementation on a modern GPU the sky will memory leak if not set to none and your game will degrade and crash.

[GSH]

No, BZ2 1.0-1.3pb4a used DirectX 6 for graphics. (1.0-1.2 used DX6 input, sound, etc; 1.3pb?? switched to DirectInput 8, and DirectSound/DirectSound3D 8). And, the DX6 graphics is really much more like DX5 plus a tiny bit of changes for EMBM bumpmapping that's present starting in DX6.

Also, 1.3 Tech Alpha 5, the first version with DirectX 9 graphics was released in late April 2009, almost 3 years ago. If there is a bug that affects you, this is the first time I've really heard of this bug. If it takes ~3 years for a bug to surface, I really don't get this OMG!PANIC!BringBackTheOldCode!!!!111!!!! comments. The old graphics code is dead to me. I don't see the old code as superior, even if there's a pretty darn rare bug in the new.

-- GSH

[JoeCapricorn]

Could the error with reflections being turned on causing all meshes except terrain to not render be related to SLI? I do have two 8800 GTX GPUs.

Or doesn't SLI matter for BZ2?

I was asking about the DirectX version that BZ2 originally used out of curiosity. I'm not saying bring the old code back (although I guess I kinda did when I mentioned a 'legacy' option), but could there be a way to solve the transparent polygon sorting issue nevertheless?

In the Dunes map, I realized that the appearance of objects further away being rendered in front of closer objects was an illusion as those vegetation objects are groups instead of individual plants. So, somehow the renderer is rendering the polygons of that group of objects from front to back instead of back to front?

I wonder if a solution might be to try and measure the distance each transparent polygon is from the camera and render them from furthest to nearest.


It's an eyesore, but it doesn't ruin the game. My primary means of playing Battlezone 2 was through making maps that were strange and imaginative, and some of these were microworlds where the 'sky' was just a water layer (although later on I made objects that generated a spherical field for the sky so I could have 'microplanets' with water).

[Nielk1]

Its simply the draw order and it isn't worth spending copious amounts of time trying to come up with a fix for.

As I tried to indicate about the old code normally the game is programmed correctly but the drivers keep changing.

[MrTwosheds]

Basically some of the models that use either mesh transparency or transparent textures need to be modified so that the same mesh cannot be seen through twice. The models need to be broken into more parts, like each crystal becoming one object rather than all of them being the same object.

[GSH]

I wonder if a solution might be to try and measure the distance each transparent polygon is from the camera and render them from furthest to nearest.

Possible, if you want the framerate to drop. A lot. DirectX prefers batchs. Big batches. Each call to DirectX to "draw X" or "draw ABCDEFGHIJKLMNOPQRSTUVWXYZ" has a fairly high overhead associated with it. So, lots of calls will kill the framerate. One of the guys at my current job says that for a nVidia 8800, calling DirectX with fewer than 256 polys in a batch will basically take the same amount of time as 256 polys.

As I said on the first page, chunking things up logically on those ice crystals to one batch per 'arm' would be the least bad way to fix it. Still a lot of small calls. But not one triangle per call.

-- GSH

[Nielk1]

We would basically need an algorithm that is capable of batching the polygons in a way that avoids the issue. That is not easy by a long shot.

[JoeCapricorn]

Not easy, but not impossible. Although I have been

I graduated from college this past December with a major in computer science, so if I ask so many questions it's because I'm eager to continue learning about the subjects of game programming. Battlezone II is one of my favorite games of all time and the engine is one that has continued to fascinate me. I remember whenever I would get an upgrade on my PC, the first thing I'd do is see how BZ2 ran. Overall, the game looks better and runs better than it ever did before. I just had a battle with two hundred units on each side, and it ran smooth as a dream. Try doing THAT in Skyrim.

[Nielk1]

Ah, I am 1 quarter out from my Bachelor of Science in Computer Science. I don't know how portable an algorithm for this sort of thing would be, considering the engine.

[GSH]

BZ2 can come to a halt pretty quickly -- have 100 APCs attack a big base. Watch the framerate tank. (This has gotten better over the years, and seems slightly better in recent private builds of BZ2.) Animated bipeds are a lot more expensive in every engine than a bunch of unskinned meshes that comprise most ISDF BZ2 units.

And, Skyrim's physics engine (Havok, $$$$$ software now owned by Intel) is way more advanced than BZ2's physics. Something like this would crush BZ2's garbage collision code. BZ2 does an O(n^2) object search to determine if anything could collide with anything else. And then tries to fix things up, rather than making sure they don't get stuck inside. No use of any spatial databases like quadtree or the like to reduce overhead. This code was garbage in 1999, and it's not gotten any better with time.

I've seen links to various approaches to using the GPU to sort transparent items. But, that requires shaders, something that can't be guaranteed by all BZ2 users.

-- GSH

[Zax]

Get this guy on the private beta team stat, he's got gonads




Never noticed this before. Never looked for it either. Reproduced with ISDF pilot, similar settings to my boy there.

[Nielk1]

Oh I saw it 100s of times, I just knew that unless we had some sort of ordering system that ran quickly enough to sit in the render code it wouldn't be fixable.

[JoeCapricorn]

I have noticed another bug where the HUD in the regular single player games would look like it was set to 640x480, the ammo being tucked to the middle of the screen. I can fix it by using alt+enter, then alt+enter again to return to fullscreen mode.

Curiously after doing this, text in most windows as well as the spinning planets are not visible. I can still move on to the next mission. I'll post screenshots next time I can.

On an unrelated note, I've been trying to figure out how to change the gravity of a map. Can this be done in the .TRN file?

[Nielk1]

The DLL is what changes the map gravity but it can read the TRN. I think most of the DLLs read a standard gravity flag from the TRN but I don't recall what it is.

The window size thing is related to fullscreen/windowed and you should restart BZ2 after changing any graphical settings.