Sign in to follow this  
arno

Placing Library Objects

Recommended Posts

Hi all.I thought maybe it was time for a new thread concerning the placement of library objects. From what I can gather, the consensus is that using objects from libraries can save coding time, and can save memory as well. Microsoft uses this technique with the default scenery objects, and Gmax apparently also produces an ASM object in Library format, and a placement ASM. It makes no difference what coding language is used to create the library object call, as long as the resultant BGL is valid.Just for comparison's sake...I placed a default Library object ( radar shack tower ) near my home airport. I used BGLPlacer, from Microsoft.Here is the CSV file from BGLPlacer, that was drag'n'dropped onto the BGLC icon to compile:; Generated by BGLPlacer 8.0;; format for each line is the following:; EFFECT, ,,,,,,,,; LIBRARY, ,,,,,,,,; WINDSOCK,,,,,,,,,; BUILDING,,,,,,,,,;LIBRARY,SCO_gen_radarshack,N42* 37.72',W88* 35.99',AGL,0.00,0.00,45.00,Very Sparse,""I took the resultant BGL, and decompiled it to SCASM with BGLAnalyse:; ----------------------------------------; RadarShack.bgl disassembled by BGLAnalyze © on Thu Dec 05 09:04:36 2002; ----------------------------------------Header( 1 N42:37:43.19 N42:37:43.19 W088:35:59.40 W088:35:59.40 )LatRange( N42:37:43.19 N42:37:43.19 ); since SCASM does not support multiple latitude ranges; the range has been set to the minimum/maximum latitude.; LatRange information in the BGL file is given as comment.; If you want to use band separation, you must edit; the source file manually.; Insert the "Set( FSVers 0x800 )" instruction at the beginning; of the file, if you want to use the FS2002 instructions; for the facilities sectionmif( [$Version < 285] ) Error( You need at least SCASM version 2.85 to compile this code )mifend; ----------------------------------------; Procedural scenery; ----------------------------------------; LatRange( N42:37:32.72 N42:37:49.31 ); ----------------------------------------; ----------------------------------------; Object # 1, offset: 0x000A size: 87 bytes (0x0057) ;; Lat: 000484943h Lon: 0C0FEE47Fh; ----------------------------------------Area( A N42:37:43.19 W088:35:59.40 100 ) PerspectiveCall( :L000021 ) ShadowCall( :L000021 ) Jump( : ):L000021 RefPoint( rel :L00005F 0.50 N42:37:43.20 W088:35:59.40 V1= 0 V2= 19 ) RotatedCall( :L00004B 0 0 45 ):L00004B CallLibObj( 0 C545A271 11D2E2EC 1000849C 2AE60C5A ):L00005F ReturnEndA; sorted list of objects; N42:37:43.19 W088:35:59.40 Object # 1; ----------------------------------------; end of SCASM sourceIn BGLC, the code is :data_base:; DATABASE HEADER dw 1 ; world set number dd 000484943h ; North Bound dd 000484943h ; South Bound dd 0C0FEE480h ; East Bound dd 0C0FEE480h ; West Bound dd 0 ; 18 VOR data dw 0 ; 22 lowest VOR freq dw 0 ; 24 highest VOR freq dd 0,0,0,0,0,0 ; 26 (MUST be 0) dd 0 ; 50 minimum safe altitude data dd 0 ; 54 new terrain data dd object_data - data_base ; 58 object data dd 0 ; 62 library data dd 0 ; 66 facilities data dd 0 ; 70 (MUST be 0) dd 0 ; 74 (MUST be 0) dd 0 ; 78 ADF data dd 0 ; 82 dynamic data dd 0,0 ; 86 minimum library id dd 0,0 ; 94 maximum library id dd 0 ; 102 misc data ( ground alt db) dd 0 ; 106 title and description data dd 0 ; 110 magnetic variation data dd 0 ; 114 exception and exclusion data dd 0 ; 118 magic number dd 0 ; 122 spare2 dw 0 ; 126 spare3; --------------------------------------------------------------object_data: rel_base: LATBAND_REL 02424h, 02425h, object_1 LATBAND_END; --------------------------------------------------------------object_1: NEAR_FAR_SMALL_OBJECT_HEADER 000484943h, 0C0FEE47Fh, object_1_end, 100 ADDOBJ object_1_body SHADOW_CALL object_1_body JUMP object_1_end object_1_body: SCALE_AGL object_1_ret, 0, 19, 000020000h, 000484943h, 068C5h, 0C0FEE47Fh, 001A0h, 000000000h, 00000h INSTANCE_CALL object_1_lib,00000h, 00000h, 02000h object_1_lib: BGL_LIBRARY_CALL 0C545A271h, 011D2E2ECh, 01000849Ch, 02AE60C5Ah object_1_ret: BGL_RETURNobject_1_end: ; --------------------------------------------------------------EOLThis BGLC code produces an identical BGL to the BGLPlacer-derived CSV code. The only thing unusual here, is the absence of the return code that the SDK ( and Gerrish Grey ) indicates that should follow the INSTANCE_CALL. Note that the decompiled SCASM code also doesn't have this return, so I would expect it acts exactly as the BGLPlacer or BGLC code. Again, it makes no difference what language is used to place the object... they all produce identical code.Dick

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

CFS1 contains an object placer within the sim. Here's an example of the code produced. I've cleaned it up a little so it will compile with our latest BGLC, and changed the GUID and location so it compares to the Radar tower in the previous post:scenery_data label byte; Database Header ****************** dw 1 ; 00 World set ID dd 000484943h ; 02 north bounds (NSEW bounds) dd 000484943h ; 06 south bound dd 0C0FEE480h ; 10 east bound dd 0C0FEE480h ; 14 west bound dd 0 ; 18 VOR_DATA dw 0 ; 22 lowest vor freq (channel 0-199 dw 0 ; 24 highest vor freq (108.00-117.95 dd 0 ; 26 seeds level 8 dd 0 ; 30 seeds level 9 dd 0 ; 34 seeds level 10 dd 0 ; 38 seeds level 11 dd 0 ; 42 seeds level 12 dd 0 ; 46 seeds level 13 dd 0 ; 50 seeds level 14 dd 0 ; 54 seeds level 15 dd object_data - scenery_data ; 58 Object Data dd 0 ; 62 Library Data dd 0 ; 66 Facilities Data dd 0 ; 70 Anchor Point Data dd 0 ; 74 Com Radio Data dd 0 ; 78 Adf Data dd 0 ; 82 Dynamic Object Paths dd 000000000h, 000000000h ; 86 Library id min dd 000000000h, 000000000h ; 94 Library id max dd 0 ; 102 Misc Data (ground alt db) dd 0 ; 106 Title and Description Data dd 0 ; 110 Magvar dd 0 ; 114 Exception List PTR dd 0 ; 118 Magic Number dd 0 ; 122 dw 0 ; 126object_data label BGLCODE rel_base = object_dataLATBAND_REL 02424h, 02425h, band_0 EOLband_0 label BGLCODE NEAR_FAR_SMALL_OBJECT_HEADER 000484943h, 0C0FEE47Fh, object_0_end BGL_CRASH_INDIRECT 0, object_0_79, object_0_35, object_0_67 SHADOW_CALL object_0_35 ADDOBJ object_0_33 JUMP object_0_101object_0_33 label BGLCODE BGLobject_0_35 label BGLCODE SCALE_AGL object_0_77, 0, 60, 000020000h, 000484943h, 068C5h, 0C0FEE47Fh, 001A0h, 000000000h, 00000hobject_0_67 label BGLCODE INSTANCE_CALL object_0_79,00000h,00000h,02000hobject_0_77 label BGLCODE BGL_RETURNobject_0_79 label BGLCODE BGL_LIBRARY_CALL 0C545A271h, 011D2E2ECh, 01000849Ch, 02AE60C5Ahobject_0_101 label BGLCODEobject_0_end label BGLCODE EOLI'm not sure what the command "BGL" means or why it's present:object_0_33 label BGLCODE BGL... also, I suspect the crash detection will slow the sim down, and I wonder if we need that instruction with FS2002.Dick

Share this post


Link to post
Share on other sites

>This BGLC code produces an identical BGL to the >BGLPlacer-derived CSV code. The only thing unusual here, is >the absence of the return code that the SDK ( and Gerrish >Grey ) indicates that should follow the INSTANCE_CALL. >>Note that the decompiled SCASM code also doesn't have this >return, so I would expect it acts exactly as the BGLPlacer >or BGLC code. Again, it makes no difference what language is >used to place the object... they all produce identical code. Hi Dick,If a Return is not inserted following the INSTANCE_CALL, the library object is called twice. Although this is not catastrophic, it is not very useful to frame rates.Regards, Luis

Share this post


Link to post
Share on other sites

Hi Luis.I was not so sure.The INSTANCE_CALL can be omitted... then the object defaults to zero x,y,z positioning.I thought, if INSTANCE_CALL were some type of subroutine, it would require a return, but I believed it was there to simply pass the x,y,z parameters, as the program flow should jump to the library call.Here's some interesting code:; ===============================data_base:; DATABASE HEADER dw 1 ; world set number dd 000484943h ; North Bound dd 000484943h ; South Bound dd 0C0FEE480h ; East Bound dd 0C0FEE480h ; West Bound dd 0 ; 18 VOR data dw 0 ; 22 lowest VOR freq dw 0 ; 24 highest VOR freq dd 0,0,0,0,0,0 ; 26 (MUST be 0) dd 0 ; 50 minimum safe altitude data dd 0 ; 54 new terrain data dd object_data - data_base ; 58 object data dd 0 ; 62 library data dd 0 ; 66 facilities data dd 0 ; 70 (MUST be 0) dd 0 ; 74 (MUST be 0) dd 0 ; 78 ADF data dd 0 ; 82 dynamic data dd 0,0 ; 86 minimum library id dd 0,0 ; 94 maximum library id dd 0 ; 102 misc data ( ground alt db) dd 0 ; 106 title and description data dd 0 ; 110 magnetic variation data dd 0 ; 114 exception and exclusion data dd 0 ; 118 magic number dd 0 ; 122 spare2 dw 0 ; 126 spare3; dd 0,0,0,0 ; 128 GUID; dd 0 ; 144 product id; dd 0 ; 148 product build number; dd 0 ; 152 new facility data pointers; dd 0 ; 156 new facility name list data; dd 0 ; 160 new facility band list data; dd 0 ; 164 new facility data; --------------------------------------------------------------object_data:rel_base = object_data LATBAND_START LATBAND_REL 02424h, 02425h, object_1 LATBAND_END; --------------------------------------------------------------object_1: NEAR_FAR_SMALL_OBJECT_HEADER 000484943h, 0C0FEE47Fh, object_1_end, 100 ADDOBJ object_1_body SHADOW_CALL object_1_body JUMP object_1_end object_1_body: SCALE_AGL object_1_ret, 0, 19, 000020000h, 000484943h, 068C5h, 0C0FEE47Fh, 001A0h, 000000000h, 00000h INSTANCE_CALL object_2_lib,00000h, 00000h, 02000h object_2_lib: BGL_LIBRARY_CALL 0C545A28Dh,011D2E2ECh,01000849Ch,02AE60C5Ah; noaa white antenna object_1_lib: BGL_LIBRARY_CALL 0C545A271h, 011D2E2ECh, 01000849Ch, 02AE60C5Ah; radar tower object_3_lib: BGL_LIBRARY_CALL 07328626Dh,011D30380h,01000859Ch,02AE60C5Ah; port crane object_1_ret: BGL_RETURNobject_1_end: ; --------------------------------------------------------------EOL; ===============================I'm using 3 library calls. All 3 objects are displayed, in cascading order. In this case they all get the rotation. Now with this:; ===============================data_base:; DATABASE HEADER dw 1 ; world set number dd 000484943h ; North Bound dd 000484943h ; South Bound dd 0C0FEE480h ; East Bound dd 0C0FEE480h ; West Bound dd 0 ; 18 VOR data dw 0 ; 22 lowest VOR freq dw 0 ; 24 highest VOR freq dd 0,0,0,0,0,0 ; 26 (MUST be 0) dd 0 ; 50 minimum safe altitude data dd 0 ; 54 new terrain data dd object_data - data_base ; 58 object data dd 0 ; 62 library data dd 0 ; 66 facilities data dd 0 ; 70 (MUST be 0) dd 0 ; 74 (MUST be 0) dd 0 ; 78 ADF data dd 0 ; 82 dynamic data dd 0,0 ; 86 minimum library id dd 0,0 ; 94 maximum library id dd 0 ; 102 misc data ( ground alt db) dd 0 ; 106 title and description data dd 0 ; 110 magnetic variation data dd 0 ; 114 exception and exclusion data dd 0 ; 118 magic number dd 0 ; 122 spare2 dw 0 ; 126 spare3; dd 0,0,0,0 ; 128 GUID; dd 0 ; 144 product id; dd 0 ; 148 product build number; dd 0 ; 152 new facility data pointers; dd 0 ; 156 new facility name list data; dd 0 ; 160 new facility band list data; dd 0 ; 164 new facility data; --------------------------------------------------------------object_data:rel_base = object_data LATBAND_START LATBAND_REL 02424h, 02425h, object_1 LATBAND_END; --------------------------------------------------------------object_1: NEAR_FAR_SMALL_OBJECT_HEADER 000484943h, 0C0FEE47Fh, object_1_end, 100 ADDOBJ object_1_body SHADOW_CALL object_1_body JUMP object_1_end object_1_body: SCALE_AGL object_1_ret, 0, 19, 000020000h, 000484943h, 068C5h, 0C0FEE47Fh, 001A0h, 000000000h, 00000h INSTANCE_CALL object_3_lib,00000h, 00000h, 02000h object_2_lib: BGL_LIBRARY_CALL 0C545A28Dh,011D2E2ECh,01000849Ch,02AE60C5Ah; noaa white antenna object_1_lib: BGL_LIBRARY_CALL 0C545A271h, 011D2E2ECh, 01000849Ch, 02AE60C5Ah; radar tower object_3_lib: BGL_LIBRARY_CALL 07328626Dh,011D30380h,01000859Ch,02AE60C5Ah; port crane object_1_ret: BGL_RETURNobject_1_end: ; --------------------------------------------------------------EOL; ===============================... object_2 ( the port crane ) is called and rotated, and then all the objects are called ( without rotation ).So you are absolutly right, the objects are called until a RETURN is encountered, with BGLPlacer giving us redundant double placements. A return should be required after the INSTANCE_CALL.Here's some odd code:; --------------------------------------------------------------object_1: NEAR_FAR_SMALL_OBJECT_HEADER 000484943h, 0C0FEE47Fh, object_1_end, 100 ADDOBJ object_1_body SHADOW_CALL object_1_body JUMP object_1_end object_1_body: SCALE_AGL object_1_ret, 0, 19, 000020000h, 000484943h, 068C5h, 0C0FEE47Fh, 001A0h, 000000000h, 00000h INSTANCE_CALL object_1_lib,00000h, 00000h, 02000h BGL_RETURN object_2_lib: BGL_LIBRARY_CALL 0C545A28Dh,011D2E2ECh,01000849Ch,02AE60C5Ah; noaa white antenna object_1_lib: BGL_LIBRARY_CALL 0C545A271h, 011D2E2ECh, 01000849Ch, 02AE60C5Ah; radar tower object_3_lib: BGL_LIBRARY_CALL 07328626Dh,011D30380h,01000859Ch,02AE60C5Ah; port crane object_1_ret: BGL_RETURNobject_1_end: ; --------------------------------------------------------------...now the radar tower and the port crane are called, but the noaa antenna is bypassed!With this, only the selected object is called, once:; --------------------------------------------------------------object_1: NEAR_FAR_SMALL_OBJECT_HEADER 000484943h, 0C0FEE47Fh, object_1_end, 100 ADDOBJ object_1_body SHADOW_CALL object_1_body JUMP object_1_end object_1_body: SCALE_AGL object_1_ret, 0, 19, 000020000h, 000484943h, 068C5h, 0C0FEE47Fh, 001A0h, 000000000h, 00000h INSTANCE_CALL object_1_lib,00000h, 00000h, 02000h BGL_RETURN object_2_lib: BGL_LIBRARY_CALL 0C545A28Dh,011D2E2ECh,01000849Ch,02AE60C5Ah; noaa white antenna BGL_RETURN object_1_lib: BGL_LIBRARY_CALL 0C545A271h, 011D2E2ECh, 01000849Ch, 02AE60C5Ah; radar tower BGL_RETURN object_3_lib: BGL_LIBRARY_CALL 07328626Dh,011D30380h,01000859Ch,02AE60C5Ah; port crane object_1_ret: BGL_RETURNobject_1_end: ; --------------------------------------------------------------The INSTANCE_CALL displays the correct object, is returned to that part of the ML sequence, and then returned to the above SHADOW_CALL ( loops again ) and then the JUMP instruction. Your analysis is exactly right.So ideally, a BGL_RETURN will immediately follow both the INSTANCE_CALL, and the BGL_LIBRARY_CALL. ( the final BGL_RETURN works for the port crane, now ).The BGLPlacer method will actually double the calls to the library objects. When calling a lot of objects ( like Gerrish's trees ), it could make the difference in framerates.Of course this now has me wondering about BGLPlacer and what it does with effects.--------------------The "BGL" instruction in the CFS1 code example, is an older 'legacy' code. It currently does no harm, but really should not be used, as the code is no longer supported... allowed switching from LOGOL to BGL in older sims.Dick

Share this post


Link to post
Share on other sites

>The "BGL" instruction in the CFS1 code example, is an older >'legacy' code. It currently does no harm, but really should >not be used, as the code is no longer supported... allowed >switching from LOGOL to BGL in older sims. Hi Dick,I am giving up that "BGL" instruction. It corresponds to Perspective in SCASM words. Here is a typical SCASM source sequence:Area()PerspectiveCall( :pcall )ShadowCall( :scall )Jump( :endA ):pcallPerspective <<<< the "BGL":scallRefPoint()Now (after the recent discussion in this forum) I will use:Area()PerspectiveCall( :call )ShadowCall( :call )Jump( :endA ):callRefPoint()It has been said that Perspective was mandatory before a Refpoint for the sorting order mechanism (based on the distance between the viewer and the object) in FS to work properly.Regards, Luisps: it is indeed very strange that "duplicated" call with the MS tool!

Share this post


Link to post
Share on other sites

Hi Luis.I'm wondering if this is the most compact Library call in SCASM:

Header( 1  N42:37:43.19 N42:37:43.19 W088:35:59.40 W088:35:59.40 )LatRange(  N42:37:43.19  N42:37:43.19 )Area( A N42:37:43.19 W088:35:59.40 100 )	PerspectiveCall( :_object_1_body )	ShadowCall( :_object_1_body )	Jump( :EndA ):_object_1_body	RefPoint( rel :_object_1_ret  0.50 N42:37:43.20 W088:35:59.40 V1= 0 V2= 19 )	RotatedCall( :_object_1_lib   0   0  45 ):_object_1_ret	Return:_object_1_lib	CallLibObj( 0 C545A271 11D2E2EC 1000849C 2AE60C5A )EndA

This saves a 'Return' after the 'CallLibObj', as I think it's not needed now.In BGLC:

; ===============================data_base:; DATABASE HEADER	dw	1	; world set number	dd	000484943h; North Bound	dd	000484943h; South Bound	dd	0C0FEE480h; East Bound	dd	0C0FEE480h; West Bound	dd	10 dup(0)	dd	object_data - data_base	dw	33 dup(0); --------------------------------------------------------------object_data:rel_base = object_data	LATBAND_REL 02424h, 02425h, object_1	EOL; --------------------------------------------------------------object_1:	NEAR_FAR_SMALL_OBJECT_HEADER	000484943h, 0C0FEE47Fh, object_1_end, 100	ADDOBJ		object_1_body	SHADOW_CALL	object_1_body	JUMP		object_1_end	object_1_body:		SCALE_AGL	object_1_ret, 0, 19, 000020000h, 000484943h, 068C5h, 0C0FEE47Fh, 001A0h, 000000000h, 00000h		INSTANCE_CALL	object_1_lib,00000h, 00000h, 02000h	object_1_ret:		BGL_RETURN	object_1_lib:		BGL_LIBRARY_CALL 0C545A271h, 011D2E2ECh, 01000849Ch, 02AE60C5Ahobject_1_end:	; --------------------------------------------------------------EOL; ===============================

Dick

Share this post


Link to post
Share on other sites

...why not just use FSRegen and place it as an api with accuracy?Shez

Share this post


Link to post
Share on other sites

Hi Shez.It doesn't seem like an API, as I understand them, is usually needed for placing library objects. That seems like a very unnecessary step.The object, and it's textures, are already created and available to the sim through it's own library BGL. All we need to do is place it. The accuracy is the same. It doesn't take much SCASM or ASM code to do that.The whole point of using an object from a library BGL is to save time, memory, HD space.Perhaps I'm misunderstanding just what it is you are proposing with fsregen. I have seen API's that just call library objects, like Gerrish Gray's Tree library. Thes API's are macros which can reduce the tedium of placing multiple objects in a single scenery ( like making a forest of trees ). But the actual objects exist in a library BGL, and do not need to be recreated for each instance. Most API's actually contain the object code, and have no library object to call. That's fine for the placement of a unique object. But if that object were used over dozens of BGLs, that means a redundancy of dozens of object redefinitions, as well as placing them. A library BGL allows you to define the object once, then call it as many times as you like in as many separate BGLs as you wish... with no redefinition of the code... just it's placing and orientation.That's why I started a thread on Library object placement, not API object placement.-------------Perhaps you need the API to place the library object with Airport or Groundmaker...In that case, this thread still has some significance, as we recently found errors in the Architect-derived code for placing objects, and perhaps errors of this type may be found in Airport, or GroundMaker as well. BGLC certainly has an error concerning CSV-placed objects ( BGLPlacer ), as I discovered today. That error is not in BGLPlacer, but in BGLC 8.0 itself.So what is learned here, can be used to check, correct or refine your SCASM or BGLC code produced by those GUI programs.Dick

Share this post


Link to post
Share on other sites

Dear Dick,I think that there are (could be) 2 problems if you do not use a Return after the CallLib:1) Unless EndA resets the "return address from subroutine buffer" FS could crash. Definitively, this was a problem with FS98: I had such errors with FS98. With FS2000 and FS2002 I never tried such a situation. If you tried this code and FS2002 did not crash, then I realize that FS2002 is more robust to "design errors" than previous versions.2) You are not allowing ShadowCall() to run!Kind regards, LuisPS: I note, with pleasure, that you are using SCASM > >

 >Header( 1  N42:37:43.19 N42:37:43.19 W088:35:59.40 >W088:35:59.40 ) >LatRange(  N42:37:43.19  N42:37:43.19 ) >>Area( A N42:37:43.19 W088:35:59.40 100 ) > PerspectiveCall( :_object_1_body ) > ShadowCall( :_object_1_body ) > Jump( :EndA ) >:_object_1_body > RefPoint( rel :_object_1_ret  0.50 N42:37:43.20 >W088:35:59.40 V1= 0 V2= 19 ) > RotatedCall( :_object_1_lib   0   0  45 ) >:_object_1_ret > Return >:_object_1_lib > CallLibObj( 0 C545A271 11D2E2EC 1000849C 2AE60C5A ) >EndA >

> >>This saves a 'Return' after the 'CallLibObj', as I think >it's not needed now.

Share this post


Link to post
Share on other sites

Hi Luis.No, there is a shadow! The BGLC code is identical, and the shadow is there as well. Not a big deal, as an 'extra' Return would simply never be called.But it is strange, as it should not return to make the shadow. When I delete the ShadowCall, the shadow does not appear, so it is getting called.----------------I think I see what happens. When the code flows to the 'EndA', it generates an error, and that error then uses the Return referenced in 'RefPoint( rel :_object_1_ret 0.50 N42:37:43.20 >W088:35:59.40 V1= 0 V2= 19 )'... that kicks the flow back to pick up the ShadowCall. The next time it is rescued by the error protection in RefPoint, it retuns to the JUMP, and ends the BGL.It is bad coding, and the return should be included after 'CallLibObj'.Dick

Share this post


Link to post
Share on other sites

FSRegen will make a Library asm file for you which you can use to generate a library bgl through BGLC. This is now your Library bgl which can be accessed as many times as you want. The api created by FSRegen is a very simple CallObjLib macro with no effect on performance etc. and is a great tool to accurately place any individual object from the Library bgl (I use Airport). Would this not be as effective a way of doing the task you are aiming to achieve? Maybe I am talking about something else...RegardsShez

Share this post


Link to post
Share on other sites

I do think the Return is necessairy, otherwise you don't jump back from the sub you call.This was one of the reason why Michel noticed a very low framerate in another thread going on lately.So I think the ideal code would be:Header( 1 N42:37:43.19 N42:37:43.19 W088:35:59.40 W088:35:59.40 )LatRange( N42:37:43.19 N42:37:43.19 )Area( 4 N42:37:43.19 W088:35:59.40 100 )PerspectiveCall( :_object_1_body )ShadowCall( :_object_1_body )Jump( :EndA ):_object_1_bodyRefPoint( rel :_object_1_ret 0.50 N42:37:43.20 W088:35:59.40 V1= 0 V2= 19 )RotatedCall( :_object_1_lib 0 0 45 )Return:_object_1_ret Return:_object_1_libCallLibObj( 0 C545A271 11D2E2EC 1000849C 2AE60C5A )ReturnEndANote I have also used Area type 4 as Gerrish has suggested in the other discussion.Arno


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

Share this post


Link to post
Share on other sites

>Gmax apparently also produces an ASM object in >Library format, and a placement ASM. What makes you think this? I think that the GMax code doesn't use a library. They just include the second _0.asm file that contains the actual object into the first one that places the object. But the object is not called from a library, it's just part of the Area block.Arno


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

Share this post


Link to post
Share on other sites

Hi Arno.I am not that familiar with Gmax... but I now understand why fsregen is needed to create a library BGL for Gmax objects. And then Shez is right about the need for some type of calling macro ( API ) so these libraries could be used from Airport, GroundMaker, etc. Otherwise, designers would need to learn SCASM or BGLC to place the objects. I was a bit disturbed by the thread that pointed out a mistake in the Architect coding, and that was the motivation for this thread... and the basic coding needed to place objects. That code referenced a "failsafe" return in the RefPoint code, that apparently did not exist, and that should have crashed the sim. I agree your code example is the best way, although I'm not sure that Area type 4 has any advantage over type A. By using Returns after the RotatedCall, and the CallLibObj, the failsafe is never used.-----------------Refering to Claviateur's code:; -----------------------------------------------------------------------------; MACRO: R18 G/SArea( b 33:50:7.753636 35:29:20.333310 20 )RefPoint( rel :noObj 0.500000 33:50:7.753636 35:29:20.333310 v1= 37040 v2= 32767 )RotatedCall( :rot 0 0 0.00 )Jump( : ):rotCallLibObj( 0 C545A270 11D2E2EC 1000849C 2AE60C5A )EndA; -----------------------------------------------------------------------------It could have read:; -----------------------------------------------------------------------------; MACRO: R18 G/SArea( 4 33:50:7.753636 35:29:20.333310 20 )RefPoint( rel :noObj 0.500000 33:50:7.753636 35:29:20.333310 v1= 37040 v2= 100 )RotatedCall( :rot 0 0 0.00 )Jump( : ):rotCallLibObj( 0 C545A270 11D2E2EC 1000849C 2AE60C5A ):noObjReturnEndA; -----------------------------------------------------------------------------... with that, all should have been well, as it adds the "failsafe" return, and the code flow Return, all in one ( though it does not check for scenery density, as Gerrish pointed out ). I'm noting his code has no shadow, so I am curious how the Architect code would add that call. I'm also curious about how Architect adds the Library calls to it's code... apparently it doesn't use an API macro, but generates the code from user input? Otherwise, Michel could have used a different API, and Architect would not be at fault. Strange they would not have noticed the error.Dick

Share this post


Link to post
Share on other sites

> although I'm not >sure that Area type 4 has any advantage over type A.Gerrish pointed out that a type 4 Area uses less memory then type A and therefore should be better for the frames. The downside of type 4 is that the Area size is not allowed to be big (so only a simple library call will fit, most objects will be to big to fit). I haven't tested this yet, but it sounds logical. Although I don't think that the difference with type A will be that big for most sceneries.>... with that, all should have been well, as it adds the >"failsafe" return, and the code flow Return, all in one.I like this version, even more compact :).> I'm >noting his code has no shadow, so I am curious how the >Architect code would add that call. I'm also curious about >how Architect adds the Library calls to it's code... I think that means that library objects placed with Archtitect never have a shadow (can any Architect user confirm this?).I also wonder how the objects are added, if it was a Macro the errors in it could easily be removed, but I don't have Architect so I can't investigate further.Of course users of Architect can still use a simple calling macro that calls the same object number and thereby prevent the coding errors (and get a shadow).Arno


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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

>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]

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

>[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]

Share this post


Link to post
Share on other sites

>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]

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this