Menu
▾
▴
hgengine-devs — Communication between developers
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: Josh <axl...@gm...> - 2010-01-13 00:34:54
|
Textures look ok. Terrain rendered fine without it a texture. Particles don't work. Josh Charles Lohr wrote: > It is highly possible that the issue could have been drawing without > textures... Why would deleting those commands fix that, though. > > Also, any ETA on when non-textured-things-working will be done? > > Charles > > Josh wrote: > >> Yes, it saves which vertex attribute are enabled, like textures >> coordinates, and normals. >> Make sure you are chasing the correct problem. Also drawing things >> without textures is broken. >> >> Also what does rapid succession mean? Short time between them, or 2 >> quads right after each other with time not making a difference? >> >> 1% is not a significant increase. If you want to increase speed, go for >> reducing draw commands. >> >> >> Charles Lohr wrote: >> >> >>> Devs, >>> >>> For some inexplicable reason, when I draw two of the same quads in rapid >>> succession in some cases the program simply crashes. >>> >>> As soon as I comment out: >>> GLCALL( glPushClientAttrib(GL_CLIENT_VERTEX_ARRAY_BIT) ); >>> and >>> GLCALL( glPopClientAttrib() ); >>> >>> Everything works as expected. >>> >>> Also, it runs about 1% faster. Is there an absolute need to run these >>> two commands? >>> >>> Charles >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> Hgengine-devs mailing list >>> Hge...@li... >>> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >>> >>> >>> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Hgengine-devs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >> >> > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
|
From: Josh <axl...@gm...> - 2010-01-12 22:34:21
|
I'll see what I can do about no textures. I didn't find it until I was working with particles. Josh Charles Lohr wrote: > It is highly possible that the issue could have been drawing without > textures... Why would deleting those commands fix that, though. > > Also, any ETA on when non-textured-things-working will be done? > > Charles > > Josh wrote: > >> Yes, it saves which vertex attribute are enabled, like textures >> coordinates, and normals. >> Make sure you are chasing the correct problem. Also drawing things >> without textures is broken. >> >> Also what does rapid succession mean? Short time between them, or 2 >> quads right after each other with time not making a difference? >> >> 1% is not a significant increase. If you want to increase speed, go for >> reducing draw commands. >> >> >> Charles Lohr wrote: >> >> >>> Devs, >>> >>> For some inexplicable reason, when I draw two of the same quads in rapid >>> succession in some cases the program simply crashes. >>> >>> As soon as I comment out: >>> GLCALL( glPushClientAttrib(GL_CLIENT_VERTEX_ARRAY_BIT) ); >>> and >>> GLCALL( glPopClientAttrib() ); >>> >>> Everything works as expected. >>> >>> Also, it runs about 1% faster. Is there an absolute need to run these >>> two commands? >>> >>> Charles >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> Hgengine-devs mailing list >>> Hge...@li... >>> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >>> >>> >>> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Hgengine-devs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >> >> > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
|
From: Charles L. <ch...@cn...> - 2010-01-12 21:10:02
|
It is highly possible that the issue could have been drawing without textures... Why would deleting those commands fix that, though. Also, any ETA on when non-textured-things-working will be done? Charles Josh wrote: > Yes, it saves which vertex attribute are enabled, like textures > coordinates, and normals. > Make sure you are chasing the correct problem. Also drawing things > without textures is broken. > > Also what does rapid succession mean? Short time between them, or 2 > quads right after each other with time not making a difference? > > 1% is not a significant increase. If you want to increase speed, go for > reducing draw commands. > > > Charles Lohr wrote: > >> Devs, >> >> For some inexplicable reason, when I draw two of the same quads in rapid >> succession in some cases the program simply crashes. >> >> As soon as I comment out: >> GLCALL( glPushClientAttrib(GL_CLIENT_VERTEX_ARRAY_BIT) ); >> and >> GLCALL( glPopClientAttrib() ); >> >> Everything works as expected. >> >> Also, it runs about 1% faster. Is there an absolute need to run these >> two commands? >> >> Charles >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Hgengine-devs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >> >> > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
|
From: Josh <axl...@gm...> - 2010-01-12 11:49:58
|
Yes, it saves which vertex attribute are enabled, like textures coordinates, and normals. Make sure you are chasing the correct problem. Also drawing things without textures is broken. Also what does rapid succession mean? Short time between them, or 2 quads right after each other with time not making a difference? 1% is not a significant increase. If you want to increase speed, go for reducing draw commands. Charles Lohr wrote: > Devs, > > For some inexplicable reason, when I draw two of the same quads in rapid > succession in some cases the program simply crashes. > > As soon as I comment out: > GLCALL( glPushClientAttrib(GL_CLIENT_VERTEX_ARRAY_BIT) ); > and > GLCALL( glPopClientAttrib() ); > > Everything works as expected. > > Also, it runs about 1% faster. Is there an absolute need to run these > two commands? > > Charles > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
|
From: Josh <axl...@gm...> - 2010-01-12 11:26:13
|
Yes. Charles Lohr wrote: > Devs, > > For some inexplicable reason, when I draw two of the same quads in rapid > succession in some cases the program simply crashes. > > As soon as I comment out: > GLCALL( glPushClientAttrib(GL_CLIENT_VERTEX_ARRAY_BIT) ); > and > GLCALL( glPopClientAttrib() ); > > Everything works as expected. > > Also, it runs about 1% faster. Is there an absolute need to run these > two commands? > > Charles > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
|
From: Charles L. <lo...@um...> - 2010-01-12 07:25:20
|
Devs,
For some inexplicable reason, when I draw two of the same quads in rapid
succession in some cases the program simply crashes.
As soon as I comment out:
GLCALL( glPushClientAttrib(GL_CLIENT_VERTEX_ARRAY_BIT) );
and
GLCALL( glPopClientAttrib() );
Everything works as expected.
Also, it runs about 1% faster. Is there an absolute need to run these
two commands?
Charles
|
|
From: Charles L. <lo...@um...> - 2009-11-09 20:11:19
|
Devs, While we've tried avoiding it thus far, it's occurring to me now that we really do, in fact need an Init() function. When loading something like a Texture, we can create it in two ways: (1) MAutoPtr< MercuryAsset > a = ASSETFACTORY.Generate( "Texture", "GRAPHIC:bob.png" ); a.SetSomeParameterA(...); a.SetSomeParameterB(...), a.ChangeKey( "GRAPHIC:bob.png" ); ******* (2) <asset type="Texture" file="GRAPHIC:bob.png" SomeParameterA="..." SomeParameterB="..." /> The *******'ed line is the one in question. There is no convenient way right now to indicate to something that it should not load in the constructor, but instead load at a later time. In this case, we aren't actually changing the key. We simply need to tell the texture "Ok, time to go load now." We also can't just do this raw in the XML function, as many times we will be creating assets in code. I am not really sure how to resolve this. Maybe there could be some special parameter that gets passed to change key to indicate that it should simply be using whatever key it was passed in with? I guess the current system isn't all that bad, but I feel like it /could/ be better. Charles |
|
From: Josh <axl...@gm...> - 2009-11-08 20:48:32
|
The terrain code is crashing because the GetGlobalMatrix is invalid. |
|
From: Charles L. <lo...@um...> - 2009-11-03 19:45:46
|
Devs, The asset creation, changing and deletion process is very complicated as of now. There appear to be some aspects that are duplicated and some that seem to be misplaced. It also seems confused when dealing with dynamic and non-dynamic assets. I propose the following change: 1) All assets should follow the following convention <asset type="[AssetType]" dynamic="[true/false]" file="..." /> 2) I would want the Asset Manager to handle production of new assets and asset instances - it should be capable of determining whether you need a new Asset or AssetInstance. It should be able to do this entirely base on whether it's dynamic (if dynamic, ALWAYS make new asset) or static, where create a new assetinstance based on file. This would reduce the complexity of actual MercuryAssets greatly. A major note is when you use the AssetManager to create a new instance, you would be forced to provide it the file associated with the asset you want, as well as whether it's dynamic or not. 3) I would like to suggest making all types case sensitive. If all three of these points are acceptable, I can modify the current system with all assets to reflect it. P.S. The new state system appears to work perfectly - well, except for there being too many instances since the current system isn't smart enough. Charles |
|
From: Charles L. <ch...@cn...> - 2009-10-27 19:00:44
|
The point should be inversely transformed, going in - then it should collide - then the point should be transformed going out. If the user is on a point where they should be - the input point and output point should be identical. I intend to investigate this later this evening. Charles Josh Allen wrote: > > > 2) This brought up an issue in the Terrain, that I still haven't > figured > out. It seems to portal the user over to a point in the terrain. > I.e. > you pass in one point, however it ends up being a completely different > point. It does produce the right results transformed back. I am not > sure why the issue is only one way. > > Because if the point that was returned to the camera by the terrain > where used in the next point computation there would be feedback and > the camera flies off into infinity. > This is because the terrain has been translated an rotated. If it > were at 0,0,0 and not rotated, the feedback would not be an issue. > > Josh > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > ------------------------------------------------------------------------ > > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
|
From: Josh A. <axl...@gm...> - 2009-10-27 15:57:14
|
> > > 2) This brought up an issue in the Terrain, that I still haven't figured > out. It seems to portal the user over to a point in the terrain. I.e. > you pass in one point, however it ends up being a completely different > point. It does produce the right results transformed back. I am not > sure why the issue is only one way. > > Because if the point that was returned to the camera by the terrain where used in the next point computation there would be feedback and the camera flies off into infinity. This is because the terrain has been translated an rotated. If it were at 0,0,0 and not rotated, the feedback would not be an issue. Josh |
|
From: Josh <axl...@gm...> - 2009-10-27 10:27:28
|
Euler is a poor choice for this since it doesn't always mathematically work and can Gimbel lock. Why not just save the quaternion values without any conversions? Josh cn...@us... wrote: > Revision: 590 > http://hgengine.svn.sourceforge.net/hgengine/?rev=590&view=rev > Author: cnlohr > Date: 2009-10-27 04:48:57 +0000 (Tue, 27 Oct 2009) > > Log Message: > ----------- > add to euler (useful for saving) it hasn't actually been tested yet... > > Modified Paths: > -------------- > Mercury2/src/MQuaternion.cpp > Mercury2/src/MQuaternion.h > > Modified: Mercury2/src/MQuaternion.cpp > =================================================================== > --- Mercury2/src/MQuaternion.cpp 2009-10-27 03:18:28 UTC (rev 589) > +++ Mercury2/src/MQuaternion.cpp 2009-10-27 04:48:57 UTC (rev 590) > @@ -52,6 +52,14 @@ > *this = this->normalize(); > } > > +void MQuaternion::ToEuler(MercuryVertex&angles) const > +{ > + //According to http://en.wikipedia.org/wiki/Conversion_between_quaternions_and_Euler_angles (Oct 26, 2009) > + angles[0] = atan2( 2 * (m_wxyz[0]*m_wxyz[1] + m_wxyz[2]*m_wxyz[3]), 1 - 2 * (m_wxyz[1]*m_wxyz[1] + m_wxyz[2]*m_wxyz[2] ) ); > + angles[1] = asin( 2 * (m_wxyz[0] *m_wxyz[2] - m_wxyz[3]*m_wxyz[1] ) ); > + angles[2] = atan2( 2 * (m_wxyz[0]*m_wxyz[3] + m_wxyz[1]*m_wxyz[2]), 1 - 2 * (m_wxyz[2]*m_wxyz[2] + m_wxyz[3]*m_wxyz[3] ) ); > +} > + > MQuaternion MQuaternion::CreateFromAxisAngle(const MercuryVertex& p, const float radians) > { > MQuaternion q; > > Modified: Mercury2/src/MQuaternion.h > =================================================================== > --- Mercury2/src/MQuaternion.h 2009-10-27 03:18:28 UTC (rev 589) > +++ Mercury2/src/MQuaternion.h 2009-10-27 04:48:57 UTC (rev 590) > @@ -23,6 +23,9 @@ > static MQuaternion CreateFromAxisAngle(const MercuryVertex& p, const float radians); > void FromAxisAngle(const MercuryVertex& p, const float radians); > void ToAxisAngle(float& angle, float& x, float& y, float& z) const; > + > + //Convert the quaternion back into euler angles (mathematically doesn't always work) > + void ToEuler(MercuryVertex&angles) const; > > ///Access a component of the quaternion with the [] operator > inline float & operator[] ( const WXYZ i ) { return m_wxyz[i]; } > > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Hgengine-cvs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-cvs > |
|
From: Charles L. <lo...@um...> - 2009-10-27 04:56:03
|
Devs, 1) I just added XML Scene Graph saving to the engine. It appears I've brought all of the currently used nodes up to speed. You can see how they operate. Additionally, I made it so it saves the XML scene every frame. It seems to take about .008s to save the entire scene every frame. The scene can be tested by invoking mercury to try the new scene. $ ./mercury -s test.xml 2) This brought up an issue in the Terrain, that I still haven't figured out. It seems to portal the user over to a point in the terrain. I.e. you pass in one point, however it ends up being a completely different point. It does produce the right results transformed back. I am not sure why the issue is only one way. 3) This did prompt a new idea - XML Scene Portaling. I think it would be useful to have a node that could say "Import this XML node over in this other file here" But, it would do so in a way that the scene graph would be aware of it, it would not transparently dump it on over. This could also be useful when doing different themes, as it would enable users to make the node different depending on the theme. Another side effect of this node is that it would be able to override the MercuryNode's XML Saving, like TextNode. This would make it possible to /not/ write out all of that other file's XML in the save file. Instead, with those sorts of nodes they are essentially marked "do not save." Any ideas? |
|
From: Josh <axl...@gm...> - 2009-10-24 21:12:05
|
Problems with held references and pointers is exactly why we don't need a DeleteSelf. Auto pointers handle all the memory allocations for assets. Why would we EVER need type information in a destructor for said type? This seems live very bad design. I would rather have DeleteSelf over this. Nodes are a little different. They need to be deleted after they are removed from the scene graph. Nodes are NEVER instanced, each node is unique. Charles Lohr wrote: > The only way we can get type information in the destructor is to keep > that char * around, since the virtual char * GetType() doesn't work > right in the destructor or constructor. If we had a DeleteSelf > function, there would be no need to have that extra char *. > > Additionally, I feel it would be useful in many cases to be able to have > something say "Remove me at your earliest convenience." After all, in > the middle of an update cycle, if you remove yourself, you could have > all sorts of problems because of references to you from things like the > alpha pass. > > Charles > > > Josh wrote: > >> I don't like this. We did this deletion thing in HG1 and it was a disaster. >> >> There is an Init somewhere, either in MercuryNode or MercuryAsset. >> It is currently unused with the intention of reusing asset/nodes. >> >> I do not want a delete self. Having that in HG1 caused all kinds of >> circular deletions, it was very messy. >> >> Also, why are you storing char * of the type? We are using RTTI so we >> don't have to do this, and it increases the size a fairly large amount. >> >> >> >> >> Charles Lohr wrote: >> >> >>> It turns out that C++ does not permit virtual function calls in >>> Constructors or Destructors. >>> >>> I've added code to make a virtual call intentionally after the creation >>> of objects that so I can set a new variable "const char * Type" that way >>> I can get the type in the destructor. >>> >>> I am curious if we were planning on adding Init() and DeleteSelf() or >>> something along those lines? >>> >>> Charles >>> >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>> http://p.sf.net/sfu/devconference >>> _______________________________________________ >>> Hgengine-devs mailing list >>> Hge...@li... >>> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >>> >>> >>> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Hgengine-devs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >> >> > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
|
From: Charles L. <ch...@cn...> - 2009-10-24 17:21:31
|
The only way we can get type information in the destructor is to keep that char * around, since the virtual char * GetType() doesn't work right in the destructor or constructor. If we had a DeleteSelf function, there would be no need to have that extra char *. Additionally, I feel it would be useful in many cases to be able to have something say "Remove me at your earliest convenience." After all, in the middle of an update cycle, if you remove yourself, you could have all sorts of problems because of references to you from things like the alpha pass. Charles Josh wrote: > I don't like this. We did this deletion thing in HG1 and it was a disaster. > > There is an Init somewhere, either in MercuryNode or MercuryAsset. > It is currently unused with the intention of reusing asset/nodes. > > I do not want a delete self. Having that in HG1 caused all kinds of > circular deletions, it was very messy. > > Also, why are you storing char * of the type? We are using RTTI so we > don't have to do this, and it increases the size a fairly large amount. > > > > > Charles Lohr wrote: > >> It turns out that C++ does not permit virtual function calls in >> Constructors or Destructors. >> >> I've added code to make a virtual call intentionally after the creation >> of objects that so I can set a new variable "const char * Type" that way >> I can get the type in the destructor. >> >> I am curious if we were planning on adding Init() and DeleteSelf() or >> something along those lines? >> >> Charles >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Hgengine-devs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >> >> > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
|
From: Josh <axl...@gm...> - 2009-10-22 22:20:50
|
I don't like this. We did this deletion thing in HG1 and it was a disaster. There is an Init somewhere, either in MercuryNode or MercuryAsset. It is currently unused with the intention of reusing asset/nodes. I do not want a delete self. Having that in HG1 caused all kinds of circular deletions, it was very messy. Also, why are you storing char * of the type? We are using RTTI so we don't have to do this, and it increases the size a fairly large amount. Charles Lohr wrote: > It turns out that C++ does not permit virtual function calls in > Constructors or Destructors. > > I've added code to make a virtual call intentionally after the creation > of objects that so I can set a new variable "const char * Type" that way > I can get the type in the destructor. > > I am curious if we were planning on adding Init() and DeleteSelf() or > something along those lines? > > Charles > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
|
From: Charles L. <lo...@um...> - 2009-10-22 18:21:32
|
It turns out that C++ does not permit virtual function calls in Constructors or Destructors. I've added code to make a virtual call intentionally after the creation of objects that so I can set a new variable "const char * Type" that way I can get the type in the destructor. I am curious if we were planning on adding Init() and DeleteSelf() or something along those lines? Charles |
|
From: Josh A. <axl...@gm...> - 2009-10-12 15:37:12
|
I think I figured it out while at work. I forgot that it should be the barycentric * length of the edge.I'll try to fix it when I get home. I guess I was changing the direction of the edge vector. Josh On Mon, Oct 12, 2009 at 6:31 AM, Josh <axl...@gm...> wrote: > Charles can you take a look at this? > The interpolation results look wrong on screen. Walking around is very > jerky. > > > > > axl...@us... wrote: > >> Revision: 562 >> http://hgengine.svn.sourceforge.net/hgengine/?rev=562&view=rev >> Author: axlecrusher >> Date: 2009-10-11 15:40:51 +0000 (Sun, 11 Oct 2009) >> >> Log Message: >> ----------- >> update >> >> Modified Paths: >> -------------- >> Mercury2/src/DataTypes/MTriangle.cpp >> Mercury2/src/DataTypes/MTriangle.h >> >> Modified: Mercury2/src/DataTypes/MTriangle.cpp >> =================================================================== >> --- Mercury2/src/DataTypes/MTriangle.cpp 2009-10-11 03:34:07 UTC >> (rev 561) >> +++ Mercury2/src/DataTypes/MTriangle.cpp 2009-10-11 15:40:51 UTC >> (rev 562) >> @@ -35,6 +35,23 @@ >> return MercuryVertex(ru, rv, 1-(ru+rv)); >> } >> +MercuryVertex MTriangle::InterpolatePosition(const MercuryVertex& >> barycentric) >> +{ >> + MercuryVertex result( m_verts[0] ); >> + >> + barycentric.Print(); >> + >> + result += (m_verts[1] - m_verts[0])*barycentric; >> + result += (m_verts[2] - m_verts[0])*barycentric; >> + >> +// result.Print(); >> + >> + result[3] = 0; >> + >> + result.Print(); >> + return result; >> +} >> + >> bool MTriangle::IsInTriangle(const MercuryVertex& p) >> { >> MercuryVertex v = Barycentric(p); >> >> Modified: Mercury2/src/DataTypes/MTriangle.h >> =================================================================== >> --- Mercury2/src/DataTypes/MTriangle.h 2009-10-11 03:34:07 UTC (rev 561) >> +++ Mercury2/src/DataTypes/MTriangle.h 2009-10-11 15:40:51 UTC (rev 562) >> @@ -13,9 +13,10 @@ >> bool IsInTriangle( const MercuryVertex& p ); >> >> float Area(); >> - >> + MercuryVertex InterpolatePosition(const MercuryVertex& >> barycentric); >> + >> bool operator == (const MTriangle& rhs); >> - private: >> +// private: >> >> MercuryVertex m_verts[3]; >> }; >> >> >> This was sent by the SourceForge.net collaborative development platform, >> the world's largest Open Source development site. >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Hgengine-cvs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-cvs >> >> > > -- http://www.stepmaniaonline.com |
|
From: Josh <axl...@gm...> - 2009-10-12 10:32:14
|
Charles can you take a look at this? The interpolation results look wrong on screen. Walking around is very jerky. axl...@us... wrote: > Revision: 562 > http://hgengine.svn.sourceforge.net/hgengine/?rev=562&view=rev > Author: axlecrusher > Date: 2009-10-11 15:40:51 +0000 (Sun, 11 Oct 2009) > > Log Message: > ----------- > update > > Modified Paths: > -------------- > Mercury2/src/DataTypes/MTriangle.cpp > Mercury2/src/DataTypes/MTriangle.h > > Modified: Mercury2/src/DataTypes/MTriangle.cpp > =================================================================== > --- Mercury2/src/DataTypes/MTriangle.cpp 2009-10-11 03:34:07 UTC (rev 561) > +++ Mercury2/src/DataTypes/MTriangle.cpp 2009-10-11 15:40:51 UTC (rev 562) > @@ -35,6 +35,23 @@ > return MercuryVertex(ru, rv, 1-(ru+rv)); > } > > +MercuryVertex MTriangle::InterpolatePosition(const MercuryVertex& barycentric) > +{ > + MercuryVertex result( m_verts[0] ); > + > + barycentric.Print(); > + > + result += (m_verts[1] - m_verts[0])*barycentric; > + result += (m_verts[2] - m_verts[0])*barycentric; > + > +// result.Print(); > + > + result[3] = 0; > + > + result.Print(); > + return result; > +} > + > bool MTriangle::IsInTriangle(const MercuryVertex& p) > { > MercuryVertex v = Barycentric(p); > > Modified: Mercury2/src/DataTypes/MTriangle.h > =================================================================== > --- Mercury2/src/DataTypes/MTriangle.h 2009-10-11 03:34:07 UTC (rev 561) > +++ Mercury2/src/DataTypes/MTriangle.h 2009-10-11 15:40:51 UTC (rev 562) > @@ -13,9 +13,10 @@ > bool IsInTriangle( const MercuryVertex& p ); > > float Area(); > - > + MercuryVertex InterpolatePosition(const MercuryVertex& barycentric); > + > bool operator == (const MTriangle& rhs); > - private: > +// private: > > MercuryVertex m_verts[3]; > }; > > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Hgengine-cvs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-cvs > |
|
From: Josh <axl...@gm...> - 2009-10-02 11:02:34
|
The whole float row thing does cause a lot of bullshit and dereferencing, but loading to SSE registers is sooooo slow. We should probably get rid of them, and just get smarted about how we use the SSE functions. Josh Charles Lohr wrote: > I am unsure as to how we went so long with the dangling SSE code that > was never actually enabled because the configuration files were never > actually included, but I included those configuration files, and now > when compiling with SSE, nothing works right. It took quite some time > just to get the project to compile. More work will need to be done to > make SSE work again. > > This does raise a big question - do we really want SSE typed float > vectors sitting around in classes, when most of the time we use them > we're popping around with individual elements. Loading them into the > SSE registers is probably something IMO that should happen in the > functions that perform copious quantities of processing on the data. > > Charles > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |
|
From: Charles L. <lo...@um...> - 2009-10-02 06:53:33
|
I am unsure as to how we went so long with the dangling SSE code that was never actually enabled because the configuration files were never actually included, but I included those configuration files, and now when compiling with SSE, nothing works right. It took quite some time just to get the project to compile. More work will need to be done to make SSE work again. This does raise a big question - do we really want SSE typed float vectors sitting around in classes, when most of the time we use them we're popping around with individual elements. Loading them into the SSE registers is probably something IMO that should happen in the functions that perform copious quantities of processing on the data. Charles |
|
From: Josh <axl...@gm...> - 2009-08-23 13:22:08
|
I did manage to figure out how to change HG2 back to the old recursive render. But there is definitely something wrong with whatever you did, and it looks pretty dirty. Why are you bitwise anding a power of 2? root->GetPasses() & (1<<g_iPass) Wouldn't this make it only render every power of 2 pass? Wouldn't you only be able to specify passes as a power of 2? Then wouldn't you need to increment g_iPass by powers of 2? Are you specifying passes using bits? Is this so you can say render this on pass 1 and pass 2 (that's pass code 3 correct)? Josh cn...@us... wrote: > Revision: 510 > http://hgengine.svn.sourceforge.net/hgengine/?rev=510&view=rev > Author: cnlohr > Date: 2009-08-22 17:51:38 +0000 (Sat, 22 Aug 2009) > > Log Message: > ----------- > allow multipass rendering > > Modified Paths: > -------------- > Mercury2/src/Mercury2.cpp > Mercury2/src/MercuryAsset.cpp > Mercury2/src/MercuryAsset.h > Mercury2/src/MercuryNode.cpp > Mercury2/src/MercuryNode.h > Mercury2/src/RenderGraph.cpp > > Modified: Mercury2/src/Mercury2.cpp > =================================================================== > --- Mercury2/src/Mercury2.cpp 2009-08-22 16:10:33 UTC (rev 509) > +++ Mercury2/src/Mercury2.cpp 2009-08-22 17:51:38 UTC (rev 510) > @@ -92,8 +92,17 @@ > // renderGraph.Render(); > // RenderableNode::RecursiveRender(root); > // printf("\n"); > + > + > + for( g_iPass = 2; g_iPass < 5; g_iPass++ ) //2,3,4 > + if( root->GetPasses() & (1<<g_iPass) ) > + root->RecursiveRender( ); > + > root->RecursivePreRender(); > - root->RecursiveRender(); > + > + for( g_iPass = 5; g_iPass < 15; g_iPass++ ) //5..15 > + if( root->GetPasses() & (1<<g_iPass) ) > + root->RecursiveRender( ); > // renderGraph.RenderAlpha(); > w->SwapBuffers(); > > > Modified: Mercury2/src/MercuryAsset.cpp > =================================================================== > --- Mercury2/src/MercuryAsset.cpp 2009-08-22 16:10:33 UTC (rev 509) > +++ Mercury2/src/MercuryAsset.cpp 2009-08-22 17:51:38 UTC (rev 510) > @@ -6,7 +6,7 @@ > extern bool DOOCCLUSIONCULL; > > MercuryAsset::MercuryAsset() > - :m_isInstanced(false), m_boundingVolume(NULL), m_loadState(NONE), m_ignoreCull(false) > + :m_isInstanced(false), m_boundingVolume(NULL), m_loadState(NONE), m_ignoreCull(false), m_iPasses( DEFAULT_PASSES ) > { > } > > @@ -65,8 +65,16 @@ > > if ( !node.Attribute("ignorecull").empty() ) > { > - SetIgnoreCull( node.Attribute("ignorecull")=="true" ); > + SetIgnoreCull( StrToBool( node.Attribute("ignorecull") ) ); > } > + if ( !node.Attribute("setPasses").empty() ) > + { > + MVector< MString > out; > + SplitStrings( node.Attribute("setPasses"), out, ",+", " \t", 2, 2 ); > + m_iPasses = 0; > + for( unsigned i = 0; i < out.size(); i++ ) > + m_iPasses = m_iPasses | (1<<StrToInt( out[i] ) ); > + } > } > > void MercuryAsset::DrawAxes() > @@ -86,7 +94,7 @@ > } > > MercuryAssetInstance::MercuryAssetInstance(MercuryAsset* asset) > - :m_asset( asset ), m_isCulled( false ) > + :m_asset( asset ), m_isCulled( false ), m_iPasses( asset->GetPasses() ) > { > } > > > Modified: Mercury2/src/MercuryAsset.h > =================================================================== > --- Mercury2/src/MercuryAsset.h 2009-08-22 16:10:33 UTC (rev 509) > +++ Mercury2/src/MercuryAsset.h 2009-08-22 17:51:38 UTC (rev 510) > @@ -58,6 +58,9 @@ > > inline void SetIgnoreCull(bool t) { m_ignoreCull = t; } > inline bool IgnoreCull() const { return m_ignoreCull; } > + > + inline unsigned short GetPasses() { return m_iPasses; } > + inline void SetPasses( unsigned short p ) { m_iPasses = p; } > protected: > void SetLoadState(LoadState ls); //thread safe > LoadState GetLoadState(); //thread safe > @@ -69,6 +72,7 @@ > LoadState m_loadState; > MSemaphore m_lock; > bool m_ignoreCull; > + unsigned short m_iPasses; > }; > > /** This holds the per-instance data for each asset instance. > @@ -85,10 +89,16 @@ > inline bool Culled(bool t) { m_isCulled = t; return m_isCulled; } > > inline OcclusionResult& GetOcclusionResult() { return m_occlusionResult; } > + > + inline unsigned short GetPasses() { return m_iPasses; } > + inline void SetPasses( unsigned short p ) { m_iPasses = p; } > private: > MAutoPtr< MercuryAsset > m_asset; //actual asset storage > OcclusionResult m_occlusionResult; > bool m_isCulled; > + > + //We need to keep our own copy, since it may be changed in software from what the original one has. > + unsigned short m_iPasses; > }; > > class LoaderThreadData > > Modified: Mercury2/src/MercuryNode.cpp > =================================================================== > --- Mercury2/src/MercuryNode.cpp 2009-08-22 16:10:33 UTC (rev 509) > +++ Mercury2/src/MercuryNode.cpp 2009-08-22 17:51:38 UTC (rev 510) > @@ -186,10 +186,10 @@ > } > } > > -void MercuryNode::RecursiveRender() > +void MercuryNode::RecursiveRender( ) > { > - if ( IsHidden() || IsCulled() ) return; > - > + if ( IsHidden() || IsCulled() || (! (m_iPasses & (1<<g_iPass))) ) return; > + > const MercuryMatrix& matrix = GetGlobalMatrix(); > const MercuryMatrix& modelView = GetModelViewMatrix(); //get the one computed in the last transform > ShaderAttribute sa; > @@ -262,6 +262,16 @@ > } > } > } > + > + if ( !node.Attribute("setPasses").empty() ) > + { > + MVector< MString > out; > + SplitStrings( node.Attribute("setPasses"), out, ",+", " \t", 2, 2 ); > + m_iForcePasses = (1<<15); > + for( unsigned i = 0; i < out.size(); i++ ) > + m_iForcePasses = m_iForcePasses | (1<<StrToInt( out[i] ) ); > + } > + > } > > > @@ -365,7 +375,9 @@ > > bool MercuryNode::m_rebuildRenderGraph = false; > __thread int g_iViewportID; > +__thread int g_iPass; > > + > /*************************************************************************** > * Copyright (C) 2008 by Joshua Allen * > * * > > Modified: Mercury2/src/MercuryNode.h > =================================================================== > --- Mercury2/src/MercuryNode.h 2009-08-22 16:10:33 UTC (rev 509) > +++ Mercury2/src/MercuryNode.h 2009-08-22 17:51:38 UTC (rev 510) > @@ -30,9 +30,17 @@ > return false;} > */ > > + > +#define STANDARD_PASS 7 > +///Which passes, by default, should be run on all nodes. > +#define DEFAULT_PASSES ( (1<<STANDARD_PASS) ) > + > ///The Global Viewport ID for this thread (to enable multi-threaded functioning for Viewports) > extern __thread int g_iViewportID; > > +///The Global Pass Number (which Pass is currently doing Render) > +extern __thread int g_iPass; > + > class MercuryNode : public MessageHandler > { > public: > @@ -106,6 +114,8 @@ > > const MercuryMatrix & GetGlobalMatrix() const { return m_pGlobalMatrix[g_iViewportID]; } > const MercuryMatrix & GetModelViewMatrix() const { return m_pModelViewMatrix[g_iViewportID]; } > + > + inline unsigned short GetPasses() const { return m_iPasses; } > protected: > std::list< MercuryNode* > m_children; //These nodes are unique, not instanced > MercuryNode* m_parent; > @@ -120,6 +130,9 @@ > bool m_culled; > bool IsInAssetList(MercuryAsset* asset) const; > > + unsigned short m_iPasses; > + unsigned short m_iForcePasses; //If (1<<15) is set, then, we know the force is enabled. > + > //The asset is actually stored here > std::list< MercuryAssetInstance > m_assets; > > > Modified: Mercury2/src/RenderGraph.cpp > =================================================================== > --- Mercury2/src/RenderGraph.cpp 2009-08-22 16:10:33 UTC (rev 509) > +++ Mercury2/src/RenderGraph.cpp 2009-08-22 17:51:38 UTC (rev 510) > @@ -56,18 +56,32 @@ > > //Update the Matrices > node->m_pGlobalMatrix = &node->FindGlobalMatrix(); > - node->m_pModelViewMatrix = &node->FindModelViewMatrix(); > - > + node->m_pModelViewMatrix = &node->FindModelViewMatrix(); > + > if ( node ) > { > //found a new renderable > entry.m_children.push_back( RenderGraphEntry(&(node->FindGlobalMatrix()), node) ); > lastEntry = &(entry.m_children.back()); > } > + > + unsigned short iPasses = 0; > > for (MercuryNode* child = node->FirstChild(); child != NULL; child = node->NextChild(child)) > + { > Build(child, *lastEntry); > - > + iPasses |= child->m_iPasses; > + } > + > + std::list< MercuryAssetInstance >::iterator i; > + for (i = node->m_assets.begin(); i != node->m_assets.end(); ++i ) > + iPasses |= i->GetPasses(); > + > + if( node->m_iForcePasses & (1<<15 ) ) > + node->m_iPasses = node->m_iForcePasses; > + else > + node->m_iPasses = iPasses; > + > //coming back up the tree > // entry = lastEntry; > } > > > 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-22 15:59:11
|
Those are not names. Those are attributes. I believe I keep all XML attributes lower case because it keeps it simple when you have to remember them. All XML names are lowercase too (node, asset). SceneGraph is not lower case but probably should be. XML can not make names and attributes case insensitive and I don't feel like putting in the effort to hack around that. Now for the values of the attributes, you can make case insensitive on an individual basis. For example, the value of type="" is case insensitive. Josh Charles Lohr wrote: > How are we doing the XML names? > > ignorecull > IgnoreCull > ignoreCull > > I'd really like some standardization. > > ------------------------------------------------------------------------------ > 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 15:51:02
|
Charles Lohr wrote: > 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. > That's how it works now. > 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. > > Na I wanna try my idea, which will include skipping texture re-binds. In the past, I think we did this but I may have had to remove it for some reason. > 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 >> >> > > > ------------------------------------------------------------------------------ > 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 15:37:47
|
How are we doing the XML names? ignorecull IgnoreCull ignoreCull I'd really like some standardization. |
