TDFmacros

[Guest]

Hi everybody,tryng to figure out how the different macros word I found that there are (at least) to different versions around. My question concerns the VTPPolyMethod2Ex macro. In the version coming with LMWDraw it runs as follows:VTPPolyMethod2Ex Macro ExPointCount; enum{ MaxNumPointsEx = 31 + 127 };; UINT8 bExPointCount; // The number of points = 31 + bExPointCount; BYTE ExPointCount WORD ExPointCountEndMin the version coming with LMWTut as follows:VTPPolyMethod2Ex Macro PointCount; enum{ MaxNumPointsEx = 31 + 127 };; UINT8 bExPointCount; // The number of points = 31 + bExPointCount BYTE PointCount + 127EndMas you can see from the comment lines, both versions are different from the infomation in the MS SDK. So which one is correct (if any)?I need the information to write some disassembler code. Of course, if in reality it is a BYTE value, than counting it as a WORD will make it impossible to read the next record correctly. If it is a BYTE, but contains a value different from the extra point count (which means, that the number of points is in reality not just 31 + the contents of this byte), the disassembler will expect the wrong number of point records to follow.Any help from the specialists will be appreciated.- osman

[Guest gorchi]

Hi Osman!I think the version 1 is true because with VTPPolyMethod2Ex You tell how many points are over the number 31 to which VTPPolyMethod2 is limited. So if You have 231 VTPWidePoint instructions, then You have these two instructions together before first VTPWidePoint instruction:VTPPolyMethod2 31, 1, 0VTPPolyMethod2ex 200Together they give You 231 points. And one more important thing. The number of points is not limited to 31+127 (=158) points; I have roads which exceed 300 points and there is nothing wrong although it can happen, that FS will behave oddly if there is more than 250 points.Hope it helps.Best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

[rhumbaflappy 113]

Hi osman.http://www.flatface.net/~rhumba/Zips/TDFmacros.zipThat's the newer version of the macros. I believe it is with the cellgrid download.

VTPPolyMethod1Ex		Macro	ExPointCount;	enum{ MaxNumPointsEx = 63 + 127 };;	UINT8 bExPointCount; 	 // The number of points = 63 + bExPointCount;	BYTE	ExPointCount	WORD	ExPointCountEndM

Christian Stock had found this to be a WORD, not a BYTE, as the SDK states, and I had misinterpreted the addition of the count. I do not know the actual upper range of the point count.If you are attempting a decompiler for the default VTPs, good luck. You may want to correspond with Christian, as I'm sure he'll agree... The VTP lines of FS2002 are not the same lines we make with the SDK information. Christian has already done a great deal of work with a decompiler. I don't know if, or when, he may release it to the public. But you might not want to redundantly duplicate his work, if the release is to be soon. I haven't written to him about this in quite some time.Christian also uses a different set of macros. When I released the TMFMacros.inc, I attempted to follow the semantics of the SDK, so we would all have a source reference we could commonly use for discussion. That seems to have worked fairly well. Christian has made a set of macros that uses an Assembly-language type naming convention, and disgards some parameters that are reserved, or always '0'. I believe he also was combining a few structures. As a result, that last version of his decompiler, that I saw, would require his set of macros to recompile.As of a few months ago, Christian was well along in his development of the decompiler... and I noted he recently mentioned it in one of his posts.===================Just try to load our homebrewed VTP lines into TMFViewer.. they rarely will display, and sometimes crash the viewer!The default lines load and display just fine.If you look at the hexcode, you'll soon find that MS designers are using some 'reserved' bits in some of the coding, and that throws off any pointcounts, or locations, from there on in the datastream.Additionally, the SDK information concerning VTP Method1 fans and strips is also wrong concerning the maximum number of points.. It is limited ( 22, I think )... and seems to have no valid extended form.The SDK information was very much needed, and helped us tremendously. But it needed a big rewrite to correct it's errors and update the structures... and it never got it. So much of VTP is still a mystery. LWM seems complete, and does load into TMFViewer just fine.Dick

[Guest]

Hi Dick,thanx for the response. My intention was to make a disassembler that I wrote before and which works fine for the normal section you can code with SCASM, work for LWM and VTP too. For me it was a way to learn to understand the code (and to be able to check if I understood everything). Up to now I only tried it on short code sections from the LWMmanual and from other examples given in LWMDraw and I was able to reproduce the source code. Next step would be to try it on MS Code; but if something similar will be released soon maybe I will forget about it. I am going to contact Christian Stock for it.

[rhumbaflappy 113]

Hi osman.Contacting Christian is the way to go. Let us know how it comes out.:)Dick

[Guest christian]

Hi Winfried (and Dick)I just got your message and I'll reply here (I use my work account for replying, but can't send from home, so usually don't reply until I'm at work).Yes my decompiler is growing strong. I've been working on it for TWO years now. Mainly, I got it all working realtively fast, but basically reinvented SCASM (that was before Manfred updated SCASM). Then I discovered the power and potential of BGLC, the real advantage over SCASM in my opinion is that once M$ decides to completely rewrite the BGL system (which may already happen in FS2004 acoording to rumours) all it takes is to rewrite the BGLC macros to get up to speed with the new scenery commands.I've pretty much put it on ice for a while, because it bacically was a whole lot of retyping of work already done. Luckily, I use public transport to go to work and recently got an ipaq, so I copied the files across and did all the typing on the tram. This works rather brilliantly and after 2 months of commuting my decompiler nears completion. I'm currently about to add the dynamic section and then I'll basically be finished. (still have to do some testing though). A release in about 3 months time may not be too unrealistic...However, I still have to work out if I'll charge a small fee for it. I think 2 years time of work really is a lot to just produce freeware... (the deal will be though that people who contibuted to it won't have to pay anything)...I think Dick really answered your questions pretty well.1) My macros are different to his. They just are a bit 'smarter', ie they do a few things automatically and the designers don't have to worry about a few critical issues (like maximum point counts, the EX functions are handled automatically). They also incorportate some undocumented stuff I've found in the default bgl files.2) Those resevered bits in the line code are crazy. If you can crack those you'll be in for a 'medal of scenery decompiling' :) Read the post about waves for some more comments I made about the lines...Cheers, Christian

[rhumbaflappy 113]

Hi all.Both Christian and I understand that one of the strengths of BGLC is the ease of Macro creation. When Christian's decompiler becomes available, it's set of macros may become the standard. Don't be alarmed... they are very similar to my set, and as Christian states, they are smarter ( and will save typing ).I have also, from time to time, used additional macros to save repetition. An exotic use of BGLC macros can be seen in the cellgrid release... take a look at the convoluted macro sometime. You'll agree that I need to be a bit demented to have created that! :-lol It's possible that our 2 different macro stess may co-exist... in other words, they could actually be used together. And that is also demented! :-xxrotflmao VTP line code is a tough mystery to solve, and necessary to solve.Dick

[Guest]

Hi everybody,thanx for the information on the decompiler. I agree that BGLC is very handy for many purposes, but on the other hand SCASM has many advantages for the ordinary stuff, like doing for us the computation of vectors for VecPolys. I still would love to have a SCASM-like program for TDF and LWM, building all the framework for me and checking for possible errors ...Winfried

[rhumbaflappy 113]

Hi Winfried.There's no reason that Manfred could not make SCASM TDF compatible. But it would take some time for him to code for it, and perhaps he doesn't have that time.I know plans for Airport are still to abandon SCASM, and go to BGLC, and perhaps they will include TDF coding, eventually.It might be possible to include some higher math routines to BGLC, to allow some floating point computation and conversions. Christian Stock has more experience with MASM, so he may have already done this.The SDKs are actually written for C+ programmers! And there is no reason a higher level language could not make a BGL... it's just bits & bytes in the correct order.Dick