Performance issues.

#1 Ok, what's your question? ;)

The directX numbers are lower because Torque doesn't use Direct3D 'right' - It translates openGL to Direct3D calls.

The Unreal numbers are much higher because It's designed to work with modern cards which weren't around when Torque was first designed. Notably, Torque doesn't use anything like the VAR or VAO extension to speed up geometry processing.

#2 nm.. the horrible performance on that map seemed to be the billboards. I get about 45-50 in the other demo maps, but still not what I'd expect (expectations based on quake2, q3, unreal, unreal2003, battlefield1942, halflife, etc).

#3 what's my question?

do those numbers seem right to you?

#4 Give or take, depending on a bunch of things you haven't mentioned, like windowed/not, resolution, color depth, etc, seems about what I'd expect.

#5 work with modern cards? the first time I played unreal was on a software renderer. I could never release anything that got 10fps under directx on *this* machine, I'd be laughed off the planet. Looking at the wrapper it looks like it was written a lot longer ago than 2001, whats with the quake references in the source?

adding it to the list.. Eberly did a nice renderer abstraction I can borrow from. I'm not going to complain, because I did only pay $100 for this, but when all is said and done I'll have refactored the entire thing by the time I'm finished.

-brad

ps okay I am going to complain

#6 oh yeah forgot.. 1600x1200 full screen 32bpp. any 3d game off the store shelves runs on this machine at breakneck speed. Even brute force does okay.. there's something not right.

-brad

#7 No, I'm facing similar questions myself. I get about 5-20 FPS on a 2 year old machine, and I hit about 100 FPS on a brand new, top of the line machine, read:

P4 2.86(overclocked)
1Gig of Geil PC3500 RAM
Radeon 9700

We did a polygon test, and loaded up about 50,000-60,000 extra polygons on the screen at one time, and took about a 50% hit, getting about 50-60 fps with that number of polygons. So it appears the problem of low framerate may be sitting with either the fill rate, or the texture memory, or brute force calculations.

I'm going through examining what I do and do not need to be in the game (class wise) to see if I cant knock out some overhead. Does my RPG character really need a recoil thread? Nah.

Just an FYI on the whole brute force calculations, we had implemented Raistlin(aka Jash) hitbox code for melee fighting. It has quite a bit of overhead with the constant raytraces it has to do, and I get about 7.5% total frame rate drop per weapon we load up. So running 20 fps to begin with, I load 2 shields, 2 swords, I am now sitting at 14 fps.

Anyhow, if you do any engine optimizations that result in better frame rate, I'd like to hear about them, as I will do the same on my end.

-Jared

#8 what map did you get 100fps on? I get 70 with an empty camera.. the directx wrapper stuff is another issue, I was thinking it could have been something in the scenegraph or some prep work, a lot of these engines (I will refrain from calling this old, I have the uptmost respect for tribes and tribes2, I regard it as my favorite all time game line.) seem to get hung up on something before they even hit the pipeline like some 'tricky c' that sped things along on old compilers or graphics api implementations but hit a brick wall on newer platforms. I had zero luck attaching the normal vc++ profiler to this, I'm going to try the line profiller tomorrow and see what's up. The code is c++ which is good, but it's c++ with tendrils.

regards

brad

#9 Well I don't complain because I've always had over 80+ fps in Torque, then again I have a fairly decent system.

The engine could use for some performance enhancements in certain key places but overall it is pretty solid.

#10 my point is not only that I'm getting sub par performance in OpenGL on torque even with, arguably the fastest video card available on the 2nd fastest cpu available (as of last month.. so might by 10th by now =) ), which is annoying, but that on my other machines and on THIS machine with directx I am getting *unplayable* performance.

which means people that play the game will get bad performance, as I'm not listing XP2600+, Radeon 9700 pro as 'recommended'.

-brad

#11 Ok, I am not a torque die hard, but I think you are getting your panties in a bunch over nothing (or very little).

Unless you are targeting a publisher who will require great DirectX support, DirectX shouldn't matter a whole lot.

The game engines that "signal" the next generation of PC graphics have been developed by id software for years. ID Software's engines are all OpenGL based.. only.

Do you see a whole lot of people freaking out because Quake3/RTCW/SOF2/DooMIII don't/won't run on DirectX? I don't.

However, Torque has a pretty dated graphics engine, it really could use an update. I can't do that, however, it doesn't bother me much because I am trying to make my art more stylistic. This will make an impression even if I don't have DOT3 Bumpmapping, Shader support, etc.

If you have the skill, update torque's graphic capabilities and sell them. If they were good quality, I'd buy licenses to use them...

#12 This seems as good a place as any to ask this question:

Has anyone ever seen significantly better performance using the Torque under DirectX vs. OpenGL? What kind of a difference did you find? Has anyone ever found a machine in which the Torque ran under DirectX but not OpenGL?

#13 hmm I've noted on more than one occasion when someone brought up performance or a gripe, the general response is 'shut up, panties in bunch, do it yourself'.

I didn't say I hate torque, I didn't say I got ripped off, I said 'I see a problem here that I must have resolved, has it been resolved, or should I do it myself'.

I'd not trying to make a 'next generation ground breaking game', I'm trying to run over 10fps on a major install base.

