Several questions about torque tech (limits)
by Jukka Kokkonen · in Torque Game Engine · 02/23/2005 (3:44 pm) · 8 replies
I've been looking at the torque demo apps for a few days now trying to figure if torque would a good development platform for my "hobby" (shareware/freeware) game. Now, quite a few question have come to my mind when playing with the demos:
1) What's with the torque OpenGL renderer efficiency...? For some reason, it seems to be a lot less efficient than the Direct3D renderer. This seems to be the case especially when there are some animated characters on the screen. At least for me, the OpenGL renderer has a significant framerate drop when there is a single character on the screen (basically meaning that any multiplayer game would hardly run fast enough). However, with the Direct3D renderer, there is basically no framerate drop at all... I don't really know why this is the case, but I'm guessing the D3D renderer might be using hw vertex shaders for animation, whereas the OpenGL renderer does that using software. (but this is just guessing). Should I be worried about this, if I intend to make a portable Windows/Linux/Mac platform game? (In which case the OpenGL is probably the more commonly used renderer.) I've been testing on a GF4Ti series card btw.
2) How does the torque netcode work in basic principle? Is it some kind of game-server / UI-client solution? (Instead of some kind of synced-game on every peer solution.) I'm interested in this to figure out how much the game would take performance hit if there were some players (~16-32 maybe) and a lot of bots (~50-200?) on same server, and also to figure out how easy this would be to implement. If basically all the gameplay is happening on the server, then I guess the implementation should be easy and the bots could perhaps be optimized to be updated only on those clients that are near the bot.
3) How much does the torque engine take "performance hit", if I were to move/insert/delete the mission objects on-the-fly (moving trees, walls, etc.).
The engine seems to be able to make changes to the map while the game is running, but I don't know how costly these changes are on performance and if all kinds of changes are possible. Specifically, can buildings (containing interiors) be moved/created/deleted without things breaking up?
4) Space partitioning... How does torque partition the mission space? The heightmap size obviously does not affect performance (as it is nicely partitioned into a grid), but what's the case with buildings and other objects (trees and rocks). Are they partitioned into some kind of grid/quadtree/... data-structures? Or does a bunch of trees on the other side of the map cause the game to slow down on the other side too? I hope not. :-) Being able to have a lot of trees and stuff would be a must in my case.
5) Alphatesting? I didn't see any alphatested objects in the demo... There are alphablended ones though (tree leaves). Surely it would be no biggie adding alphatest support too, but if it happened to be readily implemented in the engine, I would save time not having to tweak the renderer too much. So does torque already support alphatested surfaces? (As it would help the effectiveness of all those trees I was thinking of adding.)
6) How easy is it to modify the torque GUI system for custom graphics? Is there need to create custom widgets or does it natively support the use of special images for button backgrounds, fonts, etc. Shortly: Can I create a totally custom look for the GUI without having to code that?
7) How much of ready-made code is there with torque... Does all of the code used to make those torque fps/rally demo apps come with the license? This including the lobby system (with code for building a master server)?
8) Are the vehicle physics just "vehicle specific" or more general... Could they possibly be used for some other (much more common) object physics? (For boxes and stuff.) I'm assuming the vehicle physics don't have any special stacking support?
If you can answer even some of the questions, many thanks in advance.
(Sorry for the very long post.)
- J. Kokkonen
1) What's with the torque OpenGL renderer efficiency...? For some reason, it seems to be a lot less efficient than the Direct3D renderer. This seems to be the case especially when there are some animated characters on the screen. At least for me, the OpenGL renderer has a significant framerate drop when there is a single character on the screen (basically meaning that any multiplayer game would hardly run fast enough). However, with the Direct3D renderer, there is basically no framerate drop at all... I don't really know why this is the case, but I'm guessing the D3D renderer might be using hw vertex shaders for animation, whereas the OpenGL renderer does that using software. (but this is just guessing). Should I be worried about this, if I intend to make a portable Windows/Linux/Mac platform game? (In which case the OpenGL is probably the more commonly used renderer.) I've been testing on a GF4Ti series card btw.
2) How does the torque netcode work in basic principle? Is it some kind of game-server / UI-client solution? (Instead of some kind of synced-game on every peer solution.) I'm interested in this to figure out how much the game would take performance hit if there were some players (~16-32 maybe) and a lot of bots (~50-200?) on same server, and also to figure out how easy this would be to implement. If basically all the gameplay is happening on the server, then I guess the implementation should be easy and the bots could perhaps be optimized to be updated only on those clients that are near the bot.
3) How much does the torque engine take "performance hit", if I were to move/insert/delete the mission objects on-the-fly (moving trees, walls, etc.).
The engine seems to be able to make changes to the map while the game is running, but I don't know how costly these changes are on performance and if all kinds of changes are possible. Specifically, can buildings (containing interiors) be moved/created/deleted without things breaking up?
4) Space partitioning... How does torque partition the mission space? The heightmap size obviously does not affect performance (as it is nicely partitioned into a grid), but what's the case with buildings and other objects (trees and rocks). Are they partitioned into some kind of grid/quadtree/... data-structures? Or does a bunch of trees on the other side of the map cause the game to slow down on the other side too? I hope not. :-) Being able to have a lot of trees and stuff would be a must in my case.
5) Alphatesting? I didn't see any alphatested objects in the demo... There are alphablended ones though (tree leaves). Surely it would be no biggie adding alphatest support too, but if it happened to be readily implemented in the engine, I would save time not having to tweak the renderer too much. So does torque already support alphatested surfaces? (As it would help the effectiveness of all those trees I was thinking of adding.)
6) How easy is it to modify the torque GUI system for custom graphics? Is there need to create custom widgets or does it natively support the use of special images for button backgrounds, fonts, etc. Shortly: Can I create a totally custom look for the GUI without having to code that?
7) How much of ready-made code is there with torque... Does all of the code used to make those torque fps/rally demo apps come with the license? This including the lobby system (with code for building a master server)?
8) Are the vehicle physics just "vehicle specific" or more general... Could they possibly be used for some other (much more common) object physics? (For boxes and stuff.) I'm assuming the vehicle physics don't have any special stacking support?
If you can answer even some of the questions, many thanks in advance.
(Sorry for the very long post.)
- J. Kokkonen
#2
And you suppose wrong : TGE uses no shaders, be it in OGL or d3d, it's fixed function renderer that was written in the GeForce 1/2 era.
It's always surprising to hear people say things are running faster on d3d in TGE, because it's completely counterintuitive to what's going on renderer wise in TGE :)
TSE has an advanced, redesigned, and for the time being, D3D9 only renderer that supports HLSL, but I guess that's not what you're talking about since it has no OpenGL support, yet.
You could just use the TGE demo with which you've been tinkering so far, and prototype your game in it :)
Once you think it's the way to go for you, get a license. Or get one anyway : at a 100 dollars, it's worth it just for being able to learn from the code, etc.
Hope this helps, and have fun :)
02/23/2005 (4:54 pm)
If you're talking about TGE, there is no specific D3D renderer, rather it's using a derivative from the quake opengl to d3d wrapper, that basically "wraps" OpenGL calls to their D3D equivalent. And you suppose wrong : TGE uses no shaders, be it in OGL or d3d, it's fixed function renderer that was written in the GeForce 1/2 era.
It's always surprising to hear people say things are running faster on d3d in TGE, because it's completely counterintuitive to what's going on renderer wise in TGE :)
TSE has an advanced, redesigned, and for the time being, D3D9 only renderer that supports HLSL, but I guess that's not what you're talking about since it has no OpenGL support, yet.
You could just use the TGE demo with which you've been tinkering so far, and prototype your game in it :)
Once you think it's the way to go for you, get a license. Or get one anyway : at a 100 dollars, it's worth it just for being able to learn from the code, etc.
Hope this helps, and have fun :)
#3
>3) Adding normal objects (rocks, trees, etc) has never seemed to have any sort of performance impact. Dynamically adding interiors though... The issue with them is not adding them, it's that they light via precalculated lightmaps. So, when you first add one it is pitch black until you do a mission relight which takes a great deal of time.
>6) Yes. Torque allows you to assign bitmaps to buttons and such.
>8) http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5495
02/23/2005 (5:28 pm)
>2) The number of players you're talking about is pretty trivial for Torque. Well, human players. The general consensus is that Torque is good up to 128 players, but if you're willing, it isn't that hard to push that limit even higher. Oh, and you're either going to have to write your own AI code or wait for the AI pack. Torque's AI extends to "follow this predetermined path".>3) Adding normal objects (rocks, trees, etc) has never seemed to have any sort of performance impact. Dynamically adding interiors though... The issue with them is not adding them, it's that they light via precalculated lightmaps. So, when you first add one it is pitch black until you do a mission relight which takes a great deal of time.
>6) Yes. Torque allows you to assign bitmaps to buttons and such.
>8) http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5495
#4
I guess I'll be playing around a bit more with the demo and then probably buy the indie license... Not sure if I'm ever gonna get anything done with it, but the 100$ license is so cheap that it's not an issue.
I'm sure all my questions will be pretty much answered once I get the code and start learning how it works.
And what comes to the torque rendering speed of OpenGL/D3D - Yes, the Direct3D "renderer" is faster than the OpenGL renderer for me, regardless of the details of how they are implemented... I guess there has to be something "incompatible" with torque and my computer / display drivers to get the OpenGL driver so jammed up. Actually, when I've tried some other games made with torque (such as Lore), the OpenGL renderer is totally unusable (the FPS drops to somewhere around 1-2). That effect does not happen with the D3D renderer. (Note, that I've had no problems with any other OpenGL software, so it seems to be something concerning Torque.)
Also, a similar effect seems to happen when I try to export my own models to torque DTS files... Viewing those files in the Torque show tool pro (demo) drops the framerate around 1-5 fps (even when the models contain no more than about 2000 polygons). Viewing the orc model that comes with Torque demo runs much faster but still at no more than about 50 fps (which is not very good considering the low polygon count). I guess this may be due some error I have made in exporting my models, but considering the somewhat low framerate even for the Orc model, I think it once again has something to do with the OpenGL renderer.
If I happen to find out the reason for the low framerates when using the OpenGL renderer, I'll be sure to post it here, but more likely the reason will remain a mystery forever... This framerate problem is, however, a bit annoying as it makes any development much more problematic.
02/25/2005 (9:33 am)
Thanks for the quick replies... They've been useful.I guess I'll be playing around a bit more with the demo and then probably buy the indie license... Not sure if I'm ever gonna get anything done with it, but the 100$ license is so cheap that it's not an issue.
I'm sure all my questions will be pretty much answered once I get the code and start learning how it works.
And what comes to the torque rendering speed of OpenGL/D3D - Yes, the Direct3D "renderer" is faster than the OpenGL renderer for me, regardless of the details of how they are implemented... I guess there has to be something "incompatible" with torque and my computer / display drivers to get the OpenGL driver so jammed up. Actually, when I've tried some other games made with torque (such as Lore), the OpenGL renderer is totally unusable (the FPS drops to somewhere around 1-2). That effect does not happen with the D3D renderer. (Note, that I've had no problems with any other OpenGL software, so it seems to be something concerning Torque.)
Also, a similar effect seems to happen when I try to export my own models to torque DTS files... Viewing those files in the Torque show tool pro (demo) drops the framerate around 1-5 fps (even when the models contain no more than about 2000 polygons). Viewing the orc model that comes with Torque demo runs much faster but still at no more than about 50 fps (which is not very good considering the low polygon count). I guess this may be due some error I have made in exporting my models, but considering the somewhat low framerate even for the Orc model, I think it once again has something to do with the OpenGL renderer.
If I happen to find out the reason for the low framerates when using the OpenGL renderer, I'll be sure to post it here, but more likely the reason will remain a mystery forever... This framerate problem is, however, a bit annoying as it makes any development much more problematic.
#5
2) Already given, I have no doubt you'll be more than pleased with the netcode
3)Little objects don't seem to affect it much, though interiors are another matter, as mentioned by another... there are some resources out there that deal with "pathed interiors" etc... so its re-workable if you choose to put the effort in.
4) fxShapeReplicator is very nice for many objects... considering it sends the replicator to the clients so the client can then reproduce the "random" (though determined by you) placement without sending each tree (or shape) position.
6) GUI is much more powerful than what your even hoping for ... I've been very impressed with it on many occasions... I mean someone even got flash working in the GUI lol
if you check out some of my previous plans I have a picture of a journal system I'm working on in the GUI... good example of acheiving a very different look thats interactive
7) You get all of the demos... tons and tons of resources, snippets, documentation... and access to the private forums (a treasure for sure)
02/25/2005 (10:43 am)
1) Alot of this is due to video card... driver versions etc... ATI cards tend to run OpenGL better than NVidia... and I know I've seen a few drivers I've loaded that offer two different type of OpenGL support... one entitled "Special" which is for older games (this works much better for Torque)... so it may be your drivers aren't very compatible... TSE has some very nice improvements upon this (in my opinion)2) Already given, I have no doubt you'll be more than pleased with the netcode
3)Little objects don't seem to affect it much, though interiors are another matter, as mentioned by another... there are some resources out there that deal with "pathed interiors" etc... so its re-workable if you choose to put the effort in.
4) fxShapeReplicator is very nice for many objects... considering it sends the replicator to the clients so the client can then reproduce the "random" (though determined by you) placement without sending each tree (or shape) position.
6) GUI is much more powerful than what your even hoping for ... I've been very impressed with it on many occasions... I mean someone even got flash working in the GUI lol
if you check out some of my previous plans I have a picture of a journal system I'm working on in the GUI... good example of acheiving a very different look thats interactive
7) You get all of the demos... tons and tons of resources, snippets, documentation... and access to the private forums (a treasure for sure)
#6
It was indeed caused by nvidia's drivers. I downloaded the latest drivers (beta I think), and now the OpenGL renderer is running even faster than the Direct3D.
The reason for me not using the latest drivers earlier, was that somehow nvidia managed break those drivers in such way, that Direct3D totally ceased to function with my GF FX5200 (apparently a quite common problem with the latest nvidia drivers). So I had to go back to earlier drivers.
I guess rendering performance won't be a problem with torque now that the drivers are running ok... :-)
Maybe now all the other demo apps, such as the lighting pack, would start running at a sensible framerate... Gotta go try them out.
02/26/2005 (3:06 pm)
Ok, the question number 1 solved...It was indeed caused by nvidia's drivers. I downloaded the latest drivers (beta I think), and now the OpenGL renderer is running even faster than the Direct3D.
The reason for me not using the latest drivers earlier, was that somehow nvidia managed break those drivers in such way, that Direct3D totally ceased to function with my GF FX5200 (apparently a quite common problem with the latest nvidia drivers). So I had to go back to earlier drivers.
I guess rendering performance won't be a problem with torque now that the drivers are running ok... :-)
Maybe now all the other demo apps, such as the lighting pack, would start running at a sensible framerate... Gotta go try them out.
#7
This means that, if your monitor's refresh rate is set at 60Hz, and the game is running at 58fps, you'll see the game running at 58fps in D3D, with some tearing, and running at 30fps under OpenGL.
03/01/2005 (12:11 pm)
Usually Nvidia drivers will have Vsync set to "always on" for OpenGL and "off by default" to Direct3D applications.This means that, if your monitor's refresh rate is set at 60Hz, and the game is running at 58fps, you'll see the game running at 58fps in D3D, with some tearing, and running at 30fps under OpenGL.
#8
The problem is though, that I am pretty much forced to use those old slow drivers, because the new nvidia drivers (6x.xx version series) seem to be even more screwed up and cause Direct3D (version 7 interfaces) to totally malfunction on my computer. :-)
I'm hoping for the next nvidia driver release to fix this problem so that I too can enjoy both good framerates of the Torque OpenGL driver and still have all the Direct3D apps working.
03/02/2005 (12:44 pm)
This time the problem was not vsync, the reason was that nvidia drivers (5x.xx version series) were somehow screwed up and were really slow in torque (when using OpenGL). There seemed to be some other earlier posts about this same issue here on gg forums.The problem is though, that I am pretty much forced to use those old slow drivers, because the new nvidia drivers (6x.xx version series) seem to be even more screwed up and cause Direct3D (version 7 interfaces) to totally malfunction on my computer. :-)
I'm hoping for the next nvidia driver release to fix this problem so that I too can enjoy both good framerates of the Torque OpenGL driver and still have all the Direct3D apps working.
Torque Owner Eric Lavigne
www.garagegames.com/articles/networking1/
>7) How much of ready-made code is there with torque... Does all of the
>code used to make those torque fps/rally demo apps come with the
>license? This including the lobby system (with code for building a
>master server)?
All that and much more. The amount of code and documentation you get is really incredible.
>8) ...
Boxes that stack? Sounds rather trivial actually. You don't need anything as complicated as vehicles for that.