Today I found the solution for analyzing MS files with VTP polygons like the nph****.bgl files, which contain polygons for non permanent water bodies. According to MS SDK there is a reserved bit in the VTPPolyCount record. I found that when this bit is set, the next byte that follows (usually 0x01 or 0x02) is part of the VTPPolyCount record: to the number of polygons given in bCount we must add the number contained in that byte multiplied by 128. This way it is possible to have more than 127 polygons with the same layer in the same texture in one VTPDataArea. So the VTPPolyCount macro in TDFMacros.inc should be rewritten, probably with a conditional assembler instruction, either testing for an additional parameter (contents of the additional byte) or testing the size of the Count parameter. For the time being one can add just a "db nn" instruction after the VTPPolyCount macro.-osman

Hi osman.Perhaps this is correct then? :; --------------------------------------------------------------------------------VTPPolyCountEx Macro Ex BYTE Ex ; Ex = multiple of 128EndM; --------------------------------------------------------------------------------In this case, if the Reserved bit is flagged ( = 1 ), then add a second byte that is the whole multiple of 128.EDITED:The format could simply be the same:VTPPolyCount 20,1VTPPolyCountEx 1for a polycount of 148 ...( 1 * 128 ) + 20 = 148 Can you email me a ASM with a poly count of greater than 127? mailto:[email protected]

just to confirm you are correct :) I found that a few months ago and have posted that here on the odd occasion. I assume the same will hold true for the other macro with the 127 limit (can't remember the name now). I never found a bgl actually using it and never tested it either but it would make sense...I have even rewritten that macro, Rhumba should have a copy, don't have my TMFmacro.inc here unforunately...I'd still like to know the unknowns in the road / stream data though :(Cheers, Christian