Torque has elements that I couldn't do on my own, I can draw pretty terrain, I can code a bsp viewer kind of, I certainly can't combine them, I can write art tools and exporters, I can alter an existing rendering engine, I can modify a scenegraph to suit me, right now I'm going down the list and identifying what I need to do to get this to a place I can use.

clark: I've found directx to be about 1/4 to 1/2 opengl performance.

regards


brad

#14 @Brad - Hope you didn't think my questions were aimed at you or anything. I'm seriously interested in the Dx vs. OpenGL question in Torque because we are about to ship ThinkTanks and I'd like to not include DirectX if at all possible since most people will get piss poor performance if they accidentally turn it on (they don't need to know whether they are running Dx or OpenGL). But I hear your gripe. A lot of people have suggested a shallow gfx layer would have been nice...would make it easier to replace the OpenGL code with DirectX. I know some people have worked on such a thing, but I don't think anyone has shared their solution just yet.

#15 Clark, I didn't take any offense, sorry if I sounded terse, I was just tossing in a response, I think the directX support in torque is not worth the effort, I am probably going to rip it out of my game, it's that bad. One of the goals I have for my game is hardware shaders and I doubt I'd be able to do it in both anyway, so opengl it is... just wish the (#&$(*&#$ opengl consortium wasn't so slow, because currently both ATI and nVidia have thoughtfully registered totally different and incompatable opengl extensions, and unless they listen to reason and opengl 2.0 comes out right, opengl developers will have to jump through hoops to code for both branches of card, not to mention any also-rans that join the picture.

I am also considering the huge task of dragging the rendering back a step (as you mentioned), abstracting it more and going that route, I have a good example in front of me, but it pushes my experience too far for me to comfortably say I can/will do it. Then again usually by the time I feel comfortable in something I kick myself for overestimating the complexity.

I am going back and forth here, I'm still groking the source, and defining a plan. So apologies if I am rambling.

the directX wrapper seems to be from quake source and targets DX7, I don't blame the torque/sierra/whoever guys for not worrying about shaders, as no one really has used them, hell most games these days require dx8 only for the directplay and directinput they have made no changes to their direct3d, but I remember this, I remember the first pass through Voodoo card, I was the first person I knew to have one, I was also the first person to post the user's experience on usenet, (GLQUAKE OH MY GOD!!!!!).. that thread took up the whole newsgroup for 2 weeks.. heh. I remember people who hadn't seen it thinking it was just faster.. in fact a lot of companies (ATI included, and was the worst of these) sold people psuedo 3d accelerators that perhaps did push a few more triangles if you used their SDK but weren't real 3d accelerators, so it was almost 2 years before people even realized the potential. I think it's the same way here. I remember bethesda's tech lead smugly grinning that his software renderer was better than glquake (this was right after daggerfall 2 was out the game he was working on was a terminator based game, which launched as an fps non accelerated in the days when almost all were, it managed to fail and look very bad all at once, it was impressively behind the times). I questioned his sanity at first, and later I figured he just hadn't *looked* at glquake or any glide demos.

I understand GG's stand, it's a big big thing to spend time on because *if* you start doing it right now, you will have to redo it later when all the #*$#$ standards have settled down. *Unless* you do just directx.. and there goes linux and macos..

and just to make sure I don't piss anyone off, Jeff is right, gameplay beats graphics anyday, good art in a slightly dated engine will beat out fancy shiny dot3vertexbumpwarpdrivespinning engine if it's done by a clown.

now I'm officially babbling... getting ready for GDC and drunken conversations.

-brad

#16

Quote:Has anyone ever found a machine in which the Torque ran under DirectX but not OpenGL?

You might want to float Brian Ramage a message, Clark. If I remember correctly, he had stripped out the entire OpenGL layer for Metal Drift. He was running all DirectX in Torque.

#17 Bradley. have you incorporated the speedup stuff that clark released a month or so ago?

I think most of us who care about this issue know WHY its slow, not much need to rehash the same arguments.

I'd just say, dont worry about it, concentrate on your game, and worry about performance when it comes time that you actually need to, i.e. when the game is pretty much done and youre not running fast enough.

Trying to fix everything thats "wrong" right now will mean you get nowhere.

PS: Try taking out terrain :)) its WAY fast.

Phil.

#18 Well I know why the dx support is slow, I just looked at it. Heh.

Theres a few pieces of code like this that does the opposite that I've used (DX -> opengl).


Just trying to find out where it's slow so I can make it unslow =D

-brad

#19

Quote:because currently both ATI and nVidia have thoughtfully registered totally different and incompatable opengl extensions

I'm curious, Bradley, which extensions are you having this problem with these days?

Most of the important ones are being unified under ARB. I'm starting to seriously look at adding hardware vertex/fragment programs to my Torque now that ARB_fragment_program is approved, and I'll probably add VAO once the ARB version of that is around.

Sure, it'd be nice if we had an EXT or an ARB version of occlusion query and such things, but they really aren't necessary.

#20 Just for some historical perspective - the DX dll was added on during the Tribes 2 dev process to support a small number of cards that either had really bad OpenGL drivers or had no OpenGL drivers. It's a hack - certainly not a good solution for general D3D support. We recommend its usage only as a fallback.

As we move forward, this is definitely an area of weakness in the engine that will be addressed.

- Mark