Engine - C++ or TorquScript

#1 With the source anything is possible.

Your idea/example of of mobile spawnpoint can be set up through script (probably by using triggers -- that's how I manage capturable spawn points) and selection can be random or done through a simple dynamic gui "pick spawn point#" kind of thing. The fadein/fadeout is built into the engine and only takes a script command to activate it for objects in the game.

There is a lot power inherent in Torque Script, and it has it's pro's and con's. The most fluid solution would be to use a combination of source code modification and script.

#2 That's good to know. I should add I own the 2D engine and I'm thinking about getting TGEA. I was reading about the Torque Script and I see that it's rather close to PHP, which I am familiar. I'm not much of a C/C++ gru though. But like php, I'm sure I can teach myself C.

Thanks for your help Mike. I'm sure once I get the TGEA I'll be here more often!

#3 As has been mentioned, anything can be achieved in the source. But TorqueScript is incredibly powerful. In fact, you could likely achieve most results you want in source through TorqueScript. Entire AI's, path finding algorithms, random-dungeon generation algorithms have all been written in script alone. The major problem is speed (for example, most of those path-finder's I said took anywhere from 0.5 to 2 seconds to process, which is far too much). Torquescript is much slower than the source code, I remember someone saying that on average, 1 line of script is equivalent to 7 lines of C++. The thing is generally, this amount of slowness is nothing for todays modern computers, you need to consider whether an action is really based around speed or not.

A good rule of thumb is that anything which will need to be done in several milliseconds (usually just because it's going to need to happen again in that amount of time) should be done in source. For example, physics simulations/collision detection (that is the repeated simulation and integration of physics, not simple onCollision() callbacks or applyImpulse() calls), path-finding, pretty much everything related to rendering.

For the example you mention, I would say that will work in script. You could keep a dynamic field of each Player's chosen spawn point, and in the spawn function spawn them at the location of the spawn point (and revert to a default one if they have none chosen/their chosen spawn point has been claimed by the enemy, etc...). There is a function which can fade the player in/out of invisibility over a period of time, sorry I can't recall the name at the moment. You can call this to set them invisible over 0ms (so it is instantaneous), and then call it again to happen over several seconds to fade them out; or just schedule it to call several seconds later but occur over 0ms so they "pop" into visibility, instead of fading.

#4 I can see why the Torque Engine won engine of the year. Like I said before, I don't own the TGEA - yet, not until my tax return. But I do have the demo version which I'm messing with. But I don't know if I can write scripts for the demo. Kind'a hope I can but if not I have a book coming in the mail.

I think I read some where that using a scripting language is about 7% slow then native. But for some of the ideas I have, such as the mobile spawn point. Or the player loosing blood over a period of time. There's nothing that I can think of right now that would be impacted by scripts. I could be wrong but I think I'm safe.

And while I'm posting about the engine. I read that TGEA supports a maximum texture size of 512x512? Is this true? It's not a huge worry as we are just trying to get out feet wet, but if it is, is there a way to bring the maximum texture size to 1024x1024. And does TGEA support DDS? All the examples I see use JPEG and PNG, which I understand could be because not every one can edit DDS.

Thanks guys.

#5

Quote:I think I read some where that using a scripting language is about 7% slow then native.

Maybe that was actually what I read, I know it involved a 7 :p.

There is no texture limit for TGE or TGEA, it's whatever a users hardware can support. You'll find a lot of referencing to 512 as upper limits in old documents as back when TGE was new, most new hardware would not handle texture's larger than this size. That's why a few of the GUI features (like GUIChunkedBitmap) will "chunk" an image into pieces smaller than 512x512 to be used, because it was more efficient back then. But it does not do this on any in-game textures.

I'm pretty sure it supports DDS. Try it out, I don't want my post to seem as some kind of guarantee it does, but I'm pretty sure.

#6 Well I gotta tell ya, my team, that being like 3 or 4 people, will be glad to hear this. Can't wait to get this into production!

Thanks Morrock.