You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(15) |
Aug
(15) |
Sep
|
Oct
(12) |
Nov
(3) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Charles L. <ch...@cn...> - 2009-08-22 15:18:46
|
Additionally, I feel it would be pretty cool to let the user intentionally leave textures bound. They could add the texture to a parent node, then have it be applied to all of the children. I think it is a very simple solution. We just do exactly what I outlined, and we have to add some mechanism to turn textures off, like the texture has some flag in the XML that just means it's a texture disabler. I can make all of these changes very quickly if you give me the green light. Charles Josh wrote: > This is actually what I am currently looking into. > I'm trying to figure out if you can just leave textures bound and just > enable or disable them. > If we can do that, then we cold make use of the maximum number of bound > textures to reduce binds. > > Josh > > > Charles Lohr wrote: > >> Devs, >> >> I have been examining the pipeline for textures. I have found that >> there is a large slow down whenever binding/unbinding textures. I also >> feel that there is little need to have the textures always clean up >> after themselves, as it would enable a scene optimizer to group like >> objects. Simply by asking "is the current texture the one that is >> active right now" we can avoid having to disable textures and re-deploy >> them when done. In a case like the field of lamps, we are able to >> bypass the field. It would also make it possible to have the texture be >> a persistent item, and having it pass on to its children. >> >> I propose: >> We do not unbind textures from OpenGL (until in the future we have an >> option where a texture is a some sort of TEXTURE OFF thing) >> We store a static pointer to the currently OpenGL binded texture. >> When we bind a texture, we set that. When we encounter a texture that >> has already been set, take no action. >> >> By performing this, the GL call count was less than half (now it's just >> over 1k per scene) >> >> I ran a few tests where I made the window small, thus avoiding pixel >> fill time. >> >> >> Without profiling, dumb textures: >> FPS: 1089.498779, VBO batches 95.000000, TBinds 94.000000, VBinds 5.000000 >> >> Without profiling, smart-ish textures, smart matrixing: (Textures bind >> always, but never unbind) (smart matrix means only updating the matrix >> info if the object has assets attached to it) >> FPS: 1449.908691, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 >> >> Without profiling, smart textures: (Textures never unbind, and only bind >> when needed) >> FPS: 1667.601440, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 >> >> Without profiling, smart textures, smart matrixing: >> FPS: 1759.813477, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 >> >> >> Charles >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Hgengine-devs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >> >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
From: Josh <axl...@gm...> - 2009-08-22 11:59:40
|
This is actually what I am currently looking into. I'm trying to figure out if you can just leave textures bound and just enable or disable them. If we can do that, then we cold make use of the maximum number of bound textures to reduce binds. Josh Charles Lohr wrote: > Devs, > > I have been examining the pipeline for textures. I have found that > there is a large slow down whenever binding/unbinding textures. I also > feel that there is little need to have the textures always clean up > after themselves, as it would enable a scene optimizer to group like > objects. Simply by asking "is the current texture the one that is > active right now" we can avoid having to disable textures and re-deploy > them when done. In a case like the field of lamps, we are able to > bypass the field. It would also make it possible to have the texture be > a persistent item, and having it pass on to its children. > > I propose: > We do not unbind textures from OpenGL (until in the future we have an > option where a texture is a some sort of TEXTURE OFF thing) > We store a static pointer to the currently OpenGL binded texture. > When we bind a texture, we set that. When we encounter a texture that > has already been set, take no action. > > By performing this, the GL call count was less than half (now it's just > over 1k per scene) > > I ran a few tests where I made the window small, thus avoiding pixel > fill time. > > > Without profiling, dumb textures: > FPS: 1089.498779, VBO batches 95.000000, TBinds 94.000000, VBinds 5.000000 > > Without profiling, smart-ish textures, smart matrixing: (Textures bind > always, but never unbind) (smart matrix means only updating the matrix > info if the object has assets attached to it) > FPS: 1449.908691, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 > > Without profiling, smart textures: (Textures never unbind, and only bind > when needed) > FPS: 1667.601440, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 > > Without profiling, smart textures, smart matrixing: > FPS: 1759.813477, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 > > > Charles > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
From: Charles L. <ch...@cn...> - 2009-08-22 06:38:22
|
Devs, I have been examining the pipeline for textures. I have found that there is a large slow down whenever binding/unbinding textures. I also feel that there is little need to have the textures always clean up after themselves, as it would enable a scene optimizer to group like objects. Simply by asking "is the current texture the one that is active right now" we can avoid having to disable textures and re-deploy them when done. In a case like the field of lamps, we are able to bypass the field. It would also make it possible to have the texture be a persistent item, and having it pass on to its children. I propose: We do not unbind textures from OpenGL (until in the future we have an option where a texture is a some sort of TEXTURE OFF thing) We store a static pointer to the currently OpenGL binded texture. When we bind a texture, we set that. When we encounter a texture that has already been set, take no action. By performing this, the GL call count was less than half (now it's just over 1k per scene) I ran a few tests where I made the window small, thus avoiding pixel fill time. Without profiling, dumb textures: FPS: 1089.498779, VBO batches 95.000000, TBinds 94.000000, VBinds 5.000000 Without profiling, smart-ish textures, smart matrixing: (Textures bind always, but never unbind) (smart matrix means only updating the matrix info if the object has assets attached to it) FPS: 1449.908691, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 Without profiling, smart textures: (Textures never unbind, and only bind when needed) FPS: 1667.601440, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 Without profiling, smart textures, smart matrixing: FPS: 1759.813477, VBO batches 95.000000, TBinds 5.000000, VBinds 5.000000 Charles |
From: Josh <axl...@gm...> - 2009-08-20 10:46:16
|
Yes these improvements will only help with CPU bottlenecks. But I think there are many things that can be done to make much smarter use of opengl. I would much rather see a GPU bottleneck at this point. There are a lot of things that the CPU is not doing at this point (sound, physics, animations) which will be taking up time later. Josh Charles Lohr wrote: > I've just examined some changes when it comes to putting the burden on > the GPU and not. Reducing the quantity of certain calls, like > glLoadMatrix(...) did not seem to affect the performance at all when the > GPU was under load, however had a significant improvement when I shifted > the CPU back to being the bottleneck. > > 472 -> 472 > 772 -> 868 > > In order to reduce the overhead, I made the system only load the matrix > and update the shader if the specific node had children. Otherwise, it > just keeps going. > > This indicates to me that some (possibly many) of the OpenGL functions > we thought may have had something to do with stealing cycles from the > GPU, do not, that it is possible there may be another level of > pipelining going on here that we don't understand. > > Additionally, I feel as though we shouldn't strive excessively hard to > speed up the CPU if that's not the bottleneck, but the fact is, that in > the end, we should strive to make it as fast as possible because there > are always portions where it won't be the GPU that's bottlenecked, and > will in fact be the GPU waiting on the CPU. The two systems cannot be > totally decoupled. I feel we can learn a lot by examining the > performance changes both under GPU bottleneck (Window at 640x480) and > CPU bottleneck (Window at 50x50 or less). > > Sadly, I'm not sure how much we can push this, since we've seen examples > where doing more work can result in a higher framerate. > > Charles > > > Josh wrote: > >> Attached is a count of opengl API calls for a scene where most things >> are culled. >> I will be figuring out how to make this more efficient. >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Hgengine-devs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
From: Charles L. <ch...@cn...> - 2009-08-20 03:28:02
|
I've just examined some changes when it comes to putting the burden on the GPU and not. Reducing the quantity of certain calls, like glLoadMatrix(...) did not seem to affect the performance at all when the GPU was under load, however had a significant improvement when I shifted the CPU back to being the bottleneck. 472 -> 472 772 -> 868 In order to reduce the overhead, I made the system only load the matrix and update the shader if the specific node had children. Otherwise, it just keeps going. This indicates to me that some (possibly many) of the OpenGL functions we thought may have had something to do with stealing cycles from the GPU, do not, that it is possible there may be another level of pipelining going on here that we don't understand. Additionally, I feel as though we shouldn't strive excessively hard to speed up the CPU if that's not the bottleneck, but the fact is, that in the end, we should strive to make it as fast as possible because there are always portions where it won't be the GPU that's bottlenecked, and will in fact be the GPU waiting on the CPU. The two systems cannot be totally decoupled. I feel we can learn a lot by examining the performance changes both under GPU bottleneck (Window at 640x480) and CPU bottleneck (Window at 50x50 or less). Sadly, I'm not sure how much we can push this, since we've seen examples where doing more work can result in a higher framerate. Charles Josh wrote: > Attached is a count of opengl API calls for a scene where most things > are culled. > I will be figuring out how to make this more efficient. > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ------------------------------------------------------------------------ > > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs |
From: Josh <axl...@gm...> - 2009-08-20 02:12:11
|
Attached is a count of opengl API calls for a scene where most things are culled. I will be figuring out how to make this more efficient. |
From: Charles L. <ch...@cn...> - 2009-08-18 16:08:28
|
This does not fix the problem for me. I did test it, though. I changed the line to: culled = mai.Culled( a.DoCullingTests( mai.GetOcclusionResult(), matrix ) ) && culled; I also ran a test program... (verified in GCC and VS 2k5): something_false = something_false && function(); << does not execute function versus something_false = function() && something_false; << does execute function My big question is on assets that are excluded from culls (m_excludeFromCull == true), there is no way for culled to be = false (in ::PreRender). And if you have an object that is excluded from culls, it and its node should definitely not be culled. A valid fix for this would be: if ( !a.ExcludeFromCull() ) culled = culled && mai.Culled( a.DoCullingTests( mai.GetOcclusionResult(), matrix ) ); else culled = false; The reason that now, everything shows up black without that is before Asset's m_excludeFromCull was not being set. This was masking the actual problem because many times it would contain trash (either excluded or not). Now, it is being set, so we run into the case described in the second paragraph every time. Charles Josh Allen wrote: > The fix isn't to completely break culling. What you did was to tell > nodes no matter what, always render every asset. > Anyway, I think I found and fixed the problem. I think GCC was doing > some stupid optimization here > > if ( !a.ExcludeFromCull() ) > culled = culled && mai.Culled( > a.DoCullingTests( mai.GetOcclusionResult(), matrix ) ); > > I think if culled was false then it skipped the && and the operations > after the &&. > > Try retesting. I can't get the problem to happen on my laptop. > > Josh > > > > > On Tue, Aug 18, 2009 at 9:28 AM, Charles Lohr <ch...@cn... > <mailto:ch...@cn...>> wrote: > > Well, something else is going on goofey then that this fixes, so it's > got to be very close to the right answer. As it stands, an arbitrary > number of textures will load. Some times, the ground texture will > load, > other times not. When you look into it further, it's because > arbitrarily the render on some of the texture assets will never > get run, > thus never loading the texture. In the event you have excluded > objects, > they need a way of preventing the culled flag from being set. > > I don't know what you have in mind to fix this, but it is definitely > broken as it is. > > Charles > > Josh wrote: > > No this is wrong. Auto excluding from cull is also wrong. > > Right now nothing is culled. > > The nonchanging VBO batches tells you this. > > > > > > > > cn...@us... > <mailto:cn...@us...> wrote: > > > >> Revision: 488 > >> > http://hgengine.svn.sourceforge.net/hgengine/?rev=488&view=rev > <http://hgengine.svn.sourceforge.net/hgengine/?rev=488&view=rev> > >> Author: cnlohr > >> Date: 2009-08-18 05:39:50 +0000 (Tue, 18 Aug 2009) > >> > >> Log Message: > >> ----------- > >> fix dissappearing textures and assets. The problem is that we're > >> ignoring if we're actually culled or not, and just letting whatever > >> happen. > >> > >> Modified Paths: > >> -------------- > >> Mercury2/src/MercuryNode.cpp > >> > >> Modified: Mercury2/src/MercuryNode.cpp > >> =================================================================== > >> --- Mercury2/src/MercuryNode.cpp 2009-08-18 05:24:42 UTC > (rev 487) > >> +++ Mercury2/src/MercuryNode.cpp 2009-08-18 05:39:50 UTC > (rev 488) > >> @@ -277,7 +277,11 @@ > >> MercuryAsset& a = mai.Asset(); > >> if ( !a.ExcludeFromCull() ) > >> culled = culled && mai.Culled( > a.DoCullingTests( mai.GetOcclusionResult(), matrix ) ); > >> - if ( !mai.Culled() ) a.PreRender(this); > >> + if ( !mai.Culled() ) > >> + { > >> + culled = false; > >> + a.PreRender(this); > >> + } > >> } > >> SetCulled( culled ); > >> } > >> > >> > >> This was sent by the SourceForge.net collaborative development > platform, the world's largest Open Source development site. > >> > >> > ------------------------------------------------------------------------------ > >> Let Crystal Reports handle the reporting - Free Crystal Reports > 2008 30-Day > >> trial. Simplify your report design, integration and deployment > - and focus on > >> what you do best, core application coding. Discover what's new with > >> Crystal Reports now. http://p.sf.net/sfu/bobj-july > >> _______________________________________________ > >> Hgengine-cvs mailing list > >> Hge...@li... > <mailto:Hge...@li...> > >> https://lists.sourceforge.net/lists/listinfo/hgengine-cvs > >> > >> > > > > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports > 2008 30-Day > > trial. Simplify your report design, integration and deployment - > and focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Hgengine-devs mailing list > > Hge...@li... > <mailto:Hge...@li...> > > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports > 2008 30-Day > trial. Simplify your report design, integration and deployment - > and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > <mailto:Hge...@li...> > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > > > > > -- > http://www.stepmaniaonline.com > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ------------------------------------------------------------------------ > > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
From: Josh A. <axl...@gm...> - 2009-08-18 15:40:47
|
The fix isn't to completely break culling. What you did was to tell nodes no matter what, always render every asset.Anyway, I think I found and fixed the problem. I think GCC was doing some stupid optimization here if ( !a.ExcludeFromCull() ) culled = culled && mai.Culled( a.DoCullingTests( mai.GetOcclusionResult(), matrix ) ); I think if culled was false then it skipped the && and the operations after the &&. Try retesting. I can't get the problem to happen on my laptop. Josh On Tue, Aug 18, 2009 at 9:28 AM, Charles Lohr <ch...@cn...> wrote: > Well, something else is going on goofey then that this fixes, so it's > got to be very close to the right answer. As it stands, an arbitrary > number of textures will load. Some times, the ground texture will load, > other times not. When you look into it further, it's because > arbitrarily the render on some of the texture assets will never get run, > thus never loading the texture. In the event you have excluded objects, > they need a way of preventing the culled flag from being set. > > I don't know what you have in mind to fix this, but it is definitely > broken as it is. > > Charles > > Josh wrote: > > No this is wrong. Auto excluding from cull is also wrong. > > Right now nothing is culled. > > The nonchanging VBO batches tells you this. > > > > > > > > cn...@us... wrote: > > > >> Revision: 488 > >> > http://hgengine.svn.sourceforge.net/hgengine/?rev=488&view=rev > >> Author: cnlohr > >> Date: 2009-08-18 05:39:50 +0000 (Tue, 18 Aug 2009) > >> > >> Log Message: > >> ----------- > >> fix dissappearing textures and assets. The problem is that we're > >> ignoring if we're actually culled or not, and just letting whatever > >> happen. > >> > >> Modified Paths: > >> -------------- > >> Mercury2/src/MercuryNode.cpp > >> > >> Modified: Mercury2/src/MercuryNode.cpp > >> =================================================================== > >> --- Mercury2/src/MercuryNode.cpp 2009-08-18 05:24:42 UTC (rev 487) > >> +++ Mercury2/src/MercuryNode.cpp 2009-08-18 05:39:50 UTC (rev 488) > >> @@ -277,7 +277,11 @@ > >> MercuryAsset& a = mai.Asset(); > >> if ( !a.ExcludeFromCull() ) > >> culled = culled && mai.Culled( a.DoCullingTests( > mai.GetOcclusionResult(), matrix ) ); > >> - if ( !mai.Culled() ) a.PreRender(this); > >> + if ( !mai.Culled() ) > >> + { > >> + culled = false; > >> + a.PreRender(this); > >> + } > >> } > >> SetCulled( culled ); > >> } > >> > >> > >> This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > >> > >> > ------------------------------------------------------------------------------ > >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > >> trial. Simplify your report design, integration and deployment - and > focus on > >> what you do best, core application coding. Discover what's new with > >> Crystal Reports now. http://p.sf.net/sfu/bobj-july > >> _______________________________________________ > >> Hgengine-cvs mailing list > >> Hge...@li... > >> https://lists.sourceforge.net/lists/listinfo/hgengine-cvs > >> > >> > > > > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > > trial. Simplify your report design, integration and deployment - and > focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Hgengine-devs mailing list > > Hge...@li... > > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > -- http://www.stepmaniaonline.com |
From: Charles L. <ch...@cn...> - 2009-08-18 13:28:55
|
Well, something else is going on goofey then that this fixes, so it's got to be very close to the right answer. As it stands, an arbitrary number of textures will load. Some times, the ground texture will load, other times not. When you look into it further, it's because arbitrarily the render on some of the texture assets will never get run, thus never loading the texture. In the event you have excluded objects, they need a way of preventing the culled flag from being set. I don't know what you have in mind to fix this, but it is definitely broken as it is. Charles Josh wrote: > No this is wrong. Auto excluding from cull is also wrong. > Right now nothing is culled. > The nonchanging VBO batches tells you this. > > > > cn...@us... wrote: > >> Revision: 488 >> http://hgengine.svn.sourceforge.net/hgengine/?rev=488&view=rev >> Author: cnlohr >> Date: 2009-08-18 05:39:50 +0000 (Tue, 18 Aug 2009) >> >> Log Message: >> ----------- >> fix dissappearing textures and assets. The problem is that we're >> ignoring if we're actually culled or not, and just letting whatever >> happen. >> >> Modified Paths: >> -------------- >> Mercury2/src/MercuryNode.cpp >> >> Modified: Mercury2/src/MercuryNode.cpp >> =================================================================== >> --- Mercury2/src/MercuryNode.cpp 2009-08-18 05:24:42 UTC (rev 487) >> +++ Mercury2/src/MercuryNode.cpp 2009-08-18 05:39:50 UTC (rev 488) >> @@ -277,7 +277,11 @@ >> MercuryAsset& a = mai.Asset(); >> if ( !a.ExcludeFromCull() ) >> culled = culled && mai.Culled( a.DoCullingTests( mai.GetOcclusionResult(), matrix ) ); >> - if ( !mai.Culled() ) a.PreRender(this); >> + if ( !mai.Culled() ) >> + { >> + culled = false; >> + a.PreRender(this); >> + } >> } >> SetCulled( culled ); >> } >> >> >> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Hgengine-cvs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-cvs >> >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
From: Josh <axl...@gm...> - 2009-08-18 10:30:25
|
No this is wrong. Auto excluding from cull is also wrong. Right now nothing is culled. The nonchanging VBO batches tells you this. cn...@us... wrote: > Revision: 488 > http://hgengine.svn.sourceforge.net/hgengine/?rev=488&view=rev > Author: cnlohr > Date: 2009-08-18 05:39:50 +0000 (Tue, 18 Aug 2009) > > Log Message: > ----------- > fix dissappearing textures and assets. The problem is that we're > ignoring if we're actually culled or not, and just letting whatever > happen. > > Modified Paths: > -------------- > Mercury2/src/MercuryNode.cpp > > Modified: Mercury2/src/MercuryNode.cpp > =================================================================== > --- Mercury2/src/MercuryNode.cpp 2009-08-18 05:24:42 UTC (rev 487) > +++ Mercury2/src/MercuryNode.cpp 2009-08-18 05:39:50 UTC (rev 488) > @@ -277,7 +277,11 @@ > MercuryAsset& a = mai.Asset(); > if ( !a.ExcludeFromCull() ) > culled = culled && mai.Culled( a.DoCullingTests( mai.GetOcclusionResult(), matrix ) ); > - if ( !mai.Culled() ) a.PreRender(this); > + if ( !mai.Culled() ) > + { > + culled = false; > + a.PreRender(this); > + } > } > SetCulled( culled ); > } > > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Hgengine-cvs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-cvs > |
From: Josh <axl...@gm...> - 2009-08-16 23:24:14
|
I made a rather major change to mercury 2. As before, assets are instanced. One copy of an asset is loaded and uses wherever that asset is used. The assets were stored using auto pointers in the mercury nodes. Now for the change... Assets are still instanced. But now instead of being stored in auto pointers in nodes they are stored in MercuryAssetInstance classes. These classes are stored in nodes. This allows us to store some per-instance data for assets. Right now I use this for frustum culling, and occlusion tests. We could also put other things there, like a global matrix, or even make the innstance data specific to the type. You could do something with models where you load an animated model once but keep its animation data specific to each instance. Also, because of this change, I removed the prerender, render, and post render lists. All assets have prerender, render, and postrender executed all the time. We can approach this differently later to make it more efficient, it probably needs to be tied in with your experimental multi-pass render. |
From: Charles L. <ch...@cn...> - 2009-07-20 16:28:38
|
I do seem to recall on some systems ALSA had trouble on a couple fronts. Toward the end, through project Gunther, some of those were fixed. But in all cases, we were able to fall back to SDL if ALSA failed. It is something we can look into. By sound Input, I mean WAV/Ogg Vorbis. Charles Josh Allen wrote: > I can't remember if there are major problems. I think there are with > buffers, mostly memory issues. > There were also ALSA issues I think. > We had sound input in HG1? > > Josh > > > On Mon, Jul 20, 2009 at 10:06 AM, Charles Lohr <ch...@cn... > <mailto:ch...@cn...>> wrote: > > I was taking a closer look at the sound system in HG1, and I > realized we > can flat out copy the sound input drivers with very minor > modification. > The sound output drivers can be very similar as well. I was wondering > if it's acceptable to copy these cores over, or if there were any > major > known bugs in any of the cores that need to be addressed? > > Charles > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited > time, > vendors submitting new applications to BlackBerry App World(TM) > will have > the opportunity to enter the BlackBerry Developer Challenge. See > full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > <mailto:Hge...@li...> > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > > > > > -- > http://www.stepmaniaonline.com > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > ------------------------------------------------------------------------ > > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
From: Josh A. <axl...@gm...> - 2009-07-20 15:41:45
|
I can't remember if there are major problems. I think there are with buffers, mostly memory issues. There were also ALSA issues I think. We had sound input in HG1? Josh On Mon, Jul 20, 2009 at 10:06 AM, Charles Lohr <ch...@cn...> wrote: > I was taking a closer look at the sound system in HG1, and I realized we > can flat out copy the sound input drivers with very minor modification. > The sound output drivers can be very similar as well. I was wondering > if it's acceptable to copy these cores over, or if there were any major > known bugs in any of the cores that need to be addressed? > > Charles > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > -- http://www.stepmaniaonline.com |
From: Charles L. <ch...@cn...> - 2009-07-20 14:07:01
|
I was taking a closer look at the sound system in HG1, and I realized we can flat out copy the sound input drivers with very minor modification. The sound output drivers can be very similar as well. I was wondering if it's acceptable to copy these cores over, or if there were any major known bugs in any of the cores that need to be addressed? Charles |
From: Josh <axl...@gm...> - 2009-07-15 10:22:30
|
There is no MercuryPoint. There are MercuryVertex and MercuryVector. If MercuryPoint still exists, it is legacy and should be removed from SVN. Josh Charles Lohr wrote: > I was curious - under what conditions one should choose to use a > MercuryVertex over a MercuryPoint? Is there any major differences? > Should there just be one class? > > Charles > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
From: Charles L. <ch...@cn...> - 2009-07-15 02:20:21
|
I was curious - under what conditions one should choose to use a MercuryVertex over a MercuryPoint? Is there any major differences? Should there just be one class? Charles |
From: Josh <axl...@gm...> - 2009-07-11 10:46:18
|
Viewports don't do too much. It only loads the frustum matrix into the opengl projection matrix. You can probably stack the Viewports. I don't see any reason why it wouldn't work. I know you can use multiple viewports in one scene (with different child objects). I rarely use matrix stacks in openg I let mercury scene graph tree act like the stack. The only thing I use opengl stacks for are things that run purely in openg that nothing else needs to know about, like occlusion culling in bounding box. Whenever a matrix is sent to opengl, it just overwrites what was there. If you are working on an orthographic view, you should probably focus on the code in Frustum.cpp. Charles Lohr wrote: > I am having difficulty working through how the Viewport works. It looks > as though it doesn't actually deal with any stacks of any kind, and I'm > not sure if I should be emulating any behavior with my orthoport or not. > > Do these things stack? Do they just modify what's after them? > > More specifically, are: > * modelview matrix > * projection matrix > * viewport x/y x/y > Stackable? > > Charles Lohr > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
From: Charles L. <ch...@cn...> - 2009-07-11 06:01:21
|
I am having difficulty working through how the Viewport works. It looks as though it doesn't actually deal with any stacks of any kind, and I'm not sure if I should be emulating any behavior with my orthoport or not. Do these things stack? Do they just modify what's after them? More specifically, are: * modelview matrix * projection matrix * viewport x/y x/y Stackable? Charles Lohr |
From: Charles L. <ch...@cn...> - 2009-07-08 15:07:11
|
I believe it's GLU we use for that, i.e. gluBuildMipMaps. Strangely, I am having a hard time figuring out what license the compiled release of this is under. The header file for it is under a much more restrictive license which makes me nervous. http://www.opengl.org/resources/libraries/glx/ contains the information on GLU. It appears to be under the following license: http://www.sgi.com/products/software/opensource/glx/glxlicense.txt . I do not understand if we are exempt from it, since we're only linking to the project (i.e. like the LGPL) or if there's something of more significance going on here. We can use freeglut, but we don't as of now. freeglut is primarily for opening windows and controlling input. The X Consortium License is actually the MIT/X11 license, which is, as far as I understand 100% forward compatible with the NewBSD license, which we are under now. (Freeglut is OK, but unneeded) There's no reason for us to include freeglut in all the GL headers if we don't use it. Charles Lohr Josh wrote: > Right now we use freeglut for at least a few things. I know we use it > for mipmaps. > It is under the X-Consortium license. Is this compatible with our license? > > > > cn...@us... wrote: > >> Revision: 416 >> http://hgengine.svn.sourceforge.net/hgengine/?rev=416&view=rev >> Author: cnlohr >> Date: 2009-07-08 05:27:14 +0000 (Wed, 08 Jul 2009) >> >> Log Message: >> ----------- >> remove need for freeglut on Linux, and enable compilation and running on systems missing the not-universal >> glProgramParameteriEXT function. >> >> Modified Paths: >> -------------- >> Mercury2/src/GLHeaders.h >> Mercury2/src/Shader.cpp >> >> Modified: Mercury2/src/GLHeaders.h >> =================================================================== >> --- Mercury2/src/GLHeaders.h 2009-07-08 05:25:47 UTC (rev 415) >> +++ Mercury2/src/GLHeaders.h 2009-07-08 05:27:14 UTC (rev 416) >> @@ -15,7 +15,7 @@ >> #include <OGLExtensions.h> >> #else >> #include <GL/glext.h> >> -#include <GL/freeglut.h> >> +#include <GL/glu.h> >> #endif >> >> #include <GLHelpers.h> >> @@ -34,4 +34,4 @@ >> assert(0); } } >> >> >> -#endif >> \ No newline at end of file >> +#endif >> >> Modified: Mercury2/src/Shader.cpp >> =================================================================== >> --- Mercury2/src/Shader.cpp 2009-07-08 05:25:47 UTC (rev 415) >> +++ Mercury2/src/Shader.cpp 2009-07-08 05:27:14 UTC (rev 416) >> @@ -5,12 +5,20 @@ >> #include <GLHeaders.h> >> #include <string.h> >> >> +//Because we need to dynamically check for glProgramParameteriEXT, even in Linux. >> +#include <GL/glx.h> >> + >> using namespace std; >> >> REGISTER_ASSET_TYPE( Shader ); >> >> Shader * Shader::CurrentShader = NULL; >> >> +//On many GL Implementations, this is super wonky. >> +//It may not even exist at all, so we make it optional. >> +bool IsCustomGLProgramParISet = false; >> +PFNGLPROGRAMPARAMETERIEXTPROC CustomGLProgramParI; >> + >> ShaderAttribute * ShaderAttributesSet::GetHandle( const MString & sName ) >> { >> ShaderAttribute * ret = m_AllShaderAttributes[sName]; >> @@ -31,6 +39,16 @@ >> iTimeCode[0] = 0; >> iTimeCode[1] = 0; >> iTimeCode[2] = 0; >> + >> +#ifdef WIN32 >> + CustomGLProgramParI = glProgramParameteriEXT; >> +#else >> + if( !IsCustomGLProgramParISet ) >> + { >> + CustomGLProgramParI = (PFNGLPROGRAMPARAMETERIEXTPROC)glXGetProcAddress( (GLubyte*)"glProgramParameteriEXT" ); >> + IsCustomGLProgramParISet = true; >> + } >> +#endif >> } >> >> Shader::~Shader() >> @@ -272,10 +290,10 @@ >> glLinkProgramARB( iProgramID ); >> >> //If we're using a geometry shader, we have to do a little extra. >> - if( geometryShader ) >> + if( CustomGLProgramParI && geometryShader ) >> { >> - glProgramParameteriEXT( iProgramID, GL_GEOMETRY_INPUT_TYPE_EXT, GL_TRIANGLES ); >> - glProgramParameteriEXT( iProgramID, GL_GEOMETRY_OUTPUT_TYPE_EXT, GL_TRIANGLE_STRIP ); >> + CustomGLProgramParI( iProgramID, GL_GEOMETRY_INPUT_TYPE_EXT, GL_TRIANGLES ); >> + CustomGLProgramParI( iProgramID, GL_GEOMETRY_OUTPUT_TYPE_EXT, GL_TRIANGLE_STRIP ); >> >> int ierror, i; >> GLint imaxvert; >> @@ -288,7 +306,7 @@ >> } >> for( i = 1; i < imaxvert; i++ ) >> { >> - glProgramParameteriEXT(iProgramID,GL_GEOMETRY_VERTICES_OUT_EXT,imaxvert/i); >> + CustomGLProgramParI(iProgramID,GL_GEOMETRY_VERTICES_OUT_EXT,imaxvert/i); >> if( glGetError() == 0 ) >> break; >> } >> >> >> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. >> >> ------------------------------------------------------------------------------ >> Enter the BlackBerry Developer Challenge >> This is your chance to win up to $100,000 in prizes! For a limited time, >> vendors submitting new applications to BlackBerry App World(TM) will have >> the opportunity to enter the BlackBerry Developer Challenge. See full prize >> details at: http://p.sf.net/sfu/Challenge >> _______________________________________________ >> Hgengine-cvs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-cvs >> >> > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
From: Josh <axl...@gm...> - 2009-07-08 10:37:12
|
Right now we use freeglut for at least a few things. I know we use it for mipmaps. It is under the X-Consortium license. Is this compatible with our license? cn...@us... wrote: > Revision: 416 > http://hgengine.svn.sourceforge.net/hgengine/?rev=416&view=rev > Author: cnlohr > Date: 2009-07-08 05:27:14 +0000 (Wed, 08 Jul 2009) > > Log Message: > ----------- > remove need for freeglut on Linux, and enable compilation and running on systems missing the not-universal > glProgramParameteriEXT function. > > Modified Paths: > -------------- > Mercury2/src/GLHeaders.h > Mercury2/src/Shader.cpp > > Modified: Mercury2/src/GLHeaders.h > =================================================================== > --- Mercury2/src/GLHeaders.h 2009-07-08 05:25:47 UTC (rev 415) > +++ Mercury2/src/GLHeaders.h 2009-07-08 05:27:14 UTC (rev 416) > @@ -15,7 +15,7 @@ > #include <OGLExtensions.h> > #else > #include <GL/glext.h> > -#include <GL/freeglut.h> > +#include <GL/glu.h> > #endif > > #include <GLHelpers.h> > @@ -34,4 +34,4 @@ > assert(0); } } > > > -#endif > \ No newline at end of file > +#endif > > Modified: Mercury2/src/Shader.cpp > =================================================================== > --- Mercury2/src/Shader.cpp 2009-07-08 05:25:47 UTC (rev 415) > +++ Mercury2/src/Shader.cpp 2009-07-08 05:27:14 UTC (rev 416) > @@ -5,12 +5,20 @@ > #include <GLHeaders.h> > #include <string.h> > > +//Because we need to dynamically check for glProgramParameteriEXT, even in Linux. > +#include <GL/glx.h> > + > using namespace std; > > REGISTER_ASSET_TYPE( Shader ); > > Shader * Shader::CurrentShader = NULL; > > +//On many GL Implementations, this is super wonky. > +//It may not even exist at all, so we make it optional. > +bool IsCustomGLProgramParISet = false; > +PFNGLPROGRAMPARAMETERIEXTPROC CustomGLProgramParI; > + > ShaderAttribute * ShaderAttributesSet::GetHandle( const MString & sName ) > { > ShaderAttribute * ret = m_AllShaderAttributes[sName]; > @@ -31,6 +39,16 @@ > iTimeCode[0] = 0; > iTimeCode[1] = 0; > iTimeCode[2] = 0; > + > +#ifdef WIN32 > + CustomGLProgramParI = glProgramParameteriEXT; > +#else > + if( !IsCustomGLProgramParISet ) > + { > + CustomGLProgramParI = (PFNGLPROGRAMPARAMETERIEXTPROC)glXGetProcAddress( (GLubyte*)"glProgramParameteriEXT" ); > + IsCustomGLProgramParISet = true; > + } > +#endif > } > > Shader::~Shader() > @@ -272,10 +290,10 @@ > glLinkProgramARB( iProgramID ); > > //If we're using a geometry shader, we have to do a little extra. > - if( geometryShader ) > + if( CustomGLProgramParI && geometryShader ) > { > - glProgramParameteriEXT( iProgramID, GL_GEOMETRY_INPUT_TYPE_EXT, GL_TRIANGLES ); > - glProgramParameteriEXT( iProgramID, GL_GEOMETRY_OUTPUT_TYPE_EXT, GL_TRIANGLE_STRIP ); > + CustomGLProgramParI( iProgramID, GL_GEOMETRY_INPUT_TYPE_EXT, GL_TRIANGLES ); > + CustomGLProgramParI( iProgramID, GL_GEOMETRY_OUTPUT_TYPE_EXT, GL_TRIANGLE_STRIP ); > > int ierror, i; > GLint imaxvert; > @@ -288,7 +306,7 @@ > } > for( i = 1; i < imaxvert; i++ ) > { > - glProgramParameteriEXT(iProgramID,GL_GEOMETRY_VERTICES_OUT_EXT,imaxvert/i); > + CustomGLProgramParI(iProgramID,GL_GEOMETRY_VERTICES_OUT_EXT,imaxvert/i); > if( glGetError() == 0 ) > break; > } > > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Hgengine-cvs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-cvs > |
From: Josh <axl...@gm...> - 2009-07-07 01:08:04
|
I think I have gotten frustum culling working again. We are using a bounding box with a preliminary sphere test. I need to figure out how to build hierarchical bounding boxes with the nodes. I also added in an occlusion test too, which seems pretty quick in the worst case scenario of no occluders. That should obviously used if you render some large occluders first. Josh |
From: Charles L. <ch...@cn...> - 2009-07-04 14:34:01
|
1) We do sometimes need direct interaction (or at least could heavily use it). I.e. We have a gameplay screen, you have several actors moving around on a map, your scene graph has many translation nodes, and inside them actors. The gameplay screen (or some gameplay node that parents those nodes) would want to obtain a handle to those translation nodes in order to move the various objects around. I believe it would be possible to guarantee that the direction of these operations would be parent-to-child only, thus the updates could thread across unrelated nodes, and across all siblings. 2) Indeed not all objects need be named! Naming would be optional, and would be useful only when you need to find things. I feel it might be useful to be able to index _any_ named node, because I could forsee a point where someone using the engine just gets pissed off because it is broken in that regard. 3) My suggestion for having an every object register is solely to make runtime-reloading of objects possible. It could simply be some sort of global data structure with all of the nodes, indexable by pointer, i.e. set<...>. Charles Josh wrote: > Not all nodes need to have a name. > I don't like having to pass a string into object constructors, like we > did in HG1. Should this register be used only for things that want to > be found by other objects? What is the intention here? Direct > interaction between nodes should be minimized to help us thread updates > in the future. > > Josh > > > Charles Lohr wrote: > >> Devs, >> >> I'm looking into adding a way for nodes to be indexable globally and >> locally. >> >> In HG1, we were able to say OBJECTREGISTER.GetObjectByName( >> "MyCameraControl" ); And it would return a pointer to the object >> "MyCameraControl." Also, we were able to, if need be, get a list of all >> of the objects. >> >> In HG2, I feel like it would be useful to be able to have the same >> functionality there. Maybe, all objects could be indexed by name. >> >> Also, HG2 could have an additional feature (This is actually what I want >> first): Another function, to say GetChildByName( "NameOfObject" ); That >> could search a current node's children and its children's children for >> that node. This function could/should be asymptotically slower than the >> overall object register. >> >> This would leave us to implement two things: >> >> 1) OBJECTREGISTER (using an std::map<> or an MHash) >> 2) GetChildByName function added to MercuryNode. >> >> I could implement both. >> >> My only concern with #1 is it does add to the overhead of objects if >> they have to register with some central command, so-to-speak. We could >> avoid this by making it so only named objects register with >> OBJECTREGISTER. This does remove the feature of being able to get a >> list of all objects, but I am not really sure what the right tradeoff >> here is... >> >> Charles Lohr >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Hgengine-devs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >> >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
From: Josh <axl...@gm...> - 2009-07-04 12:10:37
|
Not all nodes need to have a name. I don't like having to pass a string into object constructors, like we did in HG1. Should this register be used only for things that want to be found by other objects? What is the intention here? Direct interaction between nodes should be minimized to help us thread updates in the future. Josh Charles Lohr wrote: > Devs, > > I'm looking into adding a way for nodes to be indexable globally and > locally. > > In HG1, we were able to say OBJECTREGISTER.GetObjectByName( > "MyCameraControl" ); And it would return a pointer to the object > "MyCameraControl." Also, we were able to, if need be, get a list of all > of the objects. > > In HG2, I feel like it would be useful to be able to have the same > functionality there. Maybe, all objects could be indexed by name. > > Also, HG2 could have an additional feature (This is actually what I want > first): Another function, to say GetChildByName( "NameOfObject" ); That > could search a current node's children and its children's children for > that node. This function could/should be asymptotically slower than the > overall object register. > > This would leave us to implement two things: > > 1) OBJECTREGISTER (using an std::map<> or an MHash) > 2) GetChildByName function added to MercuryNode. > > I could implement both. > > My only concern with #1 is it does add to the overhead of objects if > they have to register with some central command, so-to-speak. We could > avoid this by making it so only named objects register with > OBJECTREGISTER. This does remove the feature of being able to get a > list of all objects, but I am not really sure what the right tradeoff > here is... > > Charles Lohr > > ------------------------------------------------------------------------------ > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
From: Charles L. <ch...@cn...> - 2009-07-04 05:56:32
|
Devs, I'm looking into adding a way for nodes to be indexable globally and locally. In HG1, we were able to say OBJECTREGISTER.GetObjectByName( "MyCameraControl" ); And it would return a pointer to the object "MyCameraControl." Also, we were able to, if need be, get a list of all of the objects. In HG2, I feel like it would be useful to be able to have the same functionality there. Maybe, all objects could be indexed by name. Also, HG2 could have an additional feature (This is actually what I want first): Another function, to say GetChildByName( "NameOfObject" ); That could search a current node's children and its children's children for that node. This function could/should be asymptotically slower than the overall object register. This would leave us to implement two things: 1) OBJECTREGISTER (using an std::map<> or an MHash) 2) GetChildByName function added to MercuryNode. I could implement both. My only concern with #1 is it does add to the overhead of objects if they have to register with some central command, so-to-speak. We could avoid this by making it so only named objects register with OBJECTREGISTER. This does remove the feature of being able to get a list of all objects, but I am not really sure what the right tradeoff here is... Charles Lohr |
From: Josh <axl...@gm...> - 2009-07-03 04:12:05
|
Cool Charles Lohr wrote: > Josh, > > I added the theme system. I haven't fully tested it yet, but I will > start doing that soon. The biggest point, the file manager addition, > does appear to be working correctly. There is a big change between HG1 > and HG2 in this respect. > > HG1: FILE:test.txt => Themes/default/Files/test.txt > HG2: FILE:test.txt => Themes/default/File/test.txt > > Note that in HG2, the 's' is not automatically added. > > This is because in HG2, we are not hard-coding the FILE, GRAPHIC, MODEL, > etc. stuff. We, instead just detect for: > > [ALL CAPS PART]:[file] > > And translate it to: > > Themes/[theme search in reverse order]/[Proper caps part]/[file] > > This enables users to make up their own theme file sections. > > Charles > > ------------------------------------------------------------------------------ > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |