makedmt.py and mapdata.hs
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the category: Engine.</i>
I have now checked in the map data type processing script (<tt>Scripts/makedmt.py</tt>) and the map data types "meta header" file (<tt>Include/mapdata.hs</tt>). I have also updated p_dmu.c with the necessary changes. However, P_Copy(p) and P_Swap(p) will not work with the currently available data. We need to do some extra thinking here.
The way the P_Copy/Swap previously worked, using the propertyTypes array, is flawed. It makes the incorrect assumption that every property has the same type in each map data object. This is not the case when it comes to, e.g., flags. We will most likely need a way to determine the DDVT type of a property, given we know the DMU type (e.g., DMU_LINE, DMU_POLYOBJ) <b>and</b> the property (e.g., DMU_FLAGS). We will need to modify makedmt.py and mapdata.hs so that the internal members are mapped to properties. I was thinking something like:
<pre>
properties seg
FLAGS flags
FRONT_SECTOR frontsector
end
</pre>
...and so on.
HOWEVER. Because properties are not really 1-to-1 mappable to internal data members, we should carefully consider how P_Copy/Swap should be implemented, and how mapdata.hs should be defined. Some properties affect multiple internal data types, or are interpretations of the internal data. These can only be handled as special cases in P_Copy/Swap, or otherwise we have very complicated logic on our hands (need to define member aggregates, translations, whatnot... Not a sensible use of our time?). It seems to me that a simple mapping like in the above example is good enough for something like 80% of the properties. The rest should most likely be handled as special cases in the code, and not have any information declared about them in mapdata.hs.
I have now checked in the map data type processing script (<tt>Scripts/makedmt.py</tt>) and the map data types "meta header" file (<tt>Include/mapdata.hs</tt>). I have also updated p_dmu.c with the necessary changes. However, P_Copy(p) and P_Swap(p) will not work with the currently available data. We need to do some extra thinking here.
The way the P_Copy/Swap previously worked, using the propertyTypes array, is flawed. It makes the incorrect assumption that every property has the same type in each map data object. This is not the case when it comes to, e.g., flags. We will most likely need a way to determine the DDVT type of a property, given we know the DMU type (e.g., DMU_LINE, DMU_POLYOBJ) <b>and</b> the property (e.g., DMU_FLAGS). We will need to modify makedmt.py and mapdata.hs so that the internal members are mapped to properties. I was thinking something like:
<pre>
properties seg
FLAGS flags
FRONT_SECTOR frontsector
end
</pre>
...and so on.
HOWEVER. Because properties are not really 1-to-1 mappable to internal data members, we should carefully consider how P_Copy/Swap should be implemented, and how mapdata.hs should be defined. Some properties affect multiple internal data types, or are interpretations of the internal data. These can only be handled as special cases in P_Copy/Swap, or otherwise we have very complicated logic on our hands (need to define member aggregates, translations, whatnot... Not a sensible use of our time?). It seems to me that a simple mapping like in the above example is good enough for something like 80% of the properties. The rest should most likely be handled as special cases in the code, and not have any information declared about them in mapdata.hs.
Comments
Excellent. I've updated p_arch.c to use the new DMT_ constants in place of the DAMpropertyTypes array (DAM's propertyTypes counterpart).
A couple of properties are not currently set in mapdata.hs to generate DMT_ constants that are used in DAM but not in DMU:
node_t->bbox
node_t->children
I'm not currently setup with Python so install it and I'll do that tommorow. I'll also see about automating the invocation of the build script in vcbuild.bat once I'm all setup (a simple date&time compare should suffice).
<blockquote>However, P_Copy(p) and P_Swap(p) will not work with the currently available data. We need to do some extra thinking here.</blockquote>
<blockquote>The way the P_Copy/Swap previously worked, using the propertyTypes array, is flawed.</blockquote>P_Copy/Swap also have another flaw in that they don't work for aggregate data types. For example DMU_SOUND_REVERB cannot currently be P_Copy'ied/Swap'ped but there is no checks/logic in place to prevent it.
<blockquote>These can only be handled as special cases in P_Copy/Swap, or otherwise we have very complicated logic on our hands (need to define member aggregates, translations, whatnot... Not a sensible use of our time?).It seems to me that a simple mapping like in the above example is good enough for something like 80% of the properties. The rest should most likely be handled as special cases in the code, and not have any information declared about them in mapdata.hs.</blockquote>I agree that to do this the "Right Way" presently is not really a good use of our time. This has to fall into the realms of "in an ideal world". Since we have more pressing work to do, I think I'm happy with using a simple - internal member to property mapping, as you suggest and work around the special cases manually.
Once we have a way to determine the DDVT type of a property, I can get rid of this special case logic and the DDVT_ constants it uses.