Re: Complexity of new hardware
Alen Ladavac <[email protected]>
| Newsgroups | gmane.games.devel.algorithms |
|---|---|
| Organization | Croteam |
| Message-ID | <[email protected]> |
Adrian wrote at 4/19/2009:
> http://gameangst.com/?p=107
The syntax approach is really interesting, but I find the overall
format too verbose. Still too much redundant data for my taste.
We use something much more terse:
meta ver(1) class ENGINE_API CDecalConfig : public CResource {
public:
CDecalConfig(void);
~CDecalConfig(void);
// ... functions ...
MD_DECLARE;
public:
_( 1) Vector2f dc_vSize; _("Size (m)")
_( 2) IDENT dc_idTextureUVMap; _("Texture UV map")
_( 3) IDENT dc_idShadowUVMap; _("Shadow UV map")
_( 4) Ptr<CShaderPreset> dc_pspShader; _("Material") flags(SMF_NEW|SMF_DELETE|SMF_BROWSE)
};
This of course, requires a custom parser, but I think it is very much
worth the extra typing later on. I find all the approaches that force
you to repeat yourself to be dangerous. You can easily forget to list
one of the variables. With the preprocessor approach, in contrast, you
immediately see everything about a member when you look at its
declaration.
Also, using per-class C++ code that creates meta objects at boot time,
as you mention in the article, is really heavy on the final executable
size, and linker performance. We used that previously, but trying to
ship with that for Xbox1 forced us to rewrite it to use static data
per class, which is then read by the reflection code at boot time to
generate the needed objects. That approach makes handling templates
more complicated, though.
Alen
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list