Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
elfprince13 wrote:
KermMartian wrote:
Yeah, I figured I was, but that is still most excellent to hear. I think that event-driven network updates are going to make a huge difference, too.


I'm sure it will help too, especially on the truly enormous builds, but honestly it wasn't even a blip on the radar compared to the magnitude of the problem with the rendering pipeline when I was profiling the bottlenecks in Cemetech tower. I seem to remember that TSMesh::render() was taking over 60% of the CPU time.
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.
elfprince13 wrote:
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?
Jimmg wrote:
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.
DShiznit wrote:
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 literally 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.
DShiznit wrote:
Oh, right. Maybe I should rephrase that.

Edit- done.
Much better, sir. Smile 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.
elfprince13 wrote:
Jimmg wrote:
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.

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.

jimmg wrote:
[video]
Now you're thinking with POR-TALS.
KermMartian wrote:
jimmg wrote:
[video]
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
Jimmg wrote:
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.
KermMartian wrote:
Jimmg wrote:
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?
Jimmg wrote:
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.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 3 of 13
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement