Placing Library Objects

[ShezA 176]

Dick,Have a look at FSRegen V0.31, it already gives you the ability to create a CalLibObj api. Makes it very easy.RegardsShez

[rhumbaflappy 113]

Hi Arno.Actually Gerrish pointed to an advantage of type 4 over type B.Type 4 is NEAR SMALL Type 7 is FAR SMALL Type A is NEAR/FAR SMALL and all are 'contained' in a 256 byte page as Gerrish said... perfect for calling an object from a library. If the object code is contained in the BGL ( not called ), you'd need NEAR/FAR LARGE ( type B ) or NEAR/FAR HUGE ( type C ), depending on the size of the object code.I actually like the idea of the GUI internally generating the code for calling library objects. It is simple enough to do, and in fact, that's what the BGLPlacer/BGLC method does ( except it calls the object twice! ). I don't understand why GUIs need to use APIs for simple object calling... unless the GUI visually treats the Calling API as the object so it can move it around.Placing objects that are NOT in libraries would require an API, unless the GUI has some sort of internal code generation for "standard" objects.Am I right in that Gmax gives 2 ASM files... one for the object code alone, and another for the object plus it's placement? And the BGL is object + placement? How strange they did not account for library creation from within Gmax, especially when that is the method M$ uses itself. But then I guess Microsoft's deal with Gmax was not primarily intended for scenery objects, but for Aircraft.Dick

[arno 1]

>I actually like the idea of the GUI internally generating >the code for calling library objects. It is simple enough to >do, and in fact, that's what the BGLPlacer/BGLC method does >( except it calls the object twice! ). I don't understand >why GUIs need to use APIs for simple object calling... >unless the GUI visually treats the Calling API as the object >so it can move it around. True, the code of a library call (macro or not) is that simple that the design program can easily make it for you. That would mean that the program only needs to have a list of the available objects (and a way to add new objects of course).On the other hand, the code that the macros uses is the same (and also very simple) and for the resulting BGL there will be no difference. So for user made new objects it might be the fastest way of adding them. Another advantage of using a macro is that you can add some code to it (only used by the design program) that displays the actual shape of the object, instead of some sort of default shape. This would be more difficult to add without a macro.For the placement of the objects I don't expect much difference between using a macro or a internal GUI code, both should be represented as some sort of symbol on the screen and should thus be able to be moved around, etc.>Am I right in that Gmax gives 2 ASM files... one for the >object code alone, and another for the object plus it's >placement?The first file (test.asm) contains the code for the placement, so in SCASM terms it contains the Header, LatRange, PerspectiveCall, ShadowCall, RefPoint, etc. In this file there is an include command that loads the second file (test_0.asm) which contains the actual code of the object. So it is not so that one file contains the info of both together, they substitude each other.FsRegen only uses the _0.asm file and makes the library with the actual code for the object.The resulting BGL is thus created by compiling the first file (test.asm) and during the compilation the second file is also loaded and everything ends up in one BGL file.> But then >I guess Microsoft's deal with Gmax was not primarily >intended for scenery objects, but for Aircraft.I am afraid that is true, also when you look at the options MakeMDL has and also the bugs it has, it is clear that they looked more from the aircraft point of view.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[rhumbaflappy 113]

Hi Arno.Concerning Gmax, it's a good thing George created fsregen, so these objects can be easily 'collected' and stored into libraries. Are there any library viewers around, that actually let you see a library object? I would think such a thing could be possible.Dick

[ShezA 176]

I have been experimenting with extracting library objects through the FSRegen route and have successfully extracted all of the MS stock objects and placed them by using their GUID in the CallObjLib api. I cannot however (of course) make amendments to them as I do not have the GMAX files, however I can change the textures.Shez

[rhumbaflappy 113]

Hi all.Here's a snippet of SCASM code from FSSC:

; ship2Area( 5 S00:00:00.1296 E000:00:09.5248 12 )	IfVarRange( : 346 2 32767 )	CrashIndirect( :lblObj :lblDraw :lblRotate 0 2 )	PerspectiveCall( :lblPerspective )	ShadowCall( :lblDraw )	Jump( : ):lblPerspective	Perspective:lblDraw	RefPoint( rel :lblReturn 1.0 S00:00:00.1296 E000:00:09.5248 v1= 0 v2= 500 ):lblRotate	RotatedCall( :lblObj 0 0 0.0 ):lblReturn	Return:lblObj	CallLibObj( 0 C545A29E 11D2E2EC 1000849C 2AE60C5A )	ReturnEndA

FSSC has a means of storing APIs, and that allows a collection of library object calling macros to be stored. It also seems to have some code for default FS2000 libraries hardcoded, or derived. It appears the FS2000 library objects are identical to the FS2002(?), regarding GUID numbers.IfVarRange checks for scenery density setings. That code may slow down the sim. It does allow a user to choose density settings, but why would they use your scenery, then turn it off with the scenery density slider? I'd leave it out, as they can just not use the scenery if they don't like it.The MS library object placement I've looked at, and that placed by BGLPlacer, doesn't use any crash detection call... yet the sim does record the crash with objects placed this way... so I'm thinking that code is also unneeded, and may slow things down a bit. We may need to investigat that a bit.The PerspectiveCall doesn't need to point to the outdated Perspective command, but to the RotateCall. Also, I'm not so sure we shouldn't be using PerspectiveCall32 for FS2002(?). Perhaps someone knows something about that.It does place the Returns correctly.As Shez and Arno have pointed out, a library object calling API can be created to adjust this in FSSC, but a separate API is then needed for each object... which seems like another layer of complication to me.Placing the library objects with SCASM handcoding might actually be quicker, and would be somewhat interactive with the sim, as you can slew around in windowed mode, and have notepad right on the desktop. Just requires some cut and pasting, and fsregen can also be active, to allow you to browse libraries to gather GUIDs and scaling codes from the libraries.Placing the objects with BGLC code may also be mostly cut and paste, and could go fairly quickly. Additionally, the use of separate LatBands for each object, or groups of objects is allowed in BGLC. In SCASM, you can use only one LatBand, and must link separate BGLs together to achieve separate LatBands. This might not be needed for compact projects, like an airfields, or a city.Why MS didn't give us an interactive Library object placer is a mystery... they had one in CFS1.Even now, I think with FSUIPC, an interactive placer program could be made... even one that can select from a list of library objects ( like fsregen can derive a list and the GUIDs ). That would allow us to place library objects from any library ( even our own libraries ). The resultant SCASM or BGLC code could then be compiled or pasted into other code for compilation. Christian Fumey's 'DefArea' program used mouse-clicks to locate VTP exclusion Areas interactively with FSUIPC and the running sim... so it is quite possible.Dick

[Guest GerrishGray]

Hi guysThe correct structure for a library call is something like

[font color="red"]Area( 4 ... ) ; type 4 Area() is ideal for a simple library call  IfVarRange( : 346 2 32767 )  CrashIndirect( :Obj :Draw :Rotate ... )  PerspectiveCall( :Draw )  ShadowCall( :Draw )  Jump( : ):Draw  RefPoint( rel :EndDraw ... ):Rotate  RotatedCall( :Obj ... ):EndDraw  Return:Obj  CallLibObj( 0 ... )  ReturnEndA[/font]

Notes:[ol][li]The Perspective statement (BGL in BGLC) is obsolete and can be omitted. It is ignored by all modern FS scenery engines.[/li][li]All Return's shown are theoretically necessary for correct program structure.[/li][li]However, a BGL file is not truly executable code, it is merely 'tokenised' instructions for a programming language (namely the Bruce Artwick Organisation Graphics Language) that is interpreted at runtime by the scenery engine.[/li][li]It seems that the FS2002 engine is quite tolerant of a variety of 'programming errors' in BGL files. The engine often manages to operate correctly despite these errors and is clearly able to infer in some circumstances that a 'Return' is required/necessary even where the programmer has omitted it.[/li][li]However, it is likely that the code will execute slower because of the extra work involved in the error checking/correction, so it is probably better to code correctly in the first place rather than rely on the skill of Microsoft's programmers in creating an engine that detects and allows for our mistakes! I would be surprised if all possible mistakes can be successfully detected and corrected anyway - a further reason to make every effort to get the coding right in the first place and not get into sloppy habits![/li][/ol]Hope this helps clear up the queries that have been raised in this thread and explains the apparent puzzle that incorrectly-structured code still seems to give the correct, desired, results. Thank the often unjustly maligned guys at Redmond for the excellence of their work and their kindness in second-guessing our lack of programming skills!!!Kind RegardsGerrish

[arno 1]

>[li]It seems that the FS2002 engine is quite >tolerant of a variety of 'programming errors' in BGL files. >The engine often manages to operate correctly despite these >errors and is clearly able to infer in some circumstances >that a 'Return' is required/necessary even where the >programmer has omitted it.[/li]While converting my Fs2000 scenery I found out that the Fs2002 engines is less forgiving then the Fs2000 one. Fs2002 crashes while Fs2000 still worked with the wrong code.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[arno 1]

>IfVarRange checks for scenery density setings. That code may >slow down the sim. It does allow a user to choose density >settings, but why would they use your scenery, then turn it >off with the scenery density slider? I'd leave it out, as >they can just not use the scenery if they don't like it. I do not agree with that. Using the density settings allows users with a slower PC to still use your scenery, but maybe without all the extra details you added for the fasters PC's.But I never put a density restriction on the basic objects of my scenery that "make" the airfield, so all important things like terminal, hangars, towers are always visible.>The MS library object placement I've looked at, and that >placed by BGLPlacer, doesn't use any crash detection call... >yet the sim does record the crash with objects placed this >way... so I'm thinking that code is also unneeded, and may >slow things down a bit. We may need to investigat that a >bit. Could it be that the crash code is in the library? If it crashes I think that code is part of the library object (and thus can be removed from the calling API).>The PerspectiveCall doesn't need to point to the outdated >Perspective command, but to the RotateCall. Also, I'm not so >sure we shouldn't be using PerspectiveCall32 for FS2002(?). >Perhaps someone knows something about that.I don't know what the difference is, but for the Jump command for example, the Jump32 commands allows you to jump over bigger amount of code. As the calling API is rather small I expect no difference between using PerspectiveCall and PerspectiveCall32.>Placing the library objects with SCASM handcoding might >actually be quicker, and would be somewhat interactive with >the sim, as you can slew around in windowed mode, and have >notepad right on the desktop. Just requires some cut and >pasting, and fsregen can also be active, to allow you to >browse libraries to gather GUIDs and scaling codes from the >libraries. Sounds nice :), but not everybody likes writing there own SCASM source. But for people that like playing with source code it is a good way.For my Schiphol scenery I also place my library objects with a piece of SCASM code that I have written by hand.>Even now, I think with FSUIPC, an interactive placer program >could be made... even one that can select from a list of >library objects ( like fsregen can derive a list and the >GUIDs ). That would allow us to place library objects from >any library ( even our own libraries ). The resultant SCASM >or BGLC code could then be compiled or pasted into other >code for compilation. Christian Fumey's 'DefArea' program >used mouse-clicks to locate VTP exclusion Areas >interactively with FSUIPC and the running sim... so it is >quite possible. Yeah, that's a good idea. We have added that feature to our NL2000 scenery tool (that also places our macros). That way we can go to a spot in FS and place a macro right there with a few clicks in the tool.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[Guest GerrishGray]

Hi ArnoYou may well be right that FS2000 is more fault-tolerant than FS2002 - I didn't mean to imply that this was a feature of FS2002 specifically. In fact, it is logical that FS2002 may be less fault-tolerant because that is one of the main directions for the present development of the scenery engine - to make it 'slimmer' and therefore quicker by relying on us doing more of the 'detailed design' process in our code rather than the scenery engine doing it for us. The older BGL rendering commands did all sorts of work for us, such as triangulating polygons etc. These commands could even sort out the trickier problem of triangulating a concave polygon, as long as we flagged the problem to the engine. But the new DirectX-friendly floating point commands require us to do it ourselves (and MS have been asking us even in earlier versions not to overload the engine with concave polygons - if anyone read the SDK's thoroughly). This is very sensible because this sort of thing should correctly be a one-off design-time task, NOT something that the scenery engine has to endlessly repeat every time it interprets the BGL!Also, new programming structures are being introduced, such as the Transform Matrix, which eliminate the overhead of some of the multiple levels of nested subroutine calls, so it is probably getting slightly more difficult for the engine to correctly spot program structure errors in BGL files anyway.Maybe one day the engine will even effectively become a virtual machine executing compiled code directly, rather than being a 'p-code' interpreter as at present.It all boils down to a growing need for scenery designers (and - dare I say it - the authors of GUI tools!) to understand properly how the BGL language works and how to write correct code in SCASM, BGLC or whatever rather rely on the scenery engine sorting out sloppy programming errors. If only MS could find the time to give us proper reference manuals instead of the present incomplete SDK's and often-buggy tools ... dream on!!!CheersGerrishPS. I'm going to start separate threads about the questions of (a) crash detection and (:( the use of the different types of object header because there are some interesting issues with both.

[arno 1]

Hi Gerrish,Great overview :).I agree that more knowledge of how the scenery engine works is good for creating more efficient scenery. Know I have learned much more about it, I understand much better why all the commands are like they are etc. And that of course helps in creating the most efficient code.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]