There's a fair bit of code in the rendering pipeline that uses these two systems. If I understand correctly (which I probably don't) creg has something to do with syncing between clients and GML is a multithreaded opengl.
System/creg/creg.h talks of "registering", "binding" and "serializing" a lot but nothing about WHY you need to do any of that, when it's necessary, etc.
For GML I can't find anything at all. Presumably that's because it's just a single #define followed by a series of alternate code paths spread throughout the rendering code. Is there any general documentation on why it's needed, how to use it, etc? A forum search returns nothing, presumably because the string 'GML' is too short to be indexed or the search is busted. Wiki search was equally useless.
Unfortunately that's about the limit of my understanding. Could the esteemed devs please give me a rundown of these techs and pointers to any documentation or notes regarding their implementation, gotchas, etc.
I'll take anything right now. A general overview or a 20 page treatise, links, chat logs, notes anything.
Looking for GML and CReg information
Moderator: Moderators
Re: Looking for GML and CReg information
CREG is part of saving amongst other things
-
BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
Re: Looking for GML and CReg information
creg implements reflection in c++
gml is the opengl threading library
for gml, ask zerver, or dig in this 24 pages thread
gml is the opengl threading library
for gml, ask zerver, or dig in this 24 pages thread
Re: Looking for GML and CReg information
Thanks BD. That thread link is excellent. I also found the gml source in rts/lib/ so between the two I now have the WHY and the HOW of GML.
Having just skimmed the thread (will read in depth later), I'm inclined to think a rendering engine rewrite can overcome the need for GML (at least in its current form) by moving the ENTIRE rendering system to its own thread. Combined with more GPU and DMA offloading via VBOs and shaders this thread should never really do much work anyway.
The only parts of the current system that requires sync are the collision volumes, radius, height and pieces. The pieces are used for scripting, weapons, certain projectiles and attachment points. At the end of each frame the transformed piece data can be passed back to the rendering thread. The sim would use a mutex to make sure the renderer blocks while the pieces are updated.
This doesn't mean the model loader can't be threaded (even given a thread per import) provided it can return the piece data to the sim in a timely and reliable manner (if it can't do that the sim would be paused/desynced anyway). The only way I can see to do this right would be for unit creation to be delayed until all clients acknowledge a successful model load. The acknowledgment packet could even include a hash of the loaded pieces so every client knows they parsed the model correctly. I'd probably have the sim queue the build/fire order until the data was confirmed so there is no visible lag when a unit is first built or a piece projectile first fired (just order lag).
I don't think I need to worry too much about creg either. There wouldn't be much in the rendering system worth saving, synchronising or sending.
Having just skimmed the thread (will read in depth later), I'm inclined to think a rendering engine rewrite can overcome the need for GML (at least in its current form) by moving the ENTIRE rendering system to its own thread. Combined with more GPU and DMA offloading via VBOs and shaders this thread should never really do much work anyway.
The only parts of the current system that requires sync are the collision volumes, radius, height and pieces. The pieces are used for scripting, weapons, certain projectiles and attachment points. At the end of each frame the transformed piece data can be passed back to the rendering thread. The sim would use a mutex to make sure the renderer blocks while the pieces are updated.
This doesn't mean the model loader can't be threaded (even given a thread per import) provided it can return the piece data to the sim in a timely and reliable manner (if it can't do that the sim would be paused/desynced anyway). The only way I can see to do this right would be for unit creation to be delayed until all clients acknowledge a successful model load. The acknowledgment packet could even include a hash of the loaded pieces so every client knows they parsed the model correctly. I'd probably have the sim queue the build/fire order until the data was confirmed so there is no visible lag when a unit is first built or a piece projectile first fired (just order lag).
I don't think I need to worry too much about creg either. There wouldn't be much in the rendering system worth saving, synchronising or sending.
Re: Looking for GML and CReg information
as much as i know, creg is ONLY used for saving/loading games.
It is ugly, which explains why it is currently broken (loading/saving).
So yeah... do not worry too much about that.
It is ugly, which explains why it is currently broken (loading/saving).
So yeah... do not worry too much about that.
Re: Looking for GML and CReg information
And CEGs (custom explosion generators).
But for that, only the metadata for all projectile classes matters.
But for that, only the metadata for all projectile classes matters.
Re: Looking for GML and CReg information
It is a 24 page thread so you are excused for not getting to this part yet, but the Sim is in its own thread already. What is left in the other thread is mostly the rendering and some user input related code.SpliFF wrote:Having just skimmed the thread (will read in depth later), I'm inclined to think a rendering engine rewrite can overcome the need for GML (at least in its current form) by moving the ENTIRE rendering system to its own thread. Combined with more GPU and DMA offloading via VBOs and shaders this thread should never really do much work anyway.
Re: Looking for GML and CReg information
Yeah it'll take me a while to come to grips with where GML is at but I take from posts near the end of your other thread that it's pretty close to being stable (though not stable enough to avoid occasional desync).
If I got this right GML is a sort of hack to proxy GL commands from threads that don't render to those that do.
That means the primary difference between your approach and my proposal is simply that the boundary would be crossed using higher level functions than proxies for gl*. Obviously then the two methods can co-exist quite happily.
If I got this right GML is a sort of hack to proxy GL commands from threads that don't render to those that do.
That means the primary difference between your approach and my proposal is simply that the boundary would be crossed using higher level functions than proxies for gl*. Obviously then the two methods can co-exist quite happily.