eugene2k

and unused code will be sitting in RAM, not in your processor's cache; compared to other game assets I think the code is probably the smallest memory worry. As for faster startup times, I'm very skeptical that you'll gain much. Bigger gains are to be had optimising the code that does run rather than removing code that doesn't.

I agree with all that. I suppose I was a bit unclear, though. There's a lot of stuff done in TS that should be implemented inside the engine. And while it would make the engine a tiny fraction more efficient, the biggest gain would be that that particular bit of code will be easier to maintain than the whole TS + Needlessly exported functions mess. Case in point: adding a new scripting language would've been a lot easier if a bare-bones torque app didn't have 1MB worth of scripts :) Thanks for the t3d-bones branch, by the way. Now I don't have to go the long way trying to figure out what is actually needed in a bare-bones Torque app.

Ehh... Not saying I will be able to get Lua integrated. I set my goals high, so that I could achieve more by the time I give up on the goal :)

And thanks for responding. I'm not trying to argue either, just trying to figure out if I'm missing something in my line of thinking.

How should I say this... I'm primarily studying Torque's architecture, since there's no design manual and no comments in the code as to why something was done one way and not the other. Just by looking at the code of a shipped commercial product one can't tell whether a certain part of the code was a conscious design decision or just someone being lazy or if this was a design decision born out of some concrete need instead of an imaginary one.

Why would the end-user need to select a different subsystem, though? The days when OpenGL handled stuff differently than Direct3D are pretty much dead and gone. Both APIs nowadays support essentially the same features. I think it's the same with sound APIs. And further, I said it in the previous post already, but if you want to offer the user a way of switching between two subsystems, it can be done with an in-engine function that is geared specifically for that, instead of a collection of functions.

And the purpose to having the subsystem initialization requested at load time by script is so that you load the ones you want. If you don't want it initialized just remove it from the startup script - problem solved. Now you don't have to have a version of the engine built just for every possible system combination....

Well, that seems to be the only logical reason to have it there. Only I doubt that's very efficient. How hard is it to reconfigure the project, really? In CMake all you need to do is set some variables and then execute two commands. And that's it, you're set: you can now do what you need to do in the script while also having an engine that is custom-fitted to your needs. No redundant code sitting in the memory and never being used, faster loading times. I see only benefits in this approach.

You disable the sound at runtime in the process of swapping sound subsystems, like openAL to Fmod, for instance. Physics aren't swappable, and graphics are only checked with a fallback.

And yet both physics and graphics need to be initialized in the script. As for swapping the sound engines: I agree that you need to reinitialize sound after doing that, however, personally I would have put a function in the script that specifically does this, instead of having something like this:

/* from Templates/Empty/game/scripts/main.cs */
  // Init the physics plugin.
  physicsInit();

  // Start up the audio system.
  sfxStartup();

  // Server gets loaded for all sessions, since clients
  // can host in-game servers.
  initServer();

  // Start up in either client, or dedicated server mode
  if ($Server::Dedicated)
     initDedicated();
  else
     initClient();

That tangent out of the way, study

Thx for the links. My brain shut down when I first looked at the DefineConsole/Engine macros. Buffer overflow :D

"Disable the sound subsystem" vs "mute the sound". There's a serious difference between the two. In fact I don't think there is a game out there that disables the sound subsystem altogether at runtime (hell, I don't think there's a game out there that disables the sound subsystem period)

"The larger question is this" - not really. It's a learning experience for me. I'm interested in knowing how the scripting subsystem works, I know there's a number of people who would like to have Lua as an alternative, myself included, so the most straightforward thing to do would be to set this as a goal and try to analyze the code involved. After all it's unlikely that I'll find out anything about the internals of the scripting subsystem if I try making a game in Torque or if I add a new shader.

As it happens I also wanted to try and make Lua an option for torque. So here I am today, looking at all the *.cs files and wondering: wtf? :)

I'm not familiar with torque as an engine, but it seems to me kind of backwards to have all the subsystems initialized in the scripts. It makes no sense to me why Torque does that. Why is all this stuff done in the script as opposed to doing it in the engine internally? If you want to disable sound or physics in the engine, isn't it much easier to do so at compile time?