|
Author Topic:   DirectX ROAM demo
Cthulhu
Member
posted January 23, 2000 12:00 PM            
Available at http://www.surffi.net/~auer/roam

Lots of popping and other artifacts, pool overrides sometimes (read: often) crashing whole windows, propably many compatibility issues because of bubblegum-based direct3d implementation.

However, I like it nicely optimized. Terrain is 1024x1024 size and uses 16 256x256 textures to look nice even with voodoo cards w/o support for larger textures.

Usage: mouse looks around, arrow keys go forward and back and strafe, home turns on wireframe and end turns it off. Esc quits the program.

To avoid pool overrides, see for numbers in the upper left corner. The upper is fps and the lower is triangle count (not exactly the number of visible triangles, however). If triangle count goes over 5000, hold still until it's again around 2000. This happens often if you have only very small area visible and you turn fast to see very large area. Avoid fast mouse turns.

If you have ANY suggestions, comments, complains, WHATEVER; please reply here or mail me.

IP:

Tim
Member
posted January 23, 2000 04:06 PM            
I like the speed, though I don't believe I'm getting 500fps (which is what it tells me) Are you using split&merge queues?

For D3D, are you using their transforms or your own? Do you emit fans, strips, or lists?
I've found that D3D needs strips & fans that are at least 20-30 vertices long to 'win' over the call overhead. (which pretty much negates their usefulness, thanks Microsloth)

Also, I see some problems in Z resolution. You might want to check your perspective matrix near & far planes.

The speed gives me inspiration, My top-down only ROAM is running at 8-10fps. I'll be adding merge queues next, so I hope I can get up to your speed!

IP:

Cthulhu
Member
posted January 24, 2000 08:14 AM            
No queues. New tree every frame. Only one pass every frame, though. I use triangle lists; no stripping or fanning.

I think speed could be even more improved with frame coherency, and with camera standing still speed gain would be massive.

Note that triangle count number isn't exactly the number of triangles you see, because it counts all the backface triangles. I use 3d culling so I don't have to send them to DrawPrimitive() and I can currently disable Direct3D's own backface culling.

I think the fps are correct but I'll check them again anyway. I get around 300 with p200 + voodoo2. I won't release sources cause it's not all my code and that roam engine is going to be base for our game project.


You mentioned Z problems I am very aware of. What shoud I do with projection matrix far/near planes. Currently I'm setting near to be *very* near, is there something bad with that? (this is actually my first 3d-project ever

[This message has been edited by Cthulhu (edited January 24, 2000).]

IP:

Bryan T
Member
posted January 24, 2000 11:30 AM            
Cthulhu,

Your program crashes my machine before it even starts... I've had some problems with D3D in the past though (and Unreal crashes when I try the D3D mode too).

Anyone else crashing or is my D3D install just bugged?

--Bryan

IP:

Bryan T
Member
posted January 24, 2000 11:54 AM            
Oh, about the framerates: There's no way you're getting 300FPS with 5000 tris onscreen. Even with flat fill at extremely low res, this is WAY over the bandwith limits of todays PC hardware. Are you sure you're dividing the time correctly? Perhaps you're off by a decimal (30FPS would be about right).

timeGetTime() returns miliseconds:
1000 Miliseconds = 1 Second

As for the crashing on pool overrun.. you'll have to fix that asap. Users should be able to swing their view around at any time. When my engine overruns the pool, I get mesh cracks, but only for two or three frames.

--Bryan

IP:

Cthulhu
Member
posted January 24, 2000 04:11 PM            
Bryan: You must have DirectX 7 and zip file extracted with directories. I can't think of other fixable reasons. Propably something just says click in my d3d framework.

As I said my framerates aren't real. For real frame rates, my p200/voodoo2 gets around 30 fps with 2000 triangles (again, not all onscreen).

I'm going to fix crashes when I just get to it. I have currently million other things to fix/work on/plan. Though those overruns just take couple of minutes to fix.

However, do you people recommend moving into opengl programming? I am satisfied enough with d3d api, but I'm always looking for more speed.

IP:

Tim
Member
posted January 24, 2000 06:08 PM            
On the whole, I'd say D3D is faster.
I'm not into API wars here, but I work at a 3D chip company, and our D3D drivers have much higher priority than OpenGL. Why? Cuz our customers like Compaq and HP want good Winbench3D scores. Plus, I've seen our OpenGL source (based on the SGI ICD code), and there's a lot of wierd stuff in there. Dunno what SGI was thinking, but it'd take a long time to optimize or re-write some of that stuff. Many other IHV's are in the same boat. Another 'strike' against OpenGL is that you can't access many new features. like AGP texturing, W-buffers, Compressed Textures, and so forth. OpenGL is nice for rapid prototyping though, since it's so easy to get stuff on the screen.

As for near & far planes a 16bit z-buffer likes a near/far ratio of at most 100, stretching that out to beyond 1000 or 10000 means that your far Z resolution drops to zero!


The problem is that screen space Z is NOT linear, and a 16 bit Z only has 65536 'steps'. As you get closer to the far plane, z resolution quickly drops off.
The smaller the ratio, the more bits can be used to resolve Z conflicts.
If your far plane is 1000, and your near plane is 0.1, (a ratio of 10000) then you'll get problems like the ones you see in your demo. How do you solve these problems?

Well, as you look 'up' to near horizontal your near plane could move out a few feet. and as you look down, your near & far planes can pull in. Also, if you zoom in using FOV, push out the near plane to keep that ratio low. Otherwise, you'll have your far away tanks, planes, battle armor, and hills all resolving to the same Z. If that 'far away horizon' is important, then consider doing a depth sort on far away objects.

Another way to fix this is to use 32 or 24bit Z (if the card supports it), or try W-buffering, which is a completely different beast.

It's important to understand the perspective matrix and what it does. But just keep those ratio's down.

IP:

Cthulhu
Member
posted January 31, 2000 09:58 AM            
I uploaded new version for anyone interested. (who could that be?) Less crashing, no depth sorting errors, and about 150% of previous version speed. FPS counter does work fine now.

Sorry for the darkness, it's because of too dark textures (new map, new textures). You could add some brightness/contrast to each bmp but it's easier to adjust monitor brightness

Same location, same filename. See 1st message under this topic.

IP:

Axe
Member
posted February 13, 2000 04:05 AM            
I tried your app. It asks about res, changes, bails, no message. ideas?

IP:

Cthulhu
Member
posted February 13, 2000 07:58 AM            
At this stage I have no intention to test it with different systems. Currently uploaded version has some kind of detail texturing, so your 3d accelerator must support one-pass multiple texture blending and you must have DirectX7 installed.

Btw. what kind of machine are you running? Never hurts to get some info.

IP: