Right, I remember you discussing that. I'm hugely surprised; I always figured I/O was a much bigger bottleneck in almost every case.

We all always figured that, and maybe it is a larger bottleneck in multiplayer, but even in single player mode (in which Torque fakes a connection to itself using a special internal thing, with no real bandwidth limitations compared to a network connection, for server<->client communication) we have always had performance issues.

Though the theory we had regarding update problems was more that it takes too much CPU time to traverse the scenegraph LOOKING for updates, but again, in profiling that barely showed up.

From the few games I've played on Linux I am definitely of the impression that the graphics subsystem was the biggest factor effecting frame rate.

Will you also open up the scripting side a bit more so we can have modules and more control over the engine kinda like lua in gmod?

FreeBuild has been designed to make modding really easy, and to promote modularity. The dynload system, for example.

Modders are gonna have plenty to play with once physics have been integrated. More so than in Blockland I dare say, as you won't have a limited add-on system that has to run through a secure script-base; you can pretty much re-write the entire game if you damn well want to, as I'm actually doing now as a demonstration.

Yup, and since you're not literally rewriting the game engine itself, there's no violation of the GarageGames/Torque license.

Oh, right. Maybe I should rephrase that.

Edit- done.

Much better, sir. As always, Elfprince, let me/us know if you need any help with anything, code, algorithm, or testing-wise.

actually....if you (or anyone) really want to help with algorithms, it would be possible to start modifying the OpenSceneGraph renderer to make use of CHC++ without access to any of the Torque engine code. That would be a significant undertaking, but CHC++ example source code is available here, and the paper describing it is here.

OSG can be downloaded from here and an intro to programming with OSG is here, including important concepts like StateSets, NodeVisitors, and (I think) multiparented nodes.

This is probably the only one of the 3 potentially significant undertakings before the overhauled engine is ready that can be done without access to the TGE code. It is also worth mentioning that I suspect this algorithm will go a long way towards cutting the poly-count down, as far as stud/tube primitives are concerned. I *think* because the stud/tube geometry is stored in a separate node from the brick outline, they should be treated as occluded by the bounding volume of the brick above them, and that because this information will tend to be static, the algorithm's exploitation of temporal coherency should allow it to cache that information and save on both occlusion queries and a huge number of polygons. I may email the authors of the paper to double check that a bounding volume within a larger bounding volume will be treated as occluded by the larger.

[edit]
Also, this is an exam/project week, so progress between now and next saturday will be sporadic, but I'll try and schedule time in as I think I can manage.

I mean would we be able to do something like this.
and by modules I mean DLLs so we can hook directly into the engine.

Now you're thinking with POR-TALS.

Stencil Buffers are so awesome.

Anywho, getting back on topic, you won't be able to hook DLLs into the engine, but you will be able to use TorqueScript via DynLoad.

D'aawww

Why would you want to use DLL modules anyway? I don't know of a way that Torque can be extended using modular compiled code anyway.

Well instead of asking Elf to edit the engine to do this and that whenever we need a new feature we can just create modules so he doesn't have to do it for us.

An example would be if a server needed a edit of the engine for a flying player class they could just hook in with their DLL and do it themselves.

Well yeah, but that sort of requires access to the engine source code, which Elf's Torque license forbids him to allow open access to.

We wouldn't need access to the engine source code?

Well, a module needs to plug into something, like some subsection of the engine, and to do that you'd need to know a nonzero number of things about how the engine works, what functions it has, and some of the abstractions that it contains.